Geographic Data Files (GDF) Reader

Licensing options for this format begin with FME Desktop Professional Edition.

The Geographic Data Files (GDF) Reader allows FME to read files in the Central European Normalisation (CEN) Standard format established by European Committee for Standardisation. This chapter assumes familiarity with this advanced format.

For the detailed format specification, please see:

https://www.iso.org/standard/54610.html

Writer Deprecation Notice

https://knowledge.safe.com/articles/75379/geographic-data-files-gdf-writer-deprecation.html

Overview

The CEN standard for Geographic Data Files (GDF) is commonly called GDF 3.0. The International Standards Organization (ISO) standard is commonly called GDF 4.0. Several GDF data producers, like NAVTEQ and TeleAtlas, for example, do not strictly follow either GDF 3.0 or 4.0 standards, but rather follow their own slightly modified version of these standards.

GDF 3.0 (ASCII Sequential) is currently supported by FME (including variations such as NAVTEQ, TeleAtlas, and ETAK).

The original GDF specifications (GDF 3.0) were developed in Europe to meet the needs of professionals and organizations involved in the creation, update, supply and application of referenced and structured road network data.

It is much more than a generic GIS standard, as GDF gives rules on how to capture the data, as well as how the features, attributes and relationships are defined.

GDF was developed in a European project named EDRM (European Digital Road Map). Its primary use is for car navigation systems (for example, Bosch , Philips, Volvo); however, because the standard is based on a general, non-application-specific data model, it is also used for many other transport and traffic applications including Fleet Management, Dispatch Management, Traffic Analysis, Traffic Management, and Automatic Vehicle Locations.

The GDF file format is often referred to as a database, and was never intended to be used by applications directly. Indeed, the structure of GDF files themselves impose significant inefficiencies when extracting data from GDF files. GDF users will generally transform the data into some other database or format upon which their application will work directly.

In the GDF file structure, features (or elements) are organized into three layers. Features in each layer do not actually contain any geometry, but simply link to features in the layer below from which you are supposed to take the geometry.

Note: The term features is used within GDF documentation to refer to elements residing on levels 1 and 2. This chapter uses the term features in the manner understood by standard FME terminology.)

1. Level 0 (Topology): This level contains elementary GIS topology components. No features overlap in any way, and neighboring relationships are known. Everything is described by Nodes, Edges and Faces.
2. Level 1 (Features): Level 1 is the most used level of GDF. It contains simple features like road elements, rivers, boundaries, and signposts. Features can have attributes that are specific to the feature (for example, one way, width of the road, number of lanes). Features can also have relations, which are very important for car navigation systems. For example, relations can include “forbidden turn from road element 1 to road element 2” or “road element 1 has priority over road element 2.”
3. Level 2 (Complex Features): At this level, the level 1 “simple features” are aggregated to a higher level feature. For example, at level 1, all road elements of an intersection are represented. At level 2, the intersection may only be represented with a single point. The figure below illustrates this.

Roundabout Representation: Levels 1 and 2

Level 2 is of interest mostly when a simplified description of the road network is sufficient. For instance, inter-urban route calculation does not require a high level of detail. Vehicle location by means of a GPS receiver, however, does need the more detailed description of the road network.

The GDF reader uses symbolic names for different feature types stored within a data file. Each feature will have a gdf_type attribute on it.

Reader Overview

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 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.