Conceptually, there is no impedance mismatch whatsoever, MapGuide builds on FDO so its knows about feature schemas, capabilities, and other FDO terminology. There is a near perfect 1:1 mapping of everything!
A MapGuide FDO provider would allow for roundtripping between a FDO client application and a MapGuide Server that would not have been previously possible.
A MapGuide FDO provider would allow you to easily pull snapshots of data from a MapGuide Server. You could bulk copy data from a MapGuide Feature Source and not care whether that Feature Source points to a SDF file or an Oracle instance, or a WFS server.
A MapGuide FDO provider would allow you to have MapGuide Feature Sources sourcing data from other MapGuide servers.
You could probably do all this through a WFS facade, but that requires configuration from the MapGuide side of things, and you would lose some of the richness of FDO by going through WFS (I know I've had to deal with things like zero-length properties from a WFS data source)
A MapGuide FDO provider wouldn't need such configuration, just feed it the required connection parameters:
- MapAgent URL
- MapGuide username
- MapGuide password
- MapGuide Feature Source Id
And you're off and racing!
There's many new possibilities with a MapGuide FDO provider. Unfortunately, I lack the C++-fu to fully explore this idea :-S
Posts
1 comment:
most definitely a good idea!
even cooler if we get standardised FDO naming...
mapguide would then become something vaguely like a ArcSDE service
with a bit more abstraction, feature sources could be treated as FDO datastores
Post a Comment