Thursday, January 21, 2016

GTViewer version is Available

GTViewer version is available.

----------------------- - 01/18/16

- FIX - #7652 - The TooltipEntry_Pre entries were not correctly spliting the lines if they were over the size threshold for .GTX files.   The change in #7640 caused this problem for .GTM files too.

----------------------- - 01/13/16

- FIX - #7636 - Zoom Level was not being used correctly for symbols using fixed scales in their style definitions.

- FIX - #7640 - If a Supplemental File was used with FeatureTooltip entries or 
ToolboxEntry entries, and those entries were longer than the threshold that splits them into smaller lines, it would not work and would ignore the entries.

Wednesday, January 13, 2016

Web Apps in GTViewer for iOS version 3

Another new feature for GTViewer for iOS version 3 is the Web App Framework.
It allows GTViewer on the iOS platform to communicate with a Web Server and perform various tasks remotely, then display and save the results locally.  GTViewer for iOS is designed to work without a network connection once the dataset has been downloaded.  There may be times, though, when additional information or processing is needed beyond getting a refresh of the GIS dataset.  When a user is connected, they can now run a Web App to download information such as Outages, Jobs, Crew Locations, etc.  This information can be tabular and/or graphic and can be saved for offline use.  Other applications of this framework include resource intensive tasks like network tracing or other types of analysis.
If we compare GTViewer for iOS's Web App Framework to its Data Collection Framework, there are both similarities and differences.   They both extend functionality, they both use customizable HTML forms for their user input, and they both use a server component in some way.   The Data Collection Framework's biggest difference is that it is geared specifically for the collection of data for features or points on the map.  It also has built-in functionality to handle all of the record synchronization with a GTShare server and Lifecycle management.  The only thing you have to provide is your Data Collection Form.    A Web App, on the other hand, is an open sandbox that will let you implement whatever you want.  There is not a specified task that it is meant to solve, and it has a great deal of flexibility available.   It also requires you to implement the server portion of the Web App.   In some cases, this may be something you already have or something that is not difficult to create, but it could be a significant piece of development depending on your requirements.

In GTViewer for iOS, Web Apps are launched by selecting a feature and viewing the Attribute Information.  If a Web App is associated with a feature, a section will appear at the top of the Attribute Info containing a link to start the Web App.   A Web App Form must be provided with the dataset.  It is very similar to a Data Collection Form in that it is created in HTML and JavaScript and has access to the selected feature’s tabular attribute values.   However, instead of collecting information to save in a Data Collection Record, it is just an interface to the App you will be communicating with on a Server.   It can be simple or sophisticated depending on what options you need to send to the App on the server and how you want to represent the results that are returned.   In its simplest form, it is just a Button to start the app and someplace to display the results (if there are any).


It is probably easiest to understand Web Apps if we look at an example.   A common request for GTViewer for iOS is support for Network Tracing (Gas Valve Isolation, Upstream/Downstream Traces, Fiber OTDR, etc.).  These types of apps could be coded into the GTViewer for iOS base product, but would probably only be applicable to the users they were created for.  Unlike GTViewer for Windows, it is not so easy to create your own external apps on the iOS platform.   There is no VB or C# or built-in extensibility like we are used to in the Windows world.   The Web App Framework attempts to narrow this gap.

Let’s look at a common Electric Trace that finds all Downstream Customers from a selected Primary Conductor.   This is a fairly simple network trace, but it does have some complicated aspects.   We first need a Server App to perform the trace.   For this example, an ASP.NET app using the GTViewer Objects and GTTrace.   The GTViewer Objects are low-level .NET components for reading and using GTViewer data without running GTViewer or GTVx (no display is required).   With a GTViewer dataset, these objects can perform queries, do spatial searches, lookup feature attributes, create .GTG files, and much more.   The GTTrace objects abstract all of the commonly used network tracing functionality making it easier to create network tracing apps.    By using these components wrapped up in a simple ASP.NET application, a web page is created that will accept a Feature’s connectivity Node Ids as a starting point, then it will separately trace in all directions from the starting feature to find a Breaker (to determine the Upstream direction).  The downstream direction is then searched to gather a list of downstream customers.    The results send back to the user includes a list of customer’s, their location, and pertinent attribute information is returned as the Web Apps result's along with a list of highlighted features to identify the upstream and downstream portions of the circuit, the location of the downstream customers, and the breaker.   GTViewer for iOS will take the results from the Web App and let the user browse the list of Downstream Customers (and optionally locate on them in the map), and graphically show the highlighted trace results.

