Out of the box idea, and I realize this is a change the the oracle
datastore ... but couldn't you change the Oracle datastore to check if an
index exists in the data dictionary for the field you want returned before
emitting the SQL from a BBOX?
When the index exists for the desired column all is good and the filter can
be applied to that column, otherwise look for the first indexed column
using the natural column order defined in the data dictionary (this can be
manipulated within a view) and run the BBOX query against that column.
The queries to add into the Oracle Datastore would reference
the user_dependencies and user_sdo_index_metadata sys objects. There are
some ideas here on how to format the queries:
http://stackoverflow.com/questions/3101078/how-can-i-find-the-underlying-column-and-table-name-for-an-oracle-view
David
On Wed, Mar 11, 2015 at 4:35 PM, Martin Davis <mtncl...@gmail.com> wrote:
>
>>
>>>
>>> <wild craziness starts here>
>>>
>>> To think of this in a more general way, the issue under discussion
>>> reflects the fundamental dichotomy between WMS (rendering) queries and WFS
>>> (data) queries. For WMS queries it's useful to allow lots of scope to
>>> manipulate the data to reduce size, etc, whereas for WFS just the raw data
>>> is required. GeoServer already provides lots of capability to manipulate
>>> WMS data in the engine (e.g. Geometry Transformations), but currently
>>> limits what can be expressed on the server side. The recent PostGIS
>>> simplify addition is an example of providing a bit more capability, but
>>> IMHO that is still too limited and hard-coded.
>>>
>>> In the extreme case I can see that the user might specify an entirely
>>> different query in the SQLView for WMS usage. That's a bit extreme and
>>> error prone, though. So dialing that back a bit we get closer to what
>>> we're talking about - where various parts of the query can be altered for
>>> WMS usage. So far we've just talked about the filter part, but I think it
>>> might be nice to allow the geometry column to be manipulated as well - i.e.
>>> by substituting an entirely new expression for it. This would subsume the
>>> current PostGIS simplify capability, but in a much more general way. For
>>> example, a query could convert the geometry to a point, or simplify it
>>> using a custom function (e.g. decimation), etc.
>>>
>>> This might look like:
>>>
>>> select %GEOM( GEOMETRY, {SDO_GEOM.SDO_CENTROID(GEOMETRY, 1) GEOMETRY }
>>> from CUT_BLOCK_SP
>>>
>>> Note that the %QUERY_GEOM% parameter is not needed here, because the
>>> transformed geometry has the same name as the original, so it's fine to use
>>> the default GeoServer-generated filter.
>>>
>>>
>> Hemm... not in a place that allows me to think about it (and won't be for
>> several days) but... but I have the impression you're thinking about it
>> in too general terms, and it's not really fitting with the reality of the
>> actual operations and/or the existing code (at least, I read it and it's not
>> readily making sense to me).
>>
>> Let me put it another way. I'm proposing a way of giving the user the
> ability to define how geometries are transformed on the DB side to make
> them more efficient for WMS rendering (while still making the raw data
> available for WFS). The current PostGIS & DB2 simplify hacks are examples
> of doing this in a hard-coded way. But they're pretty limited. To do this
> more generally seems to require two things:
>
> 1. allow specifying a SQL transformation expression to be invoked only
> when the query is being made for WMS rendering
> 2. this may require some special handling of the WMS spatial filter (as
> provided by the %BBOX% parameter being discussed)
>
> MapServer apparently allows this, because it lets the user specify the
> entire query to be used.
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
