[Geoprisma-dev] Attribute filtering

[Alexandre Dube]

Etienne,

   I totally agree that this could be a GeoExt.ux widget.  All the 
features you mentioned about it have no direct dependence on GeoPrisma.  
A thread could be started on the GeoExt-DEV ML.

   In you project, do you need any access control using filtering ?  For 
example, "restrict the data X to a given extent and a given attribute 
having a specific value to the user Y".   If so, that could be discussed 
here.

Regards,

Alexandre


On 10-10-29 03:11 PM, Etienne Dube wrote:
> Hi guys,
>
> We have a new requirement in one of our projects, that involves 
> attribute filtering on a vector layer. What's needed is a widget that 
> allows the user to filter the features to be displayed by specifying 
> an attribute, an operator and a comparison value. One or more of these 
> criteria could be combined using logical operators (AND/OR) to create 
> more complex queries; eventually multiple filtering expressions could 
> be combined by forming a tree of conditions, similar to what the OGC 
> Filter Encoding standard describes. Such a feature has already been 
> discussed previously (see ticket 
> http://trac.osgeo.org/geoprisma/ticket/38).
>
> I spent some time defining the problem and exploring what tools could 
> be used to solve it. A few thoughts:
>
> - We could offer two different modes for this widget:
>
>     1. A preconfigured mode, in which the choices of attributes (and 
> possibly operators) to filter on, along with the logical operators 
> used to combine these criteria, would be defined in the widget's 
> configuration. Different preconfigured query templates could be 
> defined in this way, for every layer the widget applies to. The user 
> would only have to fill in the values to filter on.
>
>     2. An "expression builder" mode. In this case, the choice of 
> attributes, operators and any logical combination (AND/OR) or criteria 
> would be left to the user, and a GUI panel would be provided to build 
> these expressions. This mode mostly targets GIS specialists and other 
> power users who have an understanding of boolean logic, in order to 
> fulfill various free-form querying needs.
>
> - Initially we could provide support for vector layers only. 
> OpenLayers already provides the OpenLayers.Filter classes to build the 
> filtering expressions, and is able to do filtering on the client side. 
> However, since it's not a particularly efficient way of doing things, 
> a way to pass the filter expression to the service would be desirable. 
> As Yves mentioned in ticket #38, FeatureServer offers basic attribute 
> filters as criteria passed in key/value pairs in a GET request, but 
> this support is quite limited: it seems that only 1 criteria per 
> attribute is accepted, there's no way to combine multiple criteria 
> using AND/OR operators (AND is the default when specifying a filter 
> for more than 1 attribute) and only the PostGIS data source is 
> supported for attribute filters. Short of extending FS and its 
> protocol, a solution could be to add a WFS proxy and pass a Filter 
> Encoding expression in the request (as you may know, OL already has 
> the logic to generate an ogc:Filter element from OpenLayers.Filter 
> objects).
>
> - Support for filtering WMS layers (issued from vector sources) would 
> be a good idea too. I believe it's possible by passing an ogc:Filter 
> as part of a SLD in the GetMap request.
>
> - OpenGeo developed a QueryPanel widget (it's in their GXP repository) 
> that offers similar functionality; see 
> http://workshops.opengeo.org/geoext/more_ogc/app.html. I've not been 
> able to make it work yet, and from what I see it can only apply 
> filters on WFS and WMS layers. Nevertheless, this could be a good 
> starting point.
>
> - For the moment we can settle with text boxes for entering filter 
> values, but it would be interesting to offer other control types (date 
> picker, selection list). Another cool feature to have would be the 
> ability to populate such selection lists with domain values (e.g. 
> coming from a catalog table in the DB). However I'm not aware if any 
> feature service (be it FeatureServer, WFS or MapFish Server) can do 
> that kind of stuff, and I think it wouldn't be extremely elegant to 
> have to establish an off-the-band connection to the data source for 
> retrieving those domain value lists.
>
> I think that the widget could be developed as a GeoExt ux first, since 
> it's usefulness goes beyond the scope of GeoPrisma. I'm writing here 
> to have some initial feedback, and I'm open to continue the discussion 
> on the GeoExt dev mailing list if you feel it would be more relevant 
> there.
>
> Ideas, suggestions and corrections are welcome.
>
> Etienne
>


-- 
Alexandre Dubé
Mapgears
www.mapgears.com