Opened 6 years ago
Closed 16 months ago
#859 closed defect (fixed)
Voronoi issue
Reported by: | jjgreen | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 3.6.6 |
Component: | Default | Version: | 3.5.1 |
Severity: | Unassigned | Keywords: | |
Cc: |
Description
OSGEO Voronoi issue
Further to a posting on the PostGIS mailing list
in February 2018, this directory contains scripts
to generate data for the bug report for OSGEO.
The scripts generating the data can only be used
against a copy of the seadb DB which is not open
source, but the reproduce.sh
script can be used
(with minimal modifications) to reproduce the issue
with the CSV file output from the DB.
For my setup, which is Ubuntu Xenial with PostGIS from apt-postgresql.org and
- POSTGIS="2.3.3 r15473"
- GEOS="3.5.0-CAPI-1.9.0 r4084"
- PROJ="Rel. 4.9.2, 08 September 2015"
- GDAL="GDAL 1.11.3, released 2015/09/16"
- LIBXML="2.9.3"
- LIBJSON="0.11.99" RASTER
the reproduce.sh
script reports
CREATE TABLE COPY 1322 CREATE INDEX ERROR: GEOSVoronoiDiagram: TopologyException: Input
geom 1 is invalid: Self-intersection at or near point 444332.38647522771 8548816.0569835864 at 444332.38647522771 8548816.0569835864
As discussed in the PostGIS forum thread mentioned above, we
find that ST_SnapToGrid
with dyadic grid step fixes the
issue.
The original data for these points was the EuroROSE project, an EU-funded experiment on the feasibility of the use of HF-radar for measuring ocean waves, currents and so on. The experiment took place at Fedje, Norway in early 2000. More details can be found at
http://wera.cen.uni-hamburg.de/EuroROSE/EuroROSE_Intro.shtml
Attachments (2)
Change History (15)
by , 6 years ago
comment:2 by , 6 years ago
Milestone: | 3.7.0 → 3.6.4 |
---|
comment:3 by , 5 years ago
Hi, there was a gridded voronoi robustness fix in #976. Maybe this one is fixed on master too?
comment:4 by , 5 years ago
This problem does appear to be caused by input points which lie on a grid, so this is probably fixed by #976
comment:7 by , 3 years ago
Replying to Paul Ramsey <pramsey@…>:
Curiously, this case blows an exception on PostGIS, but not in the unit test.
The reason the unit test passes is that the triangulation tolerance value (100) is larger than the extent of the input geometry. This causes the data to collapse to a point, which produces an empty Voronoi diagram. If a smaller tolerance (say 0.1) is used then the test fails with a Topo exception.
comment:8 by , 3 years ago
Using DD precision for circumcentre actually fixes this issue. But the isocelese triangle heuristic for performance doesn't work. This is why the unit test fails when it is fixed to use an appropriate tolerance.
comment:9 by , 3 years ago
Verified that the original data on this issue is fixed by using circumcentreDD (with no heuristic).
Note that #976 is testing a subset of this data, which also fails:
0104000080170000000101000080EC51B81E11A20741EC51B81E85A51C415C8FC2F528DC354001010000801F85EB5114A207415C8FC2F585A51C417B14AE47E1BA3540010100008085EB51B818A20741A8C64B3786A51C413E0AD7A3709D35400101000080000000001BA20741FED478E984A51C413E0AD7A3709D3540010100008085EB51B818A20741FED478E984A51C413E0AD7A3709D354001010000800AD7A37016A20741FED478E984A51C413E0AD7A3709D35400101000080000000001BA2074154E3A59B83A51C413E0AD7A3709D3540010100008085EB51B818A2074154E3A59B83A51C413E0AD7A3709D354001010000800AD7A37016A2074154E3A59B83A51C413E0AD7A3709D35400101000080000000001BA20741AAF1D24D82A51C413E0AD7A3709D3540010100008085EB51B818A20741AAF1D24D82A51C413E0AD7A3709D35400101000080F6285C8F12A20741EC51B81E88A51C414160E5D022DB354001010000802222222210A2074152B81EC586A51C414160E5D022DB354001010000804F1BE8B40DA2074152B81EC586A51C414160E5D022DB354001010000807B14AE470BA2074152B81EC586A51C414160E5D022DB354001010000802222222210A20741B81E856B85A51C414160E5D022DB354001010000804F1BE8B40DA20741B81E856B85A51C414160E5D022DB354001010000807B14AE470BA20741B81E856B85A51C414160E5D022DB35400101000080A70D74DA08A20741B81E856B85A51C414160E5D022DB35400101000080D4063A6D06A20741B81E856B85A51C414160E5D022DB354001010000807B14AE470BA207411F85EB1184A51C414160E5D022DB35400101000080A70D74DA08A207411F85EB1184A51C414160E5D022DB35400101000080D4063A6D06A207411F85EB1184A51C414160E5D022DB3540
comment:10 by , 3 years ago
Time to re-test this against master or 3.8 branches (see https://trac.osgeo.org/geos/ticket/976#comment:25)
comment:11 by , 3 years ago
I did run this against master as a C++ unit test (but didn't commit it because data is so large). I can commit it if that seems like a good idea (there is a unit test which is a subset of this data though).
Or, have been thinking about adding ability to run Delaunay and Voronoi as XML tests (should be fairly easy).
comment:13 by , 16 months ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
data points