uber
Coordinates input validation
Hello,
We're using the h3_pg postgres bindings and together with @trylinka found that we're spending quite a bit of time debugging the same kind of issue: we've got a point table in spherical mercator coordinates in metres, we want to bin it using H3, we do it and get some garbage as an output. Fix is to convert the input into longitude-latitude degrees, but finding the spot takes some time, together with time for understanding that the output is garbage.
A simple way to avoid this will be to check the ranges for latitude and longitude on the input. @trylinka provided a PR with the check for h3_pg (https://github.com/bytesandbrains/h3-pg/pull/41), but as I see @zachasme does not want to diverge from the core H3 library too much in the behavior, which leads to this ticket.
It seems it will be beneficial to others to have a kind of input validation. As I see in #287 there was some effort to make all the values work somehow. I will say that I have not seen the real long-lat dataset that has values outside [-180,-90,180,90] box. On a safe side, even a check on latitude being in -90..90 will save some hours debugging.
Will such a PR be welcome (-90..90 latitude validation, or a stricter check), or is there a higher ideological reason to keep things as they are?
We've been handling out of bounds geos with a "best guess", mainly in order to handle points near the anti-meridian where a user wants to use numbers that fall out of range, such as >180 I think there are some other concerns here, especially about this not catching a lot of common error cases (where the coordinates are the wrong system but are valid, or lat/lng are swapped), and about the core library being very liberal in what it accepts (since we are somewhat removed from the application logic.)
Might there be a way for the binding to know what coordinate system the points are in and validate that?
It looks like the pull request on h3-pg was merged so you should be able to use the flag added there going forward.
