Thread: New version of the IRIS Java web services library: 2.0.2

Started: 2013-06-21 00:28:29
Last activity: 2013-07-04 19:17:13
Topics: Web Services

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*
        ------------------------------------------------------------------------

12:28:32 v.01697673