Inconsistent / unclear handling of SRIDs

[rustprooflabs]

Thank you for your work on this extension!

I was working on an updated post for the v4 API and found error that led me down this path. I found an inconsistency with how SRIDs are handled, and ultimately am left with questions about what I should expect as an end user. The only place I can find a mention of projections related to H3 is a generic mention on this page. I can submit a PR with details once I understand them better.

What led me here was this query with h3_polygon_to_cells() using data in SRID 3857.

SELECT h3_polygon_to_cells(geom, 4)
    FROM osm.place_polygon
    WHERE name = 'Seattle'
;

This raises the error:

ERROR:  error code: 1
HINT:  https://h3geo.org/docs/library/errors#table-of-error-codes
CONTEXT:  SQL function "h3_polygon_to_cells" statement 1

I love that the error links to documentation for error codes. Unfortunately, the description for error code 1 is "The operation failed but a more specific error is not available."

The fix was transforming to SRID 4326.

SELECT h3_polygon_to_cells(ST_Transform(geom, 4326), 4)
    FROM osm.place_polygon
    WHERE name = 'Seattle'
;

┌─────────────────────┐
│ h3_polygon_to_cells │
╞═════════════════════╡
│ 8428d55ffffffff     │
└─────────────────────┘

The inconsistency I noticed is that passing SRID 3857 data to h3_lat_lng_to_cell() function does not raise an error. Instead it returns an incorrect value of an index in the ocean west of Portugal.

SELECT h3_lat_lng_to_cell(ST_Centroid(geom), 4)
    FROM osm.place_polygon
    WHERE name = 'Seattle'
;

┌────────────────────┐
│ h3_lat_lng_to_cell │
╞════════════════════╡
│ 84352b5ffffffff    │
└────────────────────┘

From a small amount of testing, it appears things work properly if the data is in an SRID with units in Decimal Degrees, but will not work if the data's SRID uses units in meters or feet.

Questions

Can the error from h3_polygon_to_cells() with geometry in an invalid SRID provide a more specific error? I had a hard time determining the cause, even though I had previously documented that data needed to be in SRID 4326, not 3857.

What should the end user expect in terms of support for SRIDs from the h3-pg extension? Is it accurate to say "any SRID with units in decimal degrees"?

Can behavior be standardized to raise errors with invalid SRIDs? I prefer failing to run over sending back bad data.

[zachasme]

Hi @rustprooflabs, and thank you for the detailed report!

This could definitely be handled better: Currently, I am assuming SRID 4326 (because H3 core is expecting it) and blindly passing x and y components to the core H3 library. That means the error codes you are seeing is what I am receiving from H3 core.

I prefer your suggestion of handling it in the extension. Either raising or transforming on wrong SRIDs.

I'd gladly accept a PR doing either. Otherwise I'll post here when I start work on it myself.

Cheers!

[rustprooflabs]

C is not one of the languages I've been successful in. A PR for some documentation is the best I can do in this realm. :smile:

[zachasme]

No problem, thank you for the PR, I'll get around to doing proper error handling on this in the future.