Bentley Map V8i (SELECTseries 10)

FME Extension

Bentley Map has tools to import and export several different formats of geospatial data. However, users often have a requirement to access other data formats, not directly supported by Bentley Map. For this reason, the Bentley Map FME Extension has been designed to make available many additional geospatial data formats to improve user workflows.

What is FME?

FME (the Feature Manipulation Engine) is a complete data access solution for reading, writing and transforming spatial data. It is produced by Safe Software (www.safe.com). In general FME is used to translate geographic data to and from a variety of different formats including those listed on the FME Desktop Supported Formats online resource. The FME Desktop product contains additional useful tools such as the following:

  1. The FME Universal Viewer is a handy tool to view geospatial data of many formats in a quick way.
  2. The FME Workbench is a graphical authoring environment that makes it easy to graphically specify data transformations.

FME Desktop Product Installation Requirement

Please note that prior to using the Bentley Map FME Extension functionalities, you must install and license the required version of the FME Desktop product. Please refer to the Requirements section for additional information.

Data Formats

The following table lists those data formats which have been tested with the Bentley Map FME Extension application:

Format Import Export
Bentley MicroStation Design (V7) X X
Bentley MicroStation Design (V8) X X
Bentley MicroStation GeoGraphics X
Bentley MicroStation Design (V7) X X
CityGML X X
ESRI Geodatabase (File-based) ** requires installation of application software ** X X
ESRI Geodatabase (MDB) ** requires installation of application software ** X
ESRI Shapefile X X
FOT GML X X
Industry Foundation Class STEP Files (IFC) X
Intergraph MGE X X
MapInfo MIF/MID X X
MapInfo TAB (MITAB) X X
Microsoft SQL Server 2008 Spatial X X
OpenGIS KML Encoding Standard X X
OS (GB) MasterMap X X
WFS (Web Feature Service) X

Please refer to FME Desktop Supported Formats online resource for a complete list of data formats supported by the FME Desktop product.

Known Issues

This section contains information about known issues in this Bentley Map FME Extension release. Please report any other issues found while using this software. It is not necessary to report the following known issues:

Issue Details Formats
FME Desktop 2019 32-bit for Windows is not supported. FME Desktop 2019 32-bit for Windows is not supported. All
FME Desktop 2015.0 32-bit for Windows is not supported. FME Desktop 2015.0 32-bit for Windows is not supported. Users of FME Desktop 2015 32-bit for Windows software should install FME Desktop 2015.1 (or later) 32-bit for Windows. All
Limitations with import of data that contains solid geometries. During import operations, solids will be converted to multi-surfaces because Bentley Map does not currently support solids. The immediate drawback is the loss of the solid semantic and inability to export back to solids. IFC
Text is not supported. Text geometry currently cannot be imported or exported as the XfmStorage doesn't support that yet. The FME Extension will ignore instances with text geometries and log a warning. MicroStation GeoGraphics
Issues with string lengths being too long in XFM. XFM appears to have some length limitations for string properties. However that limitation is not enforced when setting the string, but rather when retrieving the property on querying the instance, e.g. in Data Browser or on export. It appears that the issue is not there after FME Extension is restarted after the import. KML, CityGML, LandXML
Structs are flattened during import operations. During import operations, structs are flattened out as properties, so a struct named 'Address', containing the properties 'Street' and 'Housenumber' will be incorporated as properties with the names 'Address.Street' and 'Address.Housenumber' respectively. FOT GML
Struct Arrays are not imported. FME Extension does not currently support modeling of structs and struct arrays. FOT GML
Structs are not exported. Any struct or struct array that an instance may contain will be stripped from the instance on export. A warning will be logged to inform the user that information has been lost on export. FME Extension does not currently support modeling of structs and struct arrays. Because structs are flattened at import, struct data still gets written at export if the feature definition is left unchanged. FOT GML
No support for multiple geometry properties. In very rare cases the user may want to import data where for a given instance multiple geometry properties exist (e.g. in CityGML a single WallSurface instance may have a geometry for LOD2 and one for LOD3). Since FME Extension does not currently support multiple geometries, only the first geometry property will be considered. Other geometry properties will be skipped and a warning will be logged. CityGML
Relationships are imported as foreign keys if the FME reader supports that. There is no conversion that creates XFM sub features for relations. FME Extension does not currently support that from a functionality point of view. CityGML
No coordinate transformation on export. During export, geometries will not be reprojected, so the exported geometries will be in the same projection as they were in FME Extension. However the coordinate system information is being exported. So the exported data knows the coordinate system it is in if the following conditions exist:
  1. A valid coordinate system was assigned to the active design file in the FME Extension session.
  2. The user selected a target coordinate system in the FME connection dialog.
