On Tue, Mar 10, 2015 at 4:23 PM, Andrea Aime <[email protected]>
wrote:
> On Tue, Mar 10, 2015 at 11:07 PM, Martin Davis <[email protected]> wrote:
>
>> Not sure I get all the constraints around this 100%, but generally the
>> idea sounds good. I like the idea of being able to take control of the
>> filter condition SQL being used (which pretty much requires access to the
>> $bbox parameter). And it's a good idea to make it optional, so it isn't
>> always executed.
>>
>> Just to be clear, the %BOX%{and ST_Intersects(g.geom,$bbox)} syntax would
>> be added to the SQLView SQL text?
>>
>
> Yep
>
>
>> Is the $bbox variable already available?
>>
>>
> No, it would be something new that we replace only withing the context of
> a %BOX%{....} thing (aside, not really in love with the syntax,
> any suggestion to make it look better? or just can just say that you like
> it)
>
Yes, syntax is a bit ugly, but it follows the current pattern of using %
for parameters. The only change I might suggest is to use:
%BBOX({...})%
(That is, % delimits the entire substituted expression, which can itself
contain parameters with the ( ) block. The { } delimits raw code strings.
This syntax would support future extensions fairly well I think)
>
>
>> Would an alternative be to use the same kind of syntax to specify the
>> actual geometry column to use in the bbox filter? That would be less
>> general, but also less error-prone.
>>
>
> No, that would require geoserver to understand the sql, and know where to
> add the filter, as said, would like to avoid going there.
>
Why? There would be no more parsing of the SQL than currently done to
replace parameters. What I'm suggesting is to supply a hint to the WMS SLQ
builder, to use a different geometry name than the one identified from the
query. E.g.
select SDO_GEOM.SDO_CENTROID(GEOMETRY, 1) PT from CUT_BLOCK_SP
%QUERY_GEOM(GEOMETRY)%
The parameter would be removed from the SQL (e.g. substituted with '') and
the contents provided as a hint to the query builder. But maybe I'm not
understanding how the current process works?
> You know your sql, you place the optional box filter in the suitable
> position, with the suitable syntax.
> For the point from x, y case we might also want to provide
> minx,miny,maxx,maxy.... actually, just providing these
> could also be the way to go, if you want to build an envelope you have the
> spatial db syntax to do so.
> Just thinking out loud.
>
+1 on providing minx, miny, maxx, maxy - that's more general-purpose.
<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.
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
