Opened 20 years ago
Last modified 17 years ago
#966 closed defect
GetLegendGraphic output not aligned — at Version 22
Reported by: | tomkralidis | Owned by: | dmorissette |
---|---|---|---|
Priority: | high | Milestone: | 5.0 release |
Component: | WMS Server | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: | valik.solorzano.barboza@…, dmorissette, assefa |
Description (last modified by )
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.
Change History (23)
comment:1 by , 20 years ago
Milestone: | → 4.4 release |
---|
comment:2 by , 20 years ago
Cc: | added |
---|
comment:4 by , 20 years ago
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.
comment:5 by , 20 years ago
Cc: | added |
---|
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.
comment:6 by , 20 years ago
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).
comment:8 by , 20 years ago
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' ;)
comment:9 by , 20 years ago
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?
comment:10 by , 20 years ago
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.
comment:11 by , 20 years ago
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?
comment:12 by , 20 years ago
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
comment:13 by , 20 years ago
Cc: | added |
---|---|
Owner: | changed from | to
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. ;)
comment:14 by , 20 years ago
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.
comment:15 by , 19 years ago
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).
comment:16 by , 19 years ago
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.
comment:17 by , 17 years ago
Cc: | added |
---|
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.
comment:18 by , 17 years ago
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
comment:19 by , 17 years ago
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>
comment:20 by , 17 years ago
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.
comment:21 by , 17 years ago
FYI, please ignore comment:19 (bug response mania got me posting the info to the wrong ticket)