geoparquet
geoparquet copied to clipboard
opengeospatial
Antimeridian Crossings and bbox
As mentioned in #191 in https://github.com/opengeospatial/geoparquet/pull/191#discussion_r1488344906, geometries that cross the antimeridian will break the current row group filtering mechanics.
e.g if you have a geometry [-10,-10,10,10] and a [170,-10,-170,10] (crossing A-M) in a single row group, then the row group stats are going to be [-10,-10,10,10] and thus the geometry crossing A-M will not be selected.
Our solution is just say antimeridian crossings are unsupported but we can use this thread to discuss solutions.
A potential solution would be to require that for a AM crossing geometry, the bbox.xmin is in the range [0,180], and add +360 to the bbox.xmax so that it is in the range [180,360]. (the x of the geometries themselves could/should still be in the [-180,180] range) So a geometry with bbox [170,-10,-170,10] would be actually indexed as [170,-10,190,10] in the bounding box columns
@kylebarron is that the same as what you suggested in the meeting two weeks ago (adding 360 to the xmax value)?
While that fixes the issue with the "wrong" rowgroup-level xmax value, how does this work for filtering based on the bbox column itself? Assume you are reading with a bbox filter of [-180, -10, -170, 10]. Using simple x/y min/max comparisons for the bbox, such a filter would also not select the row with the A-M crossing, because that bbox now doesn't overlap with [170,-10,190,10]
Assume you are reading with a bbox filter of [-180, -10, -170, 10]. Using simple x/y min/max comparisons for the bbox, such a filter would also not select the row with the A-M crossing, because that bbox now doesn't overlap with [170,-10,190,10]
True, and I'm pretty sure there is no simple/elegant solution as soon as discontinuities are involved :-) So if you spatial filter near the anti-meridian, you need to issue your spatial filter twice: one with longitudes near -180 and another time with them shifted of +360.
The other option would be to step away from GeoJSON's wording using the "most southwesterly point (min) and most northeasterly point (max)" ? And use the actual min/max of the coordinate values instead. For the example we are using, that would give a bbox of something like [-180, -10, 180, 10]. Of course, that spans a big part of the globe, and makes the bbox very not-specific (making this is selected too often). But at least that means that a naive bbox filter would not miss features, and if you want to avoid this too broad bbox values, as a data producer you can still avoid that by not having geometries crossing the A-M in a single row or row group.