[Gdal-dev] ogr2ogr, postgis, s57 & enforce_dims_wkb_geometry

[Frank Warmerdam]

On Tue, 8 Feb 2005 12:11:54 +0100, Tore Halset <halset at pvv.ntnu.no> wrote:
> Hello.
> 
> I have installed the following on my mac with Mac OS X 10.3.7:
> postgresql-8.0.1
> postgis-1.0.0-rc2
> gdal-1.2.5
> 
> I am trying to load a single S-57 cell into the database, but the first
> insert fails.
> LOG:  statement: INSERT INTO "airare" (wkb_geometry , "rcid", "prim",
> "grup", "objl", "rver", "agen", "fidn", "fids", "lnam", "catair",
> "scamin") VALUES (GeometryFromText('POINT (15.47197780
> 78.24509130)'::TEXT,1) , 684, 1, 2, 2, 1, 340, 1334049, 50002,
> '015400145B21C352', '2', 270000)
> ERROR:  new row for relation "airare" violates check constraint
> "enforce_dims_wkb_geometry"
> 
> This is the same error with another cell:
> LOG:  statement: INSERT INTO "achare" (wkb_geometry , "rcid", "prim",
> "grup", "objl", "rver", "agen", "fidn", "fids", "lnam", "catach",
> "status", "scamin") VALUES (GeometryFromText('POINT (16.82046390
> 77.82454520)'::TEXT,1) , 476, 1, 2, 4, 1, 340, 953081, 50004,
> '0154000E8AF9C354', '1', '3', 360000)
> ERROR:  new row for relation "achare" violates check constraint
> "enforce_dims_wkb_geometry"
> 
> The enforce_dims_wkb_geometry constraint are equal in airare and achare:
>      "enforce_dims_wkb_geometry" CHECK (ndims(wkb_geometry) = 3)
> 
> Anyone knows how this can be fixed?

Tore, 

As I read this, PostGIS is now requiring a 0.0 Z coordinate on the
WKT for geometries inserted in a 3D geometry column.  Is that right?

If so, this is quite annoying.  Currently the OGRGeometry class
freely produces (x,y) style WKT if the Z coordinate is zero. In fact, 
internally it doesn't even carry around a dimension.  It just checks
for non-zero Z values.  While this can be construed as a failure of
OGR, I am not convinced that particularly tight rules were ever 
available for 3D geometries in the simple features model since the
simple features model was originally 2D only. 

However, none of that necessarily matters to you.  You just want to
load some data into PostGIS.  That temporary workaround is to 
dump your data to a shapefile with ogr2ogr and then use the PostGIS
shapefile loader to load it.  However, as with the tiger->shapefile 
problem earlier today, you will find you need to use -skipfailures and
will lose a few esoteric attributes if you go via shapefile. 

The long term solution may mean I need to really keep track of
dimension in OGR or at least somehow hack the PostGIS driver
to force geometries to match the dimension of the table. 

You might also find that you can reload the PostGIS SQL with
this constraint removed.  I have had some success with this
approach in the past. 

I would appreciate it if you could submit a bugzilla bug against
OGR on this issue. 

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent