[fdo-internals] RFC-28 - Add X, Y, Z and M Expression Functions
Frank Warmerdam
warmerdam at pobox.com
Wed Nov 12 22:00:10 EST 2008
Robert Fortin wrote:
> 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...
Robert,
Well, how about I will convert from -0 to "0", leaning neither for nor
against. I am very happy with the approach and following OGC's approach.
It just seems crazy to do it in such little steps.
I'm pleased to hear it is easy to turn on the capability for non-RDBMS
providers. Wouldn't you like to prove it by doing it for the OGR and
Shape providers? :-)
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
More information about the fdo-internals
mailing list