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

[Robert Fortin]

Dan,

Interesting that you found this info.  I believe the STPointN definition is similar to what I was proposing since it depends on the order of output.  I was suggesting the same thing just in different word just applying to FDO.
I think adding the NumPoint function is also interesting and could be useful.  I'm worried about the performance of the nested function compare to a simple "last" argument.  So I still think it would useful to have the "last" point as argument.  "1" for the first point is obvious.

RF

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
Sent: Tuesday, November 04, 2008 6:14 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Request review of RFC 28 -AddStart/EndExpressionFunctions

I had a look into SqlServer2008 documentation for inspiration. It has a number of interesting functions:

STStartPoint()

STEndPoint() is the equivalent of STPointN<http://msdn.microsoft.com/en-us/library/bb933844.aspx>(x.STNumPoints()).
STNumPoints() This method counts the points in the description of a geography instance. Duplicate points are counted. If this instance is a geometry collection, this method returns of the total number of points in each of the elements in the collection.

STPointN() returns the point specified by expression by ordering all the points in the same order they would be output: first by geography instance, then by ring within the instance (if appropriate), and then by point within the ring. This order is deterministic.
If this method is called with a value less than 1, it throws an ArgumentOutOfRangeException.
If this method is called with a value greater than the number of points in the instance, it returns null.

I hope this clarifies  a little the desired behavior for polygons and multi part geometries (see in red).

As a minimal number of functions, I guess these ones will suffice:

NumPoints(geom)
PointX(geom, N) etc.

Note the expression engine supports embedded functions, therefore for getting the  Start/End points we can say:

PointX(geom, 1) etc.
PointX(geom, NumPoints(geom)) etc.


Dan.


From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Robert Fortin
Sent: Tuesday, November 04, 2008 4:41 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Request review of RFC 28 -AddStart/EndExpressionFunctions

Guys,

Unless there is standard out there, we can come up with whatever definition we want as long as it is consistant and it makes sense.

The RFC proposes the following:

If the provided geometry is a point geometry, the result of the Start/End functions is the x, y, z values of the point.
If the provided geometry is a multi-point geometry, the result of the Start/End functions is the x, y, z values of the first point.

>> I think Start should be referencing the first point and End the last point in case of multi-point.

If the provided geometry is a line geometry, the result of the Start/End functions is the x, y, z values of the start and end points of the first line.
If the provided geometry is a multi-line geometry, the result of the Start/End functions is the x, y, z values of the start and end points of the first line.

>> Same here.  Start - first point of first line, End - last point of last line.

If the provided geometry is a polygon geometry, the result of the Start/End functions is the x, y, z values of the start and end points of the exterior ring of the polygon.
If the provided geometry is a multi-polygon geometry, the result of the Start/End functions is the x, y, z values of the start and end points of the exterior ring of the first polygon.

>> Same again.  Start - first point of first ring, End - last point of last ring.
But we all know that it is not valuable to use those on polygon or circle (which is just an arc) but I don't want the function to throw an error because a polygon geometry is passed as input.
Let's agree on what it should be and return it.

RF

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Tuesday, November 04, 2008 3:15 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Request review of RFC 28 -AddStart/EndExpressionFunctions


Moreover, what if the geometry is a circle? :)



From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
Sent: Tuesday, November 04, 2008 3:14 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Request review of RFC 28 -AddStart/EndExpressionFunctions

Robert, returning to the original issue:  what is the meaning of PointX(geometry, 'end') for a polygon?

Dan.


From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Robert Fortin
Sent: Tuesday, November 04, 2008 2:46 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Request review of RFC 28 -AddStart/EndExpressionFunctions

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/e3f3591b/attachment-0001.html