Opened 15 years ago
Closed 13 years ago
#492 closed defect (wontfix)
WKT and WKB parsers behaving differently about input validation
Reported by: | martijnm | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 1.4.3 |
Component: | postgis | Version: | 1.4.X |
Keywords: | Cc: |
Description
Today we ran into some unexpected behaviour of the shp2pgsql loader.
We tried loading a shapefile (which had a polygon which did not close its exterior ring). I find it strange that putting a switch (or not putting it), gives two different results (successfully loaded in one, and unsuccessful load in the other).
When loading without -w switch, it happily loads the data into the database:
$ shp2pgsql -S -d -g geometry open.shp bug_open|psql -d gisbase Shapefile type: Polygon Postgis type: POLYGON[2] Password: SET ERROR: column not found in geometry_columns table CONTEXT: SQL statement "SELECT DropGeometryColumn('', $1 , $2 , $3 )" PL/pgSQL function "dropgeometrycolumn" line 4 at SQL statement ERROR: table "bug_open" does not exist BEGIN NOTICE: CREATE TABLE will create implicit sequence "bug_open_gid_seq" for serial column "bug_open.gid" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "bug_open_pkey" for table "bug_open" CREATE TABLE addgeometrycolumn -------------------------------------------------------- martijn.bug_open.geometry SRID:-1 TYPE:POLYGON DIMS:2 (1 row) INSERT 0 1 COMMIT
After loading, all kinds of errors start popping up (correct!):
$ psql -d gisbase Password: psql (8.4.2) Type "help" for help. gisbase=# select st_isvalid(geometry) from bug_open; NOTICE: IllegalArgumentException: Points of LinearRing do not form a closed linestring st_isvalid ------------ f (1 row) gisbase=# select st_issimple(geometry) from bug_open; NOTICE: IllegalArgumentException: Points of LinearRing do not form a closed linestring ERROR: POSTGIS2GEOS conversion failed gisbase=#
But sometimes also with unexpected results:
gisbase=# select st_pointn(geometry,1) from bug_open; st_pointn ----------- (1 row)
When running with -w switch the WKT parser stops the import (which is correct imho):
$ shp2pgsql -w -S -d -g geometry open.shp bug_open|psql -d gisbase Shapefile type: Polygon Postgis type: POLYGON[2] Password: SET dropgeometrycolumn ------------------------------------------------ martijn.bug_open.geometry effectively removed. (1 row) DROP TABLE BEGIN NOTICE: CREATE TABLE will create implicit sequence "bug_open_gid_seq" for serial column "bug_open.gid" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "bug_open_pkey" for table "bug_open" CREATE TABLE addgeometrycolumn -------------------------------------------------------- martijn.bug_open.geometry SRID:-1 TYPE:POLYGON DIMS:2 (1 row) ERROR: geometry requires more points HINT: "POLYGON((0 1,1 0,0 0))" <-- parse error at position 22 within geometry CONTEXT: SQL function "geomfromtext" statement 1 ROLLBACK
Tested with shp2pgsql:
RCSID: $Id: shp2pgsql.c 4867 2009-11-20 12:02:29Z mcayland $ RELEASE: 1.4 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
With the database running on a separate machine (sun, 64-bit):
select postgis_full_version(); postgis_full_version ---------------------------------------------------------------------------------------- POSTGIS="1.4.1" GEOS="3.2.0-CAPI-1.6.0" PROJ="Rel. 4.7.1, 23 September 2009" USE_STATS
Attachments (3)
Change History (6)
by , 15 years ago
by , 15 years ago
by , 15 years ago
comment:1 by , 15 years ago
Milestone: | → PostGIS 1.4.3 |
---|
comment:2 by , 14 years ago
Summary: | shp2pgsql behaving differently with -w and without → WKT and WKB parsers behaving differently about input validation |
---|
comment:3 by , 13 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
We're just resigned at this point to having different input validation on the older versions.
Weird bug. It is normal that a switch changes the behavior. The behaviour you're seeing is exactly the expected one (for the loader part).
Instead, you may argue that the postgis parsers (WKB end WKT) behave differently. For me, it is the WKB parser acting the correct way, as you can always check for validity after import.