Geospatial Connector

The Geospatial Connector is being developed to support geospatial data coming from multiple sources.

Supported Formats

Presently, the following formats are supported by the Geospatial Connector:

  • ShapeFile
  • PostGIS database - through a .geodb file
  • WFS (Web Feature Service) through a .geodb file
  • ArcGIS FeatureService - through a .geodb file
  • ESRI File Geodatabase
  • KML (Uncompressed KMZ file)
  • GeoJSON
  • Oracle Spatial database - through a .geodb file
  • SQL Spatial database - through a .geodb file

 The following elements will be processed by Geospatial Connector:

  • Graphical 3D data
  • Graphical 2D data
  • Elements properties

Geodetic coordinate system not supported as spatial root

The coordinate system of the file that is used to define the coordinate system of the iModel must be a projected coordinate system. When creating a connection to a non geo located iModel, the user can select a geo located input file to set the iModel geographical coordinate system. If no file is selected, the first geo located input file encountered will be used to set the iModel geographical coordinate system. The coordinate system units must be a projected coordinate system (i.e. feet or meters).  You cannot select a file which has a Geodetic coordinate systems (i.e. using degree units).

Note that the other subsequent files added to the connection can be in meters, feet or degrees.

Converting ShapeFiles

The ShapeFile format consists of a collection of files with a common filename prefix, stored in the same directory. The three mandatory files have filename extensions .shp, .shx, and .dbf. Most of the time, a .prj file is also part of the collection, containing the geographic projection information. When you process a shapefile, the mandatory files must be present in the same directory as the shapefile but only the .shp is selected for the conversion.

Converting Shape files stored in ProjectWise Design Integration

If you plan to process ShapeFile stored in ProjectWise Design Integration through iTwin Synchronizer portal, make sure you run the "Scanning for References and Link Sets" tool from ProjectWise Explorer prior to create a new connection.

 

Converting features from a PostGIS database

To convert features coming from a PostGIS database, you need to create a *.geodb file. It is a JSON file that includes the connection information as well as the list of features you want to convert.

A sample file is delivered with the program, in the C:\Users\%USERNAME%\AppData\Local\imodelbridges\GeoBridge\Assets\SampleConfig\Geodb folder.

The .geodb file can be processed through the iTwin Synchronizer client.

It is possible to include multiple features (tables) in the same .geodb file. Here is an example:

{
   "type": "PostGIS",
   "objectFilter":[{
      "schema": "schema name",
      "name": "table name",
      "type": "view or table",
      "column": "optional geometry column name"
   },
   {
      "schema": "schema name",
      "name": "table name",
      "type": "view or table",
      "column": "optional geometry column name"
   },
   ],
   "connectionProperties":{
      "Host":"database address",
      "Database":"database name",
      "Port": "port number",
      "User":"username",
      "Password":"password"
   }
}

Another option is to have one .geodb file per feature table. The advantage of having one feature per .geodb file is when you have multiple tables but only few are updated frequently. This way, you can synchronize the ones that are frequently updated only, without having to synchronize all tables unnecessarily. Another advantage is that you can control de visibility of each feature independently, which is not the case when you process multiple features in the same .geodb file.

Grey exclamation Note - This type of source can be processed with the iTwin Synchronizer client only. It cannot be processed through the iTwin Synchronizer portal because of security reasons as it contains sensitive information like the username and the password to connect to the database.

Converting WFS (Web Feature Service)

To convert features coming from an Web Feature Service server, you need to create a *.geodb file. It is a JSON file that includes the server URL, the username and password if any.

A sample file is delivered with the program, in the C:\Users\%USERNAME%\AppData\Local\imodelbridges\GeoBridge\Assets\SampleConfig\Geodb folder.

Grey exclamation Note - If the server is secured, the .geodb can not be processed through the iTwin Synchronizer portal because it contains sensitive information like the username and the password to connect to the Server. If the server is public, it can be processed through iTwin Synchronizer Portal.

Converting ArcGIS FeatureService Server

To convert features coming from an ArcGIS FeatureService server, you need to create a *.geodb file. It is a JSON file that includes the server URL, the username and password if any.

A sample file is delivered with the program, in the C:\Users\%USERNAME%\AppData\Local\imodelbridges\GeoBridge\Assets\SampleConfig\Geodb folder.

Grey exclamation Note - If the server is secured, the .geodb can not be processed through the iTwin Synchronizer portal because it contains sensitive information like the username and the password to connect to the Server. If the server is public, it can be processed through iTwin Synchronizer Portal.

Converting ESRI File Geodatabase

ESRI File Geodatabase is slightly different from the other supported formats as it is a folder and not file. Because of that, it can be processed through the iTwin Synchronizer client only as iTwin Synchronizer Portal is not supporting the selection of folder yet.

To be able to select a folder in the iTwin Synchronizer client, the user must select the option “ESRI file geodatabase” in the drop-down list. This option allows to select a folder instead of a file.

Converting KML/KMZ file

KML/KMZ is a common format for distributing geographic data as it can be delivered on the Internet and displayed in multiple applications. 

KML format can be processed in both iTwin Synchronizer applications, client and portal. KMZ format can only be processed in the synchronizer desktop application. To synchronize a KMZ in the portal application, it must be uncompressed prior to synchronize it as only the KML file are selectable.

