Request review of RFC 28 - Add Start/End Expression Functions
|
|
| 1 2 |
Orest Halustchak
|
Some javascript/style in this post has been disabled (why?)
Hi, I’d like to ask for a review of RFC 28 ( http://trac.osgeo.org/fdo/wiki/FDORfc28
) which adds some new geometry-based functions to return start and end
ordinates. Please review and provide your feedback. Thanks, Orest. _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
Jason Birch
|
Some javascript/style in this post has been disabled (why?)
Not sure what the use case is
for these functions, but the implementation seems reasonable to me. I’m
glad that the name of the functions were changed from the initial take J Jason From: Orest Halustchak I’d like to ask for a review of RFC
28 ( http://trac.osgeo.org/fdo/wiki/FDORfc28
) which adds some new geometry-based functions to return start and end
ordinates. _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
Robert Fortin
|
Some javascript/style in this post has been disabled (why?)
Jason, 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. Robert From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Jason Birch Not sure what the use
case is for these functions, but the implementation seems reasonable to
me. I’m glad that the name of the functions were changed from the initial
take J Jason From: Orest Halustchak I’d like to ask for a review of RFC 28 ( http://trac.osgeo.org/fdo/wiki/FDORfc28
) which adds some new geometry-based functions to return start and end
ordinates. _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Jason Birch
|
Some javascript/style in this post has been disabled (why?)
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 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. _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
Greg Boone
|
Some javascript/style in this post has been disabled (why?)
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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Jason Birch 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 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. _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
Dan Stoica
|
Some javascript/style in this post has been disabled (why?)
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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Jason Birch 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 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. _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
Traian Stanev
|
Some javascript/style in this post has been disabled (why?)
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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica 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:
[hidden email] [mailto:[hidden email]]
On Behalf Of Greg Boone 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Jason Birch 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 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. _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Jason Birch
|
Unless there is a reason for the other cases, then that makes sense to me.
Personally, I'd prefer to see that as CenterX with point geometry being a degenerate case, but I understand that there may not be resources to return the centroids of the other geometry types at this point. The nice thing about this is that it would set a convention for future useful functions like MinX, MaxX, etc... I guess the problem with this would be that throwing an exception would be less reasonable than it would be for a point-specific function. Jason ________________________________ From: [hidden email] on behalf of Traian Stanev Sent: Mon 2008-11-03 2:39 PM 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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. _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
Maksim Sestic
|
In reply to this post
by Traian Stanev
Some javascript/style in this post has been disabled (why?)
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: [hidden email] [mailto:[hidden email]] 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Dan
Stoica 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg
Boone 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Jason
Birch 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 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 _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Orest Halustchak
|
Some javascript/style in this post has been disabled (why?)
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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Maksim
Sestic 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: [hidden email] [mailto:[hidden email]]
On Behalf Of Traian Stanev 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone 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: [hidden email]
[mailto:[hidden email]] On Behalf Of Jason Birch 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 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.
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Maksim Sestic
|
Some javascript/style in this post has been disabled (why?)
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: [hidden email] [mailto:[hidden email]] 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Maksim
Sestic 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Dan
Stoica 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg
Boone 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Jason
Birch 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 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 3582 (20081104) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
Romica Dascalescu
|
Some javascript/style in this post has been disabled (why?)
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Maksim
Sestic 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: [hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Maksim
Sestic 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: [hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Jason Birch 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 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.
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Dan Stoica
|
Some javascript/style in this post has been disabled (why?)
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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Romica
Dascalescu 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: [hidden email]
[mailto:[hidden email]] On Behalf Of Maksim
Sestic 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: [hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak 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:
[hidden email] [mailto:[hidden email]]
On Behalf Of Maksim Sestic 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: [hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Jason Birch 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 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.
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Traian Stanev
|
Some javascript/style in this post has been disabled (why?)
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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Romica
Dascalescu 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: [hidden email]
[mailto:[hidden email]] On Behalf Of Maksim
Sestic 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: [hidden email]
[mailto:[hidden email]] On Behalf Of Orest Halustchak 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Maksim
Sestic 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: [hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone 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: [hidden email]
[mailto:[hidden email]] On Behalf Of Jason Birch 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 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.
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Dan Stoica
|
Some javascript/style in this post has been disabled (why?)
The trouble is these functions
must return doubles. On the other hand we already have the MBR functionality. Dan. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Romica
Dascalescu 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:
[hidden email] [mailto:[hidden email]]
On Behalf Of Maksim Sestic 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: [hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak 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: [hidden email]
[mailto:[hidden email]] On Behalf Of Maksim
Sestic 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: [hidden email] [mailto:[hidden email]]
On Behalf Of Traian Stanev 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Jason Birch 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 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.
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Robert Fortin
|
Some javascript/style in this post has been disabled (why?)
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica The trouble is these functions
must return doubles. On the other hand we already have the MBR functionality. Dan. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica 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:
[hidden email] [mailto:[hidden email]]
On Behalf Of Romica Dascalescu 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Maksim
Sestic 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: [hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Maksim
Sestic 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: [hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Jason Birch 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 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.
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Robert Fortin
|
In reply to this post
by Dan Stoica
Some javascript/style in this post has been disabled (why?)
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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Romica
Dascalescu 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. _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Dan Stoica
|
Some javascript/style in this post has been disabled (why?)
Robert, returning to the
original issue: what is the meaning of PointX(geometry, ‘end’) for a polygon? Dan. From:
[hidden email] [mailto:[hidden email]]
On Behalf Of Robert Fortin 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Romica
Dascalescu 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. _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Greg Boone
|
In reply to this post
by Robert Fortin
Some javascript/style in this post has been disabled (why?)
Which enumerated values are you
looking to support through this RFC? What about multi-geometry support? From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Robert
Fortin 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Romica
Dascalescu 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. _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Traian Stanev
|
In reply to this post
by Dan Stoica
Some javascript/style in this post has been disabled (why?)
Moreover, what if the geometry
is a circle? J From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica Robert, returning to the
original issue: what is the meaning of PointX(geometry, ‘end’) for a
polygon? Dan. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Robert
Fortin 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Romica
Dascalescu 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. _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
