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
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
> !DSPAM:4007,48890ed616885210051143!