[fdo-internals] RFC 11 has been posted

[Frank Warmerdam]

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