queries that cross the date line
Philip Crotwell
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:
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
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
> ----------------------
> 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/
Florian Haslinger
seems a fun little braintwister… apart from a convention translating min/max to ‘southern/northern’ and ‘western/eastern’ (not eastern/western… ) boundaries of the box, one would also have to introduce a convention in which direction to draw the box. (? maybe I am just too confused…)
In principle, one should not exclude that a user wants to wrap the box e.g. from 10E to 40E but around the ‘back’ - i.e. drawing from 10E to the west…
In that case, the convention should be to specify minlon 40 and maxlon 10
perhaps that’s already implemented?
Just thinking… how do we define bounding boxes around the poles? (It’s just too easy to draw ‘rectangles’ on flat maps…)
rambling on a tuesday afternoon….
cheers,
Florian
ps - googling that problem doesn’t produce obvious answers / conventions, I would have thought that OGC would have addressed it already, but perhaps I just didn’t look deep enough (they do address the antimeridian case, somewhat: http://cite.opengeospatial.org/OGCTestData/wms/1.1.1/spec/wms1.1.1.html#basic_elements.params.bbox )
Philipp Kästli
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