Add format_as_geojson option to cell_to_boundary()

[nojimatakashi55]

Feature Request: Add GeoJSON coordinate order option to cell_to_boundary()

In h3-js, the function cellToBoundary(cell, formatAsGeoJson) allows switching the coordinate order to [lng, lat], which is compliant with the GeoJSON standard.

Similarly, in h3-py v3.x, h3_to_geo_boundary(h, geo_json=True) provided the same capability.

However, in the current version (v4.x), h3-py lacks this option.
The function cell_to_boundary(h) always returns coordinates as (lat, lng) tuples, which requires manual conversion for compatibility with GeoJSON, Shapely, or GeoPandas.

Proposal

Introduce an optional argument to cell_to_boundary():

cell_to_boundary(h, format_as_geojson=False)

When format_as_geojson=True, the function would return (lng, lat) coordinate tuples.

This change would:

• Restore functionality that existed in v3.x
• Improve interoperability with other geospatial tools
• Align the Python API more closely with h3-js.

[ajfriend]

In the short term, the easiest thing to do would be to use one of:

• h3.cells_to_h3shape([c]).__geo_interface__
• h3.cells_to_geo([c])

which provide the lng/lat ordering you're looking for, and compatibility with GeoJSON, Shapely, and GeoPandas:

Thinking beyond that, h3.cell_to_boundary() should probably return a h3.LatLngPoly (as the most ergonomic and flexible output) instead of a tuple of lat/lng pairs, but I missed that in the 4.0 update.

What do you think? Would that be a helpful alternative? We'd have to consider if we want to make that breaking change to the API. cc: @isaacbrodsky @nrabinowitz @dfellis

[nojimatakashi55]

Thanks for the helpful suggestions!

For the short term, I’ll go ahead and use cells_to_h3shape().__geo_interface__ or cells_to_geo() which give me the GeoJSON-compliant ordering.

As for the idea of having cell_to_boundary() return a LatLngPoly,
I think that would be a forward-looking improvement, as it would enable more geometry-like operations and better interoperability with geospatial tools.
Having a richer object with well-defined conversions (e.g. to GeoJSON or Shapely) would definitely enhance flexibility and compatibility.

Either way, I’d be happy to test or provide feedback if the team explores this direction further. Thanks again for considering it!