This is an interesting idea. Are you thinking that this filter would be representable as CQL or even as an extension to filter encoding queries and thus the client could make the choice between normal filter encoding and stored queries? Or would a cascaded FeatureTypes in GeoServer be configured to target either normal filter encoding GetFeature requests or a specified stored query?
···
On Mon, Apr 14, 2014 at 5:49 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:
I like your thinking Justin.
So if stored queries are sufficiently whacky enough we can create a new interface:
public class FeatureQuery {
FunctionName getFunctionNames();
FeatureCollection storedQuery( Function );
}
public class SimpleFeatureQuery extends FeatureQuery{
SimpleFeatureCollection storedQuery( Function );
}
The above depends FunctionName which describes both the name of the query and the available parameters.
–
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, Apr 14, 2014 at 11:53 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
On Fri, Apr 11, 2014 at 5:54 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:
Hi justin,
Maybe stored queries might be represented as a dimension for the layer. The default dimension would be to use no stored query, while stored queries returning values for that particular feature type would be values for that dimension. What do you think?
I am not exactly sure what this woudl look like. Can you elaborate?
I wonder if trying to represent it as a filter function makes more sense. The same way that jdbc datastores map filter functions to native functions the wfs datastore could map filter functions to stored query calls? Problem is I don’t believe there is any api that would expose such functions… aside from having the wfs datastore product an implementation of FilterFunctionFactory. Anyways, just a thought.
And yes, I am checking that the the WFS supports stored queries before doing anything. Which actually brings up a small question regarding the WFS spec: when does a WFS service support executing stored queries? Does it have to support ListStoredQueries or DescribeStoredQueris or both
As Ilkka mentions in his reply these are supposed to be part of the lowest level of conformance (which surprised me) but I do still think it would be a good idea to check the OperationsMetadata of the capabilities document as the authoritative source. Which we will probably want to do anyways in order to check whether we can create new stored queries, etc…
Sampo
–
Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive
On Fri, Apr 11, 2014 at 2:24 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Hey Sampo,
I think what you propose sounds perfectly reasonable. I agree that stuffing stored queries into a feature type might prove tricky but I am not sure I see a better way. It is also kind of consistent with the way that jdbc datastores handle sql views.
Btw, I am assuming that the wfs client will check the capabilities doc to see whether stored queries are supported before querying?
-Justin
–
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 Wed, Apr 9, 2014 at 11:49 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:
Hi Jody (& the list),
Sorry, I should have framed my question better. My question was regarding to the WFS DataStore work I’m currently doing, which is writing WFS 2.0 Stored Query support to WFS-NG.
At least for the time being, I’m adding the stored queries as special feature types the WFS DataStore reports along with the usual feature types. For these special feature types, the data store will then use stored queries instead of filter queries. As this model requires the data store to enumerate all available “feature types” at once, it requires ListStoredQueries to happen as GeoServer requests the list of feature types. This will then happen immediately as a new wfs-ng DataStore is registered and henceforth every time a GeoServer with such a DataStore is started. As for the DescribeStoredQuery, I expect that will happen only when that “feature type” (or information regarding it) is actually requested through the DataStore API. From where I’m sitting, this seem acceptable, but feedback and comments are always appreciated.
Fitting the Stored Queries as feature types feels quite crufty though. I’d love to get a conversation going if there’s a better way to model the stored queries.
Sampo
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive
On Thu, Apr 10, 2014 at 1:17 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:
When the GetCapabilities document is produced? Since the stored queries are listed in the WFS 2.0 GetCapabilities document right? There is no guarantee that a client will use the GeoServer user interface (since that is just for configuration).
–
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, Apr 7, 2014 at 10:13 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:
Hi,
I was wondering if anyone had given thought as to what would be the appropriate time in the lifecycle of a WFS DataSource to discover what stored queries are available?
Would it make sense to run both (or just DescribeStoredQueries without a query id filter) at the same time the capabilities are loaded? Or should the client retrieve the list of possible queries only after the UI asks for the list of feature types available for a particular WFS Data Source?
This has probably been thought through when designing the database data sources and it would make sense to use the same pattern here.
Thanks,
Sampo
–
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.
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel