<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>OGR OCI Driver improvement about CoordinateDimension </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman">Dear developpers,</FONT></SPAN><SPAN LANG="fr-be"></SPAN><SPAN LANG="fr-be"> </SPAN>
</P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman">This problem is not actually well handled when we use feature with 2D and 3D coordinate.</FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman">(I provide test file with Ticket #3025) </FONT></SPAN>
</P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman">1) When we WRITE data into Oracle, TranslateTOSDOGeometry() and TranslateElemGroup()</FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> use nDimension member variable of OCIWritableLayer to handle the translation.</FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> Unfortunaly nDimension initisation is</FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> nDimension = MAX(2,MIN(3,atoi(CPLGetConfigOption("OCI_DEFAULT_DIM","3"))));</FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> which is good when creating layer but not if we update feature table and</FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> if we have different feature table with different dimension </FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> (OCI_DEFAULT_DIM cannot be set to handle both 2D and 3D simultanously). </FONT></SPAN>
</P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> The solution is to query ALL_SDO_GEOM_METADATA to get the dimension of existing table and</FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> overwrite the default value.</FONT></SPAN>
</P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> The best place I found to put this check is in OGROCITableLayer::ReadTableDefinition() because it does not concern OGROCILoaderLayer.</FONT></SPAN></P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> I attach the patch to Ticket #3025 (file is OCIWrite3025.diff )</FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> </FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman">2) When we READ data from Oracle, TranslateGeometry() and TranslateGeometryElement() take the dimension</FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> from Gtype of the SDO_GEOMETRY (That’s right).</FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman">The dimension is well used in decoding sdo_ordinates (see GetOrdinalPoint for exemple).</FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman">The problem is when we create OGRGeometry because it always construct 3D geometry even if we have 2D geometry. </FONT></SPAN>
</P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman">For exemple (in TranslateGeometryElement())</FONT></SPAN>
</P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> ...</FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> double dfX, dfY, dfZ = 0.0;</FONT></SPAN>
</P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> GetOrdinalPoint( nStartOrdinal, nDimension, &dfX, &dfY, &dfZ );</FONT></SPAN>
</P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> poPoint->setX( dfX );</FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> poPoint->setY( dfY );</FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> poPoint->setZ( dfZ ); </FONT></SPAN>
</P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> Many strategies exist to fix this problem.</FONT></SPAN>
</P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman">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)</FONT></SPAN></P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman">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</FONT></SPAN></P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman">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.</FONT></SPAN></P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman">My conclusion is that I should insert test on dimension when creating the geometry to prevent the cretion of a 3rd dimension.</FONT></SPAN></P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman">For exemple (in TranslateGeometryElement())</FONT></SPAN>
</P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> ...</FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> double dfX, dfY, dfZ = 0.0;</FONT></SPAN>
</P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> GetOrdinalPoint( nStartOrdinal, nDimension, &dfX, &dfY, &dfZ );</FONT></SPAN>
</P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> poPoint->setX( dfX );</FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> poPoint->setY( dfY );</FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> if ( nDimension>2 ) poPoint->setZ( dfZ ); </FONT></SPAN>
</P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman">If you agree with this last strategie, I would provide a patch with this kind of test for all geometries created in TranslateGeometry() </FONT></SPAN></P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> 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. </FONT></SPAN></P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> Best regards,</FONT></SPAN>
</P>
<P><SPAN LANG="fr-be"><FONT FACE="Times New Roman"> Nicolas</FONT></SPAN>
</P>
<P><SPAN LANG="fr-be"><FONT SIZE=2 FACE="Courier New">==================================================</FONT><BR>
<FONT SIZE=2 FACE="Courier New">Nicolas Simon, Informaticien</FONT> </SPAN>
<BR><SPAN LANG="fr"><FONT SIZE=2 FACE="Courier New">Service Public de Wallonie (SPW)</FONT></SPAN>
<BR><SPAN LANG="fr"><FONT SIZE=2 FACE="Courier New">Direction générale opérationnelle Agriculture, Ressources Naturelles et Environnement (DGARNE)</FONT></SPAN>
<BR><SPAN LANG="fr"><FONT SIZE=2 FACE="Courier New">Département des Aides</FONT></SPAN>
<BR><SPAN LANG="fr"><FONT SIZE=2 FACE="Courier New">Direction de l'Octroi des Aides agricoles - Service Informatique</FONT></SPAN>
<BR><SPAN LANG="fr-be"><FONT SIZE=2 FACE="Courier New">14, Chaussée de Louvain - 4e étage</FONT><FONT FACE="Times New Roman"><BR>
</FONT><FONT SIZE=2 FACE="Courier New">5000 Namur</FONT><FONT FACE="Times New Roman"><BR>
</FONT><FONT SIZE=2 FACE="Courier New">BELGIUM</FONT> </SPAN>
</P>
</BODY>
</HTML>