[gdal-dev] OGR OCI Driver improvement about CoordinateDimension
Peter J Halls
P.Halls at york.ac.uk
Thu Aug 20 08:25:18 EDT 2009
Nicolas,
I think that the default geometry for OCI is 3 dimensions (Oracle), but the
number of dimensions is stored in the mdsys_geom_metadata table entry for the
table. If you are opening an existing table, the OCI driver should set the
geometry from the metadata; it is specified to OGR when creating a table anyway.
What should you do? Well, unless you operate in a flat world, with no
elevation ever to be recorded in your data, you probably ought to respect that
tables may have either 2 or 3 dimensioned coordinates. Ideally, read the
information for an existing table and set up to read accordingly. I think that,
if you use OCI to specify three dimensioned coordinates when the table only has
two, OGR returns a zero Z value, rather than an error. That seems to be the
right approach to me.
Best wishes,
Peter
Nicolas Simon wrote:
> Hello,<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
>
>
>
> I've installed my Python environment successfully. Now I would like to test the autotest
>
>
>
> <http://svn.osgeo.org/gdal/trunk/autotest/ogr/ogr_oci.py> http://svn.osgeo.org/gdal/trunk/autotest/ogr/ogr_oci.py
>
>
>
> but in the function ogr_oci_10() the 'expected_wkt' include a third dimension for a 2D feature. Think that I would like to fixe with my patches.
>
>
>
> so I would like to replace
>
> expected_wkt = 'POLYGON ((1 1 0,5 1 0,5 7 0,1 7 0,1 1 0))'
>
> by
>
> expected_wkt = 'POLYGON ((1 1,5 1,5 7,1 7,1 1))'
>
> Which is beter for a 2D geometry.
>
>
>
> Is this change wished or does it create incompatibilities ?
>
>
>
> nb. This is also the case in ogr_oci_14() for LINESTRING and in ogr_oci_15().
>
>
>
> By the way, is there an svn access to autotest ?
>
>
>
> Nicolas
>
> -----Message d'origine-----
> De : Nicolas Simon
> Envoyé : mercredi 5 août 2009 17:04
> À : Nicolas Simon
> Objet : RE: [gdal-dev] OGR OCI Driver improvement about CoordinateDimension
>
>
>
> Hi all,
> I provide a patch file against main trunk to solve the second point (read interpretation), attached with Ticket #3025 (file OCIRead3025.diff)
>
> Can anyone who use Oracle can provide me a feedback ?
>
> Thanks.
>
> Nicolas
>
> -----Message d'origine-----
> De : gdal-dev-bounces at lists.osgeo.org [mailto:gdal-dev-bounces at lists.osgeo.org]De la part de Nicolas Simon
> Envoyé : mercredi 5 août 2009 14:55
> À : gdal-dev at lists.osgeo.org
> Objet : [gdal-dev] OGR OCI Driver improvement about CoordinateDimension
>
>
>
> Dear developpers,
>
> This problem is not actually well handled when we use feature with 2D and 3D coordinate.
> (I provide test file with Ticket #3025)
>
> 1) When we WRITE data into Oracle, TranslateTOSDOGeometry() and TranslateElemGroup()
> use nDimension member variable of OCIWritableLayer to handle the translation.
> Unfortunaly nDimension initisation is
> nDimension = MAX(2,MIN(3,atoi(CPLGetConfigOption("OCI_DEFAULT_DIM","3"))));
> which is good when creating layer but not if we update feature table and
> if we have different feature table with different dimension
> (OCI_DEFAULT_DIM cannot be set to handle both 2D and 3D simultanously).
>
> The solution is to query ALL_SDO_GEOM_METADATA to get the dimension of existing table and
> overwrite the default value.
>
> The best place I found to put this check is in OGROCITableLayer::ReadTableDefinition() because it does not concern OGROCILoaderLayer.
>
> I attach the patch to Ticket #3025 (file is OCIWrite3025.diff )
>
> 2) When we READ data from Oracle, TranslateGeometry() and TranslateGeometryElement() take the dimension
> from Gtype of the SDO_GEOMETRY (That's right).
> The dimension is well used in decoding sdo_ordinates (see GetOrdinalPoint for exemple).
> The problem is when we create OGRGeometry because it always construct 3D geometry even if we have 2D geometry.
>
> For exemple (in TranslateGeometryElement())
>
> ...
> double dfX, dfY, dfZ = 0.0;
>
> GetOrdinalPoint( nStartOrdinal, nDimension, &dfX, &dfY, &dfZ );
>
> poPoint->setX( dfX );
> poPoint->setY( dfY );
> poPoint->setZ( dfZ );
>
> Many strategies exist to fix this problem.
>
> The simplest one is to force to 2D if dimension = 2 before returning from TranslateGeometry() but this solution does a lot of extra work (building a dummy 3D and deleting the 3rd dimension)
>
> To apply this solution a call to Flatten2D maintains the Z dimention but set it to 0. Not the solution I would like => Bad solution
>
> An other way is to call setCoordinateDimension() but the doc says "Setting the dimension of a geometry collection will not necessarily affect the children geometries.". Not a definitive solution.
>
> My conclusion is that I should insert test on dimension when creating the geometry to prevent the cretion of a 3rd dimension.
>
> For exemple (in TranslateGeometryElement())
>
> ...
> double dfX, dfY, dfZ = 0.0;
>
> GetOrdinalPoint( nStartOrdinal, nDimension, &dfX, &dfY, &dfZ );
>
> poPoint->setX( dfX );
> poPoint->setY( dfY );
> if ( nDimension>2 ) poPoint->setZ( dfZ );
>
> If you agree with this last strategie, I would provide a patch with this kind of test for all geometries created in TranslateGeometry()
>
> Note: The test "nDimension>2" seems beter than "nDimension=3" because if SDO_GEOMETRY is 4 (permitted), we will generate a 3D OGRGeometry insteed of a 2D.
>
> Best regards,
>
> Nicolas
>
> ==================================================
> Nicolas Simon, Informaticien
> Service Public de Wallonie (SPW)
> Direction générale opérationnelle Agriculture, Ressources Naturelles et Environnement (DGARNE)
> Département des Aides
> Direction de l'Octroi des Aides agricoles - Service Informatique
> 14, Chaussée de Louvain - 4e étage
> 5000 Namur
> BELGIUM
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
--------------------------------------------------------------------------------
Peter J Halls, GIS Advisor, University of York
Telephone: 01904 433806 Fax: 01904 433740
Snail mail: Computing Service, University of York, Heslington, York YO10 5DD
This message has the status of a private and personal communication
--------------------------------------------------------------------------------
More information about the gdal-dev
mailing list