On Wed, Mar 11, 2015 at 4:03 PM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:
> On Wed, Mar 11, 2015 at 11:35 PM, Martin Davis <mtncl...@gmail.com> wrote:
>>
>> 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.
>>
>
> I believe you're not appreciating what GeoServer tries to be here. It's
> meant for end users, forcing people to write sql queries by hand in order
> to get
> the benefits of generalization is simply not acceptable, a checkbox is all
> that many users are willing/able to deal with.
>
> And I'm not saying that we should not care about developers that want to
> push the boundaries, we also want to reach there and improve
> over those cases of course (we would not have sql views to start with if
> we were not trying), but belittling the on the fly generalitation
> work as a hack is imho missing the point of what GeoServer tries to
> provide to the larger user base.
>
Hey, no offense intended. It's great to make things easy for users. I'm
just exploring how to get a bit more power into the hands of those who want
it.
>
>
>> 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
>>
>
> 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?
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.
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.
>
>
>> 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.
>>
>
> GeoServer does something similar with sql views, but it's more ambitious
> in the implementation in that it pushes
> more filters down into the db, not just the bbox, and it's not geared
> towards wms only, but any type of data access.
> You are having a problem with it because your sql view is creating a
> geometry on the fly, it's a case we
> don't cover efficiently now, but we can improve on it.
>
Excellent!
------------------------------------------------------------------------------
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
