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

Tue Nov 4 14:43:37 EST 2008

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 Dan Stoica
Sent: Tuesday, November 04, 2008 1:18 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Request review of RFC 28 -AddStart/EndExpressionFunctions

The trouble is these functions must return doubles. On the other hand we already have the MBR functionality.

Dan.

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

Then how about just a BBOX() function - for points it would obviously return the coordinates of the point, so it would work for the purpose we need. For other geometries, it would return the MBR.

Traian

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

How about a variation on PointX(), etc.

MidX(geom)
MidY(geom)
MidZ(geom)

Where the Mid is the center of the extents. It would make sense for all geometry types and useful (say) to place a label.

Not related to the above but to throwing exceptions: the reader has to handle the NULL geometries anyways. So the unsupported types can be handled the same.

Regards,
Dan.

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.

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

Hi Orest,

I agree, but I presume these functions will get implemented out of necessity - i.e. original RFC author definately had something in mind while suggesting PointX/Y or StartX/Y functions... and it's probably tied to labeling (Map, MapGuide). If this is the case, then functions can get adopted to fit that specific purpose. I agree it's a slippery slope there, easily slipping to stylization issues etc :-)

Regards,
Maksim Sestic

________________________________
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Orest Halustchak
Sent: Tuesday, November 04, 2008 16:00
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Request review of RFC 28 -AddStart/EndExpressionFunctions
Hi,

Maksim, these are good ideas, and there are all kinds of geometry type functions that we could add such as your AngleXY() example - centroid, mbr, buffer, etc. We already have length and area.

However, the purpose of this RFC is for a basic set of functions to help with displaying coordinate values in a data table type report, so expanding it to a lot of other things would be beyond the scope of what we wanted to build at this time. I think if folks find these other functions useful (and I agree that they are useful), my suggestion is to create a new RFC for them.

For the simple point function, it looks like we have the following ideas (extrapolating a bit from the discussion):

*         StartX(geom), StartY(geom), etc.

*         PointX(geom), PointY(geom), etc.

*         PointX(geom, n), PointY(geom, n), etc.

*         MinX(geom), MinY(geom), MaxX(geom), etc.

*         CentroidX(geom), CentroidY(geom)

The startx/endx type functions have issues related to what they mean for polygons and multi-type geometries. They make sense for line and point geometries. For a single polygon loop, they sort of make sense.

The pointx/pointy type functions are fine for points, but don't have meaning for other geometries unless we treat them as centroid. I'd rather avoid defining functions that throw exceptions for a large number of geometry types if we can. My preference would be to have a defined result for all geometry types if at all possible.

The pointx(n) type functions are more useful in general that starx/endx type functions, but have the same issue around what they mean for polygons and multi-type geometries.

The minx/miny type functions work for all geometry types, but require extra processing than just grabbing an existing point form the geometry object.

The centroidx/centroidy type functions also work for all geometry types, but also require extra processing.

Orest.

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

Why don't you introduce optional parameter for vertice index being inspected, i.e. PointX(n) - if there's no parameter then value of 0 is assumed (used with Point geometries). In that way one can evaluate linestring and polygon single vertice coordinate.

I think there's something else missing - I'm trying to draw directions for one-way roads, as in Google Earth/Map. Although each road network's linestring is directed (as in directed graph) and has direction flag attached (uni/bi-directional), I still don't have enough data to actually rotate an arrow - depicting road direction. How about introducing AngleXY() and AngleXY(n) functions returning line segment angle in plane? Is there any other solution to this, except for storing pre-calculated vectors? Maybe adding some additional stylization rule for this?

Regards,
Maksim Sestic

________________________________
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Monday, November 03, 2008 23:40
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Request review of RFC 28 - AddStart/EndExpressionFunctions
Yeah, may be just provide PointX()/PointY()/PointZ() functions which take a geometry as argument and throw an error for anything but points?

Traian

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
Sent: Monday, November 03, 2008 5:24 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Request review of RFC 28 - Add Start/EndExpressionFunctions

What has the Start point so special except for the point features? For example, the START=END for simple polygons.
Maybe this ECO should address only points?

Dan.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Monday, November 03, 2008 2:53 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Request review of RFC 28 - Add Start/EndExpressionFunctions

Yes, Lines and Polygons do offer some difficulties. Also, the multi-geometry objects are also a little weird. I am open to suggestions on how to handle these types.

Greg

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Thursday, October 23, 2008 12:34 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Request review of RFC 28 - Add Start/EndExpressionFunctions

That makes sense to me; I just wasn't sure what you would use the equivalent function for lines/polygons for.

Jason

From: Robert Fortin
Subject: RE: [fdo-internals] Request review of RFC 28 - Add Start/EndExpressionFunctions

The use case: presents the ordinates of a point geometry as attribute in a data table.  This feature will help us achieve that.
You could also think it can be used to display the coordinate as labels as part of the symbology of a feature.
Or you could use the StartZ to show the elevation of a point or apply a theme on it.
All these can't be done easily directly using the geometry attribute.

__________ Information from ESET NOD32 Antivirus, version of virus signature database 3580 (20081103) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature database 3582 (20081104) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20081104/74ecd4af/attachment-0001.html