Ok, I've submitted a request for an account on Confluence.
> 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 nam
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.
So I have something working in GeoMesa. Intercepts the Query in the
getFeatures() method and applies transformations within the database. I'd
be happy to take a first pass at implementing it in the query API itself
with ContentDataStore and the GeoMesa data stores as initial targets.
On Sun, Ap
; On Sat, Apr 12, 2014 at 9:08 PM, Anthony F wrote:
>
>> I like the Transformation process/api quite a lot too. So I think a
>> reasonable approach to implementing this would be to intercept the Query in
>> the FeatureSource.getFeatures(Query) method and check if the li
n Sat, Apr 12, 2014 at 12:37 PM, Andrea Aime
wrote:
> On Sat, Apr 12, 2014 at 5:10 PM, Anthony F wrote:
>
>> In the Query api, I can specify a subset of columns that I would like
>> returned as part of my query. It would be useful if I could pass in a list
>> of transform d
In the Query api, I can specify a subset of columns that I would like
returned as part of my query. It would be useful if I could pass in a list
of transform definitions or expressions and have the underlying database
execute the transformations. This would be similar to a SQL projection
such as