In the example shown below, you select a Primary Conductor in the map.  The Attribute Info is shown.  Since the Primary Conductor feature is associated with a Web App, there is a  a Web Apps section at the top with a Link to the Downstream Customer Trace app:

If you click the Link to the Web App, it will display the Web App Form for the Downstream Customer Trace App.   For this example, the interface to the app is very simple.  There is a Start Trace button and a Results box to display the trace's tabular results:

When you press the Start Trace button, the Web App on the Server is sent a request to perform the network trace using the selected feature's information as the starting point.   When the Server finishes processing, it will send back the trace results and the list of Downstream Customers is shown in the Results box.  

You can scroll through the Results and can select the Locate on each record to Locate that Customer in the map.   You can also press the Highlight button to draw the highlighted trace results on the map.

The Save button in the Trace Results will let you save the results so they can be recalled later.   Saved results do not require a network connection to recall, and both the tabular and graphic data are saved.

This example of a Web App is very specific but any scenario that involves selecting a feature, specifying some options, and displaying tabular and/or graphical results will work.  The capabilities of the Web App interface will expand too in future versions.

Tuesday, January 12, 2016

Data Collection in GTViewer for iOS version 3


Version 3 of GTViewer for iOS includes several major enhancements including a framework for Data Collection. This new feature provides a way to customize GTViewer for iOS (on iPhones and iPads) with your own forms to capture data in the field for any feature or point on the map.  This Data Collection functionality is designed to work offline (no internet connection required).  If the user is connected to the internet, collected data can be posted to a server (GTShare), and data posted by other users can also be retrieved.


Data Collection Forms are created using HTML and JavaScript.  They can be very simple or very sophisticated depending on your needs.   The Data Collection Forms have access to all of the tabular attribute data associated with a selected feature as well as any previously captured data for that feature.   Forms can be associated with one type of feature (such as Pole Inspection or Valve Inspection) or a group of feature types (such as Line Patrol).  Data Collection Forms can also be used at any point on the map (for identifying Missing Features or adding Field Notes).
A Lifecycle is used to manage the Data Collection process.  Each Data Collection Record has a State (Proposed, Unposted, Posted, Completed) which controls what actions can be performed on it as well as driving its symbology (how it appears to the user).  The Administrator can optionally pre-load a set of records for features in a Proposed state.   These records will appear with a certain symbology that indicates that they need to be visited by the user.   If the user edits one of the proposed records or captures new data, the State will be set to Unposted.  When the user syncs with the server, their Unposted records will transition to a Posted state to indicate that they are available to other users.   If new records posted by other users are available at the time of the sync, they will be downloaded (and their state will be Posted too).  Finally, the Administrator can mark any record as Completed, which again changes it symbology and can optionally prevent any further edits to that Data Collection Record.   The Administrator can also delete any records and a sync will remove them from user's data.

An Administrative Tool (GTShare Viewer) is also available to manage the collected records.  It can import, export, modify, delete, compact, backup, and view the collected records.


Once configured, capturing data in GTViewer for iOS is simple.   From any map view, you can select a feature to show its Attribute Information (by tapping on the feature).   If that feature has a Data Collection Form associated with it, it will have a section at the top of the Attribute Info box containing a link called Add Record:

Selecting the Add Record link, will display the Data Collection Form that you selected (you can have more than one form associated with a single feature).  For this example, the link is for a Pole Inspection form:

The Pole Inspection form in this example lets the user verify the Height, Class, and Year the pole was installed.   The fields default to the Pole feature's attribute information from the GIS.   The user can update this information if necessary, leave an optional comment, and press the Save button.  Once saved, a Red Arrow points at the feature to indicate that it has an Unposted record (the State symbology is configurable too).

If a user has network connectivity, they can go to the Data Collection page in GTViewer for iOS and use the Sync with Server option to post any collected data and to retrieve any new information that other users have posted.

Once the collected data is posted, the symbology changes to indicate that it is a Posted record (Green Arrow in this example):

If you select the same Pole again, you will see the data collected in the Pole Inspection section at the top of the Attribute Info.   An Edit Record link is also present if you want to make changes:

The Data Collection options page also provides other useful tools, like the ability to show only records that are in a particular State and to Browse Records. When browsing records, you can locate on the records in the map too:

The Data Collection Framework in GTViewer for iOS is the first feature offering user-customizable functionality on this platform.  The Web App Framework, available in version 3, also provides the ability to add your own customized functionality, but it is more of an open sandbox and not a complete solution.   Together, both of these frameworks will be very important to GTViewer on the iOS platform and will help you get the most our of your investment.