[fdo-internals] Coordinate system support for FDO
Jason.Birch at nanaimo.ca
Tue Dec 18 11:23:19 EST 2007
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
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?
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.
More information about the fdo-internals