Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#381 closed defect (fixed)

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

Reported by: ronnielouie Owned by: waltweltonlair
Priority: medium Milestone: 2.0
Component: Mapping Service Version:
Severity: major Keywords:
Cc: External ID: 1031059

Description

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.

Change History (4)

comment:1 Changed 11 years ago by ronnielouie

External ID: 1031059

comment:2 Changed 11 years ago by waltweltonlair

Owner: set to waltweltonlair
Status: newassigned

comment:3 Changed 11 years ago by waltweltonlair

Resolution: fixed
Status: assignedclosed

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.

comment:4 Changed 11 years ago by tomfukushima

Milestone: 2.12.0
Note: See TracTickets for help on using tickets.