Opened 10 months ago
Closed 10 months ago
#4627 closed defect (fixed)
ST_HexagonGrid produces overlapping hexagons
Reported by: | dbaston | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 3.1.0 |
Component: | postgis | Version: | master |
Keywords: | Cc: |
Description
SELECT * FROM (SELECT (ST_HexagonGrid(5, '01030000000100000005000000fdffffffff7f66c0fcffffffff7f56c0fdffffffff7f66c07cc0e71a95e8544000000000008066407cc0e71a95e854400000000000806640fcffffffff7f56c0fdffffffff7f66c0fcffffffff7f56c0')).*) sq WHERE i = 5 AND j IN (0, 1);
Attachments (1)
Change History (6)
Changed 10 months ago by
Attachment: | Screenshot_2020-01-22_22-29-34.png added |
---|
comment:1 Changed 10 months ago by
comment:2 Changed 10 months ago by
I have an improved version in https://github.com/postgis/postgis/pull/544 but I'm certain it is architecture dependent.
I think that if it doesn't break Windows we could push it to improve the precision between tiles.
comment:3 Changed 10 months ago by
Ug, well an improvement is nice. I fear the only real full-on solution is the one Komzpa put in the old PR: feeding in any pre-existing coordinates to the generation function so they can be re-used... so the HexagonGrid? function would have to carry a bunch of prior state, and the Hexagon function would have to be able to make use of said state. And that would still leave cases where independently generated hexagons from the same tiling space didn't have perfectly matching vertex values.
comment:4 Changed 10 months ago by
I've modified the PR to change how the coordinates are calculated to use something like:
pt.y = origin_u + tile_height * n
N will hopefully more precise value (an integer or an integer.5), but what's more important when changing to a different/adjacent tile it will do the same calculations.
For example cell_j_10 + 0.5 (10.5) should be the same as cell_j_11 - 0.5 (10.5). Technically there could still be some small differences (likely with floating point numbers), which could be solved by using ints (everything multiplied by 2, then at the very end transform it to float and divide it by 2) but I think it's an unlikely scenario.
An example that could be used as test based on that:
The current output is:
When transformed into text, the latitude is the same for all points but probably due to some rounding the binary value will be different, thus the intersection is a polygon and not a point.
I'm not sure how hard this would be to fix.