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? Is the $bbox variable already available?
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.
On Tue, Mar 10, 2015 at 1:13 PM, Andrea Aime <[email protected]>
wrote:
> On Tue, Mar 10, 2015 at 7:45 PM, Martin Davis <[email protected]> wrote:
>
>> When you say "encode the search queries accordingly" do you mean leave
>> off the spatial filter entirely? That won't work in my case, there is too
>> much data to not use an index. I think what I want is a way to force the
>> use of another geometry column (but this seems like it would have to be a
>> bit of a hack - ie. look around to see if there was another geometry column
>> available and use that).
>>
>> This sounds a bit like your second suggestion. A bbox query against the
>> "original geometry" would work I think. Not sure how you would identify
>> the "original geometry" though? It would have to be present in the SQLView
>> columns, presumably - and then determined by just assuming the "other
>> geometry column" was the one to filter against? Or would require UI/model
>> changes to allow user to pick which geometry column is to be filtered by.
>>
>
> You would not identify the original geometry, GeoServer does not parse the
> sql view at all, does not know anything about it, and I believe it should
> stay that way, because doing otherwise would open a big can on worms (sql
> parsing, database differences, understanding calling stored procedures...
> ooof)
>
> Nope, what I'm suggesting is more similar to the mapserver way where they
> provide a "box" template parameter that will be replaced with a real bbox:
>
> DATA "the_geom from (select g.gid, ST_Union(g.the_geom, 10.0) as
> the_geom from geotable g where ST_Intersects(g.geom,!BOX!)) as
> subquery using unique gid using srid=4326"
>
> Now... I find the above still quite unsatisfactory, as you are forcing a
> intersection test even when you don't have one in your original query,
> and you have to make up a non existent bbox.
>
> Maybe something like this instead (open to alternative syntax):
>
> select .... from geotable where .... %BOX%{and ST_Intersects(g.geom,$bbox)}
>
> you know, a bit of sql that would be explanded only if we find that the
> query condition we have going on can actually be
> matched to some bbox (there is a filter visitor taking a filter and
> returning a bbox that would contain its results).
>
> This would be the "primary filter", the encoding of the full ifilter would
> still happen against the computed geometry like today,
> but it would end up being a "secondary filter" that just makes sure we
> return the right features (the fact the original geometry
> intersects the bbox does not mean its centroid matches the original query,
> and we need to provide correct responses, as
> this would also be used for WFS)
>
> Probably not a quick hack, but doable.
>
>
>
------------------------------------------------------------------------------
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
