[Gdal-dev] ogr2ogr dimensionality issue with OCI

[Frank Warmerdam]

Ethan Alpert wrote:
> I’m basically doing the following:
> 
>  
> 
> ogr2ogr -update -append -f "OCI" "OCI:user/pass at host2" 
> "OCI:user/pass at host1" bork -sql “select id,geometry from wtm_sub_cells 
> where …." -nln WTM_SUB_CELL -lco "GEOMETRY_NAME=GEOMETRY" -lco "DIM=2" 
> -lco "SRID=8307"
> 
>  
> 
>  
> 
> The SDO_GTYPE in the source database is 2003 but ogr is trying to insert 
> a 3003. Anyone know why this is? I used the –lco “DIM=2”. Also note I’m 
> trying to append data. I created this table with a similar ogr2ogr call 
> and the SDO_GTYPE is correct in the database. It appears that –update 
> –append does something different than during create.

Ethan,

Yikes!

Skimming the code, the OCI driver does not seem to make any effort to
discover if an existing layer is 2D or 3D when it is accesses an existing
layer.  So when it goes to write geometries, it seems it is forcing them
to 3D by default.

Looking at ogrociwritablelayer.cpp, there is the terrible old config
to force geometry dimension when creating.  To use this set the
OCI_DEFAULT_DIM config variable to 2.   Config variables can be set
as environment variables, though I think adding the following to the
commandline will also work:

   --config OCI_DEFAULT_DIM 2

I think the right solution for this would be to somehow query oracle
for the dimensionality of the geometry column when the layer is initially
setup.  Does Oracle even keep a dimension for columns?  Perhaps by looking
at the dimension of the DIMINFO in the metadata table?

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    | President OSGF, http://osgeo.org