“Style” is a word that is probably used too much when describing aspects of GTViewer. There are linestyles, User-defined linestyles, symbol styles, element styles, and dynamic style. Dynamic styles are the type of styles dealt with by the Style Manager. A dynamic style is a Style Definition that is mapped to a particular Category Id/Filter Id pair for a particular zoom level range. A Style Definition defines all of the stylistic properties that can be used when rendering an element:
Display Flag
Color Id
Color Value
Weight
Linestyle
User-defined Linestyle Id
Symbol Id
Font Id
Scale
Fill
Stroke Angle
Offset X
Offset Y
Origin Offset X
Origin Offset Y
Angle Offset
Height Mult
Length Mult
Priority
Border Color Id
Border Color Value
Fixed Scale Flag
Extended Text Style Mode
Extended Text Style Weight
Extended Text Style Color Id
Extended Text Style Value
Justification
Some of these properties will apply to any type of element, and others will apply to specific elements. For example, Color Value will apply to all elements, while Font Id will only apply to Text and Symbol elements. When a Style Definition is applied to an element, any properties defined will override any of the corresponding properties embedded in the element.
A Style Definition is mapped to an element with a mapping rule that tells the Category and Filter Id of the elements (or feature class) and a zoom level range where the specified Style Definition will be used. Since you specify a zoom level range, you can have multiple Style Definitions mapped to the same feature and when the user zooms in or out, the style can change dynamically (hence the name “dynamic styles”).
In GTViewer, the Style Definition and Style Map files (usually called Style.def and Style.map) has been supported since Version 1.0. These files are simple ASCII files that look like the following:
Style.def:
[Style Definitions]
[Switch - Large]
ColorValue=2550255
Scale=5.0
[Gray]
ColorValue=7070255
[Primary Conductor]
Weight=3
ColorValue=2171080
[Secondary Conductor]
Weight=2
Style.map:
[Style Map]
# FilterMapminThreshmaxThreshcategoryfltIdLowfltIdHighStyle
FilterMap0011499Gray
FilterMap0044040Primary Conductor
FilterMap00355Secondary Conductor
FilterMap2500041313Switch – Large
*** The formats and a detailed scription of these files are found in the GTVConfig.doc delivered with GTViewer.
In the past, much of the data converted to the GTViewer format used Instance Based symbology which defines each element’s symbology directly on the element. The color, linestyle, font, etc. were all embedded into each graphical element. Framme, Field View, and Microstation data were the primary users of instance-based symbology. With Smallworld, Shapefiles , Geodatabases, and G/Technology, a different approach is generally taken by applying a style rule to a class of features. Also, with the recent addition of the GTViewer Reader/Writer plug-in to Safe Software’s FME, automatic conversions use the style based symbology approach by default (preparing the styles to be defined since FME does not actually convert the symbology information). GTViewer supports both instance based and style rule based symbology approaches and can use a combination of the two for maximum flexibility. In fact, if you have an Instance Based symbols dataset (such as a Framme dateset), you can usually get a much more usable display by applying a few Dynamic Styles to declutter the screen when zooming out, make certain feature emphasized, or change the printed output to better suite the medium (printing can use a different style definition and map than the display).
With the Style Rule based symbology approach being adopted more and more, it became apparent that a better way of creating the style definition and style mappings was needed. It is okay to edit a couple of text files when you only have 10 or so style definitions, but when you have 1000 or more (as many G/Technology datasets do), you need a better way to create and maintain the style information.
The Style Manager is a GUI tool built into GTViewer and is found under the Tools menu. This tool will allow you to interactively create, edit, delete, import, and export style definitions and style mappings. It has been evolving since GTViewer 3.0 and now provides a very powerful tool for managing your styles.
In the past, much of the data converted to the GTViewer format used Instance Based symbology which defines each element’s symbology directly on the element. The color, linestyle, font, etc. were all embedded into each graphical element. Framme, Field View, and Microstation data were the primary users of instance-based symbology. With Smallworld, Shapefiles , Geodatabases, and G/Technology, a different approach is generally taken by applying a style rule to a class of features. Also, with the recent addition of the GTViewer Reader/Writer plug-in to Safe Software’s FME, automatic conversions use the style based symbology approach by default (preparing the styles to be defined since FME does not actually convert the symbology information). GTViewer supports both instance based and style rule based symbology approaches and can use a combination of the two for maximum flexibility. In fact, if you have an Instance Based symbols dataset (such as a Framme dateset), you can usually get a much more usable display by applying a few Dynamic Styles to declutter the screen when zooming out, make certain feature emphasized, or change the printed output to better suite the medium (printing can use a different style definition and map than the display).
With the Style Rule based symbology approach being adopted more and more, it became apparent that a better way of creating the style definition and style mappings was needed. It is okay to edit a couple of text files when you only have 10 or so style definitions, but when you have 1000 or more (as many G/Technology datasets do), you need a better way to create and maintain the style information.
The Style Manager is a GUI tool built into GTViewer and is found under the Tools menu. This tool will allow you to interactively create, edit, delete, import, and export style definitions and style mappings. It has been evolving since GTViewer 3.0 and now provides a very powerful tool for managing your styles.
Main Dialog:
Style Definition Dialog:
Style Mapping Dialog:
If you are currently editing the Style.def and Style.map files with notepad, stop immediately!!! The Style Manager is available and it is much to create or adjust styles with it than with notepad. Also, the Style Manager will lets you make adjustments to the styles in real time seeing immediately what affect they have on the data (no editing with notepad, closeing the dataset, and reopening it to see what the change was). Also, the Style Manager shows all of the features using a particular definition and which mappings were used to do it.
If you do not use Dynamic Styles with your dataset, the Style Manager is a good way to experiment in a non-destructive was to see if your displays or printed output can benefit from this feature. In general, you can improve the appearance with very little effort.
Take time to get to know the Style Manager if you are already using Dynamic Styles or would like to try them.
No comments:
Post a Comment