[fdo-internals] RFC-28 - Add X, Y, Z and M Expression Functions
Robert Fortin
robert.fortin at autodesk.com
Wed Nov 12 12:36:14 EST 2008
Frank,
The scope limitation is due to resource and time constraints. It's not ideal but I think the nice part about the discussion around this RFC was that we agreed to follow some standard going forward. Addition of other function can be done following those standard.
The implementation will add the functions and a generic implementation to the expression engine and therefore could be used by any provider. The new functions won't be part of the Standard functions list returned by the expression engine. Each provider will need to add them to their supported list of function. If we were adding them to the standard list, then we would have to change all the provider that would not support it. At the moment, the intent is to expose them for SDF only.
So all other non-RDBMS provider would have to do is
- Register the functions as custom functions to the ExpressionEngine used by the provider.
- Add them to the list of supported functions returned by ExpressionCapabilities::GetFunctions()
I hope that raise your vote from -0 to a +0...
RF
-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Frank Warmerdam (External)
Sent: Wednesday, November 12, 2008 12:19 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] RFC-28 - Add X, Y, Z and M Expression Functions
Robert Fortin wrote:
> Since there was no feedback since the last update and review request for
> RFC-28, I'm calling for a vote by the FDO PSC members.
>
>
>
> http://trac.osgeo.org/fdo/wiki/FDORfc28
Robert,
Apparently I missed the part of the discussion where it was decided that
adding additional accessors was outside the scope of this RFC. I had
expected the StartPoint, EndPoint, NumPoints and PointN accessors to be
added. Is adding them at the same time difficult? It seems this would
give us a respectible set of accessors (possibly along with something to
access component geometries within a collection).
I'd add it quite bothers me that this sort of functionality is strictly
per-provider and that there isn't generic machinery to provide it to all
the non-RDBMS based providers in a convenient way.
I'm "-0" on the RFC as proposed because I feel a more comprehensive solution
to geometry accessors is desirable at this time rather than just adding things
in dribs-and-drabs.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
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