ogr2ogr: Oracle spatial layer type is not recognized

[sumit321]

Try to convert any point or line layer from oracle spatial to postgis.

They are always converted into polygon type. After some more debugging I found that while opening oracle spatial layer Ogr is not reading its gtype and hence it is always wkbUnknown.

Thus when you create new layer in postgis its type is not persisted correctly. I am using GDAL 1.7.0 and I was able to replicate this bug with 1.7.2 as well. OS is windows 7. Command is ogr2ogr -f "PostgreSQL" PG:"host=192.168.1.87 user=postgres dbname=postgis password=hello123 port=5432" OCI:"mdsys/test@(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.10)(PORT = 1521))(CONNECT_DATA = (SERVICE_NAME = orcl)))" SUMITLINETEST -lco "LAUNDER=YES"

[sumit321]

On further debugging I found that if source layer is from oracle spatial, Ogr never tries to read its data type. Thus when you push data from oracle to ESRI shape files, gType is always wkbUnkown. However while translating features function call of ResetGeomType? fix geometry type of ESRI shape file.

Such handling is missing in case of PostGIS and may in other data formats as well (I am not sure).

[warmerdam]

Sumit,

When creating a layer in postgres with a layer type of wkbUnknown the layer/table should be created as generic geometry (no specific geometry type constraint). You report it is being created as type Polygon, is that right? If so, that is something to fix. I did a quick test and was unable to reproduce such behavior with this command (not the layer created with a layer type of geometry shows up as having no geometry type in ogrinfo):

ogr2ogr -update PG:dbname=warmerda brklinz.shp
ogr2ogr -update -nln xx -nlt geometry PG:dbname=warmerda brklinz.shp
ogrinfo PG:dbname=warmerda
INFO: Open of `PG:dbname=warmerda'
      using driver `PostgreSQL' successful.
1: ax_punktortag (Point)
2: query2
3: brklinz (3D Line String)
4: xx

Note that shapefiles are somewhat special in that we need to have a specific geometry type for them which is why the logic is there to discover a geometry type from the first feature written.

Also, there seems to be a suggestion that we could derive a geometry for the oracle layer from the GType attribute. I'm not sure why that is not done now, but it might be that we cannot be as precise as needed to determine an OGC/OGR geometry type. For instance if GType does not allow us to distinguish between polygons and multipolygons then it can't be used.

[sumit321]

Warmerdam, Geometry type in postGIS is unknown and it is not Polygon. Way around of this could be to use -nlt option. But if you are trying to translate more than one layer then only nlt type you can use is geometry. However If we have geometry type in oracle which is properly defined, this would be a undesired lossy translation.

Rather, OGR should derive geometry for oracle layer and pass it through. Oracle is widely used and have almost all type of commonly used geometry types. OGR should be able to map them.

[warmerdam]

OK, it seems the postgres driver is performing according to expectations. The only question is whether the OCI/Oracle driver is picking up the geometry type when possible.

Add Ivan to the cc: list in case he has time to dig into this at some point.