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 On Thursday 24 July 2008 10:42:27 pm Justin Deoliveira wrote: > Hi Wayne, > > Your reasoning makes sense. I believe these exact semantics were > implemented because that is the way MapServer does its legend graphic > generation. > > I would not be against including labels by default. It might be good to > see what some of the other folks on this list think. > > -Justin > > Wayne Fang wrote: > > I was looking into the Legend feature and came across some behaviour > > that strikes me as odd. According to the GetLegendGraphic Improvements > > document > > (http://geoserver.org/display/GEOSDOC/GetLegendGraphic+Improvements) in > > section 5: > > > > * If there's just one Rule for a legend, no label is supplied > > * If there is more than one Rule for a legend, labels are supplied > > > > I'm not clear what the use case is for a legend with a single item with > > no label attached to it; it seems to defeat the purpose of a legend. > > There's a forceLabels option to force labels on or off, but I would > > think the following behaviour is more intuitive: > > > > * Draw labels by default. > > * If forceLabels is set to 'on', then draw labels. > > * If forceLabels is set to 'off', then don't draw labels. > > > > Can somebody explain the reasoning behind this to me? If not, I'd like > > to change it. > > > > Thanks, > > Wayne > > > > -- > > 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=/ > > > > !DSPAM:4007,48890ed616885210051143! > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Geoserver-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > > > > > !DSPAM:4007,48890ed616885210051143! ------------------------------------------------------------------------- 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
