You are currently reviewing an older revision of this page.
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.
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:
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.
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 by the ModelNames table.