Geographic Data Files (GDF) Reader/Writer

We used to have as a gdf_type every record type in addition to the geometric types. To make the geometry gdf_type more explicit, we now give a gdf_no_geom type to every feature type that does not contain any geometry, such as VOLHDREC.

The GDF reader reads the entire file sequentially. Header information from the Volume level is therefore processed first, followed by information from the Dataset, Section, and Layer levels, respectively. Scaling and offset factors found in the header of the GDF file are applied to all coordinates read from the file. The reader extracts each individual feature, one at a time, and passes it on to the rest of the FME for processing.

The reader supports a dynamic schema configuration based on the FIELDEFREC (03) and RECDEFREC (04) records. The reader has a default configuration for different variants such as Navteq and TeleAtlas 3.4. If the dataset to be read has a header with FIELDEFREC (03) and RECDEFREC (04) records, those will be used to adjust the configuration. Therefore, new record types can be defined in the dataset header and the reader will handle them correctly.

The geometry of level 1 points is the center of the bounding box of all the components. The geometry of level 1 lines is the concatenation of all the components. The geometry of level 1 areas is computed by "dissolving" of all the components.

Complex (Level 2) features symbolize abstract network topology and therefore cannot be faithfully represented by visual graphic representation in all cases. The attributes on complex features will always retain all information necessary to completely reconstruct the level 2 topology or otherwise access every aspect of the data represented in the GDF file. The geometry on complex features is intelligently created to visually represent those parts of the network topology where possible. In most cases, the geometry on complex features is indeed helpful in understanding the network through a graphical viewer.

The geometry assigned to complex features is either lines, points, or polygons. Complex features that have FROM/TO links are read as level 2 lines whose geometry is assumed to be a single segment line from the center of the bounding box of the FROM feature and to the center of the bounding box of the TO feature. If the complex feature has no FROM/TO links, then the types of the members are considered. Those with only polygonal members are read as level 2 polygons whose geometry is the result of dissolving all the polygonal members. Finally, those complex features that do not consist entirely of polygonal members are read as level 2 points whose geometry is assumed to be the center of the bounding box of all the components. One exception to the above should be noted; all complex features with no FROM/TO links and exactly one member will assume the complete geometry and type of that member. Any complex features that contain a reference to a member that does not appear in the file will be output as a COMPFEREC feature with no geometry.

When the GDF reader encounters an record type it does not know how to process, it simply outputs this element as an UNKNOWN_RECORD and moves on to read the next feature. However, this should not happen unless the record schema has not been previously defined in a RECDEFREC (04) record in the header.

In addition to the different record types, which are known as the physical representation in GDF terminology, the reader also takes into account the Data Model to create the FME features. This Data Model is vendor- and version-specific and defines the GDF feature names, and attribute names and values. Should the need arise, the Data Model for the different variants and versions of GDF can be edited in a text editor. The Data Model is in the FME install folder under plugins/gdf/DataModel.

Creating a GDF file currently involves a significant amount of customization. All features sent to the GDF writer are assumed to be in the “linked” structure as outlined in the feature representation section. The order of these features must also be correctly determined before sending them to the writer.

Future versions of the GDF writer may acquire more intelligence and be able to correctly produce the necessary “linked” features automatically, given regular lines, polygons, etc; currently, however, custom mapping files are required.

Producing a meaningful GDF file as output will require setting up a custom mapping file that describes the details of your input schema for the following reasons:

• Generic (automatic) translations usually work for most formats because they are so simple. (If some road has an attribute "length" in the source, it makes sense to make an attribute called "length" in the destination.) However, GDF is a special case. GDF is so incredibly complex that such a "best guess" is impossible. Translating most formats does not require the understanding of a schema, just knowledge of it. In GDF, the FME not only needs to know the schema of the input data, but it must actually understand the meaning as well.
• GDF has hundreds, if not thousands, of predefined attributes and values that features can have. When FME is given a source dataset without any indication which attributes in the source data should be used to fill in the required attribution in the output GDF file, most of this information will be lost. (There is no way to "guess" at the feature code value for any road when all it is given is a source file with no knowledge of the meaning of the schema or input data.) Therefore, an "automatic" translation will usually not generate anything useful. What needs to happen is that a user needs to create a custom mapping file that tells the FME where to find all the required GDF data within their specific source dataset.
• If gdf_fieldefrec features are written, their field width definitions will be honored. This allows the user to dynamically define custom field widths for use in the GDF files produced. This is useful, for example, in creating both TeleAtlas Multinet 3.1 and 3.2 GDF files, which use different field widths in several records.