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.

[jake-low]

A further update: now that #34 has landed, the bbox is computed in DuckDB SQL, not in Python, but the problem remains. The current bbox implementation is:

{
  xmin: ST_XMin(geometry)::FLOAT,
  ymin: ST_YMin(geometry)::FLOAT,
  xmax: ST_XMax(geometry)::FLOAT,
  ymax: ST_YMax(geometry)::FLOAT
} AS bbox,

Which for features that cross the antimeridian (like the nation of Viti / Fiji), creates bounding boxes that are 360 degrees wide (as you can see below) and are not correct according to RFC 7946.

D SELECT bbox
  FROM 'https://data.openstreetmap.us/layercake/boundaries.parquet'
  WHERE name[1] = 'Viti';
┌─────────────────────────────────────────────────────────────────────────┐
│                                  bbox                                   │
│         struct(xmin float, ymin float, xmax float, ymax float)          │
├─────────────────────────────────────────────────────────────────────────┤
│ {'xmin': -180.0, 'ymin': -21.943428, 'xmax': 180.0, 'ymax': -12.261387} │
└─────────────────────────────────────────────────────────────────────────┘

However, DuckDB spatial's ST_Extent() function has the same behavior:

D SELECT ST_Extent(geometry)
  FROM 'https://data.openstreetmap.us/layercake/boundaries.parquet'
  WHERE name[1] = 'Viti';
┌────────────────────────────────────────┐
│          st_extent(geometry)           │
│                 box_2d                 │
├────────────────────────────────────────┤
│ BOX(-180 -21.9434274, 180 -12.2613866) │
└────────────────────────────────────────┘

And there doesn't appear to be a similar function which computes spherical (not planar) bounding boxes. So fixing this may not be easy.

I also think it's worth checking whether common GeoParquet reader implementations (including DuckDB) would behave correctly if the bbox was spherical rather than planar. Changing this would affect the xmin, xmax, ymin, and ymax statistics that end up in the row group headers, which might then affect spatial filtering operations. Even if spherical bboxes are correct according to the spec, if it breaks common GeoParquet readers (returning wrong results or severely reducing spatial filtering performance) then it might be better to stick with the current behavior.