MapGuide 29 - MDF Schema Changes for Stylization

This page contains a change request (RFC) for the MapGuide Open Source project. More MapGuide RFCs can be found on the RFCs page.

Status

RFC Template Version	1.0
Submission Date	Aug 22, 2007
Last Modified	Walt Welton-Lair Timestamp
Author	Walt Welton-Lair
RFC Status	draft
Implementation Status	pending
Proposed Milestone	1.3
Assigned PSC guide(s)	(when determined)
Voting History	(vote date)
+1
+0
-0
-1

Overview

A few omissions in our new symbolization schemas have been identified. This RFC describes the proposed schema changes which address the issues.

Motivation

Multi-Variate Theming

In the new symbolization we have symbol definitions which define parameters, and symbol instances which define overrides - constant values or expressions - for these parameters. For MapGuide 1.3 we will be introducing new expression functions which can be used to specify themes. Multi-variate theming is achieved by using these new expression functions in parameter overrides. No schema change is needed to support the new expression functions - expressions are just strings and the parameter overrides are string properties. Multi-variate theming does add some complexity when it comes to legend labels, and this is where additional information in the schema is needed.

The current layer definition schema defines a legend label per style rule. Today when we create a theme we generate multiple style rules, and the legend label for each rule is set appropriately. The new multi-variate theming approach, however, uses expression and not rules to define the theme. With the current schema this means only one legend label is available for all the themes, and this is inadequate. The proposed schema change is to therefore include additional theme information to the parameter override elements.

For this release it will be sufficient to add two pieces of information: a theme description and a theme category format. Any parameter override whose value is set to a theming expression would also set these properties. The legend generation code can then use this information to generate appropriate labels for each theme / theme category. The theme description is a string that would be displayed the same as it's entered. The theme category format is a string which includes a mix of formatting codes and text, and these can appear in any order. Three codes will be supported: <min>, <max>, and <value>. The <min> and <max> codes are used with themes where each category corresponds to a range of values. This applies to themes that use Equal, Standard Deviation, Quantile, or Jenks distributions. Some example category format strings:

• "<min> to <max> miles per hour"
• "Parcel value: <min> - <max> Euros"
• "<min> <= Population < <max>"

The <value> code is used with themes that assign a single value to each category, so for themes that use Individual Values distributions. Some additional example format strings:

• "Zip code: <value>"
• "Zone <value>"

Rendering Passes

The new symbolization introduced the concept of rendering passes. For a given layer a rendering pass corresponds to an iteration by the stylization code over that layer's features. The default is to render with one pass (pass 0): we iterate once over all the features, and for each feature we stylize / draw it using all the symbols. Usually this gives the desired behavior, but not always. The common example where this doesn't work is when you want to draw a thin line on top of a thick line, and have "merging" behavior where features intersect:

This image shows the behavior for two intersecting features which are styled using a thick line and then a thin line. At left is the result if we draw with one pass: the thick line for the vertical feature is drawn on top of the thin line for the horizontal feature. At right is the result if we use two passes: we draw all the features once with the thick line, and then draw them all again using the thin line.

