On Wed, Mar 11, 2015 at 8:12 PM, Martin Davis <mtncl...@gmail.com> wrote:
>
>
> On Tue, Mar 10, 2015 at 4:23 PM, Andrea Aime <andrea.a...@geo-solutions.it
> > wrote:
>
>> On Tue, Mar 10, 2015 at 11:07 PM, Martin Davis <mtncl...@gmail.com>
>> 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)
>
>
I like the idea of % going around the entire code, not sure about the
double parenthesis ({ })... any specific reason for it?
>
>
>>
>>
>>> 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)%
>
We do not do any parsing, just a lame string replace? And you are assuming
you have a source geometry, which currently the
sql views do not have. If you are making a point from x/y you don't really
have anything to work against.
If you have a geometry with funky processing on it (e.g., a offset) then
you don't want to apply the filter on the original geometry,
you need to un-offset it first.
> 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.
>
>
Cool
>
> <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).
Cheers
Andrea
--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
-------------------------------------------------------
------------------------------------------------------------------------------
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
