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

[Robert Fortin]

I'm all for trying to use existing standard and applying to our case.

In order to address my use case which is only concerned with point geometry,  I would have to do and implement the following:

X(geometry)
Y(geometry)
Z(geometry)
(and M(geometry) by extension)

Everything else is additional to the use case.

So the RFC should only be about these 3 functions and mention the additional ones and trying to match the OGC standard.

RF


From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Orest Halustchak
Sent: Wednesday, November 05, 2008 9:13 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Request review of RFC 28-AddStart/EndExpressionFunctions

Hi,

I agree with Jason's suggestion to mimic OGC functions as much as possible.

The OGC Simple Feature spec (06-103r3, which is the most recent version) has different functions for different geometry types.

Methods that apply to all geometry types include these (among others):
                Dimension(): Int
                GeometryType(): String
                SRID(): Int
                Envelope(): Geometry
                IsEmpty(): Int
                IsSimple(): Int
                Is3D(): Int
                IsMeasured(): Int

Geometry collection types such as multi-geometry, multi-point, multi-polygon etc. include:
                NumGeometries(): Int
                GeometryN(N): Geometry

Point includes:
                X(): double
                Y(): double
                Z(): double
                M(): double

Z() and M() return null if the geometry does not include them. Jason, you mentioned returning null rather than throwing exceptions for cases that are not defined, and this is consistent with OGC.

Curve includes:
                Length(): double
                StartPoint(): Point
                EndPoint(): Point
                IsClosed(): Int  (true if start point equals end point)
                IsRing(): Int  (true if IsClosed and IsSimple)

LineString includes:
                NumPoints(): Int
                PointN(N): Point

MultiCurve is interesting:
                IsClosed(): Int  (true if each element curve is closed)
                Length(): double  (sum of lengths of the elements)

Surface and MultiSurface include:
                Area(): double
                Centroid(): Point  (mathematical centroid, not guaranteed to be on the surface)
                PointOnSurface(): Point  (a point guaranteed to be on the surface)

Polygon (sub-type of Surface) includes:
                ExteriorRing(): LineString
                NumInteriorRing(): Int
                InteriorRing(N): LineString

Interestingly, there are no MinX, MinY type functions. The Envelope of a geometry is meant to include them, but an Envelope is a geometry type so you have to process it to get specific minx, miny, etc. values. Envelope geometry typically is a polygon, but I think OGC allows it to be two points as well.

So, what should we include for FDO? It makes sense for the long term to support all of the above functions. Some of these such as Length and Area we already support. However, for this particular RFC, it would be a fair amount of work to add all of these. From Jason's last email, maybe we change this RFC to add the following. The rest can be done as they are needed using other RFCs to add them.

                StartPoint(Geometry): Point, returning null for multi-type geometries
                EndPoint(Geometry): Point, returning null for multi-type geometries
                NumPoints(Geometry): Int64, returning null for non-linestrings, e.g. if input is a curve with an arc, result would be null; point geometries could be supported
                PointN(Geometry, N): Point, returning null for non-linestrings and if N is out of range; point geometries could be supported
                X(Geometry): double, returning null if geometry is not a point
                Y(Geometry): double, returning null if geometry is not a point
                Z(Geometry): double, returning null if geometry is not a point or does not have Z
                M(Geometry): double, returning null if geometry is not a point or does not have M

Possibly NumPoints and PointN also could be done later.

It's odd to have an M value on a point, but because you can do something like M(PointN(geometry, 4)), it does make sense.


Thanks,
Orest.


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

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? :)



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/20081105/3a7e6379/attachment-0001.html