DGN with MSLinks to MS SQL Server Spatial
This document provides a general description of how to convert DGN data with MSLinks to MSSQL Server Spatial. This is achieved by using Bentley Map (SELECTseries 4) to export the DGN data to ESRI file Geodatabase. The resulting data is then translated to MSSQL Server Spatial via FME from Safe Software Inc. While not tested, it’s presumed that this workflow would also work for Oracle Spatial.
This document is not intended to be a training guide for FME or MSSQL Server Spatial.
The following products were used for this workflow:
- Bentley Map Enterprise (SELECTseries 4)
- FME Desktop 2014 SP2 from www.Safe.com
- Microsoft SQL Server Spatial 2008 R2
Step 1 - Export to ESRI File GDB
The following describes the process used to “spatialize” design data by using an intermediate file format: ESRI File Geodatabase.
In Bentley Map, open any design file that contains graphics linked to an RDBMS via MSLinks.
If desired, attach all other files as references, then using the Map Interoperability dialog, export selected features to ESRI File Geodatabase. The export will create a single GDB containing the geometry and attributes for the selected features.
For a successful translation, be aware of the following:
Graphical features must be topologically correct. Invalid geometry can be imported into MSSQL Server Spatial, but may have issues being queried. An example of invalid geometry is as follows:
MSLink Database Type must match the datasource. For example, if an ODBC datasource is used, then the linkage type must be ODBC. If needed, the type can be changed using the Verify Linkages from the Settings menu in either MicroStation or Bentley Map. The following graphic shows both ORACLE and ODBC linkage types in the open design file.
The Bentley Map project schema must match the graphics. Ensure that all features and their properties are defined correctly. A quick check to verify the export was successful is to import the data into an empty design file. The resulting graphics and attributes should duplicate the originating source files. Once successfully exported to GDB, the data can then imported into MSSQL Server Spatial by using FME from Safe Software Inc.
Step 2 - FME to push ESRI GDB to SQL Server Spatial
The following describes how to use FME to import the ESRI file geodatabase into MSSQL Server Spatial. This section is only intended as an overview and not product training. Please contact Safe Software Inc. for training and support on FME.
Open FME Workbench and generate a new workspace. Set the source data to Esri Geodatabase (File Geodb API) and the destination format to Microsoft SQL Server Spatial. Set the database parameters as needed and choose Static Schema. When done, FME will build the translation model showing mapped features similar to the following example.
The Reader and Writer Feature types can be expanded to show the mapped properties. The dataset used for this document included features with MSLinks to an Microsoft Access database, XFM features with user attributes and XFM features without user attributes.
Features with Database Attributes: The Buildings shape feature contains a variety of user defined database attributes.
XFM Features with properties: Blocks are XFM shape features with a single property called Number.
XFM Features without properties: The Curbs are simple XFM linear features and have no properties.
FME Workbench provides the ability to edit a wide variety of settings via the Feature Type Properties dialog. The User Attributes tab lists the names and data types for each column that will be created during the translation. These column properties can be changed prior to translation. For example, the default length for varchar fields is 255 which may be too long in some cases. Using this dialog, that value can be changed to a more manageable number and eliminates the need to modify the column properties after the table has been created in MSSQL Server Spatial.
In the FME Workbench Navigator, verify the translation parameters, and make adjustments if necessary. This may include adding coordinate system to the writer.
Click the Run button and check for errors. As well, note the number of features written to MSSQL Server Spatial are added to the mappings:
The total of these values should match the number of elements in the design files from which the data was exported. The following graphic shows the export results from Bentley Map to ESRI GDB and shows that 26516 features were exported.
As expected, importing this data to MSSQL Server Spatial shows that 26516 elements were written.
Once imported, the FME Data Inspector can be used to visually inspect the data and review the attributes.
The data can also be verified on the Spatial tab in Microsoft SQL Server Management Studio by choosing Select Top 1000 Rows from the tables right click menu or by issuing a simple query such as:
Select * from lots;
Step 3 - Add Primary Key (PKID)
If the data appears correct, a primary key can be added to each table by executing the following two SQL statements.
alter table dbo.tableName
add pkid int identity;
alter table dbo.tableName
add constraint pk_tableName
primary key (pkid);
Step 4 - Validate Geometry
Although the data appears to be correct, and may import without errors, it’s recommended to convert invalid data to valid data an SQL statement against a selected table. This action is done from Microsoft SQL Server Management Studio. To verify if a table has invalid data, execute this SQL.
select PKID, geom.STIsValid()from TableName
Valid geometry is returned with a value of 1, and invalid with a value of 0 as shown.
Instances of invalid geometry need to be converted to valid geometry by using the following SQL command against a selected table. Note that the MakeValid command might cause points in the geometry to shift.
Update TableName set geom = geom.MakeValid();
Step 5 - Optional Database Administration
Bentley Map automatically calculates and displays the Geometry_Area, Geometry_Perimeter and Geometry_Length when querying features.
Queries from MSSQL Server Spatial will automatically generate Database_Area, Database_Perimeter, and Database_Length . For this reason the Geometry attributes imported from Bentley Map can be deleted from the feature tables. Likewise, SYNTHETIC_OID, OGC_GEOMETRY_Length, OGC_GEOMETRY_Area are generated during the export to ESRI GDB and can be deleted from MSSQL Server Spatial.
Step 6 - Bentley Map Geospatial Administrator
When the ESRI file GDB has been successfully imported and verified, the features are registered in Bentley Map Geospatial Administrator.
In Geospatial Administrator, create a new project schema, define a workspace, a named SQL Server Spatial Connection and register the features that were added to the database.
Perform the other housekeeping tasks which includes: setting the feature symbology including property based symbology, defining the metadata, updating the Command Manager, and defining the workspace. When complete, the project schema can be saved and exported for use with Bentley Map.
Step 7 - Bentley Map
Open Bentley Map (SELECTseries 4), connect to the SQL Server Spatial graphical source and query the features. On some occasions, geometry appears to be valid, but is considered invalid by MSSQL. In this event, querying the spatial features will generate an error similar to the following:
If MakeValid in Step 4 above does not correct errors as expected, it may be worthwhile to revisit the original graphics and correct the errors directly in the design files. Bentley Map provides topology cleanup and creation tools that may assist in this task. When complete, delete the feature table with invalid graphics, and repeat the steps above to populate MSSQL Server with the correct geometry.
Finally, verify the data can be posted back to MSSQL.
- modified Wiki Category, 07/06/2017