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)

open.dbf (77 bytes ) - added by martijnm 15 years ago.
open.shp (204 bytes ) - added by martijnm 15 years ago.
open.shx (108 bytes ) - added by martijnm 15 years ago.

Download all attachments as: .zip

Change History (6)

by martijnm, 15 years ago

Attachment: open.dbf added

by martijnm, 15 years ago

Attachment: open.shp added

by martijnm, 15 years ago

Attachment: open.shx added

comment:1 by pramsey, 15 years ago

Milestone: PostGIS 1.4.3

comment:2 by strk, 14 years ago

Summary: shp2pgsql behaving differently with -w and withoutWKT and WKB parsers behaving differently about input validation

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.

comment:3 by pramsey, 13 years ago

Resolution: wontfix
Status: newclosed

We're just resigned at this point to having different input validation on the older versions.

Note: See TracTickets for help on using tickets.