Handling Dateline crossing bounding box

[ferrighi]

We need to find some formal approach to support records with dateline crossing. Currently we do specify what approach we handle, but we do say for the bounding box:

• west: The westernmost point covered by the dataset.
• east: The easternmost point covered by the dataset.

Our schema does not restrict the values of W and E, nor compares them to validate that E > W.
However, our services around MMD assume that the values are between -180/180 and that the order is E>W.

There are at least 2 possibilities to approach this:

1. allow for both -180/180 and 0/360 to be valid values for longitude values. This would mean that for a dataset spanning -20/+20 around the line we would have: W=160, E=200
2. follow the convention that if a record crosses the dateline, then E < W. This would mean that for a dataset spanning -20/+20 around the line we would have: W=160, E=-160

I've read some background info about this:

"East longitude values can be reported 0 <= X <= 360 or -180 <= X <= 180. Some applications will fail under one or the other of these conventions. Recommendation is to use -180 <= X <= 180, consistent with the WKT specification. Following this recommendation, bounding boxes that cross the antimeridian at ±180° longitude, the West longitude value will be numerically greater than the East longitude value." (from SOSO)

Another suggested alternative would be to define two bounding boxes, one on each side of 180. (i.e. for the example above -160/180 and -180/200). But it would be more complex I think, as our geolocation is not multivalue for now.

In any case we would need to support proper parsing from external records, as we might encounter different approaches implemented.

[ferrighi]

@mortenwh @steingod any view or experience on what is the most common way to approach this?

ISO/inspire: If the bounding box crosses the 180 meridian, then the value of the westBoundLongitude will be greater than the eastBoundLongitude value.

DIF is also only using -180/180

[ferrighi]

@magnarem it would be good to have an comment from your side of what solution would be easier to handle from visualisation and solr searches as well.