[Geoprisma-dev] Attribute filtering

[Alexandre Dube]

On 10-12-06 09:50 AM, Etienne Dube wrote:

> 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'm not sure I understand what you mean (I don't fully use all SVN 
features) but you have my full trust so do whatever you like.


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

Yep, they are.


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

I agree.  Resource-specific inside widget options is common among 
widgets using the XML configs, but the concept is inexistent in the 
PGSQLMapContextConfig driver.  We use resource and field options 
instead.  In the end, all config all outputs the same config_secur xml 
file and widgets that were complex (like the ResultExtGrid) were adapted 
to create resource-specific widget options using resource and field 
options, so the same could be done for this widget.  The only thing 
regrettable is that they become hard to configure.  Plus, there isn't 
currently a way to know the resource options required by widgets using 
the DB config.  You have to look at all resource options and find which 
widget use it [1].

You can look at the ResultExtGrid 'linkResource' method inside the 
widget .php file to see an example of creating the config_secur widget 
using the resource and field options.  We could do the same for this widget.

[1] 
http://www.geoprisma.org/dist/build/html/configuration/config/pgsqlmapcontextconfig.html#resource-options


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

I agree.  Like I said above, that becomes harder to configure but at 
least on user-end it's easier to use.  But, I think it would be 
beneficial to have one widget doing both. Asking the guys at OpenGEO for 
help could be good.


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

About the CQL, I think it applies to WMS layers.


Regards,

-- 
Alexandre Dubé
Mapgears
www.mapgears.com