= !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 [wiki:MapGuideRfcs 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: , , and . The and 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: * " to miles per hour" * "Parcel value: - Euros" * " <= Population < " The 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: " * "Zone " === 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: [[Image(CompositeStyle.jpg)]] 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: * Instance RP 0 * Road symbol RP 0 * Road symbol RP 1 * Instance RP 1 * Walkway symbol RP 0 * Walkway symbol RP 1 === Angle Offset Relative to Feature Geometry === == 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.