[mapguide-users] WFS-T

[Jackie Ng]

Conceptually speaking, WFS-T support in MapGuide would be quite simple to
implement. 

Based on my skim through of the WFS-T spec (OGC doesn't make this stuff
readable do they?), most of the WFS-T request structure maps cleanly to the
inputs for MgFeatureService::UpdateFeatures().

So conceptually our implementation would so something like this:

 Convert [WFS-T request] -> [MgFeatureCommandCollection]
 Call MgFeatureService::UpdateFeatures
 Convert [MgPropertyCollection result] -> [WFS-T response]

The problem as always, is in the details:

 * How to parse WFS-T requests in C++ (ugh!)
 * Grokking the XML templating engine used to generate the GetCapabilities
requests (those .awd files), so we can advertise transaction support.
 * Translating FDO provider capabilities into what we can/can't do via WFS-T
 * Fine-grain the access control. Surely, you don't want WFS-T enabled
globally but on a per Feature Source basis, you want to use the same
mechanism currently applied for WFS and WMS (resource header attributes).

Something that crossed my mind, is maybe to start it off such a feature as a
.net web extension:

 * Act as its own mapagent handler (the MapGuide API provides MgHttpRequest
and MgHttpResponse to do this)
 * Intercept WFS GetCapabilities requests to and augment the GetCapabilities
response to indicate support for transactions
 * Handle WFS-T requests to do what I just outlined above in .net
 * Output the matching WFS-T response based on the MgPropertyCollection
result of MgFeatureService::UpdateFeatures

This way, I at least know what libraries in .net I can tap into to implement
all of this.

Really, the major road block to add such support to MapGuide proper is how
to do all of what I just said in C++ with the framework/libraries we
currently have. Currently I have no idea.

- Jackie



--
View this message in context: http://osgeo-org.1560.x6.nabble.com/WFS-T-tp5053397p5053407.html
Sent from the MapGuide Users mailing list archive at Nabble.com.