[fdo-internals] RE: New RFC 49 Posted

[Traian Stanev]

Is this the only change in binary compatibility planned for this release? If yes, I'd agree, but if not, then there is no need to have two APIs where one would suffice. It is also better to make it clear to the caller what values will be used in case none are given, which the internally hardcoded values weren't doing (unless someone goes deep into the source).

Traian



-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
Sent: Monday, June 07, 2010 2:03 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: New RFC 49 Posted

Hi Romy,

Just to be clear, what I've suggested is "add setters/getters to FdoSpatialCondition and Evaluate() needs a new override".

Basically no new parameter is added and no signature is changed.

This way no compatibility is broken. The applications are free to use or not the new API. 

Thanks,
Dan.

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Romica Dascalescu
Sent: Monday, June 07, 2010 1:37 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: New RFC 49 Posted

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,
Romy.
________________________________________
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

Hi,

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>);
        select->SetFilter(filter);

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.


Thanks,
Dan.

-----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

Hi,

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.

Thanks,
Romy.
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals