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

Tue Nov 4 19:20:55 EST 2008

It seems like it would be a good idea to mimic these OGC spatial
functions as much as possible.

Instead of a "last" argument, it may be better to create the helper
functions (StartPoint, EndPoint).  The EndPoint function could be
"equivalent" to PointN(geom,(NumPoints(geom)) but have an optimized
implementation.

I wonder if FDO should consider further mimicking the OGC functions by
also implementing something like their STX and STY to get the individual
dimensions of explicit points, rather than shortcuts that have to make
assumptions about which point the ordinates are pulled from.   For
instance XCOORD(PointN(geom,1)) or XCOORD(StartPoint(geom)) instead of
PointX(geom)

http://msdn.microsoft.com/en-us/library/bb933828.aspx

I _do_ like that these functions return NULL for non-point geometries
rather than throwing exceptions.

Jason

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 15:51
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Request review of RFC
28-AddStart/EndExpressionFunctions

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? J

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