International Federation of Digital Seismograph Networks

Thread: queries that cross the date line

None
Started: 2017-08-09 04:24:42
Last activity: 2017-08-18 14:29:31
Philip Crotwell
2017-08-09 04:24:42
Hi all

The FDSNWS spec is a little unclear on how to deal with queries that
cross the date line. On one hand, the spec does clearly say that
longitude must be -180 to 180, which would seem to mean that a query
with maxlon < minlon should mean that the box goes the other way
around the world. On the other hand, data centers try to catch user
mistakes and provide useful feedback, so maxlon < minlon might
indicate an error. However, in that case the service probably has to
allow longitude to be -360 to 360 in order to have a query that can
cross the date line.

An example query that succeeds to IRIS and one that fails to the USGS are below:

https://service.iris.edu/fdsnws/event/1/query?endtime=2000-01-08T00:00:00.000&maxlatitude=75.0&maxlongitude=-130.0&minlatitude=50.0&minlongitude=170.0&minmagnitude=5.0&orderby=time-asc&starttime=2000-01-01T00:00:00.000&nodata=404

https://earthquake.usgs.gov/fdsnws/event/1/query?endtime=2000-01-08T00:00:00.000&maxlatitude=75.0&maxlongitude=-130.0&minlatitude=50.0&minlongitude=170.0&minmagnitude=5.0&orderby=time-asc&starttime=2000-01-01T00:00:00.000&nodata=404

Currently for event services I found that USGS, NCEDC and ISC give an
error while IRIS, ETHZ, SCEDC and INGV allow maxlon < minlon, although
some of these do not have any events in that part of the world so it
is a little hard to tell if they are interpreting it correctly. I have
not tested the station services.

I do not have strong feelings about which way it is done, but I do
feel VERY strongly that it should be consistent across all fdsnws
event and station web services. Otherwise writing clients that query
more than one service becomes painful.

If I had to pick, I think I would prefer sticking with the -180 to 180
longitude range and add something to the spec to explain how maxlon <
minlon should be interpreted.

