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

[Traian Stanev]

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