Changes between Version 10 and Version 11 of MapGuideRfc29
- Timestamp:
- Sep 6, 2007, 11:18:13 AM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MapGuideRfc29
v10 v11 29 29 30 30 ===== Legend Labels for Multi-Variate Theming ===== 31 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.32 33 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.34 35 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. Some example category format strings:31 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 have proposed to add new expression functions which can be used to specify themes (see [wiki:MapGuideRfc32 MapGuide RFC 32]). 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. 32 33 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 expressions 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. 34 35 For this release it will be sufficient to add two pieces of information: a theme description and a default 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. Some example category format strings: 36 36 37 37 * "<min> to <max>" … … 54 54 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. 55 55 56 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.56 The benefit of this approach is that the RP information is stored with the symbol definition: there's no need to re-specify it when referencing this symbol in a layer. 57 57 58 58 The approach, however, does have some drawbacks: … … 67 67 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. 68 68 69 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.69 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. 70 70 71 71 With this approach, I would configure the layer for the road / walkway example like the following: … … 73 73 * !SymbolInstance A 74 74 * reference to Road symbol 75 * in tance RP set to 075 * instance RP set to 0 76 76 77 77 * !SymbolInstance B 78 78 * reference to Walkway symbol 79 * in tance RP set to 179 * instance RP set to 1 80 80 81 81 At stylization time, this would result in the following sequence of passes: … … 90 90 91 91 ===== Angular Offset Relative to Feature Geometry ===== 92 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.92 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 !AngleControl is set to '!FromAngle' then we use the value of the Angle element when drawing the symbol, while if !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. 93 93 94 94 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.
