Feature Strings have been around since the introduction of
Toolboxes in GTViewer version 8.0 in 2008.
They are simply a way to specify a feature or group of features to do
something with. For Toolboxes, they
allow you to turn features on or off using Toolbox button.
Traditionally, specifying a feature in GTViewer was done
with a Category Id/Filter Id pair. This
method worked well for data using instance based symbology like CAD
(Microstation, AutoCAD) and some GIS systems like MGE and FRAMME. However, data using Style Based symbology, like
SmallWorld and G/Technology, complicate the use of Filter Ids because many Filter
Ids are now associated with a single feature (one for each style used with the
feature). For example, a primary
conductor may have 200 different styles associated with it. Figuring out those 200 Filter Ids, while
simple, is tedious. To compound this
problem, only styles that get used are mapped to a Filter Id, so as a feature
uses more and more styles (which is very common), the set of Filter Ids associated
with the feature will increase requiring constant updating of the Filter Id
list used to specify the feature. This
can problem will eventually result in having features that you can’t locate,
can’t display, can’t turn off, can’t select, etc.
To solve this problem, the Feature String was created to
give a simpler way to specify a feature or set of features by using feature
metadata instead of the Filter Ids. For example,
if you want to specify a Pole, you can now say “Pole” instead of finding all of
the different Filter Ids associated with every component of a Pole. If a new style for Poles is used (which will
use a new Filter Id), Feature Stirngs will automatically picked up by the
Feature String that specifies “Pole”.
Feature String History
This concept of using metadata to find Filter Ids for
Features was already used internally by the GTViewer Writer Plugin for
FME. By default, the FME Plugin uses the
next available Filter Id anytime a new Style is needed. To figure out which styles goes with a
particular feature, the FME Plugin added to comment to each Filter Id entry in
the Fitler File (.flt) to identify which FME_Feature_Type created the
entry.
The Filter Files (.flt) used by GTViewer contain an entry
for each Filter Id used in a Category.
Each entry in the Filter File has a Filter Id and the Filter Name plus
some other fields. One of those
additional fields is a Description field that has generally been used as a
comment area (because it is not shown or used anywhere else), but it can now be
used to define metadata about the Filter Id.
This metadata varies depending on the source GIS data and what method
was used to convert the data to the GTViewer format. Several
notations are supported in the comment field:
Used by the GTech Loader:
GIS:<G3E_FNO>,<G3E_CNO>,<G3E_SRNo>,<G3E_SRRowNo>,<Style
Name>
GIS:<G3E_FNO>,<G3E_CNO>,<G3E_SRNo>,<G3E_SRRowNo>,<Style
Name>,<Feature Name>,<Component Name>
GIS:<Feature>,<Component>,<Style
Rule Num>,<Style Num>,<Style Name>,<Feature
Name>,<Component Name>
Generic Tag (used by newer versions of FME Writer Plugin):
GIS1:<Feature>,<Component>,<Style
Name>
Originally Used for SmallWorld Data, but simple and flexible
and can be used by custom data converters.
SW:<Feature>
SW:<Feature>,<Component>
SW:<Feature>,<Component>,<Style
Name>
Used to Support some older dataset where a Feature Name was
provided in the comment:
Feature
<Feature>
Used by Older versions of FME Writer Plugin:
FME:<Feature>
With the feature metadata available in the Filter Files, the
Feature String were devices to search this information in a variety of ways to
pull out the Filter Ids you need based on a more abstract specification. There are currently 7 different Feature String
Items (commands) that you can use to select a list of Filter Ids. These items can be used by themselves or
combined with other.
Feature String Syntax
A Feature String is a list of items or a semicolon (;)
delimited list of items:
<Feature
String> = <item> [{; <item>}]
An Item can be one of the following:
<item>
= Cat(<category Id>)
<item>
= Gis(<category Id>, <Fea/Comp String>)
<item>
= Flt(<category Id>,<Filter String>)
<item>
= Dft(<category id>)
<item>
= All(<category id>)
<item>
= Contains(<category id>,"<string>")
<item>
= Name(<category id>,<mode>,”<filter name>”,
”<feature>”,”<component>”, ”<feature name>”,
”<component name>”, ”<style name>”)
<Fea/Comp
String> = <feature>[:<component>][{,<feature>[:<component>]}]
<Filter
String> = <Filter Item>[{,<Filter Item>}]
<Filter
Item> = <filter Id>
<Filter
Item> = <Low Filter id>-<High FilterId>
In the above notation, tokens in square brackets ([]) are
optional; tokens in curly braces ({}) can repeat. This notation is probably over complicating 4
fairly simple entries that are described in plain English below:
·
Cat(<category
Id>) – The Cat item will get all Filter Ids for a Category.
o Cat(1) = All Filter Ids in Category 1
o Cat(1);Cat(2);Cat(3)
= All Filter Ids in Categories 1, 2, and 3
·
Gis(<category
Id>, <Fea/Comp String>) – The GIS item will get a
list of Filter Ids for all of the Feature/Components specified in the Fea/Comp
String which is a comma separated list of <Feature>
or <Feature>:<Component>
items. If only the Feature is specified,
then all Component Filter Ids will be retrieved; if a Feature:Component is specified, only the Filter Ids for the
specific Feature Component will be retrieved.
o Gis(2,Pole)
= Category 2, All Pole components
o Gis(2,Pole:Symbol)
= Category 2, Only Pole Symbol component
For GTech Data, the Feature and
Component fields use the G3E_FNO and G3E_CNO attributes, so they are numbers:
o Gis(3,
300) = Category 3, Feature 300 (all components)
o Gis(3,
300, 305, 306) = Category 3, Features 300, 305, and 306 (all components of
each)
o Gis(3,
300:10001, 300:10002) = Category 3, Feature 300 Component 10001 and Feature 300
Component 10002
o Gis(3,
300:10001, 400, 500) = Category 3,
Feature 300 Component 10001 and Feature 400 and 500 (all components of each).
o Gis
(3,300); Gis(4,900) = Category 3 Feature 300
and Category 4 Feature 900
·
Flt(<category
Id>,<Filter String>) – The Flt item will get a list
of Filter Ids for the specified category.
The Filter String can be specified as a comma delimited list of Filter Ids,
a hyphenated list for a range of Filter Ids, or a combination of the two.
o Flt(5,
1,3,5) – Category 5 Filter Ids 1, 3, and 5
o Flt(5,
1-10) – Category 5 Filter Ids 1,2,3,4,5,6,7,8,9,10
o Flt(5,
1,4,20-23) – Category 5 Filter Ids 1,4,20,21,22,23
o Flt(5,
1,3,5);Flt(6,30,32-35) – Category 5 Filter Ids 1,3,5 and Category 6 Filter Ids 30,32,33,34,35
·
Dft(<category
id>) – The Dft item will get the list of Filter Ids in a
specified category that are displayed by default as defined by the category’s Filter
File (.flt).
- Dft(5) – Get all of the
filter ids for Category 5 that are Displayed by default
·
All(<category
id>) - The All item will get all Filter Ids in the specified
category. This item is functionally
equivalent to the Cat item.
- All(5) – Get all Filter Ids
for Category 5
·
Contains(<category
id>,"<string>") - The Contains item will find
all Filter Ids in the specified category that contain the specified string in
the Filter Id’s Name.
- Contains(5,"[Foreign
Owner]") –Category 5 that contain “[Foreign Owner]” in the Filter Name.
·
Name(<category
id>,<mode>,"<filter name>","<feature">,"<component>","<feature
name>","<component name">,”<style
name>") - The Name item will find all Filter Ids in the specified
category that meet the search criteria.
This is a very powerful and potentially confusing item to use. The Mode parameter can be:
- AND
– All of the criteria must be true (or not used) to get the Filter Id
- OR
– Any one of the criteria can be true to
get the Filter Id
- INVERTAND
– If all of the criteria is true, do not get the Filter Id
- INVERTOR
– If any of the criteria is true, do not get the Filter Id
The rest of the parameters can be
left empty (don’t use) or a wild-carded string can be specified. If a wild-card is not specified, the string
must match exactly (not case sensitive).
A wild-card can appear at the beginning, end, in the middle, or any
combination of these.
- NAME(800,AND,*,519,966,*,*,"Ln_W_Pipe_Op_*")
= Category 800, all Feature 519, Component 966 whose Style Name starts
with “Ln_W_Pipe_Op_”
o Name(5,AND,"*Foreign
Owner*") = this is equivalent to the Contains example.
Where Feature Strings are Used
There are a lot of tools and functionality that use Feature
String:
o
Feature Tooltips
and the Feature Tooltip Builder App can
use Feature Strings to specify which feature a tooltip is for.
o
GTPreset
is a GTData tool that creates a Display Preset file (.gtp) from a description
of what you want display. This description
is composed of Feature Strings.
o
Where Am
I functionality in GTViewer and GTWeb uses Feature Strings to specify which
shapes to look for.
o
Dynamic
Graphics uses Feature Strings to specify which features to operate on.
o
GTViewer
and GTVx both have methods exposed
in their APIs to use Feature Strings: GetFilterListFromFeatureString
and GetCatFilterListFromFeaStr.
o
The DGN
Export Exclude String in GTViewer uses Feature Strings.
o
The GTV
Control has two methods that use Feature Strings: GetCategoryListFromFeatureString and GetFilterListFromFeatureString.
o
GTQuery
and the Query Builder App use a
subset of the Query String (basically the GIS item) modified to fit the context
of the existing Query Definition Files.
o
Toolboxes
in GTViewer use Feature String for the Display Toggle functionality.
o
GTViewer for iOS uses Features String to associate
Data Collection forms with features.
