evil man!
Actually, you've pretty much described the extension to app-schema Ben
and I have discussed, and I was going to have a play with once I'd
gort a coupel of other jobs out of the way...
Our idea was to create an "inverse mapping" using substitution
parameters - which is pretty much what you have discussed, with the
ability to allow a user defined one, or a well-known one such as
geometryless.
This will also solve another ugly problem - querying against
manufactured string values - for example a internal database ID being
append to a data-set-specific URN to create a globally unique
identifier. At the moment this is inefficiently queried.
Our goal, as you have suggested yourself is to remove sql-datastore
and geometryless as separate modules, and app-schema already has the
capabilties to do the forward-transform.
Rob
On Tue, Mar 23, 2010 at 7:21 PM, Andrea Aime <aa...@opengeo.org> wrote:
> Andrea Aime ha scritto:
>>> For example:
>>>
>>> SELECT id, name, url, ST_SetSRID(ST_Point(longitude, latitude),4326) as
>>> location FROM non_spatial_table;
>>>
>>> where longitude and latitude are numeric columns.
>>
>> You can, but it would not be worth using performance wise.
>> For example, a bbox filter against the feature type defined
>> above would be turned into the following sql query:
>>
>> select id, name, url, location
>> from
>> (
>> SELECT id, name, url,
>> ST_SetSRID(ST_Point(longitude, latitude),4326) as location
>> FROM non_spatial_table)
>> )
>> where location && <the bbox>
>>
>> which would not give enough info to the db to turn that
>> into a filter against longitude and latitude.
>
> Thinking thinking, evil thinking...
>
> Since we're already giving the user the control to make
> her own query, what about giving her the tools to make her
> own optimizations as well?
> What if, for example, we allow a variable substitution mechanism
> based on the simplest and more common filter, the bbox one?
> We allow the user to add a special part of the definition query
> that is actually expanded only if a bbox filter can be extracted
> from the original gt2 query, and then the user could give the
> jdbc datastore something like:
>
> select id, name, url,
> ST_SetSRID(ST_Point(longitude, latitude),4326) as location
> from non_spatial_table
> {where longitude >= $bbox.minx and longitude <= $bbox.maxx
> and latitude >= $bbox.miny and latitude <= $bbox.maxy}
>
> or something like:
>
> select id, st_buffer(geometry, 1500), name
> from my_spatial_table
> where flow > 143
> {and geometry && $bbox}
>
> Assuming the $bbox would be expanded into the literal representation
> of a bounding box for that database (using the sql dialect).
> Or, to make things a little easier for us, we pass down
> $minx, $miny, $maxx, $maxy and let the user build whatever she
> feels like with them.
>
> Too evil?
>
> Cheers
> Andrea
>
>
>
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Geoserver-devel mailing list
> geoserver-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
