GetLegendGraphic output not aligned

[tomkralidis]

Using CVS, output of GetLegendGraphic graphics and text is misaligned and truncated.

process:

environment:
Linux devgeo.cciw.ca 2.6.5-1.358smp #1 SMP Sat May 8 09:25:36 EDT 2004 i686 i686
i386 GNU/Linux

- get latest CVS
- make clean
- ./configure
- make

mapfile CLASS def snippet:

  CLASS
   NAME "Other Areas"
   COLOR 0 204 200
   OUTLINECOLOR 0 0 0
  END

- test:

http://devgeo.cciw.ca/cgi-bin/mapserv/ecows?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetLegendGraphic&LAYER=man_OHMI&FORMAT=image%2Fgif

As you can see, graphics are positioned like:

rule1graphic
rule1text

...and should be positioned like:

rule1graphic rule1text

This is the case with point, polygon and line type data.

Valik (who did this fix for bug 653) did not have this problem.

[tomkralidis]

Hi,

As suggested by Valik, I tried using legend to see whether I get the 
same (bad) results, i.e.:

./legend ./config.map out.gif

...and I do (see attached below)

[tomkralidis]

output from ./legend output

[valik.solorzano.barboza@…]

Tom,

I have the feeling that is has something to do with your environment (Linux) or
the libraries you are using. My build uses the following libraries:

- curl-7.11.1
- EcwSdk-2.46
- freetype-2.1.9
- gd-2.0.21gif
- gdal-1.2.1
- jpeg-6b
- libpng-1.2.5
- pdflib-6.0.0p1
- proj-4.4.8
- regex-0.12
- xerces-c1_7_0-win32
- zlib-1.1.4

But the only one I would consider are freetype and gd. As you can see I'm
building under Windows. Would it be possible for you to check with the binary
and the required libraries I created under Windows and using your map file. Let
me know then I send you the binaries.

[dmorissette]

That's odd, I'm not aware of any recent change to the legend stuff. In fact the
last time maplegend.c was touched was in June... I'd be tempted to think that it
must be something wrong with your installation.

Tom, just to rule out the possibility that the problem could have been
introduced by Valik's changes, could you try reverting to a 4.3 CVS version from
before Valik's changes (cvs update -D 20041014) and see if the legend problem
was there as well.

I'll add Steve to the CC of this bug in case he's aware of changes that could
have caused this.

[tomkralidis]

When reverting back with this version, I get back the same result, i.e.
requesting via OGC:WMS GetLegendGraphic gives me back the last class (i.e. as
per bug 653), and running via:

http://devgeo.cciw.ca/cgi-bin/mapserv/ecows?mode=legend&layers=hydroshedg

...I get back the problem as per this bug (misaligned icons/text).

[dmorissette]

What do you get if you try the itasca demo on your server?

[tomkralidis]

Well, it seems that one needs to define a LEGEND object per se in the mapfile,
even for WMS mapfiles.  Doing this does the trick.  All examples below now work
as expected.

Still, in the context of WMS mapfiles, not defining a LEGEND object gives back
the misaligned output.  Should it be like this?  Or should there be a default
output format for GetLegendGraphic if no LEGEND is defined?  Mind you, the
output I was getting before may well be the 'default' ;)

[valik.solorzano.barboza@…]

Tom,

sounds great. I would say in the case the request is a WMS request then the
LEGEND object should be ignored, which if I understand it well from you it is
not the case now.

Daniel or Steve what you think?

[dmorissette]

It's a tough call. Generating a default legend object defeats the purpose of
having a legend object in the mapfile in the first place.

I'd be tempted to say that we should produce an exception if someone produces a
GetLegendGraphic when there is no legend object.

[dmorissette]

Or even better: do not advertize GetlegendGraphic in the capabilities if there
is no legend object. Should also disable LegendURL I guess (bug 262).

Should this be reassigned to myself or Assefa, or do you still want to work on
this Valik?

[valik.solorzano.barboza@…]

I would say a combination of both actions should be implemented. If there is no
LEGEND object in the mapfile and the user issues a GetCapabilities then no
GetLegendGraphic should be advertized.
If the user requests a WMS GetLegendGraphic request and no LEGEND object is
defined an exception should be thrown specifying that a LEGEND object is required.

At this moment I don't see an easy way of determining whether an LEGEND was set
in the mapfile. What I see is that the parsing of the mapfile is done in
mapfile.c and in the function loadMapInternal(...) it is determined whether a
LEGEND object is available if not a default is used which was set in
initLegend(...), so actually there is a default LEGEND object but it looks that
the default values are not the right ones for the GetLegendgraphic request to
function properly.

Anyway I would propose to assign this bug to Assefa or to you, if I have time
(in the coming weeks) I will also have a look at it and will let you know

[dmorissette]

We'll reassign to mapserver-bugs for now. If you (Valik) have time to take the
bug before we get to it then please don't hesitate to steal it from us.  ;)

[tomkralidis]

We don't have to disable LegendURL in WMS Capabilities if a legendurl_href is
defined.  If no legend metadata is defined in the mapfile, a default LegendURL
object is printed out with a GetLegendGraphic call on the layer.

