>
>
>
>>
>> <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
