Bounding box validity around the antimeridian

[ianthetechie]

It looks like shapely will "assume" a few things about geometries, so our current implementation writes an invalid bbox for Fiji.

The GeoParquet spec states that we should use the same rules as GeoJSON for bounding boxes, specifically calling out the antimeridian edge case. The GeoJSON RFC describes this here: https://datatracker.ietf.org/doc/html/rfc7946#section-5.2.

In experimenting with the antimeridian library, it seems to fix these cases.

Original bounding box (spans the entire globe longitudinally, which is not very helpful):

{'xmin': -180.0, 'ymin': -21.943428, 'xmax': 180.0, 'ymax': -12.261387}

Corrected bounding box (starts west of the antimeridian):

{'xmin': 176.72958, 'ymin': -21.943428, 'xmax': -178.0035, 'ymax': -12.261387}

[jake-low]

Great catch. I knew that Shapely's length and area functions are planar, but I forgot / didn't consider that bounding boxes are also planar and thus not correct (per the GeoJSON spec) for features that cross the antimeridian.

Happy to merge a PR that fixes this. The library you linked looks like a good choice; it uses a heuristic to detect antimeridian-crossing features, but this heuristic (looking for segments that span > 180 degrees longitude) should work for every feature in OSM.

[ianthetechie]

Yup! I think I have a fix for this but just haven't gotten around to properly testing it. I'll report back early next week once I have a chance.

[ianthetechie]

A quick update on this... I found some cases where it's clearly wrong with data from other sources with (well documented) non-standard geojoson geometries, but so far I haven't noticed it being as bad of an issue with OSM. So we'd be swapping something with known failure modes for something with unknown failure modes.

I'm going to have to revisit this in a few weeks. Curious if anyone else has ideas in the meantime.