All
Issues with exported spatial reference information. For certain projections the resulting output in FME doesn't contain proper SRS information (e.g. Dutch RD projection). Example output: <gml:Surface srsName="_FME_0" srsDimension="3">...</gml:Surface> GML, SHP
Incorrect schema generated by FOT GML export.

Because it isn't possible to set a schema file (XSD) in the FME dialog when exporting a file to GML, FME will always create its own schema file. This also means that the exported data might not validate with the official schema. The only way to ensure a proper export is by verifying that the feature structure (including structs + struct arrays) at export matches the official schema definition exactly. One thing beyond our control is that FME also generates two geometry properties. One is a single geometry property, and the other is its multigeometry variant. For example:

  • <element ref="gml:curveProperty" minOccurs="0"/>
  • <element ref="gml:multiCurveProperty" minOccurs="0"/>

Also the used namespace in the GML output file is wrong:

  • <gml:FeatureCollection xmlns:gml="http://www.opengis.net/gml"
  • xmlns:xlink="http://www.w3.org/1999/xlink"
  • xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  • xmlns:fme="http://www.safe.com/gml/fme"
  • xsi:schemaLocation="http://www.safe.com/gml/fme fot_out.xsd">
FOT GML
The installer complains that the ecom.config file is installed by another Bentley application. Workaround if the installer complains that the ecom.config file is installed by another Bentley application: Back-up the existing ecom.config and remove it from the specified directory and run the installer again. Note: Removing the existing ecom.config may break the applications that installed that config file All
Non-planar polygons are ignored. Some data files contain polygons which are non-planar. Technically they are invalid, and the associative regions don't match them well because of this. But neither FME nor Bentley Map throws an exception, writes a log message, or does anything else because of it. All
Import of certain IFC features cause a property type mismatch error. In some cases FME provides additionally redundant properties (e.g. the same property will be delivered as string with comma separated values and as array). This leads to a property type mismatch error. The redundant property will be discarded. 3D Data
Holes in vertical surfaces aren't always detected properly on export. Many 3D data, especially CityGML data, has vertically oriented features, like walls. Often they contain holes, like windows. In special circumstances (close parallel surfaces) holes don't get exported properly. Generally the distance between two walls is large enough to work properly, but the distance between the two sides of a window is often too small. 3D Data
Swapping two properties in schemamapping does not work. Example: given a class with the properties "name" and "description," the user chooses to assign the name property to description, and the description property to name. The exchange will complete with warnings. The log will list argumentExceptions, because the reclassifier cannot handle this. All
Exporting ESRI File Based Geodatabase files. When creating a new ESRI File Based Geodatabase during export, an ESRI ArcView license level will not work. You must have a license of ESRI ArcEditor or ESRI ArcInfo. In the FME Extension when exporting to ESRI formats, ArcGIS must be installed on the same machine as Bentley Map and the FME Desktop software. ArcGIS and FME Desktop must be both licensed. When creating a new ESRI File Based Geodatabase, you must have a license of ArcEditor or upper, an ArcView license level will not work. Workaround: Creating the File Based Geodatabase in ArcCatalog and using it in the FME Extension should provide the ability to export. ESRI File Based Geodatabase (GDB)
Exporting LandXML files. While attempting to export data to LandXML file format, an "Exchange failed" error message occurs indicating "FME Error(s): There was a problem writing out the 'Alignments' and 'Alignment' elements. The problem was: 'Item id must be globally unique'. LandXML requires that 'Name' attributes are globally unique. If features have non-unique values for the 'Name' attribute, the attribute will need to be renamed." At this time exporting of the LandXML file format is not supported. LandXML
Importing existing CityGML files. A schema mapping problem occurs for the AuxiliaryTrafficArea feature which causes FME Desktop 2010 to provide the property "citygml_function" with an incorrect property type. This issue should be fixed in a future FME Desktop release but for now we recommend to uncheck this property when importing AuxiliaryTrafficArea features when using the FME Desktop 2010 product. CityGML
In CityGML xlink:href references are ignored. In the current CityGML support xlink:href references are ignored (this is due to a limitation in FME Safe Software). For more information please visit the FME Community. CityGML

