This page outlines the current project to develop a WFS 1.1 capable
We're going to develop a DataStore for WFS 1.1 servers. There is currently a WFS DataStore though. The problem with it is it's fairly unmaintained and hard to maintain, is built upon deprecated XML/GML parsing technology, and works only for WFS 1.0 services.
By the other hand its a long lived DataStore and thus has got a lot of bug fixes and per-server specific patches (given than some WFS servers tend to have their own glitches)
So the obvious question is why a new one and not extending/fixing the current one.
Rationale is we got a set of requirements that would make doing so a so deep change that's practically easier to start from scratch. Yet, we'll try to leverage all the knowledge held on the old WFS DataStore as to alleviate the task of dealing with real world servers.
The following is the set of requirements that'll drive the DataStore design.
- Read only. No writing, transactions, or locking
- Limited to GML 3 Level 0.
- Easy to Maintain.
- Based on GTXML.
- Caching. It shall be possible to plug some cache-ing strategy. Which one and how is left to investigate. It may be worth to check out the google Summer of Code accomplished for this task. So cache-ability should be open ended. First deliverables may just use a no-cache strategy.
- Decouple input format / output format. Ability to plug in different exchange formats than GML (that is, as the output format for GetFeature operations), like geojson, georss, etc... not necessarily implement them, but something to keep in mind.
- uDig Ready. This is a long term requirement, to be seamlessly used in uDig.
The following are documentation pages for GeoTools tech it's worth to keep in mind for this project: