Hello WS users,
The DMC has released a new version (2.0.2) of the IRIS WS library:
http://www.iris.edu/dms/nodes/dmc/software/downloads/iris-ws/2-0-2/
The release now defaults to using IRIS services from the service.iris.edu host instead of the deprecated locations. We also took the opportunity to rework how the XML is parsed and introduced some new features and fixed a few bugs; please refer to the revision page for a list of all bug fixes: http://www.iris.edu/dms/nodes/dmc/software/downloads/IRIS-WS/2-0-2/revisions/
Users of irisFetch (MATLAB) should download the newest version of irisFetch at http://www.iris.edu/media/software/irisfetch.m/2-0-1/irisFetch.m to mitigate an existing irisFetch 2.0.0 bug that was exposed by the new library. Another email will provide additional details regarding the irisFetch 2.0.1 update.
This release should be backwards compatible with all other request tools.
regards,
IRIS DMC web services team
-
Hello,
The European High Schools are using directly the IRIS DMC Web Services
for data hosted at IRIS and local implementations of a subset of these
services for other data.
One local tool we have developed uses an iris type availability ws to
check for data available around the origin time of an earthquake for a
list of networks/stations. The old iris availability service
(deprecated) returns a compact response (even in XML!) for such a
request, e.g.
http://www.iris.edu/ws/availability/query?&starttime=2013-01-01T00:00:00&endtime=2013-01-01T01:00:00&sta=CMB&cha=BHZ&output=xml
<StaMessage><Source>IRIS-DMC</Source><SentDate>2013-07-03T07:31:57</SentDate><Station
net_code="BK"
sta_code="CMB"><Lat>38.03455</Lat><Lon>-120.38651</Lon><Elevation>697.0</Elevation><Channel
chan_code="BHZ" loc_code="00">
<Availability><Extent start="2013-01-01T00:00:00"
end="2013-01-01T01:00:00"/></Availability>
</Channel></Station></StaMessage>
while the replacement , e.g.
service.iris.edu/fdsnws/station/1/query?starttime=2013-01-01T00:00:00&endtime=2013-01-01T01:00:00&sta=CMB&cha=BHZ&level=channel&includeavailability=true
returns a monster response (attached!) including:
<DataAvailability><Extent start="2010-12-17T19:52:43"
end="2013-07-02T12:00:00"/></DataAvailability>
Note that besides the huge size of the response (we need to make
multiple requests for a list of stations), the <DataAvailability><Extent
in the two responses are different - the first confirms a data window
within our requested time span (exactly the response we want), while the
second seems to present to total time of data available, which we would
have to further process to confirm that our time window of interest is
available.
Is all of the above behaviour and the differences between the two
responses correct? Is there any way or any plans to get the more
compact, old-style availability response?
Thanks,
Best regards to all,
Anthony
--
Sent from my iClayTablet
------------------------------------------------------------------------
*Anthony Lomax*
*161 Allée du Micocoulier, 06370 Mouans-Sartoux, France*
*tel: +33 (0)4 93 75 25 02 e-mail: anthony<at>alomax.net
<anthony<at>alomax.net> web: http://www.alomax.net
http://www.alomax.net/ *
*Science & Special Topics: * *http://www.alomax.net/science*
*Software: * *http://www.alomax.net/software* *- updates: *
*https://twitter.com/ALomaxNet*
------------------------------------------------------------------------
-
Hi Anthony,
In the background the same "extent" (earliest and latest data) information is used by both services, the availability service simply trims it down to your request time window. It is important to note that this does not mean that time series are guaranteed to exist in that window (there could be gaps that are not represented in our quick-to-query extent information). We are looking towards being able to provide more granular data coverage information, it is a challenging problem.
If you only want to match your request window to the availability times our fdsnws-station service will already do that for you. The matchtimeseries parameter limits results to channels where the availability intersects with your starttime and endtime selection. In short, add matchtimeseries=true to your request and you do not need to do your own availability checking.
Regarding the response size, unless you really like XML or need the details included in that format you might consider using the text output (format=text) which is much more compact and easily parsed:
http://service.iris.edu/fdsnws/station/1/query?starttime=2013-01-01T00:00:00&endtime=2013-01-01T01:00:00&sta=CMB&cha=BHZ&level=channel&matchtimeseries=true&format=text
best regards,
Chad
On Jul 3, 2013, at 12:46 AM, Anthony Lomax <alomax<at>free.fr> wrote:
Hello,
The European High Schools are using directly the IRIS DMC Web Services for data hosted at IRIS and local implementations of a subset of these services for other data.
One local tool we have developed uses an iris type availability ws to check for data available around the origin time of an earthquake for a list of networks/stations. The old iris availability service (deprecated) returns a compact response (even in XML!) for such a request, e.g.
http://www.iris.edu/ws/availability/query?&starttime=2013-01-01T00:00:00&endtime=2013-01-01T01:00:00&sta=CMB&cha=BHZ&output=xml
<StaMessage><Source>IRIS-DMC</Source><SentDate>2013-07-03T07:31:57</SentDate><Station net_code="BK" sta_code="CMB"><Lat>38.03455</Lat><Lon>-120.38651</Lon><Elevation>697.0</Elevation><Channel chan_code="BHZ" loc_code="00">
<Availability><Extent start="2013-01-01T00:00:00" end="2013-01-01T01:00:00"/></Availability>
</Channel></Station></StaMessage>
while the replacement , e.g.
service.iris.edu/fdsnws/station/1/query?starttime=2013-01-01T00:00:00&endtime=2013-01-01T01:00:00&sta=CMB&cha=BHZ&level=channel&includeavailability=true
returns a monster response (attached!) including:
<DataAvailability><Extent start="2010-12-17T19:52:43" end="2013-07-02T12:00:00"/></DataAvailability>
Note that besides the huge size of the response (we need to make multiple requests for a list of stations), the <DataAvailability><Extent in the two responses are different - the first confirms a data window within our requested time span (exactly the response we want), while the second seems to present to total time of data available, which we would have to further process to confirm that our time window of interest is available.
Is all of the above behaviour and the differences between the two responses correct? Is there any way or any plans to get the more compact, old-style availability response?
Thanks,
Best regards to all,
Anthony
--
Sent from my iClayTablet
Anthony Lomax
161 Allée du Micocoulier, 06370 Mouans-Sartoux, France
tel: +33 (0)4 93 75 25 02 e-mail: anthony<at>alomax.net web: http://www.alomax.net
Science & Special Topics: http://www.alomax.net/science
Software: http://www.alomax.net/software - updates: https://twitter.com/ALomaxNet
<fdsnws-station_2013-07-03T07_33_01.xml>_______________________________________________
webservices mailing list
webservices<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/webservices
-
Hi Chad,
Thanks for the tips. I think we can work with the new service with the
fdsnws/station*matchtimeseries* parameter and text format, I will check
when I continue developments after a vacation next week...
We are using text output already, but in our schools availability web
service this returns exactly the query parameters one needs to make a
subsequent timeseries request, for example:
http://namazu.unice.fr/ws/availability/query?&starttime=2013-02-01T10:09:49&endtime=2013-02-03T10:09:49&sta=CIVF&cha=BH*
the reply to which allows easy construction of:
http://namazu.unice.fr/ws/timeseries/query?&sta=CIVF&cha=BHZ&start=2013-02-02T11:34:00.000&end=2013-02-02T11:34:00.000&output=plot
I am not sure if we will continue with this behaviour since it is not
standard IRIS WS, but maybe keep it as an additional output type, e.g.
output=tsquery, when we roll our availability service into fdsnws/station.
Thanks,
Anthony
On 2013/07/03 18:51, Chad Trabant wrote:
Hi Anthony,
--
In the background the same "extent" (earliest and latest data)
information is used by both services, the availability service simply
trims it down to your request time window. It is important to note
that this does not mean that time series are guaranteed to exist in
that window (there could be gaps that are not represented in our
quick-to-query extent information). We are looking towards being able
to provide more granular data coverage information, it is a
challenging problem.
If you only want to match your request window to the availability
times our fdsnws-station service will already do that for you. The
*matchtimeseries* parameter limits results to channels where the
availability intersects with your starttime and endtime selection. In
short, add matchtimeseries=true to your request and you do not need to
do your own availability checking.
Regarding the response size, unless you really like XML or need the
details included in that format you might consider using the text
output (format=text) which is much more compact and easily parsed:
http://service.iris.edu/fdsnws/station/1/query?starttime=2013-01-01T00:00:00&endtime=2013-01-01T01:00:00&sta=CMB&cha=BHZ&level=channel&matchtimeseries=true&format=text
best regards,
Chad
On Jul 3, 2013, at 12:46 AM, Anthony Lomax <alomax<at>free.fr
<alomax<at>free.fr>> wrote:
Hello,
_______________________________________________
The European High Schools are using directly the IRIS DMC Web
Services for data hosted at IRIS and local implementations of a
subset of these services for other data.
One local tool we have developed uses an iris type availability ws to
check for data available around the origin time of an earthquake for
a list of networks/stations. The old iris availability service
(deprecated) returns a compact response (even in XML!) for such a
request, e.g.
http://www.iris.edu/ws/availability/query?&starttime=2013-01-01T00:00:00&endtime=2013-01-01T01:00:00&sta=CMB&cha=BHZ&output=xml
<StaMessage><Source>IRIS-DMC</Source><SentDate>2013-07-03T07:31:57</SentDate><Station
net_code="BK"
sta_code="CMB"><Lat>38.03455</Lat><Lon>-120.38651</Lon><Elevation>697.0</Elevation><Channel
chan_code="BHZ" loc_code="00">
<Availability><Extent start="2013-01-01T00:00:00"
end="2013-01-01T01:00:00"/></Availability>
</Channel></Station></StaMessage>
while the replacement , e.g.
service.iris.edu/fdsnws/station/1/query?starttime=2013-01-01T00:00:00&endtime=2013-01-01T01:00:00&sta=CMB&cha=BHZ&level=channel&includeavailability=true
http://service.iris.edu/fdsnws/station/1/query?starttime=2013-01-01T00:00:00&endtime=2013-01-01T01:00:00&sta=CMB&cha=BHZ&level=channel&includeavailability=true
returns a monster response (attached!) including:
<DataAvailability><Extent start="2010-12-17T19:52:43"
end="2013-07-02T12:00:00"/></DataAvailability>
Note that besides the huge size of the response (we need to make
multiple requests for a list of stations), the
<DataAvailability><Extent in the two responses are different - the
first confirms a data window within our requested time span (exactly
the response we want), while the second seems to present to total
time of data available, which we would have to further process to
confirm that our time window of interest is available.
Is all of the above behaviour and the differences between the two
responses correct? Is there any way or any plans to get the more
compact, old-style availability response?
Thanks,
Best regards to all,
Anthony
--
Sent from my iClayTablet
------------------------------------------------------------------------
*Anthony Lomax*
*161 Allée du Micocoulier, 06370 Mouans-Sartoux, France*
*tel: +33 (0)4 93 75 25 02 e-mail: anthony<at>alomax.net
<anthony<at>alomax.net> web: http://www.alomax.net
http://www.alomax.net/ *
*Science & Special Topics: * *http://www.alomax.net/science*
*Software: * *http://www.alomax.net/software* *- updates: *
*https://twitter.com/ALomaxNet*
------------------------------------------------------------------------
<fdsnws-station_2013-07-03T07_33_01.xml>_______________________________________________
webservices mailing list
webservices<at>iris.washington.edu <webservices<at>iris.washington.edu>
http://www.iris.washington.edu/mailman/listinfo/webservices
webservices mailing list
webservices<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/webservices
Sent from my iClayTablet
------------------------------------------------------------------------
*Anthony Lomax*
*161 Allée du Micocoulier, 06370 Mouans-Sartoux, France*
*tel: +33 (0)4 93 75 25 02 e-mail: anthony<at>alomax.net
<anthony<at>alomax.net> web: http://www.alomax.net
http://www.alomax.net/ *
*Science & Special Topics: * *http://www.alomax.net/science*
*Software: * *http://www.alomax.net/software* *- updates: *
*https://twitter.com/ALomaxNet*
------------------------------------------------------------------------
-
-