Knowledge Base

This section contains a knowledge base of information that can be useful for Bentley Map FME Extension users.

Issue Details Format
Enable 3GB option in Windows for import of large datasets For large datasets and certain FME formats (e.g., KML) FME consumes a lot of memory. It is therefore recommended to enable the 3GB option in the boot.ini file of the computer in those cases. Please review the following Knowledge Base article for additional information:

In general that switch is intended for applications that are memory-intensive, such as database management systems (DBMS). The use of a larger virtual address space can provide considerable performance and scalability benefits. However, the file cache, paged pool, and nonpaged pool are smaller, which can adversely affect applications with heavy networking or I/O. Therefore, you might want to test your application under load, and examine the performance counters to determine whether your application benefits from the larger address space.

KML
FME does not export Relief features. FME does not presently support writing Relief features to CityGML. CityGML
FME 2009 does not support creationDate and terminationDate properties. These properties are present on most of the features (everything derived from the type _CityObject). This has only been added in FME 2010. CityGML
Importing CityGML data with Gauss-Krüger projection may lead to swapped X and Y coordinates. This is an FME issue that is scheduled to be fixed for FME 2011 only. For FME 2009 and 2010 this can be worked around by modifying the file <FME Installation path>\xml\gml\xfmaps\gml_keywords.xml file. In that file insert the following keywords into the group called "srsName-to-axisOrder" <group name="srsName-to-axisOrder"> <keyword name="EPSG:31466-EPSG:31469" value="1,2"/>gt; <keyword name="EPSG:25832" value="1,2"/> <keyword name="EPSG:25833" value="1,2"/> <keyword name="EPSG:4314" value="1,2"/> <keyword name="EPSG:2166-EPSG:2168" value="1,2"/> <keyword name="EPSG:2398 " value="1,2"/> <keyword name="EPSG:2399 " value="1,2"/> ... </group> CityGML
Coordinate system required when exporting from FME Extension to GML To export from FME Extension to a GML file, a coordinate system must be set or the following error may occur: Error Message: FME Error(s): * - Unable to write feature geometries without an FME Coordinate System. Either tag the FME features with a coordinate system, or use the GML writer SRS_NAME along with the SRS_AXIS_ORDER keywords to specify the GML srsName and axis order for the GML and elements * A fatal error has occurred. Check the logfile above for details * Error encountered during writer shutdown. This condition can be corrected using either of the following methods: 1. Set a coordinate system in FME Extension:
  1. Select the "Tools -> Geographic -> Select Geographic Coordinate System" menu.
    1. Press the second button of the Geographic Coordinate System toolbox (From Library).
    2. Select the appropriate Coordinate System. For more details please consult the MicroStation documentation.
  2. Set a coordinate system in the FME Export dialog.
GML
Coordinate system required when exporting from FME Extension to KML format. FME requires that the projection is set to LL84 when exporting to KML format. The following quote is from the FME documentation: KML requires all vector geometry to use the LL84 coordinate system, and to have three dimensions. The KML writer will reproject input feature geometry to ensure that this constraint is fulfilled. Note: An error will occur if the KML Writer encounters a feature with no specified coordinate system. KML
Unable to open Filenames with Unicode characters In order for FME to read non-Latin file names, you must open the Regional Settings in Windows and set the language for non-Unicode programs to the language used in the file name. To use filenames with Chinese characters on Windows XP you have to install the files for East Asian languages first. This can be done in the 'Regional and Languages Options' on the 'Languages' tab by activating the checkbox. All
Error reported if FME uninstalled after FME Extension is installed. There is no way to detect that FME is missing or uninstalled. This exception is thrown whenever an FME object type is used. Typically that happens when the Browse Dataset dialog on Import/Export is opened. All