Grey exclamation NOTE - The coordinate system of a KML/KMZ file is always degrees (lat-long).It cannot be selected to define the spatial root of the iModel because the iModel must have a projected coordinate system (meters or foot). To synchronize a KML/KMZ file in a new non geolocated iModel, it is required to use a geolocated dgn file with an equivalent projected coordinate system (in foot or meters). This design file will be used to set the spatial root of the iModel. If you have an existing design that complies with this requirement and covers the same area as the KML/KMZ, it can be used to specify the spatial root of your iModel. if not, you will have to create a new design file. 

For example, if your KML/KMZ is in Pensylvania, create a new design file and assign it a projected coordinate system covering the region your KML/KMZ is in. In this specific case, PA83-NF (NAD83 Pennsylvania State Planes, North Zone, US Foot) could be a good choice. Add at least one design element in it because empty dgn cannot be used in a synchronization connection. Save the file. This file can now be use in the connection to specify the spatial root of your iModel. 

Converting GeoJSON file

GeoJSON is an open standard geospatial data exchange format that represents simple geographic features and their nonspatial attributes, based on JavaScript Object Notation (JSON).

This format can be processed in both iTwin Synchronizer applications, client and portal.

Converting Oracle and SQL Spatial database

To convert features coming from an Oracle Spatial or SQL Spatial database, you need to create a *.geodb file. It is a JSON file that includes the connection information as well as the list of features you want to convert.

A sample file is delivered with the program, in the C:\Users\%USERNAME%\AppData\Local\imodelbridges\GeoBridge\Assets\SampleConfig\Geodb folder.

It is possible to include multiple features (tables) in the same .geodb file by using the "objectFilter" parameter.

Another option is to have one .geodb file per feature table. The advantage of having one feature per .geodb file is when you have multiple tables but only few are updated frequently. This way, you can synchronize the ones that are frequently updated only, without having to synchronize all tables unnecessarily. Another advantage is that you can control de visibility of each feature independently, which is not the case when you process multiple features in the same .geodb file.

Grey exclamationNote - This type of source can be processed with the iTwin Synchronizer client only. It cannot be processed through the iTwin Synchronizer portal because of security reasons as it contains sensitive information like the username and the password to connect to the database.

Grey exclamationIMPORTANT NOTETo be able to process Oracle Spatial data, the Oracle client 19c program must be installed on the computer running the iTwin Synchronizer application. 

If the Oracle client is not installed, the synchronization will stop and a message similar to the following will be displayed:

Using a Configuration file

Basically, geographical elements coming from a Spatial Database don't have any symbolization. To assign symbology to the elements that will be stored in the iModel, a configuration file is required.

The configuration file is also used to specify the Geographic Coordinate System (GCS) of the input file if no GCS is set on the data or if the data needs to be reprojected

Grey exclamation NOTE - The use of configuration file is not mandatory. If no configuration file is present beside the input file, a default symbology will be applied, and the Coordinate System will be taken from the data itself.

A sample configuration file (SampleConfig.cfg.xml) is delivered with the program, in C:\Users\%USERNAME%\AppData\Local\imodelbridges\GeoBridge\Assets\SampleConfig\GeoConfig\.

Configuration file definition

Appearance section

Color

It is the color applied to the point, line and outline (polygon). The color must be specified with Hexadecimal values.

Example: <Color>0036a3</Color> (light blue)

FillColor & Transparency

It is the color applied to the interior of polygon. The fillcolor must be specified with Hexadecimal values. The transparency is defined by adding the level of transparency after the fille color value. In the example bellow, a transparency of 50% will be applied on the dark blue fill color. 

Example: <FillColor>84dee850</FillColor> (dark blue)

Weight

It is the weight applied to the point, line and outline (polygon). The Weight is “value set + 1 screen pixels.

Example: <Weight>4</Weight> = 4+1=5 pixels.

GCS section

CoordinateSystemKeyName

It is the coordinate system of the input file.

If no coordinate system is specified in the configuration file, the coordinates from the input file will be read as is.

In case of a shapefile, the coordinate system is usually defined in a .prj file. If no .prj file is present along with the shape file and you know in which coordinate system is the shapefile, the key name can be specified in this parameter.

Any Key Name available in the Bentley coordinate systems dictionary (coordsys.dty) is accepted.

When required, the input file coordinate system will be reprojected to the iModel coordinate system.

Not all coordinate systems are compatible for reprojection. The user needs to make sure the input file coordinate system can be reprojected to the coordinate system defined in the iModel. If the iModel is not already geolocated, the coordinate system of the input file must be projected with meter units, as the  iModel units is exclusively meters. 

 Features section

When converting multiple features from a database or from an ESRI File Geodatabase, it is possible to apply a "per feature" symbology by using the “Feature Name” parameter in the configuration file.

If the user has specified symbology on few features only, the ones he hasn’t defined symbology on will have the default symbology defined at the top of the configuration file.  User can edit the default symbology as well to fit his needs.

The color must be set in hexadecimal values. The sample file has the following values specified as example:

<Color>0036a3</Color> (light blue)

<FillColor>84dee8</FillColor> (dark blue)

<Weight>2</Weight>

 

If no configuration file is defined, a default symbology will be applied:

Color Outline: 000000 (black)

Color: 008be1 (blue)

FillColor: 008be1 (blue)

Weight for point type: 2

Weight for line type: 1

 

The XML configuration file must be in the same folder as the input file and must have the same name as the input file.

For example:

Recommended
Related