[Geoprisma-dev] Attribute filtering

[Alexandre Dube]

Hi Etienne,

   Thanks a lot for your work on this widget.  See some comments below :

On 10-11-29 04:05 PM, Etienne Dube wrote:
> Hi everyone,
>
> I would be ready to commit an initial (experimental) version of the 
> AttributeFilterPanel widget; please see the following ticket for the 
> patch: http://trac.osgeo.org/geoprisma/ticket/175 (this patch file is 
> the most recent: 
> http://trac.osgeo.org/geoprisma/attachment/ticket/175/gp-attributefilterpanel-20101129.patch).

I think it would be best if the source code of the widget (the .js 
files) to be linked as an svn external instead of being in the widget's 
directory.


> I still need to write a full-fledged GeoPrisma sample for the widget;

That would be very helpful.


> though this would require a FeatureServer service along with a 
> PostgreSQL+PostGIS instance on the geoprisma.org server.

Even though there isn't much interesting attributes to filter to, you 
could use the GMap services already scattered all around the samples.  
They already have FeatureServer datastores you could use.


>
> Alexandre has shared with me some concerns that references to the 
> resources contained in the widget's configuration could be a problem 
> with the PostgreSQL config. driver. I'm looking for some input on that 
> issue -- what would be the best way to put in the widget's config a 
> reference to the vector layer each filter is applied to? You can have 
> a look at the .rst file from the patch for the syntax of the widget's 
> configuration.

I'm still not sure how we could implement this widget inside the 
PGSQLMapContextConfig driver.  What we need is resource option(s) to 
link each resource to an according widget.  The easiest and most wanted 
resource option is a simple flag, like 'queryable:true' ( in this case, 
it would be 'filtering:true' or something like that ).  But we need to 
define a bunch of other options (attributes, what type of filter to do, 
labels, etc.).  That would become hard to configure.

If, instead of having to manually define each attribute with each filter 
and labels, we let the user decide what to do on the UI side, then much 
less options would be required.  The widget could still support to have 
pre-defined combines of attribute+filter+value, but having then defined 
on UI side as well would simplify things for the PGSQLMapContextConfig 
driver.  Having a single resource option 'filtering:true' would be 
enough in that case.

Take a look at the following image (taken from geoexplorer).  That 
pretty much sums up what I have in mind.  We could have something that 
looks like this : (see bottom left portion, under the 'table' tag)

http://img.skitch.com/20090331-fxbj9u4x4hp6kmtsnsf4d9uts6.png

Any thoughts ?

-- 
Alexandre Dubé
Mapgears
www.mapgears.com