GTViewer Server Box - Part 1

GTViewer for iOS, GTViewer for Android, and GTViewer (for Windows), are all designed to take your GIS Data to the field.   They do not rely on a connection to a server for normal operation making them ideal for storm/disaster situations where network access is not available, unreliable, or inaccessible.  

With GTViewer for Windows, there are many ways to load and update your GIS Data on a laptop (using SD cards, thumb drives, DVDs, etc.).   With the device versions of GTViewer, their sandboxed environments complicate this process.  The GTViewer Data Server was developed as Web App running under IIS to host your GIS Data so the devices can easily download or update their local copies of the GIS Data.   GTViewer for Windows can also use the GTViewer Data Sever to download and update it GIS Data via the GTViewer Data Client app.   This workflow operates very well except when you need to load or update the GIS Data your devices at critical times (storms, disasters, etc.) and no internet or intranet connectivity is available.  Consequently, these critical time are when GTViewer is most valuable.

Our solution to this problem of updating or loading your GIS Data when no network connectivity is available is GTI’s first venture into the Hardware world.  The GTViewer Server Box is a small, portable, self-contained server running the GTViewer Data Server and GTShare.  GTViewer for iOS, GTViewer for Android, and the GTViewer Data Client on Windows can all connect to the GTViewer Server Box via WiFi and download or update their local GIS data.

The GTViewer Server Box is based on a Raspberry Pi which is a small computer on a single credit card sized board running a flavor of Linux (Raspbian) and a full Apache web server.  The GTViewer Server Box acts as a Wireless Access Point and DHCP server allowing multiple clients to simultaneously connect and interact with a Linux version of the GTViewer Data Server.

 

The GTViewer Server Box had to meet the following criteria:

•          Support GTViewer Data Server and GTShare.
•      Require no Internet connection or network connection of any kind.
•          Support a variety of Power sources: AC Outlet, Car Adapter, Battery, USB.
•          Appear just like the standard GTViewer Data Sever and GTShare to the clients.
•          Support iOS, Android, and Windows clients.
•          Provide enough storage to support a number of GTViewer datasets.
•          Provide an easy way to update the GIS Data it serves out.
•          Provide security for the GIS Data.
•          Require no display, keyboard, or mouse.
•          Be extremely easy to use, portable, and reliable.

If you have the right WiFi component, a Raspberry Pi can act as a WiFi access point.  With some creative configuration, it can function as a DHCP server and Domain Name server without the need for internet access or any connection to other servers.

The Raspberry Pi is powered by a Micro USB connector opening up a wide variety of cheap and plentiful methods for powering the server.   External Batteries used to charge cells phone are an excellent method for making the Server Box ultra-portable while still allowing power to come from AC Plugs, Car chargers, or even laptops via their USB ports.

A slimmed down version of the GTViewer Data Sever and GTShare were ported to Linux/Apache.   They do not offer all of the features of the regular GTViewer Data Server and GTShare for Windows/IIS, but they provide everything needed to accomplish its task of getting the GIS Data to the clients and sharing redline and collected data.

An iPhone, iPad, Android Phone, Android Table, and Laptop with WiFi all see the GTViewer Server Box as another WiFi Network you can connect to.  When you want to download data, just connect your device or laptop the GTViewer Server Box’s SSID, enter the WiFi password, then interact with the GTViewer Data Server and GTShare like you normal do.

GTViewer datasets are managed on GTViewer Server Box by using a USB Thumb Drive.   Prepare the USB Drive on your PC or Laptop and plug the thumb drive into the Server Box when you are ready to use it.   As these are regular thumb drives, have one plugged into your normal system and copy any updated GTViewer Data Sets to the thumb drive when you update your regular GTViewer Data Server.  This way you will always have an up-to-date set of data ready to go.   Thumb drives are very inexpensive and can hold a large amount of data.

Security on the GTViewer Server Box is primarily based on the WiFi password.  If you do not know it, you will not have access to the data.  User management like that found on the IIS version of the software can also be used, but the WiFi password can be used on its own.    All of the actual data files on the Server Box can be fully encrypted, so losing a GTViewer Server Box would not put the data at risk.

The GTViewer Server Box was designed to be extremely easy to use.  You basically need to plug in the thumb drive containing the GTViewer datasets, plug in the power, and press the On button.   There is no need for a display, keyboard, or mouse for general operation or updating of the GIS Data.  You may want to connect the server to a display, keyboard, and mouse if you want to customize the WiFi SSID, WiFi Password, or Server Domain name.

The photo above shows the prototype GTViewer Server Box plugged into an external battery used to charge cell phones.  This battery is a large one (16800 mAh), but it ran the GTViewer Server Box for over 30 hours (minimal use, but available).   The production version is very similar to the prototype only with a slightly different case sporting an On/Off button.  Range is limited by the WiFi component, but general you need to be in the same room or near the Server Box for high performance downloads.

**** To see the final design, go to this post.

Feature Strings

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.

GTData version 14.0.0.2 is Available

GTData version 14.0.0.2 is available.

-----------
14.00.00.02 - 6/9/15
-----------

- FIX - #7347 - GTQuery - The Feature/Component name processing was updated to match the latest in GTViewer.

- CHG - #7407 - GTTextQuery - If a Text string contains just spaces, it will now be omitted.

- FIX - #7408 - GTTextQuery - The OmitString entry was not working.

- FIX - #7409 - GTTextQuery - Text Elements were not trimming the text string and did not match Omit Strings.   Group Elements with text did trim the text.

- NEW - #7413 - GTTile - The FileNameOnlyFlag was added so the embedded data on the range Boxes (DrawBox entry) will just put the filename and not the full path.

- NEW - #7415 - GTTile - The CreateKeys entry has been added to automatically generate key values for the DrawBox shapes.

- NEW - #7501 - GTConv - RangeFileMode entry added to change the format of the range file.

- NEW - #7505 - GTQuery - The OffsetDB query type has been added to provide Integer Pair to Integer Pair lookup without the need of a key file.

- FIX - #7506 - GTQuery - The Offset Query Type was setting the key type incorrectly.

- FIX - #7507 - GTQuery - QueryType was not defaulting to Type 0 as it previously did.

- FIX - #7508 - GTFontEdit - Tab Order on Import Character form was not correct.

- NEW - #7509 - GTFontEdit - Browse button added to Import Character dialog.

- NEW - #7510 - GTSum - The -ct option has been added to generate a list of files that contain Color Table elements.

- NEW - #7541 - GTFormatInfo - The <%CRLF%> token has been added to insert a blank line.

- FIX - #7557 - GTQuery - Prompt queries did not support the Constant token in PromptColumn entries.

Milsoft Users Converence 2015

Come see us June 9th through June 11th at the Milsoft Users Conference in Arlington, Texas.

We will be showing GTViewer for iOS, GTViewer for Android, GTWeb, GTViewer, GTPlot, and much more.