[gdal-dev] OGR OCI Driver improvement about CoordinateDimension
Nicolas Simon
nicolas.simon at spw.wallonie.be
Thu Aug 20 09:35:21 EDT 2009
Peter,
> -----Message d'origine-----
> De : Peter J Halls [mailto:P.Halls at york.ac.uk]
> Envoyé : jeudi 20 août 2009 14:25
> À : Nicolas Simon
> Cc : gdal-dev at lists.osgeo.org
> Objet : Re: [gdal-dev] OGR OCI Driver improvement about
> CoordinateDimension
>
>
> 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.
There is no default dimension in Oracle, but when creating Oracle table through OGR,
OGR uses 3 unless OCI_DEFAULT_DIM is specified.
nDimension = MAX(2,MIN(3,atoi(CPLGetConfigOption("OCI_DEFAULT_DIM","3"))));
You are right when saying that dimension can be found in mdsys_geom_metadata
In my case, I have table with 2D and other with 3D.
I agree with you when you said that the OCI driver should set the geometry from the metadata.
But this is not the case unless you apply the patch I submit.
>
> 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.
>
What I propose with the patch, is to return a valid Z value when we read from a 3D table and
no Z value we read from a 2D table.
Unfortunaly, autotest create a 2D table and check a zero Z value.
So patch for the code and autotest (not yet provided) should by apply simultaneously.
> Best wishes,
>
> Peter
>
Best wishes,
Nicolas
> 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-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
> >
> >
> >
> >
> >
> >
> >
> --------------------------------------------------------------
> ----------
> >
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at 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
> --------------------------------------------------------------
> ------------------
>
>
>
More information about the gdal-dev
mailing list