Changes between Version 4 and Version 5 of MapGuideRfc29

Timestamp:

08/24/07 04:59:19 (17 years ago)

Author:

waltweltonlair

Comment:

--

MapGuideRfc29

@@ -25 +25 @@
 A few omissions in our new symbolization schemas have been identified.  This RFC describes the proposed schema changes which address the issues.
 
+
 == Motivation ==
 
@@ -45 +46 @@
 
 === 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:
 
@@ -81 +81 @@
 At stylization time, this would result in the following sequence of passes:
 
- * Instance RP 0
+ * !SymbolInstance RP 0
   * Road symbol RP 0
   * Road symbol RP 1
- * Instance RP 1
+ * !SymbolInstance RP 1
   * Walkway symbol RP 0
   * Walkway symbol RP 1
 
+Here's an image showing the different behaviors for lines:
+
+[[Image(CompositeStyle.jpg)]]
 
 
-=== Angle Offset Relative to Feature Geometry ===
+=== 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.