Back to your actual proposal - still a great idea!
Clarification - Query does not accept a list of strings - that is a helper
method. The actual data structure is:
protected List<PropertyName> properties;
And is available via query.getProperties().
Since these are PropertyName instances they have a bit of namespace info
and can be XPath expressions.
I have a couple of research questions. They may just end up as discussion
points, but they may influence if we can encode this stuff for the WFS
client data store.
Q: is it really called an SQL projection? I would of considered it an SQL
function or data transform with SQL :)
A: yes it is - http://www.postgresql.org/docs/6.5/static/sql-language.htm
In that case we are going to have fun naming these new methods for the
Query object.
Q: Do we represent projections using CQL (like in Transform) or using XPath
(like in WFS)?
I tend to like our extended CQL for everything, but we should at least look
at how XPath functions work as we will need to know when encoding these for
WFS DataStore.
This is where we need some input from Ben on how XPath is used in anger.
WFS 2.0 Research: WFS 2.0 has Minimum XPath and Schema Element Function.
Appears to only use a subset of XPath which does not look like it supports
functions. They have examples such as
*addresses/Address[street="Oxfordstrasse"]/number* used to select a
specific element out of a list.
We still have the option of allowing GeoTools to support a greater subset
of XPath and include our projection here.
Aside: I also suspect that this facility will allow us to implement WFS 2.0
Stored Queries quite well for GeoServer :)
Jody Garnett
On Thu, Apr 17, 2014 at 7:22 AM, Anthony F <[email protected]> wrote:
> All,
>
> I'd like to propose a change to the Query api that will enable SQL-style
> projections (as opposed to geospatial projections).
>
> The Query class currently has a variant that includes an array of String
> properties that specifies a sub-type of the feature schema. This is
> especially useful in e.g. Geoserver because rendering does not necessarily
> require all attributes. Each data store can optimize these types of
> queries to only transfer the minimal set of data required to satisfy the
> query.
>
> Geotools also has a transformation API (in gt-transform) that allows an
> application to transform (rename, compute transformations on multiple
> properties, etc) in a very flexible way. However, the transform API does
> not delegate to the underlying data store. Rather, it builds a
> TransformFeature* that dynamically maps the data to the new schema on the
> fly.
>
> I propose that we unify these two concepts and allow data stores to
> optimize the transformation. For instance, PostGIS could optimize a query
> such as:
>
> select id as identifier, strConcat(id, name) as uniqname, buffer(geom,
> 0.01) as bufferedgeom from geom table where ....
>
> which combines renaming of attributes, mapping of multiple attributes to a
> single attribute, and geometric computations in a single query. In the
> case of the GeoMesa data store, these transformations can be executed in
> parallel across a distributed set of compute and storage resources.
>
> To support this capability, we would need to modify the Query object to
> take a data structure very similar to the transform api. This consists of
> Definitions and contained Expressions. The FeatureSource will then compute
> a new schema based on the transform and return a collection representing
> the mapped result. The data store could then optimize the population of
> the collection using whatever capabilities it has available to it.
>
> The first two DataStores targeted for this functionality could be GeoMesa
> and ContentDataStore. ContentDataStore can construct a TransformFeature*
> to do the transformation on the fly while GeoMesa could interpret the
> transformation and parallelize the computation.
>
> Thoughts?
>
> Also, question on procedure: should this email thread turn into a proposal
> on confluence or jira (if it gets that far)? How do these things normally
> work?
>
>
>
> P.s. I've hacked a version of this into the GeoMesa code base as I had a
> need for it in an application. The hacked version intercepts the Query in
> FeatureSource.getFeatures(), treats the String array as a
> Definition/Expression string, and builds the new schema. It then rewrites
> the Query against the original schema and sets up the parallelized
> transformation. Works quite well and provides *very* efficient map-reduce
> style computations using (E)CQL.
>
>
> ------------------------------------------------------------------------------
> 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/NeoTech
> _______________________________________________
> GeoTools-Devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
------------------------------------------------------------------------------
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/NeoTech
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
