Closed SkybuckFlying closed 1 year ago
We only use this in one place in the runtime code, which is to find the closest face of the icosahedron to a given point. The primary consideration here is performance, so there's no need to scale the vector, and we don't have any requirement to do the reverse operation.
Long story short, I would consider _geoToVec3d
to be an internal implementation detail (hence the underscored name), and not intended for more general use. You should use whatever lat/lng to XYZ conversion works for your use case.
We only use this in one place in the runtime code, which is to find the closest face of the icosahedron to a given point. The primary consideration here is performance, so there's no need to scale the vector, and we don't have any requirement to do the reverse operation.
Long story short, I would consider
_geoToVec3d
to be an internal implementation detail (hence the underscored name), and not intended for more general use. You should use whatever lat/lng to XYZ conversion works for your use case.
There must be more to it... once the closest face is found it must then find in which hexagon it lies at different/deeper resolutions.
Here the H3 library seems to rotate the hexagons as it goes deeper, back and forth 19.x degrees... ultimately somehow it calculate resolution 15 to be as close around the point as possible I would assume.
So is my assumption correct that the given lat/long will lie perfectly within the deepest resolution 15 hexagon ? Or is H3 only trying to approximate it and is it possible that the lat/long lies outside of the resolution 15 hexagon ?
That's not actually how the H3 indexing system works. There's a detailed description of the algorithm in the docs. Essentially:
The lat/lng values are almost perfectly within the hexagons (in some edges cases they're subject to FPE, but in general if you test a lat/lng against the boundary of a cell modeled as a spherical polygon, the point will be within the shape of the hexagon it indexes to).
I see a lot of different conversion formulas and values, I tried a few, but they seem slightly off from where H3 thinks the lat, long should be for a certain X,Y,Z.
There is _GeoToVec3d in H3 library to convert from lat, long to x,y,z but what would be the opposite function/formula ?
What I am currently using is:
I find it strange how _geoToVec3d is different from this above link:
Why is this ?
Also the output of _geoToVec3d is normalized ? and must be multiplied with 6.371 to get something resembling the center of the H3 index/hexagon, but still not perfect...
Here you can see slight inaccuracies, not sure what is causing it, I suspect conversion trouble or maybe it's something else:
https://youtu.be/eqntfB5Y7K4