queries that cross date line

[crotwell]

As discussed in WGIII mailing list, just creating issue so not forgotten. Also similar issue filed on fdsnws-station

http://www.fdsn.org/message-center/thread/508/

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.

[crotwell]

As alternative that would help clarify the meaning would be to rename the parameters to south, north, west, east instead of minlat, maxlat, minlon, maxlon. Then it is clear that the west parameter is the western boundary of the box even if numerically it is greater than the east (maxlon) parameter.

Letting longitude values be -180 to 360 would also help, ie when crossing the date line, the eastern (maxlon) parameter would be > 180.

A center-radius search is also complicated if it crosses the date line. The spec should document what happens if the max radius is large enough to include the date line, ie lon+maxradius > 180 or lon-maxradius < -180.

[petrrr]

We are looking at details of the specs and encountered a problem related to this issue. In particularly were asking ourselves how to handle request with minlon > maxlon.

We acknowledge the parameter naming is at least unfortunate here, but given the original intention to define a bounding box, the request make sort of sense. There are other details which are not well specified regarding the bounding box.

Some consideration/suggestions:

1. keep the range for the longitude at -180 .. +180. It retains backward compatibility and is cleaner. A range of -360 .. 360, -180 .. 360 would be a bit messy and might add to the confusion. (no change);
2. Going forward we might want to rename (add) parameters which reflect better the real meaning, e.g. bbwest, bbeast, bbsouth, bbnorth (or similar names). Though all this is "optional", it might require a major version bump;
3. Interpret the parameters as defining a bounding box in a general case, minlon assumes the meaning of bbwest, maxlon assumes the meaning of bbeast (doc clarification);

I think most services already implement a wrap around interpretation.
In the current specs these parameters are all optional parameters, so not sure how much clients can rely on any behavior. Probably if single services choose to reply to minlon > maxlon with code 400, the client needs to be able to handle the situation or should not rely on requests with minlon > maxlon.

But any updated spec document probably would clarify the behavior and maybe require some of the functionally currently specified as optional.

[crotwell]

Current status of servers that I know of is that Northern California/NCEDC and USGS/NEIC fail on an event query that crosses the date line. RESIF, INGV, NEIP, NCEDC and SCEDC all fail on similar queries for stations that cross the date line. Some of these may implement the -180 to 360 workaround.

I am fine with any solution, but it would be really really nice if all fdsn station and event web services implemented it in the same way. Trying to do one thing for one server and a different one for another is way too painful for a general client.

[crotwell]

Recommend that FDSN consider adopting the same convention as the bounding box within the GeoJSON spec for dealing with antimeridian and poles.

https://www.rfc-editor.org/rfc/rfc7946#section-5