Hexagon GeoMedia Access Warehouse Reader
FME can read data from Hexagon GeoMedia Access Warehouse.
Hexagon GeoMedia Access Warehouse (FM0) Product and System Requirements
Format |
FME Platform |
Operating System |
||||
---|---|---|---|---|---|---|
Reader/Writer |
FME Form |
FME Flow |
FME Flow Hosted |
Windows 64-bit |
Linux |
Mac |
Reader |
Yes |
Yes |
No |
Yes |
No |
No |
Overview
GeoMedia warehouses store both geometry and attributes for features in the form of columns within the tables of a database. Tables can be divided into two groups based on content. The first group contains meta-information about the formatting of the data, including coordinate systems, tables aliases, modification logs, a data table list, and a field level index. The second group is the list of tables that actually contain the geometry features and their attributes.
In order to retrieve information from a GeoMedia warehouse, an Open DataBase Connectivity (ODBC) source must be set up. GeoMedia Access Warehouse requires a filename (and will also accept a data source name [DSN]). Once the reader has all the required information, it then dynamically creates a temporary ODBC source (when a filename is supplied) to connect to that database.
Point, line, area, arc, and text primitive geometric data can be stored in the tables produced by GeoMedia, as well as composites (aggregates), boundaries (donuts) and collections (aggregates) of those types. The reader can read a given data table holding multiple types of geometries. , but the writer only produces tables containing one specific geometry type each, including boundaries, composites or collections of that type. The result is that one table containing many types of features may be converted into several tables – one for each type of feature by the writer. This is especially true of the collection type in GeoMedia which is very generally a collection of any primitive type and has no corresponding equivalent in FME. Syntactically, the type is simply appended to the table name separated by an underscore (for example, tableOfManyTypes_area).
Table Names
The key table for determining the names of the spatial tables is called the GFeatures table. This table contains the list of names of the geometry and attribute data tables. This information can also be retrieved from the FieldLookup table which also contains the specific fields of each geometry table. Before either of these lookups can happen, however, you have to find the GFeatures and FieldLookup tables. Table names can be aliased and there is only one table that must have a constant name (the GAliasTable). From here, you can look up the given names of the other metadata tables in the specific database you are viewing.
GeoMedia warehouses hold three-dimensional geometries. A geometry table may contain any mix of attributes the user has specified, but must contain a column containing the actual geometry object. This column is a blob type and is simply an encoded block of binary data. Each geometry blob type is encoded in a unique way and varies in length.
Text
GeoMedia can store text in two variations: plain text and rich text. Since FME supports plain text only, the GeoMedia reader will convert all rich text to plain text and set the text size to either the default (1 ground unit) or to the user-supplied size in ground units using the Text Size in Ground Units parameter. If the text being read is in rich text format, it also sets the attribute fm0_rtf_text_string to the original formatted string.
Because reading is performed by parsing the tables and respective binary BLOBs directly from the Microsoft Access database, the reader does not require GeoMedia to be installed in order to run.
Coordinate System Support
Coordinate system support exists for reading: in the best case, a GeoMedia warehouse that contains a defined coordinate system can be read and converted to any of the supported writer formats in FME which also support coordinate systems, with the same coordinate system name. If the coordinate system is not specifically identified to have the exact same defined name within FME, the attributes of the coordinate system are still transferred, producing an identical coordinate system in all but name.
One issue involves the type of projection used in a coordinate system definition which GeoMedia calls the Base Storage Type. This type can be set to one of projected, geographic or geocentric. Projected types are the usual case and are handled normally by FME, though it is notable that the storage center values from the GeoMedia coordinate system become built into the coordinates and are cleared in translated warehouses. All geographic types are represented in the Lat/Long coordinate system but remain identical in appearance. The storage center values here will represent how to convert the coordinates to radians since they will be provided in degrees, as is consistent with the way GeoMedia itself handles geographic types. Finally, the geocentric type is not supported by FME.
Spatial Indexes
The reader supports native spatial indexing.
Reader Overview
The reader produces FME features for all data held in the Microsoft Access .mdb or .accdb
files, with the exception of image (coverage) data.
The reader opens the connection to the source dataset and reads the GAliasTable to determine the proper table names to be used. Next it reads the table of GFeaturesTable type to determine the list of tables that contain geometry data. This list of data tables to be read is modified by the specified reader and feature type parameters in the workspace. Each geometry table is then read and its features are processed and returned one at a time. When a table is exhausted, the reader starts on the next data table in the list until all tables are read.
Geometries from GeoMedia do not map exactly to FME geometries. This will have the following effects on the resulting FME features:
- Collections map to one aggregate feature for each FME fm0_type depending on which types exist in the collection.
- Multilevel composites may be flattened out to simpler first- or second-level nesting.
- Because GeoMedia is not strict in its typing, the reader can produce some nonsensical features that may be skipped (for example, a line aggregate containing points).