Purpose of LatLngPoly and LatLngMultiPoly, and the potential for geometry methods.

[nojimatakashi55]

I'm digging through the codebase and trying to understand the purpose of LatLngPoly and LatLngMultiPoly.

They seem to be data containers for lat/lng polygons (with holes, in the case of LatLngPoly).
But they don’t perform any geometry operations themselves, no .contains(), .intersects(), etc.

• Are they mainly meant to wrap polygon data for use with polyfill() or similar?
• Are there any plans to add geometry methods in the future? Or to rely on external libraries like Shapely? If so, those geometry methods should be relatively easy to implement.

Appreciate any insight! I want to try to get a clearer picture of how these are meant to be used.

[ajfriend]

You're right that the intention is for them to be lightweight containers to provide an input structure for functions like h3shape_to_cells() and an output structure for functions like cells_to_h3shape(). They're designed to roughly align with the C library structs: GeoPolygon and GeoMultiPolygon (source).

We had also seen recurring issues around confusion between lat/lng ordering (what H3 uses) and lng/lat ordering (what GeoJSON, Shapely, GeoPandas use). Hopefully these classes make that expectation explicit.

That being said, we also wanted these objects to be broadly compatible with other geospatial Python libraries, so they can convert to and from the standard __geo_interface__: https://gist.github.com/sgillies/2217756 and https://uber.github.io/h3-py/polygon_tutorial.html#id1

For example, you can convert to Shapely to perform geometry operations:

And regarding your questions around .contains() and .intersects(): One of the main attractive trade-offs of H3 is the use of discretization to avoid expensive geometric calculations. What use case were you thinking of for these operations? My expectation is that most use cases could be handled well, either by utilizing the H3 discretization or by composing with compatible libraries like Shapely. But I'm also curious to know if there's anything we're overlooking, so would appreciate any feedback!

[nojimatakashi55]

Thank you for your comment, and I agree that the lightweight nature of LatLngPoly and LatLngMultiPoly is a major advantage.

After reviewing my source code again, I can confirm that in my case, managing data on AWS and using H3 cells as keys in a key-value style data structure (like S3) allows me to efficiently retrieve data associated with each H3 cell.

Here’s a simplified version of my pipeline:

1. Convert Shapely polygons into H3 cells
2. Store data in S3 using the H3 cell as the key
3. Use AWS Lambda (with h3-py as a Layer) to retrieve the data efficiently

With some tuning of data granularity and H3 resolution, the Lambda-backed API typically responds in about 700 milliseconds — performant enough for production use.

In addition, some map applications access data using tile-based polygonal regions in a distributed format.
I’ve also seen that some experimental methods have been introduced that could further streamline this process:

• h3.h3shape_to_cells_experimental
• h3.polygon_to_cells_experimental

I’m currently using my own implementation for polygon-to-cell conversion, but I plan to migrate to these once they’re no longer marked as experimental.

So far, this direction has been the main focus in my use case.
Because the polygon-to-cell conversion is already fast, converting cells back to polygons hasn’t really been part of my workflow.
That said, if working with LatLngPoly and LatLngMultiPoly to generate polygon shapes becomes more practical or streamlined, I’d be happy to brainstorm potential use cases.

Thanks again for your work on h3-py and it’s been incredibly useful for geospatial processing in cloud-native environments like AWS.