[Geoprisma-dev] Attribute filtering

[Etienne Dube]

Hi Alexandre,

On 30/11/2010 8:53 AM, Alexandre Dube wrote:
> 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.
>

Good idea, I added an external property to point to the GeoExt sandbox. 
I need to commit the changes so the external files can be retrieved when 
doing an update. Do you mind if I create a SVN branch for the 
AttributeFilterPanel code? I'd merge it to the trunk when the code is 
stable enough.

>
>> 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.
>

Are those based on a PostGIS datastore? FeatureServer can only apply 
attribute filters when using PostGIS.

>
>>
>> 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.

I should try the PGSQLMapContextConfig and have a look at the DB schema 
to get a better understanding of how it works. The main difficulty I see 
here is to devise a way to put a reference to a layer from a widget's 
configuration -- this is what I did with the XML config syntax and the 
XSLT functions (in a rather hackish way I must say). The way 
AttributeFilterPanel works currently is that only one 
AttributeFilterPanel widget is instanciated, and it contains one or more 
filters dialogs, with each one applying to a specific vector layer. I 
can see other use cases where a widget has to be configured specifically 
for a layer -- for example a custom "Query feature" widget that not only 
displays the raw attribute values in a table, but displays a 
window/panel with formatted information derived from the feature 
attributes. So I believe it's valuable to think of a reusable way to put 
layer-specific configuration in a widget's config.


>
> 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.
>

Letting the user decide what attribute and operators to use when 
filtering was something we wanted to support initially (this is similar 
to what I described as the "expression builder" mode). However in many 
cases our end users are not always GIS professionals and prefer to have 
more guidance when applying a filter on a layer, by having the 
attributes and/or operators preselected. This is why I initially 
designed the widget with the "preconfigured" mode in mind. The two modes 
are not exclusive, though it could be easier to support both using two 
different widgets (ExtJS' FilterPanel would be kinda hard to modify in 
order to implement a full-fledged expression builder, we'd need to code 
a new GUI component from scratch).

> 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

Yes, I've seen that screenshot when researching the existing solutions 
for attribute filtering. That would be the way to do an "expression 
builder" filter widget, though I'd add more flexibility if possible, 
like the possibility to combine predicates using logical ops like AND or 
OR. I wonder what the "query with CQL" link does...

Thanks for your feedback

Etienne


-- 
Etienne Dubé
Developer

Boréal Informations Stratégiques
101, Du Moulin, bureau 202-A
Magog (Québec)
J1X 4A1
Canada

Tel. :  514.313.5951 #1131
Email: etienne.dube at boreal-is.com