[fdo-internals] RFC 11 has been posted

Dan Stoica dan.stoica at autodesk.com
Mon Sep 10 13:39:33 EDT 2007


Frank, I think it's kind of confusing for the user having 3 flavors (and
not standard). I guess we'll be better off to relate the length
calculation to what Oracle does:

-	SDO_LENGTH() may take a parameter which specifies the desired
dimensionality. Which makes me think that our Length() should do the
same and it should default to 2D. But say in the case of a pipe that
goes up and down by ignoring Z the results are pretty much wrong. Orest
suggested a Length3() function. In either case, we should implement both

-	The length is in meters for geodetic data. Would it be
reasonable to implement the conversion to XYZ given the spheroid
parameters listed in the WKT? Algorithms are available. (Please note I'm
not suggesting to introduce projection support).
		This point conversion utility can be either a simple
function or the default implementation of an interface for the case the
FDO user prefers to override it. Or better yet, implement a virtual
method to return the distance between 2 points?

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Frank
Warmerdam (External)
Sent: Saturday, September 08, 2007 3:46 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] RFC 11 has been posted

Orest Halustchak wrote:
> Hi Frank,
> Adding projection support to FDO hasn't been on the radar screen (at
> least any that I've seen). Focus so far has been on keeping FDO as the
> basic data access layer that does not try to modify the data going in
> coming out. Projection operation or other data modification (e.g.
> converting arcs to polylines) is being done at a higher level.
> Do we want to change this? If we want to discuss this, then this is
> right forum in which to do that, but I'd like to decouple it from the
> RFC 11 discussion. I'd like to come up with an approach to add area
> length support if possible within the current framework of what fdo
> and have the projection discussion separately.

Orest / others,

Agreed.  Whether or not to introduce projections support within FDO
is essentially unrelated to RFC 11.  But the lack of it at this time
we can't really provider provider implementors utility functions to
linear results for length and area as has been suggested.

Given that assumption, would it be reasonable for RFC 11 to address
indicating what results are returned?  Or perhaps we could have:

and Length()

with LenthCartesian() (if available) doing the obvious cartesian
LengthMetric() returning a result in meters and Length() doing either
no apriori definition of which will be done. Would this approach be

Best regards,
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo,

fdo-internals mailing list
fdo-internals at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20070910/3009ebaa/attachment.html

More information about the fdo-internals mailing list