[fdo-internals] RFC 11 has been posted

[Orest Halustchak]

Hi,

Comments below ...

Thanks,
Orest.

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

[OH] Don't forget that the Z units are not always the same as XY units.
It may be uncommon, but even when XY are non-lat/long units such as feet
or metres, Z can be different. Certainly with XY in degrees, Z is
different. Also, I'm really leery of trying to do a 3d area with just
the boundary. You really need the interior surface.

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

[OH] But, you'd still need to do the length calculation on the surface
of the ellipsoid or are you saying that you'd just do Euclidean
distances at this stage?

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

_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals