[gdal-dev] OGR OCI Driver improvement about CoordinateDimension

Nicolas Simon nicolas.simon at spw.wallonie.be
Thu Aug 20 08:00:30 EDT 2009


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 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090820/b8f40fa0/attachment-0001.html


More information about the gdal-dev mailing list