[fdo-internals] RFC 11 has been posted

Dan Stoica dan.stoica at autodesk.com
Mon Sep 10 16:00:02 EDT 2007

I have to take back what I said about 3D support :-(  By running a quick
test found that Oracle's Length() doesn't do 3D. That is, that optional
parameter must match the actual dimensionality of the geometry. And for
Area() Oracle states clearly: 2D only.

The same restriction apparently applies to MySql.

Other comments below under [DS]...

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: Monday, September 10, 2007 2:20 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] RFC 11 has been posted

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


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.
> suggested a Length3() function. In either case, we should implement
> 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
> 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

	[DS] Cartesian operations should be avoided for lat/lon data
because of the serious errors (the extents of such datasets are usually
very large). That's why I suggested to expose a "distance" function as
being more useful than a geodetic->geocentric point conversion. 

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.

	[DS] Yes, we need to document properly these functions wrt
accuracy and native 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
>             implement a virtual method to return the distance between
>             points?

I would think we provide a point transformer from geodetic to
xyz geocentric based strictly on the ellipsoid.  

	[DS] We can do that but I believe it is not useful for the
problem at hand.

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.

	[DS] Right. I see overridability important here because there
are various algorithms around and the user may have a preference.

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,

fdo-internals mailing list
fdo-internals at lists.osgeo.org

More information about the fdo-internals mailing list