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
