[fdo-internals] RE: New RFC 49 Posted

Romica Dascalescu Romica.Dascalescu at autodesk.com
Mon Jun 7 13:36:49 EDT 2010

Hi Dan,

Looking at FDO API the only place where we can specify/get a tolerance is in Spatial Context. So FDO API allows you only in that place to assign a spatial context having a certain tolerance to a (FDO) class. This is the way FDO was designed.
Normally that tolerance should be used in spatial queries evaluation, however this is not possible without this RFC. Oracle allows you to specify a tolerance to a (table) class and that tolerance will be used by Oracle.

This RFC wants to improve the FDO API and allow to pass in evaluate function XY and Z tolerances. This spatial API is not necessary ONLY used by providers in Select, it can be used by applications (it's an API) to evaluate different things (e.g. Overlay in Map3D)
In C++ you can have default parameters to a function and we use the same parameters with hard-coded values, however in C# (managed API) indeed we need to add two more Evaluate functions: one passing XT tolerance and one passing XY and Z tolerances. This way user has 3 functions depending of needs. There is a comment in RFC we will add all necessary changes to managed API side.

Regarding tolerances to spatial filters in FDO I don't think is a good idea. We will break compatibility changing FDO spatial filters because many applications have  filters serialized into XML/text config files. 
Also in FDO spatial filters are not functions are operators (Geom ENVELOPEINTERSECT GeomFromText(''')) and at the end we already have an optional parameter for distance evaluations, and adding two new extra parameters will be overkill.
Maybe we could add two new parameters to the select XY & Z tolerances but till now I did not see any request to do that.
Overall even we add parameters to other commands/spatial filters we still need to update the API to allow providers (which uses this spatial API) to pass a tolerance.

Best Regards,
From: fdo-internals-bounces at lists.osgeo.org [fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
Sent: Sunday, June 06, 2010 3:09 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: New RFC 49 Posted


The proposal is to pass programmatically the tolerance to FdoSpatialUtility::Evaluate().

I wonder how is it going to be used by an application since usually Evaluate() is called indirectly by Select:

        FdoPtr<FdoSpatialCondition> filter = FdoSpatialCondition::Create(<geometryPropertyName>, <spatialOperator>, <geometry>);

Hence the tolerance should be passed as well to FdoSpatialCondition::Create() like:

        FdoSpatialCondition::Create(<geometryProperty>, <spatialOperator>, <geometry>, toleranceXY, toleranceZ);

On the other hand, managed C++ does not accept default parameters as suggested.

This said, it seems to me that the way to go is to add setters/getters to FdoSpatialCondition and Evaluate() needs a new override rather than a signature extension.


-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Romica Dascalescu
Sent: Wednesday, June 02, 2010 9:14 AM
To: fdo-internals at lists.osgeo.org
Subject: [fdo-internals] New RFC 49 Posted


RFC 49 (http://trac.osgeo.org/fdo/wiki/FDORfc49) is now ready for review. The main purpose is to change FDO API spatial functions to be able to provide tolerances (XY & Z) used for spatial evaluation.
Please review and provide additional feedback.

fdo-internals mailing list
fdo-internals at lists.osgeo.org
fdo-internals mailing list
fdo-internals at lists.osgeo.org

More information about the fdo-internals mailing list