[fdo-internals] Coordinate system support for FDO

[Maksim Sestic]

I'll try to explain how it's done in SharpMap and it's NTS (JTS-port)
implementation, so you may come to less troublesome solution. There's
utility set of classes CoordinateSystems exposing similar functionality to
what I expect of Mentor library. Among other related types (datums,
projections...), there's also a CoordinateReferenceSystem one.

Now, GeometryFactory optionally receives a CRS object to deal with - any
geometry created by the factory gets transformed using given CRS definition
(if any) if it differs from generic one, set via feature store. It seems
that FDO GeometryFactory needs a coordinate "pre-processor" and
"post-processor" 
engines at core level (not a provider level) which performs actual
coordinate transformation. In other words - CRS engine resides as a utility
set of classes, but gets implemented (in one way or another) via Geometry
Factory. It's implementation is similar to precision engine's. One more tip
- any geometry created by the factory should carry SRID (Spatial Reference
System ID) info based on source CRS, if any (SRID can be EPSG identifier or
whatever proposed by Mentor). 

IMHO it should be seamless to providers, I don't expect them to mangle with
CRS stuff since it's far from trivial.

Regards,
Maksim Sestic
 



JasonBirch wrote:
> 
> 
> 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.
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
> 
> 

-- 
View this message in context: http://www.nabble.com/Coordinate-system-support-for-FDO-tp14397583s18162p14414248.html
Sent from the fdo-internals mailing list archive at Nabble.com.