Opened 7 years ago
Closed 6 years ago
#411 closed defect (fixed)
Invalid geometries are accepted in DB but no way to take them out
Reported by: | strk | Owned by: | strk |
---|---|---|---|
Priority: | critical | Milestone: | PostGIS 1.4.2 |
Component: | postgis | Version: | 1.4.X |
Keywords: | Cc: |
Description
The attached shapefile contains shapes that are imported in PostGIS with no warning or error, but result in them being stuck in there forever. In particular you can NOT copy them somewhere:
postgis_bugs=# copy poly_molto_critici to '/tmp/out'; ERROR: geometry requires more points
Of course you can't even pg_dump:
postgis_bugs=# select the_geom from poly_molto_critici; ERROR: geometry requires more points
Note that I'm testing this with current trunk, but the original reporter (Regione Toscana) mentioned they are using 1.4.1 so for them to be out of the induced nightmare we'd need a C-only fix and a 1.4.2.
Attachments (1)
Change History (11)
comment:1 Changed 7 years ago by strk
- Owner changed from pramsey to strk
- Status changed from new to assigned
comment:2 Changed 7 years ago by strk
comment:3 Changed 7 years ago by strk
See also ticket #168
comment:4 Changed 7 years ago by strk
comment:5 Changed 7 years ago by strk
Committed in 1.5 branch with r5216.
Regina, time to fire your hard shakers for catching warms out of the can with 1.4, 1.5 and trunk branches
comment:6 Changed 7 years ago by strk
comment:7 Changed 7 years ago by strk
- Resolution set to fixed
- Status changed from assigned to closed
comment:8 Changed 7 years ago by mcayland
- Resolution fixed deleted
- Status changed from closed to reopened
While this allows you to unparse invalid geometries, it is not a fix because you haven't stopped the invalid geometries getting into the database in the first place. Can you take a look at which validity check is failing before closing? Unfortunately the shapefile itself doesn't appear to be attached to the ticket.
Changed 7 years ago by strk
comment:9 Changed 7 years ago by strk
I'm not sure we want to stop invalid geometries getting into the database. We don't do it for self-intersecting rings for example.
In this case the invalidity is a non-closed ring (probably due to FP numbers).
Mind you, with TRUNK st_isvalidreason would now tell you rather than throw an exception. 1.4 and 1.5 will only NOTICE you that.
The table loaded with shp2pgsql have these invalidities: =# select gid, st_isvalidreason(the_geom) from "poly_molto_critici";
gid | st_isvalidreason
1 | IllegalArgumentException?: Invalid number of points in LinearRing? found 3 - must be 0 or >= 4 2 | Self-intersection[1.70103e+06 4.89325e+06] 3 | IllegalArgumentException?: Invalid number of points in LinearRing? found 3 - must be 0 or >= 4 4 | IllegalArgumentException?: Invalid number of points in LinearRing? found 3 - must be 0 or >= 4 5 | IllegalArgumentException?: Invalid number of points in LinearRing? found 3 - must be 0 or >= 4 6 | IllegalArgumentException?: Invalid number of points in LinearRing? found 3 - must be 0 or >= 4 7 | IllegalArgumentException?: Invalid number of points in LinearRing? found 3 - must be 0 or >= 4 8 | IllegalArgumentException?: Invalid number of points in LinearRing? found 3 - must be 0 or >= 4 9 | IllegalArgumentException?: Invalid number of points in LinearRing? found 3 - must be 0 or >= 4
10 | IllegalArgumentException?: Invalid number of points in LinearRing? found 3 - must be 0 or >= 4 11 | IllegalArgumentException?: Invalid number of points in LinearRing? found 3 - must be 0 or >= 4 12 | IllegalArgumentException?: Invalid number of points in LinearRing? found 3 - must be 0 or >= 4
(12 rows)
Note gid number 2, and how the whole thing looks more consistent now ... :P
comment:10 Changed 6 years ago by pramsey
- Resolution set to fixed
- Status changed from reopened to closed
My proposal here is to unparse with PARSER_CHECK_NONE within all output routines. Won't touch input ones, it's fine to me to check there (beside, in this case the input routines are not even checking given the shapefile is imported...)