Hi Gabriel, Thanks for the explanation. The main issue, though, is that behaviour is inconsistent between the one and many cases. It wouldn't matter if the labels are on or off by default, as long as it was the same for all cases. We have a client thinking this is a bug (not a 'feature' ;-) ).
Thanks, Wayne Gabriel Roldán wrote: > Hi Wayne, > > off the top of my head, I guess the thing is more or less like this: > > The GetLegendGraphic operation is meant to produce a "representative enough" > graphic for the styling of a layer OR a rule, depending on the RULE parameter > being present or not. It is not meant to produce a full legend for the whole > map, as you can do with, say, ArcIMS. > Now, the spec does not mention those "representative graphics" including rule > names as labels. Moreover, it suggests (if it does not explicitly tell) that > no label shall be produced, since the client has access to the style > information and thus the rule titles are available to it. Hence the client > could compose the legend as it likes getting the graphic from the server and > the rule titles from the style document. > > But things are not actually that easy: geoserver does not implement the > GetLegend operation, it is optional, and most clients can't manage the > complexity of grabbing the raw style in xml, figuring out the rule names, > deciding when a given rule is visible or not depending on the min/max scale > settings, and making sure exactly the same scale is computed by it and the > server to avoid confusing legends. > > So in practice almost every client application just makes a single per layer > GetLegendGraphic call instead of one per applicable rule. This means the > server, to return a "representative enough" legend graphic needs to compute > which rules are applicable and stack a graphic of each one in the returned > image. That is also why the WIDTH and HEIGHT arguments for the > GetLegendGraphic operations are just _hints_ about the desired dimension of > the returned graphic, but the server is free to return a different sized > image (one way of doing that is respecting the WIDTH argument and stacking as > many images of the required HEIGHT as rules apply) > > All in all, whether to return the label at the right of the image for each > rule or not is an open question, the spec does not mandate anything about it, > and hence the custom parameters to force the labels on or off. One can even > say I want the labels at the left of the image because that's the natural way > in my locale. We can't currently do that, but is equally reasonable. > > Now, whether labels should be on by default or not is still open to > discussion, and there gonna be arguments in favor and against, equally valid. > Which, the the sake of flexibility, and given the SLD 1.0 spec is closed, we > could only add more custom parameters and default values for users to > configure the legends as they better fit them. Just be sure there won't be a > default configuration that fits all client needs. > > Sorry for the rant, hope it helps clarify a bit the situation though. > > Cheers, > > Gabriel > > -- Refractions Research Suite 300 - 1207 Douglas St Victoria, BC, V8W 2E7, Canada ph: (250) 383-3022 fax:(250) 383-2140 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
