This page outlines the current project to develop a WFS 1.1 capable
Overview
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.
Requirements
The following is the set of requirements that'll drive the DataStore design.
Non Functional
- 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.
Prior Art
The following are documentation pages for GeoTools tech it's worth to keep in mind for this project:
WFS DataStore
WFS GML DataStore
Current WFS DataStore issues:
38
issues
