With the JDBC DataStore, there exists a direct connection between the query parameters and what comes out of the data store. In that case it is certainly possible (even easy) to do some of the filtering within GeoServer. However with stored queries, there is a relationship between the input parameters and the output properties, but that relationship is unknown. From a systems point of view, the stored query is a black box.
I’m beginning to suspect that the disconnect between input properties and output properties will cause issues in other places of GeoServer as well.
However, we could see the filter operands as filtering based on either input or output properties separately. Maybe the filter strategy could be something like:
It’s possible the operands applicable for the pre-filter are placed in the query tree in a way that a single pre-filter will not be able to satisfy the entire query. (FOO = ‘bar’ OR FOO = ‘zoo’) In this case, the original query would need to be split into separate pre and post-filters which would be executed separately. Finally, the results from all split queries would be combined and duplicates removed (identified by fid or another property configured for the stored query).
This still does not give us a 1:1 model with OGC queries though. Any other operands than literal equivalency targeted at the input parameters could cause unexpected behavior.
···
On Mon, Mar 17, 2014 at 1:57 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:
You know that filters do not only come out of the WMS GetMap right? Each datastore query is constructed from the WMS GetMap information combined with the WMS style. Many styles have multiple rules, each one of which has a Filter.
It is this combination that forms the individual queries that are sent to the datastore.
The JDBC DataStore implementation has a similar limitation (not every filter can be expressed in SQL). In this case the Filter is split into two: the part that can be sent to the database, and the part that (as Andrea indicated) must me done in locally in Java.
Not trying to discourage you, just let you know what you are up against. GetMap requires a fairly general purpose WFS Query due to styling.
Jody
–
Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc
This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.
Jody Garnett
On Mon, Mar 17, 2014 at 10:50 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:
Learn Graph Databases - Download FREE O’Reilly Book
“Graph Databases” is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
On Mon, Mar 17, 2014 at 1:35 PM, Andrea Aime <andrea.aime@anonymised.com8…> wrote:
Stored queries do not support OGC filters or anything as expressive. Therefore there is no way to support any and all filters. Consider a OGC filter which specifies a PropertyIsBetween operand and mapping that filter to a query which only supports a single value for that parameter. Also note that with stored queries, there is no fixed relationship with request parameters and data in the output format. e.g. you could have a request parameter YEAR_OF_BIRTH and the output data would include the percentage of senior citizens in that age group. This means that you can’t read a wider data set from the data store and then just execute the filter within GeoServer to come up with the correct response for the query.
There is no generic way of solving this, and the only direction I can currently come up with requires stripping down what the data store allows to do. Of course it’s another question altogether how the strategy to cope with unsupported operands. We can decide to be either strict or relaxed.
S.
–
Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc
This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.
On Mon, Mar 17, 2014 at 12:31 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:
You are not writing a valid store if you decide which queries are acceptable, and which are not, a valid store
must work with all possible incoming filters, if they are not giving you the parameters you need, you’ll have
to replace them with some reasonable defaults I guess.
On Fri, Mar 14, 2014 at 3:24 PM, Andrea Aime <andrea.aime@anonymised.com8…> wrote:
I’m thinking I could deal with mapping WMS dimensions to Stored Query parameters like so:
- Only “and” filters are accepted (nested or flat)
- All filter operands must assert equivalence of a property to a literal value, or a bounding box
- The equivalence filters would be mapped as stored query parameters (property => parameter name, literal => parameter value)
- Bounding box is given in the format appropriate for the stored query in question (in my case, it’s given OGC BBOX KVP style to the stored query)
The first two steps are checked in the data store and the query is aborted if it contains operands that are out of scope.
Do you think this would work? And are there corner cases this simple model doesn’t cover?
On Fri, Mar 14, 2014 at 11:49 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:
To support parameters for the stored queries, the WMS dimensions need to be leveraged to pass on any dimension values to the WFS 2.0 data store.
Ah, those go down as filters… and I guess this might be a problem? With stored queries you are pretty much stuck with whatever
is in the query template, cannot pass more filters down (and you need to understand how the generic filter GeoServer will give you
is mapped in the stored query, which means, understanding the stored query itself…). Any other filter will have to be run client side
(which is of course inefficient…)
And thanks for checking with the community to determine scope. We find the occasional project which gets as far as making a pull request, but did not leave enough budget for test coverage and documentation.