[fdo-internals] RFC 11 has been posted

[Frank Warmerdam]

Dan Stoica wrote:
> 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:

Dan,

I agree that aligning with some standard would be good, and perhaps
the 3 variations is overkill.

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

Computing Length in 3D is pretty straight forward, but how would
this extend to areas?  It seems to me that 3D areas are not well
defined.  A common technique of tesselating and computing the sum
of the area of the triangles would work, but the result will vary
depending on what tesselation gets chosen.  Perhaps we just declare
the results to be approximate and do our best?

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

Are we trying to compute "surface tracking" lengths and areas
for geodetic values or would we settle for transforming geodetic
locations to geocentric (xyz) space and then doing simple cartesian
operations?

I'd be fine with saying that length() and area() always return
linear units.  And if we offer 3D variants I'd be fine with
stating that the results may be somewhat poor approximations
depending on the capabilities of the provider.

>             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?

I would think we provide a point transformer from geodetic to
xyz geocentric based strictly on the ellipsoid.  I'm not
sure if overridability would be important, but I do think that
providers should be able to ignore our implementation and do it
themselves if they want.

I see your point about not needing a projections library. My original
thought was to try and reproject geodetic data into an appropriate
regional projection with good local "metric calculation" support, but
that is overkill if we can adequately do things in geocentric space.

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