[fdo-internals] RFC 11 has been posted

[Dan Stoica]

Hi,

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
now.

-	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?
		
Thanks,
Dan.
 

-----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
or
> 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
the
> 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
and
> length support if possible within the current framework of what fdo
does
> and have the projection discussion separately.

Orest / others,

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

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

LengthCartesian()
LengthMetric()
and Length()

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

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,
http://osgeo.org

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