Invalid geometries are accepted in DB but no way to take them out

[strk]

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.

[strk]

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...)

[strk]

See also ticket #168

[strk]

Committed in trunk with r5215 Committed in 1.4 branch with r5215 ... next should come 1.5 branch ...

[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

[strk]

Sorry for confusion (I'm still not used to SVN really).

The changesets are:

- Trunk: r5214 - 1.4 branch: r5215 - 1.5 branch: r5216

[mcayland]

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.

[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