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 : [email protected]
[mailto:[email protected]]de la part de Nicolas Simon
Envoyé : mercredi 5 août 2009 14:55
À : [email protected]
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
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
