MgMappingService::GenerateLegendImage() fails when layer uses Composite feature type styles

[ronnielouie]

Refer to ticket #380,  http://trac.osgeo.org/mapguide/ticket/380.

When previewing the map, based on the data attached to ticket 380, no legend symbols are displayed. A preliminary investigation indicates that the data contains vector scale ranges that have ftsComposite feature type styles which need to be correctly dealt with.

[waltweltonlair]

GetLegendImage was missing support for composite type styles, and therefore the returned byte reader was NULL. I updated GetLegendImage to handle composite type styles. This ended up being relatively straightforward: the GeometryContext on the symbol instances determines whether a composite type style is compatible with the supplied geometry type.

I also noticed that GetLegendImage was being called with invalid theme categories, and this was also causing the returned byte reader to be NULL. Although returning NULL no longer causes a crash due to Ronnie's fix, it does result in a missing image in the legend. So instead of returning NULL I made the method return a blank image.

The cause of the invalid theme categories is some invalid logic in the legend UI web code. In my example I had a layer with 2 theme rules. The layer has 3 composite type styles, the first with 2 rules (this is the type style of interest - the one with the correct geometry usage), and the other two with 1 rule each (these have an incompatible geometry usage). The legend UI code simply adds up all rules for each type style type and assumes there are that many categories altogether (so 4 in this example). In any case, the logic I added to GetLegendImage will detect the correct type style / rule to use when called with the valid theme categories, so there's no strong need to fix the logic in legend UI code right now.

I also cleaned up StylizationUtil::DrawStylePreview quite a bit - code that was duplicated 4 times now appears just once.