-----Messaggio originale-----
Da: geoserver-devel-bounces@lists.sourceforge.net
[mailto:geoserver-devel-bounces@lists.sourceforge.net] Per
conto di Andrea Aime
Inviato: giovedì 4 gennaio 2007 11.26
A: Fabio Da Soghe
Cc: 'geoserver-devel'; 'Geotools-Devel list'
Oggetto: Re: [Geoserver-devel] R: [Geotools-devel] Attacking
the tiling rendering issues (Geoserver, but uDig too)Fabio Da Soghe ha scritto:
>> From a user point of view, I'd prefer to configure
Geoserver, setting
>> the metabuffer size once for every layer (== feature type).
>> This not only for convenience, but it can happen one is
using a third
>> party WMS client library and it could be impossible or at least
>> time-consuming to properly configure in order to have it
supply the
>> custom WMS hints (if I understand well, the metabuffer
options have
>> to be supplied as part of every WMS request).Ouch... what clients do you know that make providing custom
WMS parameters hard/impossible?
Actually we're using only OpenLayers, so I know only it. And it's not impossible nor hard to make it provide a custom WMS parameter. My consideration was more regarding to two other points:
1) there could be scenarios where one cannot modify the WMS request, because it's deeply embedded in the thirdy part client; maybe the client itself is not a library but a final client application, where the user cannot/don't know how to set that custom parameter;
2) moving the logic regarding the association between layer and metabuffer size outside Geoserver makes necessary for every application using tiles to menage this association; so I end up to do the configuration work for every application I deploy that uses the same Geoserver instance. It seems a duplicate work (but maybe only for me: I wrote more about this below).
> I don't understand why this is not possible, at least regarding the
> metabuffer issue, which is one parameter (extra pixel size
for every
> feature type). The extra pixel size has only the effect to
take into
> consideration for rendering a bigger number of features,
but the SLD
> has to be applied as usual, regardless of its origin
(default style,
> specified in the request, custom SLD).What I mean, is that the user provides an SLD, then whatever
buffer you set against the FeatureType (in the geoserver
configuration) may be too small.
My point is, the metabuffer size is related to the SLD you're using.
Since GetMap allows the user to decide whatever SLD he may
want, he has to provide us with a proper metabuffer as well.
Now I got the whole point.
Well, at least conceptually I agree with you: a style with a little cell needs a smaller metabuffer then a style with a big cell. So you should be correct.
What I still think is that, at least in my (little) experience, it's rare to need more then one style on the same layer. I see always I need to put on a style for every FeatureType, appropriated for the application that uses that FeatureType, and that's all. So there's always a one-to-one relationship between feature type and metabuffer size.
But of course I'm only one user of Geoserver: I understand your position, where you have to take care of every possible type of user, so probably your solution is better.
I'm still concerned about a "closed" client. For example, how a uDig-tiled would act with this solution? It should be extended with some preferences where the user has to put in the metabuffer size?
Moreover, I don't want to spend another half a day just to
add a single parameter to Geoserver... I may end up to, but
the very idea of putting my hands again in that mess makes me
shiver...
I see. What is the mess you talk about? The configuration web pages where the metabuffer and other additional FeatureTypes options should have be put?
Cheers,
Fabio
Cheers
Andrea--------------------------------------------------------------
-----------
Take Surveys. Earn Cash. Influence the Future of IT Join
SourceForge.net's Techsay panel and you'll get the chance to
share your opinions on IT & business topics through brief
surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge
&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
