[fdo-internals] Coordinate system support for FDO

[Jason Birch]

I certainly see the benefits of implementing this at the utility level.


I am not sure how to deal with providers that have native support for
these functions though.  It may be more efficient or align better with
other systems on the same data store to perform the transformation in
the source (for instance, if it is running a different projection
engine).

I would love to see the utility layer as a levelling mechanism;
providing a default set of functionality (so that we don't have a
mish-mosh of capabilities to deal with) but allowing individual
providers to override it.

Is there a sustainable way to allow individual providers to implement
the utility functionality, with a fallback to the utility layer if it
doesn't exist?  I'm revealing my total ignorance of software development
here, but is there a way that the utility layer could check for a
particular function signature in the provider and, if it doesn't exist,
call an internal implementation instead?

Jason

-----Original Message-----
From: Traian Stanev
Subject: RE: [fdo-internals] Coordinate system support for FDO

If it resides within providers, it means every provider would have to
implement it. There are lots of providers.
If it's implemented as a utility that, say, overloads a feature reader's
GetGeometry() call, then it can be used against all providers.
Same applies to raster providers, but there it would be the GetRaster
call I guess.