[tomkralidis]

Any update on this issue?  As most of our people have moved to 4.4.1, you now
see their WMSs with misaligned legend icons (i.e. no LEGEND object def).

[tomkralidis]

Any update on this issue?  As most of our people are now moving to 4.6.0. 
Wonder what the best behaviour is for WMS legends.

[tomkralidis]

So out path of action is:

• msWMSGetCapabilities: check if LEGEND object is defined in mapfile. If not defined, do not advertise GetLegendGraphic in Capabilities XML
• msWMSGetLegendGraphic: check if LEGEND object is defined in mapfile. If not defined, throw exception

Not sure how to check for LEGEND object in mapfile, however. If anyone has any advice/tips here, I can take this one.

[tomkralidis]

here's a snippet from irc this AM with some valuable info for this ticket:

> i.e. I'm able to check for, say map->legend.transparent, but not map->legend
<tbonfort> how do you check for those?
> i.e. if (map->legend.transparent) {
<tbonfort> if you can check for that then you should be able to check for map->legend
<tbonfort> what do you want to check for exactly?
> I want to check if a LEGEND object is defined in a mapfile (making changes to mapwms.c)
<tbonfort> it's filled in by default if none is present
<tbonfort> so map->legend is always true
<tbonfort> width status=width=height=0
<tbonfort> *with
> ok....see http://trac.osgeo.org/mapserver/ticket/966 for more details.
> maybe I need to check for specific things within LEGEND, as opposed to the object itself
<tbonfort> isn't the status enough ?
> not sure.  I'm working with http://rafb.net/p/BegcDv74.html as an example
<tbonfort> well you do get size and width at 0 if no legend is defined
<tbonfort> and explicitely setting width or size to 0 in a legend object would be a bit peculiar
> true
<tbonfort> but it would be a quite fragile test imho
> but wait...I get different results even if I set an empty LEGEND object.  If I set an empty LEGEND object (i.e. LEGEND\nEND), then I
+get aligned output.
> so, in this case, width would still =0 and size would still =0
<tbonfort> yes it is.... just checked
> so even if a LEGEND object is empty, it's still ok.
> and the default LEGEND which is set (if none is defined), produces misaligned output
> so what exactly happends, or is set/unset once an empty LEGEND object is defined?
<tbonfort> yeah.... it's created with default values... 
<tbonfort> don't know how you can get around that
> I thought maybe freeLegend, but what happens if someone has a valid legend defined
* tomkralidis wonders if legendObj would benefit from a legend->isdefault member

[tomkralidis]

Assefa: is SLD_BODY being processed at all via mapwms.c? The call is there, but doesn't seem to do anything.

http://devgeo.cciw.ca/cgi-bin/mapserv/carts?service=WMS&version=1.1.1&request=GetLegendGraphic&layer=cws&format=image/png&sld_body=<StyledLayerDescriptor><Name>Pearse</Name><Title>Pearse Drainage Areas</Title><Abstract>Pearse Drainage Areas</Abstract><NamedLayer><Name>cws</Name><UserStyle><Name>PearseStyle</Name><Title>PearseStyle</Title><IsDefault>1</IsDefault><FeatureTypeStyle><Rule><Name>foo</Name><PolygonSymbolizer><Geometry><PropertyName>msGeometry</PropertyName></Geometry><Fill><CssParameter name="fill">#FF0000</CssParameter></Fill><Stroke><CssParameter name="stroke">#999999</CssParameter><CssParameter name="stroke-width">2.0</CssParameter></Stroke></PolygonSymbolizer></Rule></FeatureTypeStyle></UserStyle></NamedLayer></StyledLayerDescriptor>

[tomkralidis]

FYI here are the three cases outlined:

1./

No legend object defined in mapfile:

​http://devgeo.cciw.ca/ms_tmp/wms-getlegendgraphic-no_legend_object_defined.png

2./

Empty legend, i.e.:

LEGEND
END

..defined in mapfile:

​http://devgeo.cciw.ca/ms_tmp/wms-getlegendgraphic-empty_legend_object_defined.png

3./

More detailed legend object, i.e.:

 LEGEND
  LABEL
   SIZE 10
   TYPE TRUETYPE
  FONT verdana COLOR 0 0 0
  END
 END

​http://devgeo.cciw.ca/ms_tmp/wms-getlegendgraphic-legend_object_defined_with_label.png

Basically, we want case 1 to look like case 2 and / or 3.

[tomkralidis]

FYI, please ignore comment:19 (bug response mania got me posting the info to the wrong ticket)

[dmorissette]

Checking this now.

[dmorissette]

The difference between cases 1 and 2 above (3 being essentially the same as 2 but with more params) is in the default values:

1- no legend: legend.label.position = MS_CC

2- empty legend: legend.label.position = MS_XY

This explains the behavior we've seen.

I'll check the legend generation code and see what's the best way to fix this.

[dmorissette]

Fixed in r6584.

We simply had to override the legend->label.position = MS_XY in initLegend() after initLabel() the same way as was done for the scalebar object.