GDF - Geographic Data Files

DISCLAIMER:

The Geographic Data Files section of the old ERTICO website was originally created by Marcel Konijn (Intergraph) with the financial support of the European Commission in the framework of the ANIMATE project. These pages were originally produced thanks to a cooperation of ERTICO and Navigation Technologies (now Navteq).

Although the original GDF site has been edited and re-organised in July 2005 for style purposes, except where noted, the content itself was last updated in May 1999. ERTICO no longer provides any additional support or the GDF Helpdesk, but if you have a general question or comment about this section, you may contact info@mail.ertico.com

More information is also available from the International Organization for Standardization (ISO), at the following link: http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=30763&ICS1=3&ICS2=220&ICS3=1

 

CONTENTS

 

 

 

GDF Introduction

(last updated 5 May 1997)

What is GDF?

GDF (Geographic Data Files) is a European standard used to describe and transfer road networks and road-related data. Much more than a generic GIS standard, GDF provides rules on how to capture the data as well as how the features, attributes and relations are defined.

GDF was developed in the EDRM (European Digital Road Map) project. Its primary use is for car navigation systems (from Bosch, Philips, Volvo etc.), but it can also be used in many other transport and traffic applications such as fleet management, dispatch management, traffic analysis, traffic management, and automatic vehicle location.

Importance / Political impact of GDF

GDF version 3.0 has been released and issued to CEN for the voting procedure. If accepted, it will become the only CEN-accepted standard for digital road networks. GDF will also be promoted as an ISO standard. Working Group 3 of ISO204 has adopted GDF, and an ISO standardisation of GDF is expected next year.

In Europe, GDF is not only a theoretical standard, but it is also promoted by the major digital road data suppliers such as EGT, Bosch, ETAK and Tele Atlas – which have committed themselves to build their databases according to GDF specifications. This implies that all of Europe will be available in GDF format in the coming years. It is expected that GDF will become a true commodity item, available for purchase on CD like other software products.

The use of the same standard by different suppliers makes the comparison (price/quality) for GDF users easier.

The European Commission has recommended that GDF should be used in their 4th Framework Programme, which means that all pilot projects across Europe are required to use GDF if digital road maps are needed, which again gives a major push towards the acceptance of the standard.

(Mis)Understanding GDF

There have been quite a few misunderstandings about the use of GDF:

  • GDF is not only an exchange format. GDF contains an exchange format, but also much more including rules for data capturing, visualisation, etc... 
  • A GDF map has no scale. It depends on the application where it is used, as a GDF map does contain accuracy (e.g. <5m). 
  • A GDF map can be detailed, but this is not always needed. Quite often, people say that a GDF map is too detailed for their application, but they probably think that the GDF used by a car navigation system is too detailed. 
  • A GDF database (in the exchange format) will never be used as such. Users will first transform it into their system, which could be a GIS (Geographic Information System), car navigation system, or routing algorithm. Therefore you cannot talk about a GDF application, but rather an application that uses GDF. 
  • GDF is not a CD standard for car navigation systems. GDF is used and converted onto the CD-ROM in the internal format of the navigation system. 
  • GDF is application independent
  • GDF is a stable standard. Although the development is still ongoing in ISO204, there will not be any fundamental changes. This protects the investment when working with GDF. 
  • Building a spaghetti road map is simple, but building an accurate road map for ITS (Intelligent Transport Systems) is a professional task.


International acceptance
Since GDF is being accepted by ISO, it will be reviewed by North American and Japanese organisations. Most organisations feel that the European GDF standard is much more advanced than the Japanese (JDS) and American (SDTS) standards. Australia is also actively looking into the use of GDF for their applications.

GDF Structure
GDF has a three-level structure:

Level 0: Topology. This is a common GIS topology description that is widely accepted - i.e. everything has been described by nodes, edges and faces. This topology description is similar to DIGEST.

Level 1: Features. Level 1 is the most used level of GDF and contains simple features such as road elements, rivers, boundaries, and signposts. Features can have attributes that are specific (i.e. one way, road width, number of lanes) as well as relations that are very important for car navigation systems. Relations can be “forbidden turn from road element 1 to road element 2” or “road element 1 has priority over road element 2”.

Level 2: Complex Features. At this level the “simple features” are aggregated to a higher-level feature. For instance, at Level 1 all road elements of an intersection should be represented, but at Level 2, the intersection is only represented with a single point. Level 2 is mostly used when a simplified description of the road network is sufficient. For instance, inter urban route calculation does not require a high level of detail, but vehicle location by means of a GPS receiver does need the detailed description of the road network. Currently, work is being devoted to make more aggregated levels for various applications.

 

