Product(s):	WaterGEMS, SewerGEMS,
Version(s):	v8i, CONNECT Edition
Area:	Other

Problem

Some users prefer to store their source data networks in geographic coordinate systems such as the World Geodetic System (WGS84), which are based on latitude and longitude coordinates. Importing these data sources directly into Bentley OpenFlows products leads to distortions of angles and distances. This is due to the differences between planar and geodetic coordinates and distances.

While OpenFlows products do not currently support directly importing from geographic coordinate systems, importing and syncing can be achieved through the use of an intermediate data source which is projected into a planar coordinate system such as a State Plane system. If this intermediate data source is maintained with consistent names and data structures then the OpenFlows ModelBuilder tool can be used to keep hydraulic models in sync and accurate as if the source data were in a planar coordinate system.

Note: Care should be taken whenever working in both geographic and projected coordinate systems, as it is easy for confusion to result in significant distortion errors. It is important to recognize whether a measurement refers to the geodetic distance or the planar distance. This is especially true in applications such as ArcGIS where the underlying data may be in a different projection than the current map view, and the measurement tools may be context-sensitive. 

Solution

This sample solution assumes that the user is maintaining information for multiple distinct networks across a wide geographic region, and is storing these networks in a common WGS84 dataset. The basic approach is as follows:

1. Establish Data:
   1. Set up the source data for pipes, junctions, and other network elements in the desired geographic coordinate system (such as WGS84), as feature classes in a geodatabase or as shapefiles. 
   2. Add a Model Name field to each feature class, so that each element is associated with a particular model network.
   3. Create a Model Coordinate System table, where each model name is associated with the appropriate planar coordinate system.
   4. Define a target location for the intermediate data. This can be a folder for shapefiles, or a geodatabase for feature datasets.
2. Update Intermediate Data
   1. Clear all old results from the intermediate data location.
   2. Iterate through each model name in the Model Coordinate System table and identify the appropriate coordinate system.
   3. For each model, iterate through each feature class and filter to only include elements that match the current model name.
   4. For each feature class, project the filtered elements to the specified coordinate system and save the results in a subfolder specific to the model name.
   5. Repeat update procedures as frequently as desired so that the intermediate data remains current.
3. Sync OpenFlows Model
   1. Each model network has its own model file in the relevant OpenFlows product (WaterGEMS, SewerGEMS, etc.).
   2. For each model, use the Bentley ModelBuilder tool to connect to the intermediate data source.
   3. Repeat the sync process as frequently as desired so that the OpenFlows model remains current with the source data.
   4. Note: Ensure that the intermediate data updates are complete prior to initial ModelBuilder import and subsequent syncing.

Note: Projecting data between different coordinate systems can result in loss of accuracy, although for well-defined coordinate systems this is generally minor. In the example below, converting between WGS84 and NAD 1983 State Plane California VI (US Feet) resulted in pipe lengths distorting by approximately 1 inch per 100 miles.

Example Update Procedure

One sample procedure for maintaining an intermediate data source is outlined below utilizing the ArcGIS ModelBuilder functionality. You may need to consult your GIS specialist to implement this procedure and tailor it to your particular data structure. Note that the procedure can be further simplified and customized if utilizing Python scripting with ArcGIS. A Python script could also be automated to update the intermediate data on a regular schedule.

In this example, the intermediate data source is a set of shapefiles for each separate model. A geodatabase with datasets for each model could easily be substituted for the shapefiles.

The overall data structure for this example is shown here:

The automated procedure has been separated into four tools, due to how ArcGIS Iterators behave. The main tool that is run by the user is called "_ExportModels". This can be pre-configured with all required parameters, so the user may simply run the tool with default parameters to update the intermediate data for all feature classes and for all models. 

The main tool first calls a sub-tool to clear any old results, and then calls a sub-tool to perform the projections.

The ClearOutput tool first deletes the output folder in order to remove out-of-date results, and then recreates an empty output folder.

The ProjectAll tool iterates through the table of Model Names. For each Model Name, it calls the ProjectModel tool.

The ProjectModel tool creates a subfolder in the output folder for the specified Model Name, and looks up the appropriate coordinate system name. It then iterates through all feature classes in the Source dataset (such as Pipes, Junctions, etc.). For each feature class, it filters down to just the elements which have the given Model Name, and then projects this subset of features into the appropriate coordinate system. 

The Template file is an empty feature class that has the appropriate coordinate system assigned. This is stored in some stable location and given a short descriptive name which is used within the ModelNames table.