OGR PostGis driver fails to read geometry data with: ERROR 6: Unsupported WKB type 825242416

[lloldrup]

We just discovered a bug in the OGT PostGis reader and our conclusion is that the problem can be triggered if there exists a TABLE (and/or another type) by the name “geometry” in the postgres database.

Findings: The decimal constant 825242416 in the error message equals 31303330 in hexadecimal notation, so it seems that the driver tries to parse the geometry data as binary even though it is in the standard postgres hex encoding.

For example: Executing “SELECT ST_GeomFromText('POLYGON ((100 100, 200 100, 200 200, 100 200, 100 100))', 25832));” in PgAdmin will yield the hex-representation:

“0103000020e864000001000000050000000000000000005940000000000000594000000000000069400000000000005940000000000000694000000000000069400000000000005940000000000000694000000000000059400000000000005940”

We believe that the problem could (in most cases) be fixed by changing the SQL-select for looking up OIDs for geometry-types in ogr/ogrsf_frmts/pg/ogrpgdatasource.cpp from:

“SELECT oid, typname FROM pg_type WHERE typname IN ('geometry', 'geography')”

To:

“SELECT oid, typname FROM pg_type WHERE typname IN ('geometry', 'geography') AND typtype='b'”

The problem will still exist if another BASE TYPE called geometry is created in the database. Assuming that PostGis was installed BEFORE the none PostGis table named “geometry” was added to the database, the metadata select could be further refined by appending it with: “ORDER BY oid LIMIT 2" ;)

[Even Rouault]

In 38593:

PG: do not be confused by a 'geometry' table in a non-PostGIS enabled detabase (patch by lloldrup, fixes #6896)

[Even Rouault]

In 38594:

PG: do not be confused by a 'geometry' table in a non-PostGIS enabled detabase (patch by lloldrup, fixes #6896)