#Flag and #Symbol Directives |
Top Previous Next |
|
Unless you disable station marking, the locations of survey stations (i.e., vector endpoints) are indicated on maps by a customizable symbol called the station marker. Much greater flexibility with regard to station highlighting is available if we group stations into named categories -- each with a customizable flag symbol. For example, on an area map we may want only cave entrances and karst features marked -- ideally with distinct marker styles. The #Flag and #Symbol directives described below make this possible. In a similar vein, a #Note directive allows us to replace specific station names with long descriptive titles called notes. The Flag and Marker Symbol dialog allows us to not only hide specific flag symbols but also hide the notes for stations having no flags or only hidden flags.
#Flag Directive The #Flag directive identifies the stations that may need to be highlighted with category symbols on maps. For example, the directive
#Flag ENT0 A0 SUR:31 /Pit Entrances
allows us to optionally display a special marker symbol at the locations of stations ENT0, A0, and SUR:31. One or more station names can appear on the directive line. Also, the same station can appear on #Flag directives in more than one place in your data files and it doesn't matter where. Note that the usual prefix and case rules apply to the names, as if this were a vector data line.
A slash-prefixed flag name (e.g., "/Pit Entrances") can optionally follow the list of station names. Stations assigned different flag names can be displayed with different, multi-colored marker symbols as defined by the #Symbol directive (see below) and as specified in the Flag and Marker Symbols dialog. Therefore, be sure to use meaningful flag names for stations you may later want to distinguish between. This is important, for example, if you intend to use the GIS export feature of Walls, which supports a special flag shapefile. You can also create a coordinate report with stations grouped by named flag category.
If the #Flag directive contains only a slash-prefixed name and no list of stations, then it reassigns a default flag for any #FIXed stations subsequently encountered. If the flag name is also missing, the default flag name is removed. Only #FIXed stations are assigned a default flag in this manner (or equivalently, with a "FLAG=" parameter on the #Units directive). For an example of this, see #FIXed stations.
One station will typically have multiple flag names associated with it. For example, you might want to tag a station as having all of these characteristics: cave entrance, gated cave, bat cave, mapped cave, and GPS position. You can control the priority of flag symbols (i.e., which symbols are drawn last, possibly overlapping other symbol types) and also whether or not just one flag symbol gets drawn at a station -- the one with the highest priority. You can also interactively disable or enable certain flag symbols, depending on what you want a map to show. For a description of this feature, see Flag and Marker Symbols.
In contrast to station markers and name labels, the visibility of flags (and notes), has nothing to do with the segment attributes of adjacent vectors. Flags and notes are like vectors in that they have their own assignment to whatever segment happens to be current at their directive's location in the data file. (This segment may or may not contain vectors.) Thus, their visibility can be controlled in much the same way as vectors, for example, by detaching segment tree branches; however, it's probably much easier to do this in the Flag and Marker Symbols dialog.
Unlike notes and labels, flags and markers are always drawn without testing for possible overlap of other map features. You can, however, depend on the following drawing sequence with respect to overlap: 1) vector lines, 2) station markers, 3) station flags (from lowest to highest priority), 4) station notes, and finally 5) station name labels. Normally, notes and labels are drawn so they aren't obscured by themselves or by other objects. For more information on the conditions that must be satisfied for flags and notes to appear on maps, see #Note Directive.
The #Symbol directive associates a specific map symbol with a named flag. Since it's now easy to accomplished this interactively via the Flag and Marker Symbols dialog, you may choose not to use #Symbol directives at all -- particularly if your project has only a few station categories (flag names). The symbol assignments you make interactively will be preserved across recompilations, and will remain associated with a particular project tree branch. The only drawback to defining symbol styles interactively instead of via #Symbol directives is that those styles will be lost (reset to their defaults) whenever workfiles are purged -- a process that in the past was sometimes necessary when a new program version was released. When categories are numerous, the shapes, sizes, colors, and priorities you've painstakingly assigned to flagged station markers can themselves have significant information content. The #Symbol directive allows you to selectively preserve certain attributes in a documented text format.
Without data-defined symbols, all flagged stations will have the same marker following a first compilation (or after a workfile purge). This will be the default flag symbol specified in the Map Format Options dialog. Subsequent to this, you can assign an array of symbols interactively via the Flag and Marker Symbols dialog and easily modify them whenever it's useful -- for example, to highlight only a certain kind of survey station. Unless workfiles are purged, symbol attributes will be preserved across recompilations until they are subsequently overridden by new #Symbol directives in your data files.
The Flag and Marker Symbols dialog allows you to preview what's available in the way of flag symbols. There are currently four basic shapes (squares, circles, triangles, and plus signs) that can be shaded four different ways: "solid" (filled with color), "opaque" (colored outline with background color interior), "clear" (colored outline with transparent interior), and "transparent" (50% opaque). Note that Transparent is different from Clear only for exported SVGs. While the background color is selectable for a screen map, the symbol color can be selected individually for different flag names.
The directive format, which is likely to undergo future expansion to support TrueType font symbols, is currently
#SYMbol <style><size> <color> /<flag name>
where <style> is a concatenation of the first letters of the following two groups of words:
Solid Square Opaque Circle Clear Triangle Transparent Plus sign
An integer point size immediately follows (with no separator) the two style letters. Following that is an optional "RGB color" specification in parentheses. Here are some examples:
#symbol CS8 (0,255,0) /GPS position ; Clear Squares of size 8 and color bright green: an RGB-value of (0,255,0) #symbol SC12 /Unexplored pits ; Solid Circles of size 12 and with default or pre-assigned color #symbol SP- /Sink ;Solid Plus signs of pre-assigned size and color
These directives will cause all stations that were flagged "GPS position" to be marked with clear green squares of size 8 points. Unexplored pits will show as solid circles of size 12, but with the currently-assigned color unchanged. Note that we could have assigned "Unexplored pits" a colored symbol interactively following a previous compilation. Likewise, we preserve the current size and color of the symbol for "Sink ". Although we can change that symbol's shape interactively, the next recompilation will reset it to a plus sign.
In case you're unfamiliar with RGB colors, black is (0,0,0) and white is (255,255,255). Bright red, green, and blue are (255,0,0), (0,255,0), and (0,0,255), respectively. A brighter blue (cyan) is (0,255,255). You can use color selection dialogs in Walls to determine the RGB values of other colors.
A station can be assigned different flags at various points in your data files. The initial flag priority is determined by the order #Flag and/or #Symbol directives are encountered during processing. Subsequent to compilation, you can change flag priorities interactively and also determine whether or not multiple symbols can be drawn at a station, with higher priority symbols on top. You can also quickly disable, or "hide" certain flags.
The minus sign (-) can be substituted for each of the three style components (shade, shape, and size) to indicate that the currently assigned or default setting should be used. For example, "#symbol -S- /Caves", will reset the symbol for caves to squares without changing the other attributes. The symbol can also be reset to zero point size ("-S0"), causing it to be omitted from the map and possibly causing no marks of any kind to be drawn for stations with the "Caves" flag (depending on priorities).
For now, the line thickness of a flag symbol's outline is a global (project-independent) setting in the Map Format Options dialog, and will be the same for all flag symbols drawn on the map. It's measured in pixels (dots) and can be different for the three types of map output: screen, printer, and metafile. That's because 1-dot wide outlines would be nearly invisible on printouts produced by high resolution printers. For screen output you'll probably want to leave line thickness set to one. (Line thickness is irrelevant for solid-style symbols.)
Recommendations Since the order of appearance of flag names (either with #Flag or #Symbol directives) in your data files can be important, it's probably most convenient to group all #Symbol directives together in a separate data file -- say, SYMBOLS.SRV -- attached just beneath your project tree's root folder. In fact, you may want to prepare several alternative symbol files, only one of which is in an attached state during compilation. However, this is only if you decide to use #Symbol directives at all. Beginning with release B6, Walls lets you assign and experiment with different symbol styles interactively via the Flag and Marker Symbols dialog. This is often more convenient than the "hard coded" approach described here.
Unlike other directives, #Symbol plays no role whatever in defining survey data; it only affects how data will be displayed. Ordinarily, display preferences are set interactively after data sets are compiled, and are maintained in the project's database of processed data -- specifically the NTA workfile. As a general rule I think this is preferable. The disadvantage of this approach is that the NTA file produced by compilation is sometimes discarded when survey data is archived or when Walls itself is upgraded. Flag symbol attributes are themselves often informative enough -- or at least hard enough to prepare to one's liking -- that they may be worth preserving as documented directives in SRV text files. This will depend on the nature of your survey projects.
|