Changes between Version 10 and Version 11 of MapGuideRfc16
- Timestamp:
- Feb 22, 2007, 11:39:13 AM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MapGuideRfc16
v10 v11 27 27 == Motivation == 28 28 29 !MapGuide currently supports 2D representation of spatial data. However, many spatial data sets contain height information for the features they contain, giving the potential for 2.5D representation. This RFC describes how the !MapGuide Layer Definition schema can be extended to specify expressions to be used to calculate a base elevation and extrusion size. Support for 2.5D would initially be implemented by the KML service, allowing visualization of solid objects in Google Earth . An example of the potential output is shown below:29 !MapGuide currently supports 2D representation of spatial data. However, many spatial data sets contain height information for the features they contain, giving the potential for 2.5D representation. This RFC describes how the !MapGuide Layer Definition schema can be extended to specify expressions to be used to calculate a base elevation and extrusion size. Support for 2.5D would initially be implemented by the KML service, allowing visualization of solid objects in Google Earth, though it could be extended to other viewers at a later date. An example of the potential output is shown below: 30 30 31 31 [[Image(KmlExtrusionScreenshot.jpg, align=center)]] … … 37 37 === Layer Definition Schema Modifications === 38 38 39 The layer definition schema contains numerous !ExtendedData1elements that allow the schema to be extended without breaking forward or backward compatibility. The changes proposed in this RFC would initially be added into one of these elements, and would eventually be moved to the main part of the schema whenever the next schema version update is carried out. See [wiki:MapGuideRfc10 MapGuide RFC 10] for more details.39 The layer definition schema contains numerous <!ExtendedData1> elements that allow the schema to be extended without breaking forward or backward compatibility. The changes proposed in this RFC would initially be added into one of these elements, and would eventually be moved to the main part of the schema whenever the next schema version update is carried out. See [wiki:MapGuideRfc10 MapGuide RFC 10] for more details. 40 40 41 41 The affected section of the original schema looks like this: … … 107 107 === MDF Model and Parser Modifications === 108 108 109 The MDF Model would require the addition of two new classes: !ElevationSettings and !VectorScaleRangeExtendedData1, corresponding to the <!ElevationSettings> and custom <!ExtendedData1> elements respectively. Similarly, the MDF Parser would require two new classes: IOElevationSettings and IOVectorScaleRangeExtendedData1.109 The MDF Model would require the addition of two new classes: '''!ElevationSettings''' and '''!VectorScaleRangeExtendedData1''', corresponding to the <!ElevationSettings> and custom <!ExtendedData1> elements respectively. Similarly, the MDF Parser would require two new classes: '''IOElevationSettings''' and '''IOVectorScaleRangeExtendedData1'''. 110 110 111 The parser classes would be responsible for reading and writing the elevation settings to /and from XML. The model classes would be used to store and access those settings. The methods implemented by each class would be very simple get/set or read/write functions.111 The parser classes would be responsible for reading and writing the elevation settings to and from XML. The model classes would be used to store and access those settings. The methods implemented by each class would be very simple get/set or read/write functions. 112 112 113 113 === Rendering / Stylization Modifications === … … 115 115 A few changes would be required to the internal stylization interfaces in order to pass the elevation settings through the framework to the Stylize() methods of the affected !GeometryAdapters. Inside these methods, the offset and extrusion expressions would be evaluated for the current feature, and the resulting floating point values would be passed as additional parameters into the Renderer::!StartFeature() command. The method signature chages are as follows: 116 116 117 !GeometryAdapter::Stylize()would be modified from this:117 '''GeometryAdapter::Stylize()''' would be modified from this: 118 118 {{{ 119 119 virtual void Stylize(Renderer* /*renderer*/, … … 138 138 where RS_ElevationSettings is a simple struct-like class that contains the elevation settings. 139 139 140 Renderer::!StartFeature()would be modified from this:140 '''Renderer::!StartFeature()''' would be modified from this: 141 141 {{{ 142 142 virtual void StartFeature (RS_FeatureReader* feature, … … 156 156 }}} 157 157 158 All concrete classes that implement these interface methods would need to be updated to reflect the changes. 159 160 === KML Service Modifications === 161 162 The KML Service generates KML using the !KmlRenderer class - a concrete implementation of the Renderer interface. This class would be updated to set the Z coordinate of the generated geometries to be equal to (zOffset + zExtrusion). Also, if zExtrusion > 0, we would write out the KML element <extrude>1</extrude> to indicate that the features should be extruded down to the ground. If zOffset > 0, we will stil extrude the features down to the ground level, since Google Earth does not currently provide a means for rendering floating extruded objects. 163 158 164 == Implications == 159 165 160 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.166 This RFC does not describe any modifications to the GUI tools used to create layer definitions. The elevation settings would need to be configured by manual modification of the layer definition XML files. 161 167 162 168 == Test Plan == 163 169 164 How the proposed change will be tested, if applicable. New unit tests should be detailed here??? 170 Unit tests should include KML generation for layers that contain elevation settings 165 171 166 172 == Funding/Resources == 167 173 168 This section will confirm that the proposed feature has enough support to proceed. This would typically mean that the entity making the changes would put forward the RFC, but a non-developer could act as an RFC author if they are sure they have the funding to cover the change.174 Autodesk to provide resources / funding.