thanks
Philip

  • Chad Trabant
    2017-08-15 18:43:12

    Hi Philip and all,

    I also do not have a particularly strong option on how it is solved, but agree that it needs clarification and consistent implementation. From a practical standpoint it may be easiest to leave the range -180 to 180 as suggested and further define the minlat/maxlat/minlon/maxlon as southern/northern/eastern/western boundaries of the selection.

    Chad

    On Aug 9, 2017, at 3:26 AM, Philip Crotwell <crotwell<at>seis.sc.edu> wrote:

    Hi all

    The FDSNWS spec is a little unclear on how to deal with queries that
    cross the date line. On one hand, the spec does clearly say that
    longitude must be -180 to 180, which would seem to mean that a query
    with maxlon < minlon should mean that the box goes the other way
    around the world. On the other hand, data centers try to catch user
    mistakes and provide useful feedback, so maxlon < minlon might
    indicate an error. However, in that case the service probably has to
    allow longitude to be -360 to 360 in order to have a query that can
    cross the date line.

    An example query that succeeds to IRIS and one that fails to the USGS are below:

    https://service.iris.edu/fdsnws/event/1/query?endtime=2000-01-08T00:00:00.000&maxlatitude=75.0&maxlongitude=-130.0&minlatitude=50.0&minlongitude=170.0&minmagnitude=5.0&orderby=time-asc&starttime=2000-01-01T00:00:00.000&nodata=404

    https://earthquake.usgs.gov/fdsnws/event/1/query?endtime=2000-01-08T00:00:00.000&maxlatitude=75.0&maxlongitude=-130.0&minlatitude=50.0&minlongitude=170.0&minmagnitude=5.0&orderby=time-asc&starttime=2000-01-01T00:00:00.000&nodata=404

    Currently for event services I found that USGS, NCEDC and ISC give an
    error while IRIS, ETHZ, SCEDC and INGV allow maxlon < minlon, although
    some of these do not have any events in that part of the world so it
    is a little hard to tell if they are interpreting it correctly. I have
    not tested the station services.

    I do not have strong feelings about which way it is done, but I do
    feel VERY strongly that it should be consistent across all fdsnws
    event and station web services. Otherwise writing clients that query
    more than one service becomes painful.

    If I had to pick, I think I would prefer sticking with the -180 to 180
    longitude range and add something to the spec to explain how maxlon <
    minlon should be interpreted.

    thanks
    Philip

    ----------------------
    FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

    Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
    Update subscription preferences at http://www.fdsn.org/account/profile/


  • Philipp Kästli
    2017-08-18 14:29:31
    Hi all,

    to me it seems that the current specification is actually pretty clear:

    look at table 4/5 of http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.1.pdf
    :
    "minlongitude: Limit to stations/events with a longitude larger than or equal to the specified minimum."
    "Maxlongitude: maxlongitude: Limit to stations/events with a longitude smaller than or equal to the specified maximum."

    It refers to minimum and maximum values of longitude, not to easternmost and westernmost selection limits. (IMHO this is adequate: If you would interpret maxLongitude as easternmost, on a globe, the concept of easternmostness, even of more or less eastern, is dubious, as it strongly depends on how far you are ready to go).
    As a result, in an implementation compliant to the current FDSN standard, a query with minimum longitude larger than maximum longitude should return nothing, and "rectangular" (whatever this means on a globe) selection crossing the date line needs to be decomposed in two requests.

    While this may be considered a deficit at first, it should also be seen in the light of rectangular and circular being very limited anyway (obvious e.g. if you try to retrieve the earthquakes of Algeria, or Pakistan, or the US west coast from FDSN services).

    Kind regards,

    Philipp




    -----Original Message-----
    From: fdsn-wg3-products-bounce<at>lists.fdsn.org [mailto:fdsn-wg3-products-
    bounce<at>lists.fdsn.org] On Behalf Of Philip Crotwell
    Sent: Mittwoch, 9. August 2017 03:26
    To: FDSN Working Group III
    Subject: [fdsn-wg3-products] queries that cross the date line

    Hi all

    The FDSNWS spec is a little unclear on how to deal with queries that cross the
    date line. On one hand, the spec does clearly say that longitude must be -180
    to 180, which would seem to mean that a query with maxlon < minlon should
    mean that the box goes the other way around the world. On the other hand,
    data centers try to catch user mistakes and provide useful feedback, so
    maxlon < minlon might indicate an error. However, in that case the service
    probably has to allow longitude to be -360 to 360 in order to have a query
    that can cross the date line.

    An example query that succeeds to IRIS and one that fails to the USGS are
    below:

    https://service.iris.edu/fdsnws/event/1/query?endtime=2000-01-
    08T00:00:00.000&maxlatitude=75.0&maxlongitude=-
    130.0&minlatitude=50.0&minlongitude=170.0&minmagnitude=5.0&orderby=
    time-asc&starttime=2000-01-01T00:00:00.000&nodata=404

    https://earthquake.usgs.gov/fdsnws/event/1/query?endtime=2000-01-
    08T00:00:00.000&maxlatitude=75.0&maxlongitude=-
    130.0&minlatitude=50.0&minlongitude=170.0&minmagnitude=5.0&orderby=
    time-asc&starttime=2000-01-01T00:00:00.000&nodata=404

    Currently for event services I found that USGS, NCEDC and ISC give an error
    while IRIS, ETHZ, SCEDC and INGV allow maxlon < minlon, although some of
    these do not have any events in that part of the world so it is a little hard to
    tell if they are interpreting it correctly. I have not tested the station services.

    I do not have strong feelings about which way it is done, but I do feel VERY
    strongly that it should be consistent across all fdsnws event and station web
    services. Otherwise writing clients that query more than one service
    becomes painful.

    If I had to pick, I think I would prefer sticking with the -180 to 180 longitude
    range and add something to the spec to explain how maxlon < minlon should
    be interpreted.

    thanks
    Philip

    ----------------------
    FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-
    wg3-products/)

    Sent from the FDSN Message Center (http://www.fdsn.org/message-
    center/)
    Update subscription preferences at http://www.fdsn.org/account/profile/