[fdo-internals] RFC 11 has been posted

Jason Birch Jason.Birch at nanaimo.ca
Fri Sep 7 12:34:40 EDT 2007

I think that it would be worth considering the addition of a layer of
common functionality to FDO.  
In this case, it would mean that where providers have their own
projection implementations they are used.  Where they don't, FDO will
use PROJ.4 (or I suppose Mentor for proprietary builds) to do the work
for them.  This would allow for more of the typical processing to be
done at source, increasing the efficiency of spatial operations
I'd actually like to see this concept of generic functionality that can
be overridden by the individual providers extended to things like
grouping, ordering, etc as well.


From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Orest
Sent: Friday, September 07, 2007 08:39
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 11 has been posted

Hi Dan,


We didn't want to require providers to start building coordinate system
libraries into their implementations. Currently, all coordinate system
projection work is done outside of FDO. The OS version of MapGuide does
its projection work outside of FDO using Proj4 for example. Simple
calculations would be Euclidian geometry based calculations.


These functions are meant to be 2d functions. We could add 3d functions
in the future, e.g. called Length3D. The proposed functions should
compute area and length on the 2d data and ignore any z that is there.
3d calculations would necessarily need to be more complex: area of a
polygon would need to deal with surfaces and not just polygon
boundaries, length would need to account for different xy and z units,





From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
Sent: Friday, September 07, 2007 11:10 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 11 has been posted




A few questions:


"It is the proposal of this RFC that providers that do not use
coordinate system libraries simply return simple calculations directly
against the lat/long data (i.e. using Euclidian geometry based


What "simple calculations" means exactly? It implies returning the
length in radians and area in square radians... L


There are algorithms around to do such transformations. How about
implementing them as common utilities? Is it too much trouble?


Or say the user has a CSYS library like proj4. I believe it would make
sense to allow him to use it.

"It should also be noted that the functions execute 2D calculations
only. Therefore, if an object is defined in space, the functions should
not be used to determine the area or length of such an object. "

Do you mean these functions will not work with 3D data ("an object is
defined in space") ?






From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Thomas
Sent: Thursday, September 06, 2007 5:33 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RFC 11 has been posted




A new RFC (http://trac.osgeo.org/fdo/wiki/FDORfc11) has been posted. The
RFC follows up on RFC 8 by adding geometric functions to the list of
well-known FDO functions. 


Please review the RFC. Any comments/suggestions and questions are
welcome. All feedback is expected by the end-of-day September 12th 2007.
If no changes are required it is my intent to motion that a vote for the
acceptance of the RFC be made and subsequently voted on by the PSC.







-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20070907/21a0ca30/attachment.html

More information about the fdo-internals mailing list