Opened 4 years ago

Closed 4 years 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:


SELECT * FROM  (SELECT (ST_HexagonGrid(5, '01030000000100000005000000fdffffffff7f66c0fcffffffff7f56c0fdffffffff7f66c07cc0e71a95e8544000000000008066407cc0e71a95e854400000000000806640fcffffffff7f56c0fdffffffff7f66c0fcffffffff7f56c0')).*) sq  WHERE i = 5 AND j IN (0, 1);

Attachments (1)

Screenshot_2020-01-22_22-29-34.png (47.2 KB ) - added by dbaston 4 years ago.

Download all attachments as: .zip

Change History (6)

by dbaston, 4 years ago

comment:1 by Algunenano, 4 years ago

An example that could be used as test based on that:

WITH geoms AS
    SELECT * FROM  (SELECT (ST_HexagonGrid(5, '01030000000100000005000000fdffffffff7f66c0fcffffffff7f56c0fdffffffff7f66c07cc0e71a95e8544000000000008066407cc0e71a95e854400000000000806640fcffffffff7f56c0fdffffffff7f66c0fcffffffff7f56c0')).*) sq  WHERE i = 5 AND j IN (0, 1)
j0 AS
    SELECT * FROM geoms WHERE i = 5 AND j = 0
j1 AS 
    SELECT * FROM geoms WHERE i = 5 AND j = 1
    ST_Intersects(j0.geom, j1.geom),
    ST_AsText(ST_Intersection(j0.geom, j1.geom))
FROM j0,j1;

The current output is:

 st_intersects |                                                   st_astext                                                    
 t             | POLYGON((35 8.66025403784439,40 8.66025403784439,40 8.66025403784439,35 8.66025403784439,35 8.66025403784439))

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.

comment:2 by Algunenano, 4 years ago

I have an improved version in 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 by pramsey, 4 years ago

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 by Algunenano, 4 years ago

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.

comment:5 by Raúl Marín <git@…>, 4 years ago

Resolution: fixed
Status: newclosed

In 95bff56/git:

ST_HexagonGrid: Improve precision

Change the order of the operations so adjacent tiles have the exact
same coordinates

Closes #4627

Note: See TracTickets for help on using tickets.