On Wed, Mar 11, 2015 at 5:00 PM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:
> On Thu, Mar 12, 2015 at 12:18 AM, Martin Davis <mtncl...@gmail.com> wrote:
>
>> 1. allow specifying a SQL transformation expression to be invoked only
>>>> when the query is being made for WMS rendering
>>>>
>>>
>>> What I proposed previously (the bbox thing) has no WMS specific
>>> limitations, and should still allow you to get what you want.
>>>
>>
>> Hmmm.... not sure how this would support rendering transformed
>> geometries, but get the raw data when needed via a WFS or GetFeatureInfo
>> query?
>>
>
> Oh ok, so you _want_ to make it WMS specific...
>
Yes.
>
>> Or is this is supported by (a) adding an extra transformed geometry
>> column (say GEOM_TRANS) to the SQL View query and then referring to that
>> column in the SLD <Geometry> element? If so then that seems like a good
>> solution.
>>
>
> Yes, this would be an approach... the downside is that your extra column
> would also show up in WFS.
>
Hmm, that's not good. A leaky abstraction....
>
>> It would also be nice to be able to alter the transformation based on the
>> scale of the current query (as is done in the built-in simplify
>> functionality, via the distance value). This might need some extra
>> built-in parameters being exposed for use in the SQLView query.
>>
>
> Uuuh... the result might become very confusing... in the simple case you
> might want to just change a function call,
> in the complex one you might have to rewrite half of the query.
>
Well, let's not let the best be the enemy of the good. I'd be happy if the
"simple" case was handled.
> For something like that I'd use a different approach:
> * create N sql views, one for each different data processing
> * attach a different style with scale dependencies to each of them
> * make them non advertised, and create a layer group hiding their structure
>
> The WFS/GetFeatureInfo case would be handled by the one layer that is not
> transformed, which you probably would advertise as normal
> (and remember to query for GetFeatureInfo in place of the group).
>
Um, this just throws the complexity onto the GeoServer admin and client
developer, IMHO. Not a preferred option in our environment.
>
> Another completely different angle could be to go fully SLD driven, have
> geometry transformations in SLD, and
> make it so that we encode the functions in sql equivalents (if the db has
> them)... but to go there, we'd first
> have to implement support for expressions in Query selection (as opposed
> to just listing properties), something
> that Jody has been pushing for, but that I believe has no funding yet...
>
Except this requires GeoTools coding whenever a new DB function is
introduced. Since the database happily provided "dynamic binding", it
would be nice to be able to take advantage of this in GeoServer.
------------------------------------------------------------------------------
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