The current symbol definition schema allows rendering passes (RP's) to be specified in a CompoundSymbolDefinition. The example above could be done using a CompoundSymbolDefinition containing thick and thin line style symbols, with the RP's for the thick / thin lines set to 0 / 1.

The main benefit of this approach is that the RP pass information is stored with the symbol definition: there's no need to respecify it when referencing this symbol in a layer.

The approach, however, does have some drawbacks:

• Rendering passes can only be used by defining compound symbol definitions
• Mixing compound symbols that define RPs with other symbols is problemmatic

Here's an example that clarifies the latter drawback. I want to create a layer which shows roads and pedestrian walkways. I have custom symbols already defined for the roads and walkways - both are compound symbols that have thick and thin line styles defined using RP 0 and 1. I set up my layer so that features of type "road" are styled using the Road symbol, while features of type "walkway" are styled using the Walkway symbol. I also have the requirement that walkways need to draw on top of roads. With the symbols defined as is this won't work. The first rendering pass - pass 0 - will iterate over all features and draw the thick Road lines and then the thick Walkway lines. The second rendering pass will then draw the thin Road lines and the thin Walkway lines. In places where walkway features intersect road features, the thin Road lines drawn in RP 1 will end up drawing on top of the thick Walkway lines drawn in RP 0.

We could easily fix this by editing the Walkway symbol to use RP 2 and 3, but then this also affects other layers in other maps that use the Walkway symbol. I may then have to adjust RP values for yet other symbols. Or maybe the Walkway symbol is part of a symbol library that I purchased, and I don't want to change it.

Another use case where the current schema's support for rendering passes is insufficient is when a user wants to build up a composite line style from predefined symbols. MapGuide Studio, for example, provides UI to do this. If the user only works with SimpleSymbolDefinitions, then this could be done by creating an inlined CompoundSymbolDefinition that references all of the simple symbols and sets the appropriate RP values. This approach doesn't work, however, if the user wants to include a CompoundSymbolDefinition in his composite style. That's because we can't add a reference to his CompoundSymbolDefinition in the inlined CompoundSymbolDefinition - by design compound symbols can only reference simple symbols.

The proposed solution to this is simple: add a RenderingPass element to SymbolInstance, so that we now have two levels of rendering passes. The algorithm is straightforward. We start the layer stylization with symbol instance rendering pass 0, and only instances with their RP set to 0 are enabled for this pass. We then stylize / draw using the symbol definitions for this set of instances, making as many sub-rendering passes as necessary based on the RP values of these symbol definitions. We then move to the next symbol instance rendering pass. Again we only consider symbol instances / symbol definitions for this pass, and do sub-rendering passes as necessary. This is continued until all necessary symbol instance RPs have been made.

With this approach, I would configure the layer for the road / walkway example like the following:

• SymbolInstance A
  • reference to Road symbol
  • intance RP set to 0

• SymbolInstance B
  • reference to Walkway symbol
  • intance RP set to 1

At stylization time, this would result in the following sequence of passes:

• SymbolInstance RP 0
  • Road symbol RP 0
  • Road symbol RP 1
• SymbolInstance RP 1
  • Walkway symbol RP 0
  • Walkway symbol RP 1

Here's an image showing the different behaviors for lines:

Angular Offset Relative to Feature Geometry

The symbol definition schema currently includes support for specifying whether symbol angles are absolute or are computed from the geometry. This is done via the AngleControl element in PointUsage, LineUsage, and AreaUsage. If the AngleControl is set to 'FromAngle' then we use the value of the Angle element to determine the angle to draw the symbol, while if the AngleControl is set to 'FromGeometry' then we use the feature geometry to compute the draw angle. In the latter case we ignore the Angle element.

The proposed change in behavior is that in the case of 'FromGeometry' we now use the Angle element to specify the additional amount to rotate the feature relative to the angle computed from the geometry.

In the case of point features this change makes no difference - the computed angle of a point is zero. The behavior only changes for line and area features. For line features the computed angle is the angle of the polyline at the symbol insertion point. With the proposed change a user would be able to specify that his/her symbol be rotated a given amount relative to the polyline. For area features the computed angle is the angle of the longest edge. The same behavior change applies here.

Proposed Solution

This is a more detailed description of the actual changes desired. The contents of this section will vary based on the target of the RFC, be it a technical change, website change, or process change. For example, for a technical change, items such as files, XML schema changes, and API chances would be identified. For a process change, the new process would be laid out in detail. For a website change, the files affected would be listed.

Implications

This section allows discussion of the repercussions of the change, such as whether there will be any breakage in backwards compatibility, if documentation will need to be updated, etc.

Test Plan

How the proposed change will be tested, if applicable. New unit tests should be detailed here???

Funding/Resources

Supplied by Autodesk.