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

Tue Nov 4 10:28:21 EST 2008

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