[HTML Legend] Legend icons all the same color

[dmorissette]

Concerning this post:

> I'm using a dynamic legend and it's showing all my lines as red, even

> though I've classed them as different colors in the mapfile. This only

> seems to be a problem when I use OVERLAY-. The "under" color is always

> red and the "over" color shows up as whatever color is defined in the

> layer's first class. Has this happened to anyone else? Is it a bug?
 
I've attached a zip with the data, htmls and map file. I'm using the following
version on mapserver.

MapServer version 4.1 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG OUTPUT=WBMP OUTPUT=PDF
SUPPORTS=PROJ SUPPORTS=FREETYPE SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT
SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT INPUT=SDE INPUT=ORACLESPATIAL INPUT=OGR
INPUT=GDAL INPUT=SHAPEFILE
I hope the zip isn't too big. Let me know if it doesn't go through.
 
Thanks,
Amy

[dmorissette]

I am able to reproduce the bug with the data that Amy sent and the following URL:
http://127.0.0.1/cgi-bin/mapserv_41?map=/tmp/legendbug/nav.map&mode=legend&map_legend_template=legend.html

Looking into this now.

[dmorissette]

I found the source of the problem, but the solution may involve several code
changes so I'll describe the problem here and see what Frank/Steve think before
fixing it.

Note that this will happen only with 8 bits outputformats, so you can work
around the problem for now by using "IMAGETYPE PNG24".

---

OK, so the problem happens when you produce 8 bits legend icons for an HTML
legend for a layer that has multiple classes using the same symbol but a
different color, e.g.

  CLASS
  	EXPRESSION "2"
  	SYMBOL 'circle'
  	SIZE 3
  	COLOR 255 0 0
  	OVERLAYSYMBOL 'circle'
  	OVERLAYSIZE 1
  	OVERLAYCOLOR 0 0 0
  END
  CLASS
  	EXPRESSION "4"
  	SYMBOL 'circle'
  	SIZE 3
  	COLOR 0 255 0
  	OVERLAYSYMBOL 'circle'
  	OVERLAYCOLOR 0 0 0
  END
  CLASS
  	EXPRESSION "6"
  	SYMBOL 'circle'
  	SIZE 3
  	COLOR 255 255 0
  	OVERLAYSYMBOL 'circle'
  	OVERLAYCOLOR 0 0 0
  END

The function msCreateLegendIcon() creates a new gdImage and eventually calls
msDrawLineSymbolGD() for each legend icon, ausing the same 3 pixels circle
symbol for each class.  

The problem is with the imageCache where the brushes are cached: it carries a
pen number (integer) for each brush, but it should carry the full RGB color when
working with 8 bits images. In the case of 24 bits images, carrying the pen
number works since the pen number if a 24 bits RGB value, but in the case of 8
bits images the pen number is just an index in the color table of the current
image... and in the case of legends we have a new image for every icon. 

When the first legend icon is drawn, a "3 pixels red circle" brush is created
and added to the imageCache with color=1 (the pen id allocated for color "255 0
0"). When we come to draw the second legend icon, the color "0 255 0" is
allocated in the new image and gets the same index: color=1 ... then we lookup
the imageCache and find a "3 pixels circle with color=1" so it is used to draw
the second icon... that's why we end up with all legend icons the same color.

The solution seems obvious: store a ColorObj in the imageCacheObj, but doing
this cleanly would involve several changes in the code since the rendering
functions currently all work with pen numbers and not with colorObjs, so we
should ideally change the "fc" and "bc" variables everywhere from integers to
colorObj* and then use fc->pen and bc->pen when calling GD functions.

There may be other ways to handle this that would involve less changes, but that
wouldn't be as clean.

Does my description of the problem make sense to you?  What do you think?

[fwarmerdam]

Your description makes sense to me (though I don't know that code too well).
It would seem that things will need to be updated to use colorObj's. 

[sdlime]

I have another test case that shows this problem if we need it. I thought I 
filed a bug on that test case 6 months ago but couldn't find it...

Steve

[dmorissette]

The problem is quite clear to me... what I need is your opinion on the best fix.
I could implement the fix or let you take it if you prefer.

[sdlime]

I'll take this one.

[sdlime]

I committed a fix tonite. I'm not setup to test it here but can at work
tomorrow. Dan's diagnosis was basically correct. However, the cache keys should
probably be expanded to basically cover a styleObj. I'll file that as another
bug once this one is closed.

Steve

[sdlime]

The fix doesn't seem to have worked, not on my test case. Anyone else tried? 
Amy is your test data still around? Could you attach to the bug.

Steve

[dmorissette]

The fix works for me using Amy's mapfile.

I'll attach a small zip with the minimum to reproduce: just the mapfile and
legend template.

[dmorissette]

bug608.zip - Mapfile and legend template to reproduce

[sdlime]

It does work, should've trusted myself. I had problems with a browser cache so 
I couldn't see the effects. Marking as fixed. Will file a new bug about 
imageCacheObj keys.