After investigating this further, I was going to create an issue in jira
proposing to change the way KMLLegendTransformer works. Currently, it
relies on a GetLegendGraphic request to produce a full-fledged legend,
despite that being contrary to its spec. The KMLLegendTransformer
should figure out what rules apply and create the "representative
enough" legend graphic and produce appropriate KML for Google Earth to
display. As it is, it generates a GetLegendGraphic request in KML.
Feedback is more than welcome. A coworker is looking into getting
possibly funding for this.
Thanks,
Wayne
Wayne Fang wrote:
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
