Opened 20 years ago

Closed 20 years ago

Last modified 20 years ago

#1006 closed defect (fixed)

WMS GetLegendGraphic produces a GD error

Reported by: dmorissette Owned by: mapserverbugs
Priority: high Milestone: 4.4 release
Component: WMS Server Version: 4.3
Severity: normal Keywords:
Cc: bartvde@…, valik.solorzano.barboza@…, astrid.emde@…

Description

Astrid Emde wrote:
> Hoi Daniel,
> 
> thanxs for your help. Thinks still don't work fine. That'S why I send 
> you some more informations.
> 
> Daniel Morissette wrote:
> 
>> Astrid Emde wrote:
>>
>>> Hello,
>>>
>>> wenn I send my getLegendGraphic-Request I get the following error:
>>>
>>> msDrawLegend(): GD library error. Unable to initialize image.
>>> msImageCreateGD(): Image handling error. Cannot create GD image of size
>>> 60 x 0.
>>>
>>> Does anyone know, what can be wrong? How can I solve the problem?
>>>
>>
>> Is this using the 4.4.0-beta1? If not then the first thing to do would
>> be to try 4.4.0-beta1.
> 
> 
> O. k. - I did ms 4.2.5 at the beginning. Not realyx up to date. But know 
> I tried my map with ms 4.4.0 and still I get the message.
> 

... testcase was attached to the email. Cannot attach to this bug.

Change History (9)

comment:1 by dmorissette, 20 years ago

Milestone: 4.4 release
Status: newassigned
Looking into this now. I am able to reproduce locally using Astrid's mapfile and
the following URL:


http://sb1/cgi-bin/mapserv_43?map=/tmp/bug1006/legend/obk_kreisuebersichten.map&VERSION=1.1.0&REQUEST=getLegendGraphic&SERVICE=WMS&LAYER=flurbereinigung_t&FORMAT=image/gif

comment:2 by dmorissette, 20 years ago

Cc: bartvde@… added
I found the source of the problem: this happens because the specified layer or
all its classes are out of scale at the default mapfile extent's scale, so there
are 0 items to display in the legend which results in a 0 vertical size. I'm
surprised that this never happened before with the CGI.

In bug 809 comment 9 and 10 there were some discussions of forcing the layer
scale in the case of GetLegendGraphic to force something to be returned. I think
that would solve the current problem as well.

comment:3 by bartvde@…, 20 years ago

Cc: valik.solorzano.barboza@… added
Added Valik to the cc.

Also, here is a response from Craig Bruce from Cubewerx on the wms-dev list 
(Sept 2004). What the Cubewerx server does is also an option I guess:

"The legend/scale determination can be done by the client.  It can examine
the rules to determine if a layer/rule shows anything or not.  However,
if a GetLegendGraphic request is actually sent to a server for a layer
that will display nothing because of scale rules, then we can assume that
the client is not entirely smart enough to filter it out and that it is
probably expecting to receive back and display an image.  The best thing
for the server to do is to return an image that somehow indicates that
you will see nothing on the map for the layer/rule.  CubeWerx returns a
small image with the letters "N/A" painted into it."

comment:4 by dmorissette, 20 years ago

I think what I'll do for this specific bug is add a
scale_independent=MS_TRUE|MS_FALSE arg to msDrawLegend(). When called from the
WMS GetLegendGraphic interface, unless a scale was explicitly specified in the
URL then I would pass scale_independent=MS_TRUE and all classes in the layer
would be returned in the legend, whether they are in scale or not. A minor
side-effect of this is that if multiple classes were available for the same
objects at different scales then they would all show up.

How would that sound?

Note that if a scale is specified then the behavior would be unchanged. (We
would need a new bug for the N/a thing if we want to do it)


comment:5 by dmorissette, 20 years ago

Um... to solve the side-effect mentioned above, if there is no explicit SCALE in
the request and the classes in the layer have a minscale/maxscale set then we
could decide to use the minscale of the first class as the default scale for the
layer and then show all classes that match that scale. As a minimum we would
always get the first class, and for sure we would never get duplicate legend
items for classes that cover non-overlapping scales for the same objects.

I think I'll go with that unless I hear objections.

comment:6 by bartvde@…, 20 years ago

Sounds okay to me, assuming that this behaviour will only occur if no Rule is 
specified in the GetLegendGraphic request. If somebody asks for a specific Rule, 
then it would be unwanted to have all classes/rules returned. But the Rule 
parameter has not yet been implemented AFAIK (bug 843).

comment:7 by dmorissette, 20 years ago

Resolution: fixed
Status: assignedclosed
I have committed the fix described above to the 4.3/4.4 CVS. However since
msDrawLegend() ignores class->scale, the scale_independt argument only applies
to layer scale.

One potential problem remains: if the specified layer has no class, or none of
the classes have names then we would still get this exception. A possible fix in
this case could be to return an image with "N/A" icon as suggested by Craig
Bruce, but that will have to be the topic of another bug.

comment:8 by dmorissette, 20 years ago

Bug 1007 was created about the possible problem with layers that contain no
classes with a name which would still trigger this exception.

comment:9 by astrid.emde@…, 20 years ago

Cc: astrid.emde@… added
Note: See TracTickets for help on using tickets.