[Geoprisma-dev] Attribute filtering

[Julien-Samuel Lacroix]

Hi,

After giving it some thought on my side, I think the best way to go is 
as you describe. Develop a GeoExt UX that allow attribute filtering and 
apply it only on the client side in the beginning. Then when we will 
want more performance, we will add a WFS service type in GeoPrisma and 
modify the UX to support WFS Filter.

I advise you to contact the GeoExt-dev list right away though. You will 
probably have some nice feedback. Also create yourself a sandbox in 
GeoExt SVN and put your code there.

Julien

On 10-11-02 10:06 AM, Etienne Dube wrote:
> Hi Alexandre,
>
> We don't need access control based on filters for this specific project,
> but it's still something that's on our wishlist. I see that as somewhat
> different from the attribute filtering widget, since this kind of access
> control would have to be implemented server-side (probably by putting
> some logic in the proxy) to offer any real security.
>
> I started coding a first chunk of the widget, and will post to
> GeoExt-dev when I have something to show.
>
> Thanks for your feedback,
>
> Etienne
>
>
>
>
> On 01/11/2010 8:12 AM, Alexandre Dube wrote:
>> 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
>>>
>>
>>
>
>

-- 
Julien-Samuel Lacroix
Mapgears
http://www.mapgears.com/