[Featureserver] FeatureServer 2.0: Soonish

Wed May 21 10:27:11 EDT 2008

Not sure whether it's of interest but I wrote a quicky script to use
feature server from web.py (to integrate with attribute handling that I
do from there).  If that is of interest to add as a handler (requires
some refactoring) I'd be happy to send it..

-b

On Wed, 21 May 2008 00:18:27 -0400
Christopher Schmidt <crschmidt at metacarta.com> wrote:

> 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
> _______________________________________________
> Featureserver mailing list
> Featureserver at openlayers.org
> http://featureserver.org/mailman/listinfo/featureserver

-- 
Bud P. Bruegger, Ph.D.          +39-0564-488577 (voice),  -21139 (fax) 
   European Chair, Global Collaboration Forum on eID
   Chair, Porvoo Subgroup on collab. govs/operating systems
   Leader of the Permanent eID Status Observatory (PESO) project
Servizio Elaborazione Dati       e-mail:  bud at comune.grosseto.it
Comune di Grosseto               jabber:  bud at jabber.no
Via Ginori, 43                   http://www.comune.grosseto.it/
58100 Grosseto (Tuscany, Italy)
http://www.comune.grosseto.it/interopEID/