Level 1 representation of a roundabout                  Level 2 representation of a roundabout    

 

 

GDF 3.0 Documentation & Manual

Last Updated: June 11, 1996

 

The GDF 3.0 standard is described in a manual with the following themes:

  • GDF introduction gives a general overview of what GDF is.
  • The GDF data model describes the GDF objects by means of a NIAM scheme.
  • Feature catalogue describes the features’ themes (categories) and features defined in GDF. Besides the pre-defined features, there is a possibility to enter user-defined features. This should be done with care, since it will lead to different flavours of GDF.
  • Attribute catalogue describes all feature attributes in detail as well as how the attribute should be captured to avoid ambiguity. For instance, “Traffic Flow” can be one way direction positive, one way negative, or open or closed in both directions 
  • Relationship catalogue defines the relationships that are present and which features are involved.
  • Feature representation explains how a feature should be represented, but this is rarely used, since every GDF implementation chooses its own way of showing the feature.
  • Quality description descibes how the quality of a GDF data set can be measured.
  • Global Data catalogue explains how general GDF data information should be entered (such as the projection method used, producer’s name, date of GDF set, etc.)
  • Media Record Specification is very important to most users of GDF! It describes the format in which GDF data should be transferred. A GDF dataset is an 80-character ASCII file that is readable. The media record specification describes each record in the GDF dataset, with the first two digits indicating the type of record (line feature, attribute record, edge record, XY record, relationship record). The picture below shows part of a GDF data set according to the media record specification.  

 

The extensive description of the standard described in the various chapters below shows that GDF is much more than just an exchange format. It gives data producers instructions how they should capture data in GDF format and GDF users know what they can expect when someone is delivering a GDF data set.

 

The complete GDF3.0 Manual contains 12 chapters plus annexes:

Table of contents / Chapters 1-5 TOC1-5.pdf (135 KB)
Chapter 6 PR6.pdf (1256 KB)
Chapters 7-9 PR7-9.pdf (135 KB)
Chapters 10-12 PR10-12.pdf (135 KB)
Annexes Annexes.pdf (508 KB)

 


 

How to Specify a GDF Map

Last Updated: 15 July 1997

The GDF map user’s experience is important when specifying a map. Below you will find guidelines on how to specify a map to your needs so that a data producer can build or supply the standard map with the desired features.

When a customer says, “I need a road map of my city”,  the data producer will first ask is what the content, detail, and quality should be. If you can specify the map in GDF terms - with the desired features, attributes and relations -  the data producer can often give you the exact availability and price. You can also check with different suppliers, since you can talk the "same language" as the data suppliers!

An extensive description on how to describe and specify (measure) the quality of a GDF map is given in Chapter 9 of the GDF Manual listed above.

You should specify (in order):

  • Feature themes
  • Features
  • Attitudes
  • Relations
  • Complex features (aggregation)
  • Accuracy
  • Up-to-dateness
  • Completeness

