[fdo-internals] RE: New RFC 49 Posted

Dan Stoica dan.stoica at autodesk.com
Mon Jun 7 15:10:58 EDT 2010 

> Could you please tell me how FdoSpatialCondition tolerances will be used?

In exactly the same way your Evaluate() is going to use them.

For the other questions, let me put it this way: changing Evaluate() only has a very limited use unless I hear otherwise, i.e. FdoSpatialCondition is rarely used.

And my last argument is that optional parameters are unprecedented in FDO API. A matter of style and consistency...

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 2:55 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: New RFC 49 Posted

Hi Dan,

Could you please tell me how FdoSpatialCondition tolerances will be used?
Now in case we call ToString() one FdoSpatialCondition we something like "Geom INSIDE GeomFromText(...)"
How this change will affect FDO Filter parser, also how the filter will look as text? How we will handle Filters backwards compatibility?

Thanks,
Romy.

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

> As Traian said I would rather 'see' the default values for optional parameters than internally hardcoded.

First, you can see the default value using say FdoSpatialCondition::GetToleranceXY()  before calling SetToleranceXY().

Secondly, the proposed default values must match the existing hardcoded values, otherwise we have a regression problem. The RFC does this.

Therefore, since it is about the same values, I don't see a problem.

Dan.

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


Adding new non-virtual functions would not have broken binary API compatibility, but again, I don't think this is relevant here since people would be expected to recompile providers with a new FDO version anyway.

Traian


-----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 2:29 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: New RFC 49 Posted

Changing the API, adding more functions will break somehow the compatibility.
As Traian said I would rather 'see' the default values for optional parameters than internally hardcoded.
That's one of the reasons we do this RFC: we change the API and all providers must be build with this change in order to work.

Romy.
________________________________________
From: fdo-internals-bounces at lists.osgeo.org [fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Monday, June 07, 2010 2:21 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: New RFC 49 Posted

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
_______________________________________________
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_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals

More information about the fdo-internals mailing list