[fdo-internals] RE: New RFC 49 Posted

Greg Boone greg.boone at autodesk.com
Mon Jun 7 17:07:18 EDT 2010 

IMHO.. I am happy with the RFC changes as defined, unless there are additional use cases that have arisen from this discussion. The proposed API modifications are meant to be limited, and in that light, are proposed for the Spatial package, which is not that heavily exercised (at least publically) by Providers. Making the modification here, and not in the FDO API directly, will help safeguard current Provider implementations and avoid the need to worry about backwards API compatibility support and excessive QA re-testing.

If the changes that Dan advocate are needed, I agree that a separate RFC would be a good idea. Such an RFC would need heavier scrutiny, testing, developer buy-in, etc.

Regards,
Greg


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

The parser will work both ways, with or without the extra parameter.

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

Some comments below...

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

The Parse syntax will change to accommodate for tolerance like: ".... 7.1770013502456 43.7501967446194 0))', 0.0177)");

One can get the tolerance back if he wants to.
[RD] First: this will break the backward compatibility of filters with older versions of FDO. There are many places when we save filters as text and applications will not be able to load them anymore. This requires too many changes (Fdo, providers, Map Guide, some applications) and, time and resources are limited. If this is really required maybe some one from OSGEO community or you could write a second RFC adding these changes and we can go ahead with them if approved. Now this RFC just open a window to be able to evaluate spatial filters having a tolerance. In the worst we can re-write spatial code evaluation in SQLite provider.

BTW, how the Z tolerance is going to be used?
[RD] There will be a limited 3D functionality added (for now 3D points, 3D lines, and 3D polygons, but not solids).

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


We have many places where we convert a filter from text to FdoFilter (e.g. having a spatial condition) and back to text.
Lets take an example:
 - FdoPtr<FdoFilter> filter = FdoFilter::Parse(L"Geom INSIDE GeomFromText('POLYGON XYZ ((7.1770013502456 43.7501967446194 0, 7.1770013502456 43.6912771493358 0, 7.27407112243824 43.6912771493358 0, 7.27407112243824 43.7501967446194 0, 7.1770013502456 43.7501967446194 0))')");
 - We will have a FdoSpatialCondition in the filter.
 - we get FdoSpatialCondition  and we set tolerances.
 - we call "string NewFilter = filter->ToString();"
 - we call "FdoPtr<FdoFilter> filter2 = FdoFilter::Parse(NewFilter)"

Where we keep tolerances set at step (2)? Do we lose them when we convert filter to text, text to filter? We should have a way to preserve the filter having all settings. Also many times tolerances depends of the server and not of the caller.

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

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