[Featureserver] FeatureServer 2.0: Soonish

[Christopher Schmidt]

This weekend, at Wherecamp, Myself, jlivni, and brentp took on the task
of refactoring a significant chunk of FeatureServer.

The result, which I've been referring to as FeatureServer 2.0, will
likely be a significant step forwards, and although I expect it won't be
significantly different to operate, there are enough changes that I'd
like to call it '2.0', and stop further development of the 1.x line.

Major new feature:
 * Improved support for attribute queries: Now supporting comparisons
   like greaterthan, lessthan, etc. using django-like URL filters, on
   datasources which support them.  

 * Support for processing actions on output. Any datasource can now
   define a list of 'processes', which will then be applied to the
   features after they are loaded from the dataset and before they are
   returned to the user. 

   http://featureserver.org/refactor/doc/Processes.html has more
   information. 

As a demo:
 http://featureserver.org/refactor/featureserver.cgi/scribble/17.html
 Complex Line.

 http://featureserver.org/refactor/featureserver.cgi/scribble_simplify/17.html
 Somewhat simplified line. Not visibly so: the default of .1 at this
 zoom shows little degredation.

 http://featureserver.org/refactor/featureserver.cgi/scribble_simplify/17.html?process_simplify_tolerance=10
 Very simplified line. 


New Properties:
 * Feature model and serialization/deserialization is handled by 
   a seperated chunk of code, currently called vectorformats.
   vectorformats is a lightweight OGR-like data converter in Python,
   designed for the purpose of things like FeatureServer. (It will also
   work well for other Python projects which need to serialize geometry
   + attributes.)

 * Refactored web serving to seperate code common to TileCache,
   FeatureServer,  WPServer.

 * Updated internal geometry model to current GeoJSON specs

One thing that I'm thinking seriously about doing is changing the
'default' format/service from GeoJSON to HTML (and, correspondingly,
improving the HTML to work in more places/support a wider set of
depandancies as options). The upshot of this would be:
 * The default view is broser-oriented.
 * Crawling from services like Google or other web services 
   would be more likely.
 * It's easier to link from HTML to other services than the other way
   around. 

Downsides: 
 * Applications which expect a GeoJSON file based on a no-extension, 
   no-content type request will get screwed.

That downside seems an appropriate step to take at a 2.0, assuming that
the default setup can be made to fall back to something else which is
sensible if HTML support is not available.

At the moment, the work is in the 'refactor' branch. If there's
something about FeatureServer that has been bothering you, but it seemed
like an API change, now might be a good time to mention it. My current
plan is to continue hacking / playing in refactor for another week or so,
mostly writing tests and so on, and then merge it back to trunk, at
which point trunk will become '2.0 prep' until we release 2.0.

If this seems likely to interfere with deadlines of yours, please let
the list know, and we can look at how to solve the problem. 

Regards,
-- 
Christopher Schmidt
MetaCarta