[Featureserver] featureserver and dynamic layers?

[Christopher Schmidt]

On Thu, Mar 13, 2008 at 06:18:19PM +0100, Bud P. Bruegger wrote:
> 
> > Yes. There have been multiple people interested in adding this
> > functionality. I have no plans to add the functionality at this time,
> > but will gladly take patches to integrate it, and assist developers on
> > it in any way I can. If anyone is looking to develop this functionality,
> > I highly encourage discussion via the mailing list and the IRC Channel
> > (irc.freenode.net, #featureserver).
> 
> Great!  So I start discussing right off..
> 
> First a question on OpenLayers:  when loading a layer, does it always
> add a BBOX to the query sent to featureserver?  And does Openlayers
> automatically take care of re-querying featureserver during panning and
> zooming?

With a WFS Layer: Yes.

> So that leaves that the URL must specify what data one wants.  I
> suppose a simple (single table, no joins) generic case is quite
> straight forward to express in GET parameters.  Does that sound right?

Yes. We had discussed using Django-like filter names: things like
attrname__lt, attrname__gt, etc. And then translating these at the datasource
level.

> What I don't see very clearly is how querying relates to backends.  I'm
> very centered on PostGIS.  Is this something to do for postgis only or
> is this something to do for a group of backends that are "queryable"?
> (And which are those?)

It would be an implementation that would be generally applied to the 
queryable things passed to the backend datasources. Datasources could
choose what to do with these (or ignore them). As someone cares about a
datasource, they could add the support to that datasource. No one has
expressed interest for any of the datasources other than PostGIS.  

> In the latter case, is there some existing abstraction layer (e.g.,
> some component of an ORM) that already abstracts from backend-specific
> querying?  (But I suppose you want to avoid additional dependencies
> where possible?)

I think that for FeatureServer's purposes, the problem is pretty simple.
Currently, 'queryable' data is passed as a set of key/value pairs.
Instead, it will be passed a set of key/operator/value tuples. Parsing
from the URL doens't get much harder, and passing it to the database
only changes a little bit, and then datasources can take advantage of
the operator, or not. 

Regards,
-- 
Christopher Schmidt
MetaCarta