WFS Simple

NEWS! first release of Simple WFS, an open source implementation of WFS Simple.

Please join this public mailing list to participate in the development of WFS Simple:

The WFS Simple mission is to specify a common, minimal feature set for geospatial-temporal data queries on the Web.

A primary goal is to encourage databases with basic location information (like lat/long coordinates), to support location-aware queries. Most mainstream Web systems, like blogging engines and standard PHP/MySQL setups, should be able to easily add WFS Simple functionality by supporting two standardized parameters, BBOX and TIME, in queries.,42.3,-71.1,42.6&TIME=2006-10-23/2006-10-25

The primary differences between the OpenGIS Web Feature Service Specification© and WFS Simple are:

  1. GML is not a required output format
  2. There is no HTTP POST encoding of a WFS Simple request
  3. Only one Feature Type is allowed per service instance (therefore the TypeName parameter goes away)
  4. Queries are specified using regex instead of a <Filter> parameter
  5. Query support is optional (this applies to WFS also, but it is important to emphasize)

The WFS Simple service consists of three mandatory operations:

  • GetCapabilities: metadata about the service, including output formats and ownership
  • DescribeFeatureType: access the data's schema
  • GetFeature:  retrieve data

Please join this public mailing list to participate in the development of WFS Simple:


DescribeFeatureType &

DescribeFeatureType & Filter

How does the DescribeFeatureType applies when the output is GeoRSS?

We also need to filter the output by keywords and not just date/bbox. The filter can be as simple as a single keyword to a more complex regular expression if necessary. The filter would apply to the contents of the feed (and categories)

Pat Cappelaere

Raj Singh's picture

In the case of Atom/GeoRSS,

In the case of Atom/GeoRSS, DescribeFeatureType would have the Atom schema with the GeoRSS extension--or even better it would have only the parts of the Atom and GeoRSS schemas that the service was using.

Let me try to explain better the filtering scheme proposed. The basic idea is that the GetFeature request parameters listed on the web page are those common to all Basic WFSes. However, services can advertise their data set's properties in the DescribeFeatureType response, and these properties can be put into the GetFeature request and searched. This doesn't violate the WFS spec because these parameters can be considered vendor-specific. It just happens that we've described a way for them to be automatically discovered.

Some will say that this mechanism is exactly what the filter specification allows you to do, but using filter is complex--not because it requires XML parsing, but because writing code to generically process the logic of a filter statement is hard. Dealing with HTTP GET parameters is much simpler.

We should probably move mindate and maxdate out of the basic parameters to keep in line with the WFS spec, but I think they are so universally useful I hesitate to do that.



I would argue that, assuming

I would argue that, assuming a GeoRSS output (which ought to be the default), this would not be of much use. So this is not basic anymore.
My responses are much looser or simpler as they do not require me to define any properties at all. If we want to be specific, then go traditional WFS.

Regarding the filtering scheme, by taking out the bbox and dates, we might as well allow for content filtering.
Not using the Filter spec is a good thing. This approach is much simpler and breaks down explicity what can be filtered.

Pat Cappelaere

Raj Singh's picture

But WFS Basic is not

But WFS Basic is not designed to be the service specification for Atom/GeoRSS. It's targeted at general database content service-enabled via common Web languages like Java, PHP, and Perl. If this does not work well for RSS feed interactions, then maybe something different is needed for RSS.


Most of us in State and

Most of us in State and Local Government GIS operations generally have way too many things piled up on our 'to-do' lists, so simpler/faster/easier is always an improvement, and much appreciated.

If publishing our GIS data as a feature service could be much less cumbersome and the data more easily and quickly consumable by a larger audience, that's also a good option to have. Fast and easy counts - a LOT.

I think a recent blog post by Paul Ramsey summed it up quite aptly as to how most public sector GIS data producers really feel about implementing WFS (althougth that particular topic is only a subset of the larger problems Paul was applying his comment to):

"..but for the most important people to the process, the data creators, it is just a pain in the ass."

I am not suggesting that WFS Basic would solve the entire problem Paul discusses, or even most of it. But, if it can help reduce the "PITA" of WFS a bit, then that's an improvement. There would always be situations where you'd want to implelement the full WFS spec, but I think there's still plenty of room for WFS Basic.