Feature Themes
There are 10 feature themes defined in GDF, although in most cases, not all are necessary. Appendix A1.1 of the Manual gives you an overview of the feature themes and classes.
1. Road and ferries - in 99.9% of ITS applications, this feature theme is required.
2. Settlements and named areas (postal codes, elective districts etc) - These are always useful for reference, but for postal code areas, the amount of data and thus the GDF data set will increase rapidly – and thus its price.
3. Administrative areas - These refer to political boundaries such as country and regional boundaries. (See Pages 47 and 52 of the Manual to see the difference between administrative areas and named areas.
4. Land Cover and use – can be useful for visualisation purposes, but does not have a large direct relation to ITS.
5. Bridges and tunnels -  May be needed for freight and special transport (bridge heights for special transport or location of tunnels for dangerous goods transport).
6. Railways - Mostly needed for visualisation/orientation.
7. Waterways - Mostly needed for visualisation/orientation.
8. Road furniture (traffic lights, sign posts, traffic signs) – necessary for large scale maps, a high level of detail for urban traffic management.
9. Services - (petrol stations, hotels, banks, etc.)
10. Public Transport – Necessary for integrated public/private ITS network  

Features (Classes)
After deciding which Feature Themes should be present in the set, you must decide which features should be included and check if they match your own definition (see Chapter 5 of the Manual).

Issues to consider:

  • If, for example, you define main roads and secondary roads as separate features, GDF separates one feature by the attribute code "functional road class". 
  • Are all your features present in the GDF definition, and if not, can they be modelled in GDF?
  • What are the remaining (user defined) features?
  • Can they can be grouped into the same feature classes that GDF defines?


Attributes
Per feature class, many attributes can be defined - for instance, a road element can have more than 50 attributes.

For road elements, the most commonly used attributes are DF (direction of flow), FC (functional road class), FW (form of way) are most likely supplied in any base map. For urban navigation, house numbering may be an option. Street names are always kept in the attribute ON (official name).

Appendix A1.4 of the GDF Manual lists the type of attributes per feature theme, while Chapter 6 provides an extensive definition and description of each attribute. Some attributes have pre-defined codes, as listed in Appendix A1.5. (For instance, FW 10, means "road element is part of a slip road".)

Issues to consider:

  • Are the attributes that belong to the features defined in the same way as for GDF? (E.g. bridge heights, road width, number of lanes...)
  • Is there a need for user defined attributes?
  • Could attribute values be converted to match the GDF definition?
  • Is there sub-attributing - for instance "one way street for cars, but two way for others"?

Relations
GDF Relations can roughly be divided into two categories:

1. Indication of the relations between features - "Road A is in City X", "Restaurant Y is along Road B".
2. Typical relations for car navigation systems - "Prohibited Manoeuvre" to indicate that it is not allowed to turn left at a certain junction.
 
Relations, especially the second category, are essential for car navigation systems as they calculate the optimal route. For other ITS applications, relations may not be so relevant. Relations are pre-defined by the relationship code described in Appendix 1.6 of the Manual and Chapter 7 provides an extensive definition and description of each relationship.

Issues to consider:

  • Are relations used/needed?
  • How do the relationships match the GDF relations?
  • Is there a need for user-defined relations?

Complex Features (Aggregation)
GDF supports the possibility of grouping features classes in a logical way, such as grouping all road elements that belong to intersection. The GDF definition (grouping) can be used or individual groupings can be created based on the GDF data set interpretation.

The guidelines used by the GDF data producers to aggregate road elements into complex features (Road and Intersections) are described in Appendix A1.3.

Logical groupings can also be based on road number - i.e. all road elements that carry the same route number (A1, N325) – so one complex feature could be modelled as “Aggregated Way".

Issues to consider:

  • Is the standard complexing (aggregation of features) satisfactory for your targeted application? (Using Road, Intersection, Aggregated way)
  • Are you responsible for the grouping in your own system? (using the basic GDF level 1 elements)
  • Is there a need for own (user defined) aggregation definition?


Accuracy
GDF maps do not have a scale and are defined with a certain accuracy – such as all features within 10 metres. Certain applications that use differential GPS need a high accuracy of the features. If the GPS can indicate the position within 5 meters, the map should be created accordingly.

Interurban routing or fleet management may not require a high level of accuracy – less than 100 meters may be sufficient.

The level of accuracy impacts two factors in regards to the GDF data set:

1. Size: more accuracy means a higher number of intermediate points.
2. Price: every level of accuracy has its price!

Up-to-dateness
The requirement for up-to-dateness can vary per ITS application and Feature class. For instance, an emergency services application requires up-to-date information about the road network. An out-of-date feature in the map can cause ambulances to take the wrong road. Other applications, such as tourist information, will not suffer so much from out-of-date information.

One could also specify the up-to-dateness per Feature Class, depending on the ITS focus. The road network should be updated yearly, but the location and characteristics of the services updated only every month.

The up-to-dateness is quite often the point where non-commercial map makers fail. Often a lot of effort is made to build a map for the city or region, but often the map is rarely updated and older maps are used. Just like the accuracy, up-to-dateness has its price. Poor up-to-dateness is experienced as poor completeness and poor correctness (of attributes, geometry and topology).

Completeness
How complete should a map be? A 100% completeness can never be guaranteed, but some maps could require a 99.5% completeness. This means that if there is more than one out of 1000 features which are incomplete, the set can be refused because a certain completeness was requested. Data producers will mostly guarantee a certain completeness of their data in combination with the up-to-dateness and accuracy.

 


 

Examples of GDF

 

These GDF files used for testing GDF were created are according to the GDF exchange format in ASCII. Normally the next step will be to translate (import) the GDF file into the system that requires the data, such as GIS, car navigation, (dynamic) vehicle routing system, etc. Use the GDF viewer.zip (508 KB) to access these files.

Brussels National Airport - Zaventem, Belgium  bxl_nat.zip (508 KB)
Sulzbach, Germany  sulzbach.zip (508 KB)

 

 

 

 

GDF & Location Referencing

Last Updated: May 20, 1999

ERTICO’s work on location referencing was executed by its Sub-Committee on Location Referencing, which was responsible for the EVIDENCE project.

ILOC 017v10.pdf (508 KB)
The above document on location referencing describes the coding procedure in detail. Executive summary:

Traffic and traveller information is a key issue in transport telematics. Such information is always related to objects in the real world, such as a stretch of road, an intersection, a hotel or a public transport facility. In transport telematics terminology, real world objects are called locations.

A message provides information about a location and refers to it by using a location reference: an identifier used by the system that creates and sends the information, which can then be interpreted without ambiguity by the receiving system. In current systems for traffic information, locations are pre-defined and pre-coded, with the codes are stored in location tables.

The disadvantage of such tables is that they need to be created and maintained, and stored in the receiving system. This becomes a problem when certain bits of information – such as every street section in Europe - need to be addressable.

On-the-fly coding (no tables, no maintenance)
The ERTICO Committee on Location Referencing developed a new, universal method for location referencing that does not require any pre-coding of locations. A key characteristic of the method is the on-the fly coding approach. A code is created by the system when needed that sends the information, which is then interpreted, used, and discarded by the receiving system.

The coding basis is the Intersection Location, or ILOC. An ILOC exists where two or more roads having different sets of road descriptors (such as numbers and names) meet. Road sections between ILOCs are referenced by two bounding ILOCs. Road units that are part of an ILOC are referenced by manoeuvre relationships between three consecutive ILOCs.

ILOC referencing
The ILOC code created on-the-fly consists of the WGS84 co-ordinate pair (in 10 microdegrees) of the centre of the ILOC (a geodetic identifier) and three road descriptor identifiers of five characters each (a descriptive identifier). The descriptive part is used to resolve ambiguities that may arise because map databases of different origin generally differ in specification and resolution.

The ILOC referencing method describes rules for creating an ILOC identifier, such as determining the centre of the ILOC, creating the road descriptor identifiers, and deciding which ones to use in a specific code. The method is compatible with GDF.

The EVIDENCE project
Manual tests carried out between five different databases were very promising. The method is described in a document which was submitted in October 1997 to ISO TC204 WG3 for standardisation. The ERTICO-led, EU-funded EVIDENCE project, which finished in May 1999, aimed at refining and finalising the rules, and preparing them for implementation in ITS applications.

 

Other GDF Reference Materials

GDF workshop - February 1995

Organised by some of the members of the DRIVE EDRM project (Bosch, Tele Atlas and Intergraph).

Workshop handouts handouts.pdf (457 KB)
Workshop proceedings proceedings.zip (1116 KB)
GDF: A Proposed Standard for Digital Road Maps - Luc Heres/H. Claussen gdf_standard.pdf (67 KB)
Standards for Driver Information Systems - Luc Heres standards_heres.pdf (68 KB)
GDF: A Lingua Franca for Geographic Information - Luc Heres/T. Wood gdf_linguafranca.pdf (80 KB)
Geosperanto (in Dutch) - Luc Heres geo_heres.pdf (80 KB)
Via Incognita (in Dutch) - Luc Heres via_incognita.pdf (70 KB)
Vraagen naar de korste weg (in Dutch) - Luc Heres vragen_heres.pdf (51 KB)
U Verklaat nu het gedigitaliseerde gebied! (in Dutch) - Luc Heres verklaat_heres.pdf (64 KB)
Werken aan het netwerk (afl. 3 - in Dutch) - Luc Heres werken_3.pdf (18 KB)
Werken aan het netwerk (afl. 4 - in Dutch) - Luc Heres werken_4.pdf (15 KB)
Harmonisation of Dynamic Traffic Data, based on GDF - Marcel Konijn Harmonisation_konijn.pdf (117 KB)
Congestion, Where is the Problem? - Marcel Konijn Congestion_konijn.pdf (110 KB)

 

 

GDF class at ERTICO – March 1997

Welcome - Marcel Konijn welcome.pdf (218 KB)
General Introduction - Rob van Essen   gdf_intro.pdf (450 KB)
Introduction to Digital Map Databases - Kees Wevers intro_maps.pdf (368 KB)
Role of GDF in Map Database Exchange - Volker Hiestermann gdf_role.pdf (162 KB)
Glance through the GDF Document - Volker Hiestermann gdf_manual_glance.pdf (129 KB)
Data Format vs. Data Content - Kees Wevers data_format.pdf (300 KB)
Data Model - Bart Tielens data_model.pdf (560 KB)
Exchange Format - Volker Hiestermann gdf_exchange_format.pdf (508 KB)
Pointers and Levels in the GDF Format - Bart Tielens pointers_levels.pdf (560 KB)
GDF Catalogues - Marcel Konijn gdf_catalogues.pdf (300 KB)
Steps in Conversion and Using GDF  - Uwe Henze gdf_conversion.pdf (443 KB)