[fdo-internals] Request review of RFC 28 -AddStart/EndExpressionFunctions

[Robert Fortin]

I think there was plenty of good idea of how far we can go with these kind of functions.  But, trying to go back to the original issue we were trying to resolve by RFC-28 which is simply to get the coordinates values for the first and last point...

I think Romy has an interesting proposal that makes the function evolutive over time and avoid over populating the list of functions with new names each time we think of a new possibility. It also makes it clear that it is about the points on the geometry and not computed point as other functions like MidX or CentroidX would be  (but that a matter for another debate).

I was thinking of even rationalizing it further (by adding another enumeration parameter to indicate x,y and z - we forgot about "m" by the way!) but I think the name of the function PointX, PointY and PointZ are just clear enough.

Can we go for that as far as the RFC is concerned?

RF


From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Romica Dascalescu
Sent: Tuesday, November 04, 2008 11:27 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Request review of RFC 28 -AddStart/EndExpressionFunctions

Hi,

A different approach is to create functions which takes a geometry and an enumeration, this way each provider can implement all cases or just a few of them, e.g.:

PointX(geom, enum)
PointY(geom, enum)
PointZ(geom, enum)

Where enum can be: 'start', 'end', 'min', 'max', 'centroid', ...
For now we may implement just a few of them (start, end) and in the future we could implement more cases.

Romy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20081104/20d0b1e8/attachment.html