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 email@example.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
(last updated 5 May 1997)
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.
There have been quite a few misunderstandings about the use of GDF:
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 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
Last Updated: June 11, 1996
The GDF 3.0 standard is described in a manual with the following themes:
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)|
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):
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
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:
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:
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:
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:
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!
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).
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.
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)|
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.
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.
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)|