| 38 | | 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. |
| | 38 | The proposal is to create one engine that will satisfy the requirements of all three symbolizations (point, line, and area). This engine will use as input a new XML resource, parameters, and geometry, and will use the rendering interface of MapGuide to perform high quality stylization from those inputs. The resource format and the engine will ultimately be able to handle all three symbolization types. |
| | 39 | |
| | 40 | To implement all of this we will create a new type-style element for the MapGuide layer definition schema. This type-style can reference the new symbolization resources. |
| | 41 | |
| | 42 | Symbols themselves will be represented as a new resource type, and will be stored in the MapGuide resource repository. Groups of symbols can then be easily stored in folders in the repository to represent symbol libraries. The proposed design includes the ability to define both simple and compound symbols. A simple symbol consists of a collection of path, image, and text elements that define the graphics, and information on how the symbol is used in the context of points, lines, and areas. A compound symbol contains a collection of simple symbols, either inlined or using references to existing symbols. |
| | 43 | |
| | 44 | The details on how the symbolization works are best gathered from the XML schema. Please refer to appendix A for the schema. |
| | 45 | Here are some examples to make it more clear how the symbol engine will work. |
| | 46 | |
