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