Issues for bbox covering 180° longitude

[FuhuXia]

For a given bbox, when it covers 180° longitude line, as shown in the attached image, I can see there might be two issues in map displaying and spatial solr querying.

Map display:
If a spatial data contains polygon as [[[170, 60], [-170, 60], [-170, 70], [170, 70], [170, 60]]], instead of mapping it as it should be in the attached image with 20° wide longitude, it actually maps it the other way around the global with a 340° wide longitude box, equivalent to this map http://demo.ckan.org/dataset?ext_bbox=170,60,-170,70

Spatial query:
When plotting the bbox covering 180° longitude line on the map and send spatial query to solr, the mapping code is actually converting the one of the longitude to value larger than 180 or less then -180, depending on where the line is drawn on the map. So the bbox is displayed correctly on the map, but the actual spatial query is asking for wrong data. For example, for bbox in the attached image, the actual bbox values used is -190(instead of 170), 60, -170, 70. For the part of -190 to -180, solr is not going to return any meaningful data. In this case, a combined query of 170, 60, 180, 70 and -180, 60, -170, 70 will make more sense, and get correct data from solr.

[FuhuXia]

We did two commits to address first map display issue.
GSA@f5ad7a6
GSA@d3840fe
A pull request can be submitted upon exam and confirmation.

[amercader]

Hi @FuhuXia, sorry about the late reply.

The patch for the first issue looks good, can you send a PR?

As for the second issue with the spatial search, this might require a bit more of investigation. My gut feeling is that there should be a way to handle date line crossing queries in Solr without having to separate the bbox in two. Perhaps playing with what gets indexed or the way the query is sent.

This presentation (slide 44) seems to suggest that date line crossing should be supported on this particular query format so maybe we can explore this route.

[amercader]

@FuhuXia I've pushed a patch to deal with the second issue with the dateline crossing search (efc8b6c). Can you check if latest master solves it for you?