GeoTools : WFS 1.1 DataStore

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.

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: 63 issues


Andrea's brain dump
Christophe Google Summer of Code project


XML Developers Guide

Issue Tracking

Architecture Worksheet