Network for Developers

Data Extraction Format Guide

CONFIDENTIAL

Disclaimer
This content is provided "as-is" and without warranties of any kind, either express or
implied, including, but not limited to, the implied warranties of merchantability, fitness for a
particular purpose, satisfactory quality and non-infringement. NAVTEQ does not warrant
that the content is error-free and NAVTEQ does not warrant or make any representations
regarding the quality, correctness, accuracy, or reliability of the content. You should
therefore verify any information contained in the content before acting on it.
To the furthest extent permitted by law, under no circumstances, including without
limitation NAVTEQ's negligence, shall NAVTEQ be liable for any damages, including, without
limitation, direct, special, indirect, punitive, consequential, exemplary and/or incidental
damages that result from any content, even if NAVTEQ or an authorized representative has
been advised of the possibility of such damages.

NAVTEQ Network for Developers

ii

CONFIDENTIAL

DATA EXTRACTION FORMAT GUIDE

Table of Contents

NAVTEQ Map Data ................................................................................................................. 1

1.1
1.2

1.3
1.4

1.5
1.6

1.7

1.8

Structure Overview .........................................................................................................................1

Geometry ........................................................................................................................................2
1.2.1 Link Attributes......................................................................................................................3
1.2.2 Node Attributes....................................................................................................................6
Navigation .......................................................................................................................................7
Path ..............................................................................................................................................11
1.4.1 Naming ..............................................................................................................................12
1.4.2 Addressing.........................................................................................................................12
1.4.3 Logical Addressing vs. Actual Addressing .........................................................................13
1.4.4 Other Issues ......................................................................................................................13
Administrative ...............................................................................................................................14
Cartography ..................................................................................................................................15
1.6.1 Cartography Attribute Size ................................................................................................17
1.6.2 Polygon Formation ............................................................................................................18
Points of Interest (POI) .................................................................................................................19
1.7.1 POI Attributes ....................................................................................................................20
1.7.2 POI ParentChild Relationships ........................................................................................21
Traffic Codes.................................................................................................................................21

NAVTEQ Extraction Formats .............................................................................................. 24

2.1

2.2

2.3

2.4

Overview .......................................................................................................................................24
2.1.1 RDF (Relational Data Format) ...........................................................................................25
2.1.2 GDF 3.0 (Geographic Data Format) ..................................................................................26
2.1.3 SIF+ (Standard Interchange Format).................................................................................26
2.1.4 NAVSTREETS...................................................................................................................27
2.1.5 POI XML ............................................................................................................................27
RDFTM Overview ...........................................................................................................................27
2.2.1 Target Developer Profiles and Business Markets..............................................................28
2.2.2 Benefits of RDF .................................................................................................................29
GDF 3.0 Overview ........................................................................................................................30
2.3.1 Levels ................................................................................................................................30
2.3.2 Attributes ...........................................................................................................................31
2.3.3 Relationships .....................................................................................................................32
2.3.4 Usage of GDF 3.0 Data .....................................................................................................32
2.3.5 NAVTEQ and CEN GDF 3.0 Differences..........................................................................32
2.3.6 Data Availability/Distribution ..............................................................................................32
SIF+ Overview ..............................................................................................................................33
2.4.1 File Content .......................................................................................................................33
2.4.2 Usage of SIF+ Data ...........................................................................................................37
2.4.3 Data Availability/Distribution ..............................................................................................37

NAVTEQ Network for Developers

iii

CONFIDENTIAL

2.5
2.6

NAVSTREETS Overview ............................................................................................................38

POI XML Overview .......................................................................................................................39
2.6.1 Delivery Package...............................................................................................................40
2.6.2 Content Attributes..............................................................................................................41

Development Environment Considerations ...................................................................... 42

Choosing an Extraction Format.......................................................................................... 43

4.1
4.2
4.3
4.4
4.5
4.6
4.7

Availability of Out-of-the-Box Tools...............................................................................................43

Adherence to International Standards...........................................................................................44
Geographic Availability .................................................................................................................44
Content Availability .......................................................................................................................45
Lifetime of Extraction Formats ......................................................................................................45
Extraction Format Flavors .............................................................................................................45
Other Considerations ....................................................................................................................46

Using Your Extraction Format ............................................................................................ 48

Technical Customer Support .............................................................................................. 49

6.1
6.2

TCS Assistance ............................................................................................................................49

Changes to Extraction Formats.....................................................................................................49

Appendix A.1

Glossary ........................................................................................................... 50

Appendix A.2

NAVTEQ Overview .......................................................................................... 51

Appendix A.3

NAVTEQ Data Compilation............................................................................. 53

Appendix A.4

NAVTEQ Data Maintenance............................................................................ 55

Appendix A.5

Using Look-Aside Files .................................................................................. 56

Appendix A.6

NAVTEQ Data Format Quick Reference........................................................ 58

NAVTEQ Network for Developers

iv

CONFIDENTIAL

Revision History
Version

Date

Comments

Public

3/14/07

Public Version

NAVTEQ Network for Developers

CONFIDENTIAL

This page intentionally left blank

NAVTEQ Network for Developers

vi

CONFIDENTIAL

1
1.1

NAVTEQ Map Data

Structure Overview

NAVTEQ has a number key map data dimensions of great interest to developers, including:
Unique, powerful structure
Unique geodesic reference system (WGS 84) with longitude and latitude in decimal
degrees (10-5)
Contiguous country borders
Cross-border road networks
The structural elements of the NAVTEQ map database are shown below.

NAVTEQ Database Worldwide Structure

GEOMETRY
NAVIGATION
PATH
ADMINISTRATIVE
CARTOGRAPHY
POINTS OF INTEREST
TRAFFIC CODES
CUSTOMER SPECIFIC

NAVTEQ Network for Developers

- Links, nodes, shape points, relative elevation,

connectivity
- Arterial classification, dividers, barriers, one-ways,
speed limits, road signs, turn restrictions, ramp signs,
time of day and flow restrictions
- Street names, route number and address ranges
- Country, state, city, settlement, province, postal
codes, etc.
- Railroads, rivers, canals, lakes, golf courses, shopping
centers, woodlands etc.
- Hotels, restaurants, tourist attractions,
transportation terminals etc.
- RDS-TMC codes from national providers
- Special requests aggregated to underlying
geometry

CONFIDENTIAL

1.2

Geometry

The key dimensions of the geometry portion of the database include:

Link road segment beginning and ending at a node
Node intersection, termination of a link, or change of attribution (a square in the
diagram)
Shape point adds shape to a segment (a circle in the diagram)

The database geometry is organized around the link-node relationships. Each link has a
reference node and a non-reference node. A reference node determines the left/right side of
a link, and is a node with the lower latitude. If the latitudes of both end nodes are identical,
the reference node is the node with the lower longitude. Each link has a variety of attributes.

NAVTEQ Network for Developers

CONFIDENTIAL

Trafalgar Square
Link
25307534

Node

1.2.1

Link Attributes

Link attributes include:

Access characteristics
{

Enable vehicle specific applications

Define the types of vehicles that are permitted to use the link

Supported vehicle types include:

automobiles

buses

carpools

deliveries

emergency vehicles

pedestrians

taxis

through traffic (see the following diagram)

trucks

NAVTEQ Network for Developers

CONFIDENTIAL


Destination

X1

X2

Red = Thru Traffic not allowed to travel in the specified direction

X1 & X2 = Origins

Display characteristics
{

Attributes that are used in routing, map publishing, and display applications

Supported display characteristics include:

boat ferry

bridge

controlled access

detailed city inclusion

frontage road

full geometry

indescribable

in-process data

intersection internal

manoeuvre

multi-digitized (see the following diagram)

paved

poi access road

private

rail ferry

NAVTEQ Network for Developers

CONFIDENTIAL

ramp

roundabout

special traffic figure

tollway

tunnel

undefined traffic area

urban

Multiple Digitization

NF

ID

EN

TI

AL

Real world representation of lanes diverging

CO

Digitization of lanes diverging

The multi-dig flag is not applied if the road beds are > 80 meters
apart or if a feature runs down the middle

An example of some of the link attributes attached to link: 25307534 is shown below.
General Attributes
Link ID:

25307534

Display:

Detailed city, Paved

One-way: Yes
Access Characteristics
Deliveries: No

Emergency: Yes

Pedestrians: Yes

Taxis: Yes

Carpools: No

Buses: Yes

Trucks: No

Cars: No

Bicycles: Yes

NAVTEQ Network for Developers

CONFIDENTIAL

Addresses
Name:

Trafalgar Square

Address range: Left: 66-5 (Mixed)

1.2.2

Right: Valid un-addressed

Node Attributes

Node attributes include:

Z-Level
{
{

Represents relative elevation

Used in route calculation to prohibit turns between roads that do not meet at
grade

Can be used to enhance display

Represents relative elevations

Applies to both nodes and shape points

Values are -4 to +5A (Z-level of 0 does not mean it is at ground level)

Z-level = 0

Z-level = 1

Aligned
{

Used to edge-match two adjoining sub-regions

Applies to nodes and shape points on the sub-region border

Nodes and shape points have the same latitude and longitude in both files
Note: Border nodes and links (as of Q4, 2006) also have the same permanent
IDs adjoining regions. Exceptions: Mexico/US border, Thailand and its
bordering countries, and Indonesia. These exceptions are stored as
separate RMOBs (Relational Map Object Base).

NAVTEQ Network for Developers

CONFIDENTIAL

1.3

Navigation

The navigation part of the database includes the following attributes:

Arterial classification (functional classes)
Dividers/barriers location, legal
One-ways/direction of travel
Speed information (speed limits, special speed situation, special speed limits)
Signs
Lane information (number of lanes, extended number of lanes, connected lanes)
Scenic routes
Time of day

NAVTEQ Network for Developers

CONFIDENTIAL

 Turn restrictions
Direction of traffic, flow restrictions
Long haul
Stub links
Arterial classification is a particularly important attribute known as functional class (FC).
Functional class defines the hierarchical organization of the road network. The purpose is to
determine logical ways to connect cities.
Five road FCs are captured in the NAVTEQ database:
FC 1
Very long distance routes between major cities. The highest-level network comprises
the FC 1 arterials, which are primarily controlled access highways designed for verylong-distance travel linking major metropolitan areas and cities.

FC 1 Example

FC 2
Primary routes between major and smaller cities and through metro areas. Extending
the coverage of the FC 1 network is the primary role of the FC 2 network. Most highspeed, limited-access highways not in the FC 1 network are assigned FC 2, together
with other classes of roadways. Often, the FC 2 network connects the major cities as
the FC 1 network does, but at a lower mobility level; it also provides the best
connection between smaller cities. Major through roads in metropolitan areas are
typically coded FC 2.

NAVTEQ Network for Developers

CONFIDENTIAL

FC 12 Example

FC 3
Major routes between minor cities or towns, and through city districts. The FC 3
network complements the FC 1 and 2 networks to form connections between the higher
level networks and minor cities. In metropolitan areas, roads used for intermediatedistance routes, capable of handling high traffic volumes relative to other local roads,
are often coded FC 3 to serve as primary routes through and between contiguous town
centers or city districts.

FC 13 Example

FC 4
Routes connecting minor towns or villages and collecting the local traffic in the city
districts. The FC 4 network moves most traffic along main roads to smaller towns and
through and between neighboring parts of cities. The FC 4 roads form a well-connected
network of good quality roads for through traffic in the interstices between the higherlevel arterials. The FC 4 level is used when a hierarchy between two or more roads
cannot be guaranteed by the simple combination of the other traffic attributes and the
length of the links.

NAVTEQ Network for Developers

CONFIDENTIAL

FC 14 Example

FC 5
Roads that are not efficient through routes. The lowest level and final category is FC 5,
which comprises roads not considered to be arterials or transportation corridors. Local
streets, including most minor collectors, roads in areas with few outlets, low-speed
neighborhood streets, most indirect routes, and dead-end streets are coded FC 5.

FC 14 TO FC 15 Example

NAVTEQ Network for Developers

10

CONFIDENTIAL

1.4

Path

Path attributes refer to street names, route numbers, and address ranges, and include:
Names/addresses
{

Address range

Address format

Address scheme

Address type

Feature type

Route type

Base name

Language code*

Prefix

Suffix

Direction on sign

Street type

Name Status
{

Exit number

Explicatable

Junction name

Name on road sign

Postal name

State name

Vanity name
*

Language codes include Unicode. Unicode refers to a character code that

defines every character in most of the speaking languages in the world. It is a
standard for representing characters as integers. Unlike ASCII, which uses 7 bits
for each character, Unicode uses 16 bits, which means that it can represent more
than 65,000 unique characters.

NAVTEQ Network for Developers

11

CONFIDENTIAL

1.4.1

Naming

NAVTEQ uses various naming rules, with many dependent on the country. Most do not apply
to postal-only names. In the U.S., the naming rules include:
Abbreviations
{
{

Mount > Mt; Saint >St

If a name exceeds 35 characters, other abbreviations are used (i.e., natl, lndg,
etc.)

Punctuation
{

Sunnyvale-Saratoga Rd

Normalizing names
{

1st Ave not First Ave

CA-82 not Hwy 82

Most complete name

1.4.2

Main St not Main

N Tully Ave not Tully Ave

Addressing

NAVTEQ has specific conventions regarding addressing, including:

Address range
{

Beginning and end

Left and right sides

Logical ranges in North America (see the following diagram)

Address format
{

Numeric (e.g., 100)

Hyphenated (e.g., 10-98)

Leading zero (e.g., 0100)

Alphanumeric (e.g., 2S300, W5, N121W20198, etc)

Address scheme
{

Even

Odd

Mixed

Address type

Base

City

County

NAVTEQ Network for Developers

12

CONFIDENTIAL

1.4.3

Commercial

Old

Logical Addressing vs. Actual Addressing

Logical addressing
{
{

Applied in North America

Entire range of valid addresses for a given block is included, regardless of whether
or not a structure is present
Often represented in blocks of 100 (i.e., the hundred block is 100-199)

Actual addressing

1.4.4

Applied in Europe

Only the addresses of existing structures are included

Other Issues

Duplicate addresses may exist within cities (i.e., Los Angeles)

{

Zones/postal codes can be used as tie breakers

Multiple address ranges can be associated with a name (see the following diagram)
{

When an area is renumbered, both ranges may be used for some amount of time

On a boundary (i.e., city vs. country addressing)

Address ranges can be associated to a particular name on a link

Example: CA-82 has no addresses, but El Camino Real has address range 100198

Arques Ave
20201-20299
(base)

NAVTEQ Network for Developers

Unincorporated Area

Arques Ave
20200-20298
(base)

City of San Jose

Arques Ave
100-198 (base)
20200-20398

San
Mateo

Arques Ave
101-199

Santa Clara
County

13

CONFIDENTIAL

1.5

Administrative

Administrative information includes:

Administrative levels
{

Country

State

County

City

Settlement

Province

Administrative level descriptions

Postal codes
Zones (zone type = PA, KD, and KA)
Daylight savings time
Time zone
Government codes
Language codes
The administrative hierarchy includes complete administrative information for both sides of
each link:
Boundaries for the administrative levels are included
Administration levels vary by country

United States

State

County

City

N/A

Canada

Province

County/District

Municipality

Settlement

Germany

Bundesland

Kreis

Gemeinde

Settlement

France

Region

Department

Commune

Settlement

England

Postal County

Postal Town

Locality

N/A

Puerto Rico

Commonwealth

Municipio

Barria

N/A

Postal codes
Postal codes can be numeric or alpha-numeric
{

US: 95126

England: WD6 4

NAVTEQ Network for Developers

14

CONFIDENTIAL

Canada: L7L 6R1 (3 digits are available in the core map; 6 digits as an external
file)

Postal code is provided for both sides of each link

Postal codes are often generalized
{

US: only the first 5 digits are published (i.e., code is 95054-1163; NAVTEQ
publishes 95054)
England: only the first 4 digits are published (i.e., code is WD6 4RN; NAVTEQ
publishes WD6 4)

External file for postal centroids that can be used for the UK and The Netherlands

1.6

Cartography

Cartography attributes capture the location and description of geographical features.

Attributes include:
Administrative boundaries
{

Aircraft roads

Airports

Bay/harbor

Built-up area

Canal/water channel

Cemeteries

Golf courses

Hospitals

Industrial complexes

Islands

Lakes

Military bases (North America only)

Native American Reservations (North America only)

Oceans

Parks (city/county, national, state)

Pedestrian area

Railroads

Rivers

Shopping centers

Sports complexes

Undefined traffic areas

NAVTEQ Network for Developers

15

CONFIDENTIAL

Universities/colleges

Woodlands

Boundaries/Landmarks
{

Cartographic country boundary

Business/commerce building/landmark

Convention/exhibition building/landmark

Cultural building/landmark

Education building/landmark

Historical building/landmark

Medical building/landmark

Park/leisure building/landmark

Residential building/landmark

Retail building/landmark

Sports building/landmark

Tourist building/landmark

Transportation building/landmark

Elevation contours

Cartographic state/province boundary (North America only)

Park in Water

NAVTEQ Network for Developers

16

CONFIDENTIAL

1.6.1

Cartography Attribute Size

Cartography attribute size is used to determine polygonal inclusion (versus linear inclusion)
in the NAVTEQ digital map for some features.
This section meets the
criteria for polygonal
inclusion

The change between linear

and polygonal inclusion is
generalized within 25 metres

Polygons > 10,000 m2/108,000 ft2:

Polygons >50,000 m2/540,000 ft2:

Municipal (city) park

Cemetery

County park

Golf courses

State park

Hospital complexes

National park

Industrial complex

National monument

Universities

Named/unnamed islands, or
islands with navigable features
regardless of size.

Shopping center

Lakes

Native American Indian Reservations

Sports complexes
Military bases
Landmark footprints
Other:
Bays/harbors >1 million m2/
10,800,000 ft2 (when there is a logical
point of closure).
Canals/channels/rivers wider than 25
meters/82 feet

NAVTEQ Network for Developers

17

CONFIDENTIAL

1.6.2

Polygon Formation

Different features can be captured with different types of polygon formations. In the
following example, capturing the footprint of an airport can be done via an outline
formation; that is, it is not necessary to capture the terminals, parking garages, runways,
etc. However, other features such as airport roads (runways) or parking garages need to be
captured in full formation. The formation polygons are then layered for the correct display of
the airport information.

Outline Formation vs. Full Formation

Aircraft Roads
Aircraft
Roads
Polygon
Enclave

Airport Polygon
Airport

Aircraft Rd is
Full Formation

NAVTEQ Network for Developers

Airport is Outline
Formation

Layer polygons for

correct display

18

CONFIDENTIAL

1.7

Points of Interest (POI)

NAVTEQ has over 60 POI categories. The following categories are regionally included in the
core map. Not all categories and attributes are available in all regions/countries:
Airport

Home specialty store (Q2, 2007)

Amusement park

Hospital

ATM

Hotel

Automobile dealership new cars

Ice skating rink

Auto dealership used cars

Library

Auto service and maintenance

Medical service

Automobile Club

Museum

Bank

Named place

Bar or pub

Night life

Book store
Border crossing

Office supply and services store

(Q2, 2007)

Bowling center

Park and ride

Bus station

Park/recreation

Business facility

Parking garage

Casino

Parking lot

Cemetery (Q2, 2007)

Performing arts

Cinema

Petrol/gasoline station

City hall

Pharmacy

Civic/community center

Place of worship (Q1, 2007)

Clothing store (Q2, 2007)

Police Station

Commuter rail station

Post office

Consumer electronics store

(Q2, 2007)

Public sport airport

Convenience store (Q2, 2007)

Residential area/building (Q1, 2007)

Convention/exhibition center

Rest area

County council

Restaurant

Court house

School

Department store (Q2, 2007)

Shopping

Embassy

Ski resort

Ferry terminal

Specialty store (Q2, 2007)

Golf course

Sporting goods store (Q2, 2007)

Grocery store

Sports center

NAVTEQ Network for Developers

Rental car agency

19

CONFIDENTIAL

 Guest house

Sports complex

Hamlets

Tourist attraction

Higher education

Tourist information

Historical monument

Train station

Home improvement & hardware store

(Q2, 2007)

Winery

1.7.1

POI Attributes

POIs can have the following attributes:

Accessible for heavy good vehicles

National importance

Actual address

Open 24 hours

Address
Airport type

Parent/child (see the following

diagram)

ATM available

Percent from reference node

Building type

Phone number

Capital indicator

Place of worship building type

Car wash available

POI exonyms

Chain name and ID

POI lat/long coordinate (calculated

based on address attributes)

Convenience store available

Facility type
Food type
High flow diesel pump available
In vicinity
Located on motorway
LPG, CNG and diesel availability
Name language code

NAVTEQ Network for Developers

POI name
POI side
POI synonyms
Population
Rest area type
Supported petrol cards
Vanity city

20

CONFIDENTIAL

1.7.2

POI ParentChild Relationships

Many POIs have a parent-child relationship, such as airports and airport parking.

ST Parking

Parent POI

LAX

Child POIs with

Logical Associations

Addison St

ATM
Child POI with
Physical Association

LT Parking

Parent / Child Relationships

Physical: child POI is located in or is directly attached to its parent
Logical: child POI is not located in or is not directly attached to its parent

Parent-child relationships or associations can be physical or logical, which are not always
the same. In the above airport example, the airport terminal POI is physically part of the
airport, whereas there may be no such physical association for a hotel. Instead, the parking
lot association is logically represented in the NAVTEQ database.

1.8

Traffic Codes

Traffic codes are database elements that provide:

Map displays of traffic problems
Dynamic route guidance when used in conjunction with real time traffic incident
information.
A traffic location is defined as a specific point that can be identified as a landmark, (i.e.,
interchanges, bridges, rest areas, and toll plazas. This information is coded for ease of use
and transmission in the form of a radio data system (RDS) source:
In Europe, codes are assigned by governments
In North America, the predefined code table comes from a consortium formed by
NAVTEQ and Tele Atlas
North American codes follow the standard radio data system-traffic message channel
(RDS-TMC) model used in Europe as much as possible

NAVTEQ Network for Developers

21

CONFIDENTIAL

Traffic codes are used in conjunction with a traffic table (not part of the map data itself). In
North America, the table is provided by NAVTEQ; in Europe, the tables are obtained from
individual governments. That said, NAVTEQ has modeled the North American table after the
European traffic tables for consistency. Key points:
The table consists of an area identifier, road names, previous and next traffic
locations, and lat/long
A traffic provider transmits messages in the form of an event, an event location, and
an extent
The navigation system receives traffic information through a variety of inputs and
uses this data in many ways, including:
{

display of problem areas

dynamic route guidance

Some customers need the database, some need the table, and some need both.
The following table provides an illustration of a traffic table.

NAVTEQ Network for Developers

22

CONFIDENTIAL

Traffic Table Example (U.S)

[ed note: inconsistent font size in table; don't have original art for the table and can't fix
word breaks for "reference", etc.]

NAVTEQ Network for Developers

23

CONFIDENTIAL

2
2.1

NAVTEQ Extraction Formats

Overview

The NAVTEQ data production environment, while not designed to be adopted directly by
customers, is designed to insulate customers from data structure changes, additions, and
deletions. NAVTEQ uses data extraction formats to publish NAVTEQ data externally to its
customers, enabling them to process map data into their own production environment.
These extraction formats generally have a design that is independent from the NAVTEQ
internal production environment, and are not impacted when NAVTEQ modifies parts of the
production environment.
Some extraction formats are defined by standard committees and act as industry standards,
while others are defined specifically by NAVTEQ. The extraction formats offered by NAVTEQ
are:
RDF (industry standard)
GDF 3.0 (industry standard)
SIF+ (NAVTEQ proprietary)
NAVSTREETS (NAVTEQ proprietary)
POI XML (industry standard)
Extraction formats generally publish the same content with the differences mostly in the
representation of the data. The following diagram illustrates the position that extraction
formats play in map data processing.

NAVTEQ Network for Developers

24

CONFIDENTIAL

There are a variety of reasons to offer multiple extraction formats, including:

A given format targets a specific user-profile, often related to the business in which a
customer operates
A variety of customer development environments trigger the need to support
different flavors of extraction formats
Historical reasons, which created dependency on specific extraction formats
The following summarizes the formats offered by NAVTEQ, and provides links to additional
information.

2.1.1

RDF (Relational Data Format)

RDF is a delivery format that enables customers to load NAVTEQ data directly into a
relational database environment. RDF publishes NAVTEQ data in an easy to understand and
well-defined relational structure.
RDF combines various NAVTEQ data sources into a single repository per NAVTEQ region
(North America, European Union, Mexico, World Market, India, Thailand, and Indonesia) and
presents it in a seamless relational format. The content is delivered to RDF customers via
DVD media with database installation scripts. Highlights include the ability to:
Work with NAVTEQ data directly using commercially available relational databases
Load NAVTEQ data directly into a RDF database, with the latest NAVTEQ data content
Look-aside content integrated into RDF

NAVTEQ Network for Developers

25

CONFIDENTIAL

 Deliver RDF as a seamless product

Provide data validated by NAVTEQ, as part of the RDF release process, on a
continental level
Provide data conversion focused on contents, without overhead for database
management tasks
The key benefit of RDF is the ability to accelerate the product development lifecycle and
reduce the associated costs by simplifying the processes involved with loading, compiling,
integrating, and using/visualizing map data.

2.1.2

GDF 3.0 (Geographic Data Format)

GDF 3.0, a European standard created by Comit European de Normalisation (CEN), is

emerging as the de facto international standard for exchanging navigable databases. GDF
has multiple versions, which prevents usage of a single GDF compiler worldwide to serve all
map suppliers. GDF highlights include:
Standard defines both the structure and the content of the file
ACSII file structure with record types related by pointers
Sequentially ordered by ID within the record type; however, the record types are not
in sequential order
No out-of-the-box tools for reading format (a GDF viewer is available, which allows
browsing the GDF file; the viewer is not a GDF parser)
Relationally-organized using pointers
Cumbersome, but flexible and easy to expand
The GDF conceptual data model comprises three entities: levels, attributes, and
relationships.

2.1.3

SIF+ (Standard Interchange Format)

SIF+ is a NAVTEQ proprietary format and is based on the NAVTEQ Internal Data Model,
previously known as DNDC. The SIF+ is a textual file, composed of 164 byte fixed-length
records. The standard defines both the structure and the content of the file. SIF+ highlights
include:
ACSII file structure, with record types related by pointers
No out-of-the-box tools to read or parse SIF+ files
Relationally-organized using pointers
Link information is grouped together, as a result of file sequence structure being
dictated by Link ID (unique ID per segment)
Each position is predefined; thus SIF+ is an inflexible data model
Four categories of records make up a SIF+ file: Interchange File Records, Node Records,
Link Records, and Composite Road Feature Records. Each record is a 164-byte text file.

NAVTEQ Network for Developers

26

CONFIDENTIAL

2.1.4

NAVSTREETS

NAVSTREETS is a NAVTEQ defined format that enables NAVTEQ data to be uploaded into
commercially available GIS tools. It is a layered, Geographic Information System (GIS)
focused representation of NAVTEQ data currently delivered in two GIS formats, specifically:
ESRI Shapefile Format - layered, GIS-oriented, representation of NAVTEQ data,
delivered in ESRI Shapefile format. Compatible with ESRI ArcView 3.x and ArcGIS
8.x 9.x software suites
MapInfo Table Format - layered, GIS-oriented, representation of NAVTEQ data,
delivered in MapInfo's native (TAB) format. Compatible with MapInfo Professional
5.x and above
NAVSTREETS highlights include:
GIS database to store data
Programming language supported by commercially available GIS packages (e.g.,
Visual Basic, MapBasic)
Out-of-the-box functionality for mapping and spatial analysis using commercially
available GIS tools
Relatively little secondary compilation required to enable routing and geocoding
software utilization on a set of NAVSTREETS data tables

2.1.5

POI XML

NAVTEQ Points of Interest (POIs) and associated reference data are delivered in an
Extensible Markup Language (XML) format. The data in this format include NAVTEQ Core
POIs (North America) and Extended Listing POIs (North America). European POI data is
slated for delivery in XML format in Q3, 2007.
NAVTEQ will use the general specification for the delivery of additional POI data sets,
including ACSI, Fodor's, Zagat, and more as product plans are announced. Any product
specific additions to the data delivery formats will then be detailed in a product-specific
documentation delivery.

2.2

RDFTM Overview

RDF (Relational Data Format) is a delivery format enabling customers to directly load
NAVTEQ data into a relational database environment. RDF publishes NAVTEQ data in an
easy-to-understand and well-defined relational structure.
RDF combines various NAVTEQ data sources into a single repository per NAVTEQ region
(North America, European Union, Mexico, WM, India, Thailand, and Indonesia) and presents
it in a seamless relational format. The content is delivered to RDF customers via DVD media
with database installation scripts.

NAVTEQ Network for Developers

27

CONFIDENTIAL

2.2.1

Target Developer Profiles and Business Markets

Developers with the following profiles will receive great value from RDF:
NAVTEQ customers developers that convert NAVTEQ data using a relational
database benefit directly from using RDF.
Content integrators developers that integrate third-party data in addition to
NAVTEQ data will find it easier to integrate data with RDF.
Multiplatform vendors developers that have both media-based solutions and
server-based solutions or a variety of media-based solutions will find it easier to
support them through RDF.
Markets and application categories that lend themselves to using RDF include:
In-vehicle markets system vendors vendors wishing to establish a common
database for multiple platforms and offerings can do so more easily with RDF than
with traditional formats
Consumer markets
{

Service providers integration of third-party content is simplified through the use

of relational technology
Independent software vendors (ISVs) custom-compiled databases can be done
more quickly and easily using RDF

Enterprise markets RDF is well suited for fleet applications in which integration with
other data sources is a requirement

NAVTEQ Network for Developers

28

CONFIDENTIAL

2.2.2

Benefits of RDF

Using RDF can benefit developers at multiple levels.

Traditional Compilation

RDF-Accelerated Data Compilation

With commercially available
relational databases,
developers can start working
directly with NAVTEQ data

Significant upfront
development work is required
prior to working with map data
Development and maintenance
of data loader (GDF/SIF+) for
NAVTEQ data are required
Look-aside content integration
is required

NAVTEQ data can be loaded

directly into RDF database,
always up-to-date with latest
NAVTEQ data content

Stitching of data into seamless

database is required

Look-aside content can be

integrated into RDF

Continental data integrity

needs to be validated by
customer

RDF is delivered as a seamless

product
Data are validated by NAVTEQ,
as part of RDF release process,
on continental level
Data conversion can focus on
contents, no overhead for
database management tasks

The key benefits of RDF are acceleration of the product development life cycle and reduction
of associated costs, because the number of steps is reduced and the processes for loading,
compiling, integrating, and using/visualizing map data are simplified.

NAVTEQ Network for Developers

29

CONFIDENTIAL

2.3

GDF 3.0 Overview

GDF 3.0 (Geographic Data Format), a European standard created by Comit European de
Normalisation (CEN), is emerging as the de facto international standard for exchanging
navigable databases. GDF has multiple versions, which prevent usage of a single GDF
compiler worldwide to serve all map suppliers. Highlights are as follows:
Standard defines both the structure and the content of the file
ACSII file structure, with record types related by pointers
Sequentially ordered by ID within the record type; however, the record types are not
in sequential order
No out-of-the-box tools for reading the format (a NAVTEQ GDF viewer is available,
which allows browsing the GDF file; the viewer is not a GDF parser) To access the
viewer go to http://www.navteq.com/gdf/login.jsp ;'(username: ntcustomer,
password: g3tgdf)
Cumbersome, but flexible and easy to expand
The GDF conceptual data model comprises three entities: levels, attributes, and
relationships.

2.3.1

Levels

The GDF levels represent real-life objects that have locations, such as roads, railways,
states, and water elements. GDF has three feature levels:

Level 0 representation is geometry

Level 1 representation is simple features

Level 2 representation is complex features

Level 0 - Geometry
Level 0 describes the geometry of the map in terms of the cartographic primitives. It
breaks the map down into its most basic form for representation. Geometric features
(level 0) are nodes, edges, and faces. XYZ coordinate records define the longitude,
latitude, and relative altitude of the nodes and/or shape points of an edge. One XYZ
record for each node identifies its geometric location, while a single XYZ record
identifies the location of all shape points of an edge. An edge is bound by two nodes
identifying its end points. A face consists of one or more edges identifying its
boundaries.

Level 1 - Simple Features

Level 1 describes the map in terms of simple features, which can take the form of
points, lines, or areas. For example, a road element is a line feature and a junction is a
point feature. On level 1, the level 0 elements receive real world significance. The
following relationships exist between level 1 and level 0:

NAVTEQ Network for Developers

30

CONFIDENTIAL

Each point in level 1 corresponds to one node from level 0

Each area corresponds to zero, one, or multiple faces from level 1

Each edge either corresponds to a line or bounds a face

Level 2 - Complex Features

Complex features comprise a group of simple or complex features. For example, the
United States is a country, which is made up of a group of states. This is level 2 of the
GDF. The GDF feature representation schema specifies how the individual features
should be represented by nodes, edges, and facesthe cartographic primitives.

2.3.2

Attributes

The properties of features are referred to as attributes. A feature can have zero or more
attributes. Except for a few cases, attributes apply to specific features. For instance, the
form of way attribute is valid only for the feature category roads and ferries, while the
official name attribute may apply to any feature category (e.g., roads and ferries," services,
etc.).
The two types of attributes are simple and composite. Simple attributes have one
component. For instance, form of way is a simple attribute. Composite attributes have more
than one attribute, each of which can be a simple attribute or another composite attribute.
All components of a composite attribute have to be taken into account; otherwise, the
incorrect representation may result. Each set of composite attributes is represented by its
own segmented attribute (SATT) record. House number range is an example of a composite
attribute, which consists of:
Address format left (user defined)
Address format right (user defined)
Address scheme left
Address scheme right
Address type (user defined)
First house number left
First house number right
House number structure
Last house number left
Last house number right
Note:

The house number range listed is in addition to the ON, AN, or $R in the
same SATT record. CEN GDF 3.0 also allows user-defined attributes and
their associated values.

NAVTEQ Network for Developers

31

CONFIDENTIAL

2.3.3

Relationships

A relationship consists of two or more features and identifies an association among those
features. For instance, the prohibited maneuver relationship consists of a line feature (road
element), a point feature (junction), and one or more line features. Relationships can have
attributes of their own. For instance, the attribute vehicle type is associated with a given
prohibited maneuver relationship.

2.3.4

Usage of GDF 3.0 Data

NAVTEQ customers may have a proprietary data structure for publishing navigable map
contents, as used by their application. Data contained in an extraction format must be
converted into this proprietary data structure. Customers must build or buy a compiler that
reads the extraction format, interprets the data in the format, and publishes the content
into their proprietary data structure.

2.3.5

NAVTEQ and CEN GDF 3.0 Differences

The CEN standard allows the creation of user-defined entities. NAVTEQ has added userdefined records, features, attributes, and relationships to ensure a complete representation
of the NAVTEQ Core Map in GDF. The CEN standard defines attributes, features, and
relationships that are not included in the NAVTEQ GDF, although to conform to the standard,
some NAVTEQ attributes are forced into CEN representation.
All attributes in the NAVTEQ Core Map database are represented in the NAVTEQ GDF. The
facility codes are different (e.g., airport is 4581 in the NAVTEQ internal database and 7383
in the NAVTEQ GDF) and the terminology is different:

Grade-separated crossing versus Z-level

Service versus POI

GDF also supports supplemental data options not currently available in the NAVTEQ internal
database (i.e., Long Haul, NAVTEQ Map Voice Data, etc.).

2.3.6

Data Availability/Distribution

NAVTEQ map data are available in GDF 3.0 format:

Europe, 60+ files
North America, 34 files

NAVTEQ Network for Developers

32

CONFIDENTIAL

 World markets including Mexico, Brazil, Taiwan, Macau, Hong Kong, Singapore,
Malaysia, South Korea, Thailand, Qatar, Saudi Arabia, Kuwait, United Arab Emirates,
Oman, Bahrain, South Africa, India, Indonesia, Thailand, and Australia, 20 files
China, 1 file
The region counts listed are based on fourth quarter 2006 databases and are published as a
reference only; regions are expected to grow with continued increased coverage worldwide.
China is available through the NAVTEQ/NavInfo joint venture NAV2.

2.4

SIF+ Overview

The SIF+, Standard Interchange Format, is a NAVTEQ proprietary format based on the
NAVTEQ internal data model, known as DNDC. SIF+ is a textual file, composed of 164-byte
fixed-length records. The standard defines both the structure and the content of the file.
SIF+ highlights include:
ACSII file structure with record types related by pointers
No out-of-the-box tools needed to read or parse SIF+ files
Relationally organized using pointers
Link information grouped together, as a result of file sequence structure being
dictated by link ID (unique ID per segment)
Each position predefined, thus an inflexible data model

2.4.1

File Content

The SIF+ file schema is shown below. Four categories of records make up an SIF+ file:
interchange file records, node records, link records, and composite road feature (CRF)
records. Each record is a 164-byte text file.

NAVTEQ Network for Developers

33

CONFIDENTIAL

Interchange File Records

Interchange file records contain information about the interchange file as a whole.
Every SIF+ file has the following interchange file records:
File identification records contain information that uniquely identifies a particular
SIF+ file, including the date the SIF+ file was created, the SIF+ file version, and the
geographical area represented in the file. These are the first two records of every
SIF+ file
Reference records and compound reference records contain reference information,
including the unique coding schemes used in the SIF+ file
Cross reference records contain point of interest (POI) categorization information
for premium business listings products. These records relate facilities to categories
and subcategories to parent categories
Area records contain the definition of all the administrative areas included in the
SIF+ file. Area records are referenced by link basic main, link POI attribute, and zone
records. Two types of area records are defined:
{

Area main records contain the primary information about an administrative area,
including the area name, government code, administrative level, and
administrative hierarchy
Area daylight savings time records contain information about when daylight
savings time is in effect for the administrative area.

NAVTEQ Network for Developers

34

CONFIDENTIAL

 Zone records contain the zone name and zone attributes for all the zones
contained in the SIF+ file. Zone records are referenced by link basic main and link
basic zone records
File control records contain record and byte counts for each record type in the SIF+
file. There is one file control record for every record type in the SIF+ file. In addition,
there is one file control record that contains record and byte counts for the entire
SIF+ file. These are the last records in the file.

Node Records
Node records contain the coordinates and attributes for all nodes in the SIF+ file. Node
records are referenced by link basic main records and CRF records.

Link Records
Link records contain data about the links in the SIF+ file. These data include the link's
position and attributes, as well as associated features (e.g., usage data), driving
conditions, signs, and POIs. The following link records are defined:
Link basic records contain information specific to a link, including the link's
topology and attributes. Three types of link basic records are defined:
{

Link basic main records contain node references, left and right area and zone
references, left and right postal codes, and primary attribute information for a link.
Link basic attribute records contain the access characteristics, display
characteristics, and special attribute information for a link.
Link basic zone records contain additional zone references and exist for any link
that has more than one zone applied to a particular link side.

Link shape records contain the coordinates and attributes of the shape points that
reside on a link. There are one or more link shape records for each link that has
shape points
Link usage records contain information about the link specific to the manner in
which the link is used (e.g., a street, a cartographic feature, an administrative border,
etc.). There is at least one link usage record for every link in the SIF+ file. Three
types of link usage records are defined:
{

Link usage feature records contain primary information about a feature,

including the feature name, street type, feature type, and name route type.
Link usage block records contain information about a feature specific to a given
link, including name status and base address information.
Link address records contain optional address information if additional (nonbase) address ranges exist for a feature.

Link POI records contain information describing each POI associated with a
particular link feature (usage). Six types of link POI records are defined:

NAVTEQ Network for Developers

35

CONFIDENTIAL

Link POI main records contain the primary information about a POI, including
facility type, chain ID, street address, and phone number.
Link POI name records contain the facility name and any synonym or exonym
names that might exist for the POI
Link POI attribute records contain various types of attribute information about a
POI, including food type, vanity city, population, capital city, diesel, 24-hour
indicator, building type, rest area type, and airport type attributes.
Link POI actual address records contain optional actual address information for a
POI
Link POI parent records contain references to the parent POI(s) for POIs that
are themselves children
Link POI child records contain references to the child POI(s) for POIs that are
themselves parents.

Link sign records describe the road signs that are associated with a particular link.
The link sign records are attached to the sign destination link.
Link condition/driving maneuver (CDM) records describe the exception conditions
and the preferred or restricted driving maneuvers associated with a particular link or
group of links. The link CDM records are attached to the CDM source link. Three
types of link CDM records are defined:
{

Link CDM main records contain primary information describing the condition or
driving maneuver.
Link CDM date/time modifier (DTM) records contain optional information about
the time period when the CDM is in effect.
Link CDM maneuver link records contain additional maneuver link information if
more than one maneuver link exists for the CDM. The link CDM main record
contains the first maneuver link.

Link CDM lane traversal records contain lane connectivity information between
lanes of the source link and lanes of the destination link (i.e., final maneuver link).
This record is applicable only to lane traversal conditions.
Link CDM lane template records contain the values in the lane representation. A
lane template record exists only if a lane condition is defined.
Link CDM modifier records contain modifier information for modifier types 10 and
higher.

CRF Records
CRF records enumerate the components (i.e., the links and nodes) that make up CRFs.
These records contain link IDs and node IDs that are references to link records and
node records. Three types of CRF records are defined:
CRF main records contain primary information about the CRF, including CRF type,
number of components, number of lanes, number of names, landmark point X and Y

NAVTEQ Network for Developers

36

CONFIDENTIAL

coordinates (for CRF objects only), and ref and nref CRF intersections (for CRF roads
only)
CRF component records contain the components (links and/or nodes) that make up
the CRF
CRF name records contain names for a CRF object. If the CRF object is unnamed,
this record is not published.

2.4.2

Usage of SIF+ Data

NAVTEQ customers may have a proprietary data structure for publishing navigable map
contents, as used by their application. Data contained in an extraction format must be
converted into this proprietary data structure. Customers must build or buy a compiler that
reads the extraction format, interprets the data in the format, and publishes the content
into their proprietary data structure.

2.4.3

Data Availability/Distribution

NAVTEQ Map Data are available in SIF+ format as follows:

Europe, 60 files
North America, 34 files
World markets including Mexico, Brazil, Taiwan, Macau, Hong Kong, Singapore,
Malaysia, South Korea, Thailand, Qatar, Saudi Arabia, Kuwait, United Arab Emirates,
Oman, Bahrain, India, Indonesia, South Africa, Australia, 20 files
China, 1 file.
These region counts are based on second quarter 2006 databases and are published as a
reference only; regions are expected to grow with continued increased coverage worldwide.
China is available through the NAVTEQ/NavInfo joint venture NAV2.
NAVTEQ North America provides a SIF+ statistics file with each delivery:
Record counts
Feature counts
Attribute counts.
NAVTEQ North America also provides a named place POI Report with each delivery. Both are
located on the NAVTEQ database CD-ROM.

NAVTEQ Network for Developers

37

CONFIDENTIAL

2.5

NAVSTREETS Overview

NAVSTREETS is a NAVTEQ-defined format that enables NAVTEQ map data to be uploaded

into commercially available GIS tools. NAVSTREETS is a layered representation of NAVTEQ
map data and is available in two GIS formats:
ESRI Shapefile Format layered, GIS-oriented, representation of NAVTEQ data,
delivered in ESRI Shapefile format; compatible with ESRI ArcViewTM 3.x and ArcGISTM
8.x 9.x software suites
MapInfo Table Format layered, GIS-oriented, representation of NAVTEQ data,
delivered in MapInfo's native (TAB) format; compatible with MapInfo Professional
5.x and above
NAVSTREETS provides the most navigable attributes available in a database. Utilizing the
data to its fullest allows the user to access features such as expressway ramps; complete
and correct connectivity of all roadways; one-way streets; physical, logical, and legal turn
restrictions; construction projects; and physical and painted lane dividers. In addition to
these navigable attributes, NAVSTREETS provides address ranges down to the level of the
correct side of the street. Mapping applications are enhanced with five functional
classifications of roads, and polygonal representation of features such as airports, aircraft
roads, cemeteries, golf courses, hospitals, military bases, parks, national monuments,
public use areas, pedestrian zones, shopping centers, sports complexes, undefined traffic
areas, university/colleges, and woodlands.
Additional NAVSTREETS highlights include:
Programming language supported by commercially available GIS packages (e.g.,
Visual Basic, MapBasic)
Out-of-the-box functionality for mapping and spatial analysis using commercially
available GIS tools
Based on SIF+ Extract (ASCII Flat file) of the NAVTEQ database
Data tables allow unlimited modification by the end user
Secondary compilation is required to enable routing and geocoding software
utilization on a set of NAVSTREETS data tables
NAVSTREETS is delivered as a premium product on DVD media. The delivery includes the
NAVTEQ map data and database statistics files. There are also supplementary DVDs that
contain the NAVSTREETS Customer Technical Reference Manual (CTRG), electronic scope
book, and data product release notes. The NAVSTREETS Premium product includes the
following data layers:
Signs
Z-levels
Condition/driving maneuvers (date/time modifiers and maneuver links)
Traffic location codes

NAVTEQ Network for Developers

38

CONFIDENTIAL

 Major highways and shields

Secondary highways and shields
Railroads
Zones, administrative boundaries
Oceans, islands, waterway polygons and segments
Land use features
Building/landmark polygons
16 point of interest (POI) layers
Metadata
Streets (complete set of attributes)
Additional attributes found in the streets layer include:
Speed category
Divider location
Direction of travel
Access automobiles
Access buses
Access taxis
Access carpools
Access pedestrians
Access trucks
Access through traffic
Access deliveries
Access emergency vehicles
Special traffic figure
Maneuver
Divider legal
Traffic codes

2.6

POI XML Overview

NAVTEQ POIs and associated reference data are delivered in an XML format. These data
include NAVTEQ Core POIs and Extended Listing POIs for North America. European POI data
in XML format are slated for delivery in Q3 2007.
NAVTEQ will use the general XML specification for the delivery of additional POI data sets,
including ACSI, Fodor's, Zagat, and more as product plans are announced. Any productspecific additions to the data delivery format will be detailed in a product-specific
documentation delivery.

NAVTEQ Network for Developers

39

CONFIDENTIAL

2.6.1

Delivery Package

Each POI XML delivery package contains the POI records delivered. The package has several
attributes to describe the details of the delivery such as version number and creation time,
as well as the applicable directory of reference data. The reference data delivered are only
that data relevant to the specific product purchased. For example, the Cuisine_Type_Desc
file is only included when the facility type Restaurant is included in the product.
The delivery package contains the following attributes:
Name

Type

Use

Description

VersionNo

xs: string

Required

Version number of the Delivery Package

CreationTime

xs:
dateTime

Required

Creation date and time of the Delivery Package

MapVersion

xs: string

Required

Version number of the map database associated to the POIs

Language_Code_Desc

xs: string

Required

Name of the Language Code

Reference file used

Country_Code_Desc

xs: string

Required

Name of the Country Code

Reference file used

XY_Type

xs: string

Optional

Coordinate system used, and the format used (e.g., no

decimal point)

xs: string

Required

Name of the Category Reference File used

xs: string

Required

Name of the Cuisine Type Reference File used

xs: string

Required

Name of the Chain, Brand and Supplier Reference file used

Char_Set

xs: string

Required

Character set used in the Delivery Package

UpdateType

xs: string

Required

Identifies the type of the update contained in the Delivery

Package: Incremental (only the changes are delivered) or
Bulk (replacement of the entire POI records)

Category_Code_Desc
Cuisine_Type_Desc
Chain_Brand_Desc

Note: Only the Bulk Update is supported at this time.

Coverage

xs: string

Required

Describes the coverage area of the Delivery Package (e.g.,

DCA)

Category

xs: string

Required

Describes the categories included in the Delivery Package

Note 1Cuisine_Type_Desc is only delivered when a product contains the facility type Restaurant (5800)
Note 2

Chain_Brand_Desc is only delivered when a product contains a facility type that supports chain
names, e.g., Hotel (7011)

NAVTEQ Network for Developers

40

CONFIDENTIAL

2.6.2

Content Attributes

The key content attributes describing the POIs include:

Action describes the action to be taken for a specific POI (e.g., add, delete,
update)
Supplier ID describes the source of the POI
Identity contains information about the identity of a POI and is categorized as:
{

POI_Entity_ID

Names

Chain_ID

Category_ID

Product_Type

Relationship identifies relationships between two or more POIs

{

Association_Type

POI_Entity_ID

Locations defines a POI location by address, geo-position, and NAVTEQ link ID and
may have more than one location (i.e., main entrance and service entrance).
Information is categorized as:
{

Address

Actual Address

GeoPosition

MapLinkID

Confidence

Contacts contains all contact information about a POI (e.g., phone number)
Revision History

NAVTEQ Network for Developers

41

CONFIDENTIAL

Development Environment Considerations

The NAVTEQ data production environment is not designed to be adopted by customers.

Therefore, extraction formats are used to publish the raw NAVTEQ data externally to
customers, thus enabling them to process the data into their own production environment.
Extraction formats are essentially containers of NAVTEQ data, and the formats do not
directly relate to a specific development environment or architecture.
Experience indicates that typical environments can be deduced in relation to extraction
formats. Key considerations include:
Data storage requirements:
{

File-based structure vs. real database technology

Database management tasks developed in-house or using database technology

Performance vs. controllability (better conversion performance does not

automatically imply shorter production times);controllability of process is essential
part in database compilation architecture
Methods for validating and analyzing converted data
Requirement to integrate additional contents
Alignment of development staff with ongoing software evolutions
This table illustrates the typical development environment associated with each extraction
format.
Format
GDF

Typical architecture
- C++ or Java code to parse GDF file
- File based customer data structure; C++ based code to fill data structure or
- Relational environment, filled from parsed GDF file, using C++ or Java (less typical)

SIF+

- C++ or Java code to parse SIF+ file

- File based customer data structure, C++ based code to fill data structure or
- Relational environment, filled from SIF+

RDF

file, using C++ or Java (less typical)

Relational database to store data

SQL and/or Java / C++ code to fill customer database

NAVSTREETS

GIS database to store data

Language supported by GIS package (e.g., Visual Basic , MapBasic )

NAVTEQ Network for Developers

42

CONFIDENTIAL

Choosing an Extraction Format

Extraction formats generally publish the same content; the differences are mostly in the
representation of the data. All extraction formats publish the core NAVTEQ database with
the most relevant attributes.
Extraction formats can be used to build competitive products, but there are reasons for
offering various extraction formats, including:
Each format targets specific user-profiles, somewhat related to the business a
customer operates
Variety of development environments at customers trigger the need to support
different flavors of extraction formats
Historical reasons, which built-up dependency on specific extraction formats
Depending on the development strategy, developers may or may not have a choice with
respect to extraction formats. In particular, when using a geospatial platform provider (GPP)
as the LBS development tool provider, the extraction format may have been specified
already. For example, Autodesk uses SIF+ and deCarta uses GDF 3.0.
When not using a GPP and developing directly with NAVTEQ data, determine which format is
best for the application. Each extraction format has various benefits and tradeoffs. The key
dimensions to consider in selecting an extraction format are:
Availability of out-of-the box tools
Adherence to international standards
Certain geographies are not available in all formats
Certain content is not available in all formats at the same time
Lifetime of extraction formats
Extraction format flavors.
Note: Most flavoring is now handled by contractual limitations rather that
changing or limiting the process for data extraction.
The POI XML format is not included in the preceding comparisons of the dimensions because
POI XML is intended to be able to deliver POIs in a neutral data format that can be added on
top of any of the map formats, or even a map from another data supplier.

4.1

Availability of Out-of-the-Box Tools

Even when not using Geospatial Platform Providers, there are other tools that can be used
by developers, depending on the extraction format.
GDF3.0 - no out-of-the-box tools to read format (a GDF viewer is available, which
allows browsing the GDF file; the viewer is not a GDF parser); no single standard
however
SIF+ - no out-of-the-box tools to read format

NAVTEQ Network for Developers

43

CONFIDENTIAL

 RDF - data can be uploaded into standard database environments (e.g. Oracle or
SQL Server, with associated tools)
NAVSTREETS - layered GIS focused, representation of NAVTEQ data in various
standard GIS formats, with ability to upload data in commercially available GIS tools
(e.g., MapInfo, ArcGIS, Oracle Spatial). In addition, data can be added in from Excel
files with relative ease. As long as the basic geometry of roads, POIs, and polygons
are supported, then either NAVTEQ or a third-party can add infinite information to a
customers final product.

4.2

Adherence to International Standards

Adherence to international standards is key to many customers. These standards

increasingly include map data standards. For example, GDF 3.0 is an European standard,
emerged as the de-facto international standard for exchanging navigable databases.
Note: Despite the status of an international standard, GDF has flavors prevent
the usage of a single GDF compiler worldwide to serve all map suppliers.

4.3

Geographic Availability

Not all regions are covered by all formats. In particular China is not available in the
NAVSTREETS format. Also, the RDF format has one file per region, so even if only selected
countries within one region are wanted, the entire regional file must be acquired.

Format

Regions Covered

Delivery Method

GDF 3.0

EU, NA, WM,

China

GDF file per sub-region

EU, NA, WM,

China

SIF+ file per sub-region

EU, NA, WM,

China

Seamless continental dataset

EU, NA, WM

NAVSTREETS file per sub-region

SIF+

RDF

NAVSTREETS

(EU: 60+ files, NA: 34 files, WM: 20 files, China:

1 file)

(EU: 60+ files, NA: 34 files, WM: 20 files, China:

1 file)

(EU: 1 file, NA: 1 file, WM: 1 file, Mexico: 1 file,

India: 1 file, Thailand: 1 file, Indonesia: 1 file,
China: 1 file)

(EU: 60+ files, NA: 34 files, WM: 20 files)

Additionally NAVSTREETS can be delivered at
STATE level for the United States.
Legend: EU = Europe; NA = North America; WM = World Markets including Brazil, Taiwan, Macau, Hong Kong,
Singapore, Malaysia, Qatar, Saudi Arabia, Kuwait, U.A.E., Oman, Bahrain, Australia

NAVTEQ Network for Developers

44

CONFIDENTIAL

4.4

Content Availability

Content in the NAVTEQ core map database is available in most formats, except as noted in
the following table.

Contents not supported

in one of the extraction
formats

GDF

SIF+

RDF

NAVSTREETS

Complex Features (CRF

Coding)

Extended Lane

N (Available Q3, 2007)

City Models and 3D

Landmarks

N (City Models available Q3,

2007)

Long Haul support

(Long Haul / Stub Link)

Daylight Saving Time

Time Zone

Point of Interest (POI)

coordinates

N (indirect, only via geometry

objects)

Node and Shape

coordinates

N (indirect, only via geometry

objects)

Topology for Cartographic

features (polygon)

N (only geometry object

provided, no topological
description (no ability to
define polygon as set of Link
pairs))

Often new data is requested by particular customers using a specific format. In these cases,
the first inclusion of the data in the core map will typically be available first in the extraction
format used by the customer, with the other formats updated in a later release.
In addition, certain content is not included in the core map database and are instead
available in look-aside files in various data formats. See Appendix A4, Using Look-Aside
Files, for a table that shows which look-aside files are available and in which formats.

4.5

Lifetime of Extraction Formats

Exact lifetimes are not defined for extraction formats. When a format is being discontinued,
this information is communicated in a timely manner and is only decided upon after having
assured viable alternatives are available.

4.6

Extraction Format Flavors

Most formats have specific relevant options, or flavors when requesting the data from
NAVTEQ. These options relate to the commercial usage of specific contents of the NAVTEQ
core map.

NAVTEQ Network for Developers

45

CONFIDENTIAL

Not all content in the NAVTEQ database is useable under traditional commercial agreements.
Therefore, specific content needs to be suppressed depending on contractual agreements
between NAVTEQ and the customer. Other options relate to the technical customer
preferences for receiving the data (e.g., media type, transmission, etc).

Flavor / Option

GDF

Sectioned / Unsectioned

SIF+

RDF

NAVSTREETS

Ability to deliver GDF as smaller

sub-files, cut by country-specific
Administrative level.
Merged / Unmerged

Ability to merge different datasets

together to Database Coverage
Area (DCA) level. For GDF results
in conversion records, for
NAVSTREETS in one file.

(Option only
for EU and
World
Markets)

(Due to size, merging

is only enabled for
certain countries)

Standard / Premium

Ability to deliver data where

contents are suppressed to limit
usage of the NAVTEQ data.

(Standard will cease to

exist as delivery option
from Q3, 2006)

State Level Delivery

North American option only to

deliver State level NAVSTREETS
products.

4.7

Other Considerations

Unicode refers to a character code that defines every character in most of the speaking
languages in the world. It is a standard for representing characters as integers. Unlike
ASCII, which uses 7 bits for each character, Unicode uses 16 bits, which means that it can
represent more than 65,000 unique characters.

NAVTEQ Network for Developers

46

CONFIDENTIAL

Format
Topic

GDF

SIF+

RDF

Unicodeenabled format

(via lookaside)

(via lookaside)

International
standard

Geometry
OpenGIS (OGC)

(via Oracle
geometry
objects (SDO))

(via Oracle
geometry objects
(SDO))

N*

N
(via look-aside)

Compliant
Map display via
standard tools?

NAVSTREETS

NAVTEQ has a GDF viewer available that allows for browsing the GDF file,
with limited display capabilities.

NAVTEQ Network for Developers

47

CONFIDENTIAL

Using Your Extraction Format

Developers who are directly using NAVTEQ data (versus using a GPP) in their development
environment will need to compile the data using their own tools or third-party provider tools.
Key customer-related activities to data compilation include:

Understand the physical structure of the extraction format

Understand NAVTEQ database content

Define an internal data structure to publish NAVTEQ data

Develop (or buy) a converter that:

{

Reads the extraction format (parse relevant contents)

Maps NAVTEQ content to your data structure

Develop and implement a validation process for the data structure to verify that
converted NAVTEQ content is valid

Once the compilation process is in place, maintenance work is required to assure continued
production:
Assure compiler is up-to-date with new content added to NAVTEQ database
Assure compiler is up-to-date with changes in physical structure of NAVTEQ
extraction format
Ensure customer data structure enables publication of new NAVTEQ data content
Keep up with contemporary technology to remain flexible and competitive
The effort involved to load map data is outlined in the following table. Data conversion is a
complicated task and requires significant investment.

Format

Tools for
Loading
Data

Effort Involved to Initially Load Data

GDF

Requires customer to develop code that reads the ASCII GDF

files and parses out relevant contents to be used in compilation
process

SIF+

Requires customer to develop code that reads the ASCII SIF+

files and parses out relevant contents to be used in compilation
process

RDF

Install relational database

Full RDF Oracle (9i or higher) installation available
Upload into other relational databases possible by using standard
database load tools

NAVSTREETS

Install GIS software (MapInfo, ArcView) or install Oracle

database
Installation available for MapInfo, ArcView, Oracle 9i

NAVTEQ Network for Developers

48

CONFIDENTIAL

Technical Customer Support

NAVTEQ Technical Customer Support (TCS) mission is to enable customers applications to

fully utilize the NAVTEQ database in order to optimize performance and enhance their end
products.

6.1

TCS Assistance

TCS assists customers by:

Providing technical information and detailed training programs
Answering questions about the database, delivery formats, and NAVTEQs tools
Assisting in test driving (Locations: Europe, Japan and North America)
TCS also informs customers about modifications in the NAVTEQ database via Technical
Notification Memorandums (TNMs) on topics including:
New Data
Improved Representation
Bug and Processing Fixes
Version Numbers
Dataset IDs
Database Enhancements

6.2

Changes to Extraction Formats

Although extraction formats are stable and generally do not change, smaller modifications
can be implemented. Any change to an extraction format is communicated via a standard
procedure (e.g., TNMs), generally with a 6-month notification timeframe.

NAVTEQ Network for Developers

49

CONFIDENTIAL

Appendix A.1 Glossary

Term

Description

CDM

Condition/driving maneuver

CTRG

Customer Technical Reference Guide

DC

Detailed Coverage

DSS

Data Server Suite

DTM

Date/time modifier

FC

Functional Class

GDF 3.0

Geographic Data File

GIS

Geographical Information System

GPP

Geographical Platform Provider

Link

A road segment beginning and ending at a node

Look-Aside Files

Data components that are not published in the core extraction formats

Node

Indicates and intersection, termination of a link, or change of attributes

OGC

Open Geospatial Consortium

POI

Points of Interest

RDF

Relational Data Format

Reference Node

Node with the lower latitude

RNC

Road Network Coverage

SDAL

Shared Data Access Library

Shape Point

Adds "shape" to a segment.

SIF+

Standard Interchange Format

TCS

Technical Customer Service

TNM

Technical Notification Memorandums

XML

Extensible Markup Language

NAVTEQ Network for Developers

50

CONFIDENTIAL

Appendix A.2 NAVTEQ Overview

Background
Founded in 1985 in Silicon Valley, California, NAVTEQ has a unique and eventful history
rooted in technology, geography, hands-on research, and an infectious entrepreneurial spirit.
From the beginning, NAVTEQ has been focused on capturing the reality of the road network
to enable dynamic turn-by-turn routing. The company began by collecting detailed data for
large metropolitan city areas. After Philips Electronics signed on as an early investor, the
company grew strategically, establishing its first European office in 1991. The companys
significant growth led to the opening of offices in Yokohama, Japan in 1996.
Today, NAVTEQ, headquartered in Chicago, Illinois, USA has approximately 2,100
employees worldwide, and has major production facilities in Fargo, North Dakota, USA, and
a support center in Yokohama, Japan. NAVTEQ has achieved ISO 9001: 2000 certification of
all of its main operating locations.
NAVTEQ provides products and services that address several parts of the location-based
services (LBS) value chain. At its core, it provides the digital map data content that forms
the heart of all location-based services. NAVTEQ provides this data in a variety of formats
directly to customers as well as to geospatial platform providers such as Autodesk and
deCarta who in turn offer developers various tools to develop their LBS applications.

LBS VALUE CHAIN

CONTENT
PROVIDERS

LOCATION
PLATFORMS AND
SUPPORT SVCS

PLATFORM
PROVIDERS

APPLICATION
DEVELOPMENT

PLATFORM
PROVIDERS

MOBILE
DEVICES

NETWORK

WIRELESS
CARRIERS
SPECIALTY
NETWORKS

MOBILE
PHONES
IN-VEHICLE
PNDs/PDAs

DEVELOPMENT TOOLS
Source: E911-LBS Consulting

NAVTEQ also provides a variety of technical, business, and application development support
services including:
Business development support
Navigation advisory services
Product development support
Testing services
Channel development services
End-user services

NAVTEQ Network for Developers

51

CONFIDENTIAL

More information on these services is available at:

http://developer.navteq.com/site/global/30_developingwnav/70_bussupportsvc/p_bussupsv
c.jsp.

Why NAVTEQ?
Every day, millions of consumers and hundreds of companies rely upon NAVTEQ data to
reliably find and route to people, places, and points of interest. They do so because NAVTEQ
is considered by every major navigation and LBS provider as the best value in geo-spatial
database content. All NAVTEQ products and services are based on a comprehensive and
multi-faceted set of dimensions, including:
Product quality deliver a superior service or product to the customer
Product delivery provide a product that is fresh and delivered on time to meet
customer needs
Product range provide the ability to choose from a comprehensive range of options
and realize the best fit for your specific needs
Ability to innovate provide the requisite attributes and technical capabilities
(e.g., 3D graphical display) available to support improvements as customer demands
change and application functionality improves
Post-sales support address technical and project management support needs
Business development support help find and capture new sales and product
extension opportunities as part of an ongoing commitment to create win-win
situations
Financial strength and stability expect product enhancements on a continual basis.
Flexible pricing provide varying levels of functionality and/or geographic coverage
that can be tailored to meet unique needs and is reflected in the fee structure
Evidence of success expect product superiority and all of the above, elements that
are backed up by successful results
For more information on these dimensions please go to http://developers.navteq.com.

NAVTEQ Network for Developers

52

CONFIDENTIAL

Appendix A.3 NAVTEQ Data Compilation

NAVTEQ follows a 4-step process in developing its core digital map data.

Quality-In-Line
(QIL) & Product
Validation

Product
Functionality
Testing

QUEST Testing

NAVTEQ Map
ReporterTM

Quality-In-Line and Product Validation

Quality-In-Line and production validation testing ensure quality throughout the process.
Each has multiple steps:

Rigorous Release Validation

Design Quality In

Find &
Evaluate
Sources

Create
Consistency

Find the
Ground
Truth

Link Attributes
to the Map

Multiple Quality-In-Line tests (QIL) measure the

Validate

Hundreds of pre-release
validation tests, developed
through years of
experience, are run against
the database for each
release

Additional validations are

run against SIF, GDF and
ArcInfo extracts

validity and logic of new data as it is entered

Many critical to quality tests occur by the production

analyst and reviewed by QA specialist

NAVTEQ Network for Developers

53

Create &
Deliver

CONFIDENTIAL

QUEST Testing
QUEST is the NAVTEQ standard for testing and continuous improvement. NAVTEQ is the first
in the industry to develop a rigorous statistically significant testing methodology. NAVTEQ
was awarded CERTECS award for field Data Quality for the QUEST methodology.

Links
Cities

Results feed
investment
Miles
driven

Formulate
strategic
collection
programs

Ensure efficiency

Implement
corrective action

Product Functionality Testing

NAVTEQ tests the most important driver of end-user satisfaction: accuracy of the navigation
experience. NAVTEQ asks and tests numerous questions as it reviews the accuracy of its
products through the eyes of the consumer. It tests routing performance.

The NAVTEQ Map Reporter is covered in Appendix A4, Data Maintenance.

NAVTEQ Network for Developers

54

CONFIDENTIAL

Appendix A.4 NAVTEQ Data Maintenance

Keeping NAVTEQ map data up-to-date and achieving its goal of 97% accuracy is a
continuous process. Roads, road attributes, and POIs are continually changing. NAVTEQ has
found the level of change each year to be on average 10% to 15% change in geometry and
attributes and 20% change per year for POIs.
In addition to proactively updating map data, NAVTEQ provides users and customers with a
channel to report errors via its NAVTEQ Map Reporter. Below is an excerpt of the type of
information that users can provide. NAVTEQ investigates these issues and incorporates the
corrections into its normal release process. The complete Map Reporter process can be
found at http://mapreporter.navteq.com/dur-webexternal/secured/submitDur.do?userType=CONSUMER&language=en.

INSTRUCTIONS: Find location on map where update is requested. If location that is found is correct,
proceed with details below; otherwise, double-click on the map where the update you are requesting is
located.
2. Type of feedback:
Choose from list:
Point of Interest (POI) (bank, store, etc.)

Address
address is missing

POI is missing

address appears in the wrong location

POI has incorrect details

(location, category, phone number, etc.)

address should be removed

POI should be removed
Traffic Restriction

Road and Road Feature

road is missing

add restriction

road has the wrong name

incorrect restriction

road is in the wrong place or has the wrong shape

remove restriction
Other

NAVTEQ Network for Developers

55

CONFIDENTIAL

Appendix A.5 Using Look-Aside Files

NAVTEQ also has various data components that are not published in the core extraction
formats. There are various reasons for this, in particular:

Supporting prototype development

Restrictions to delivery formats

Development for specific business groups restricted to specific format

Supporting Prototype Development

NAVTEQ delivers prototype data that can either be added into a standard data set or can
stand alone for assessment by customers. In general, customers can receive some small
regional clip of a prototype or sample of a new dataset. An example is stop light
representation. NAVTEQ might deliver a text file that has locations and timing information
for stoplights that can be added to the Q4, 2006 map delivery. The customer can take a
look at NAVTEQs proposed representation of that data and submit their requirements based
upon that data. With that NAVTEQ could work to fully integrate that data into the Q2, 2007
release.

Restrictions to Delivery Formats

Some data formats have constraints on what they can feasibly publish. Neither ESRI
Shapefiles nor GDF 3.0 can support Unicode characters in the data directly. So for Chinese
or Greek characters, for example, NAVTEQ delivers a text file that has data columns with a
name ID and the appropriate Unicode character representation therein.

Development for Specific Business Groups Restricted to Specific Format

Some companies have invested a lot in a specific format. If a company has developed on
GDF 3.0 and they are not able or willing to re-compile to include new POIs, for example,
then NAVTEQ could provide a flat POI file for late-bind into their map process.

Other Issues
Look-aside content needs to be integrated into the core NAVTEQ Map by customers. This
typically requires software components to be developed by the customer.
Look-aside content does not have a fixed design, therefore code to integrate look-aside
content might be different depending on the type of data.
Examples of look-aside content:
Phonetic data to support NAVTEQ Map Voice Data product (text to speech and voice
recognition)
Traffic Location Tables
Unicode strings

NAVTEQ Network for Developers

56

CONFIDENTIAL

 Truck Attributes
Points of Interest (POI) Extended Listings
The following table shows how the availability of various look-aside content varies by data
extraction format.

Look-Aside Data and Extracts (Sub-Set Only)

Look-Aside Contents

GDF

SIF+

RDF

NAVSTREETS

Unicode String

Look-aside
by VSAM

Look-aside by
VSAM

Integrated

Look-aside by
VSAM

NAVTEQ Map Voice

Data

Look-aside
by VSAM

Look-aside by
VSAM

Integrated

Look-aside by
VSAM

Traffic Location Tables

(NA)

Look-aside

Look-aside

Integrated

Look-aside

Points of Interest (POI)

Extended Listings

Look-aside
by VSAM and
POI category

Look-aside by
VSAM and POI
category

Integrated

Look-aside by
VSAM and POI
category

Postal Code add-ins

Look-aside
by Country

Look-aside by
Country

Integrated

Look-aside by
Country

NAVTEQ Truck
Attributes

Not available

Not available

Not available

Separate layer with

truck contents

Elevation Contours

Separate
GDF by
continent

Separate SIF+ by
continent

Separate RDF
delivery by
continent

Separate
NAVSTREETS by
continent

World Cartographic
layer

Separate
GDF

Separate SIF+

Separate RDF

Separate
NAVSTREETS

NAVTEQ Telecom

Not available

Not available

Not available

Separate layer with

Telecom contents

(NL, UK, US)

VSAM = sub-region

NAVTEQ Network for Developers

57

CONFIDENTIAL

Appendix A.6 NAVTEQ Data Format Quick Reference

Dimension

GDF 3.0

SIF+

RDF

NAVSTREETS

POI XML

Description

Geographic Data File

Standard
Interchange File

Relational
Data Format

NAVTEQ defined
format

NAVTEQ defined
format

NAVTEQ
defined format

ASCII file structure,

with record types
related by pointers

Relational
representation
of NAVTEQ
database

Layered,
Geographic
Information System
(GIS) focused,
representation of
NAVTEQ data in
various standard
GIS formats

Points of Interest
Extensible
Markup Language

European standard,
emerged as de-facto
international standard for
exchanging navigable
databases*
ACSII file structure, with
record types related by
pointers
Data is sequentially
ordered by Record Type

Data is sequentially
ordered by Link ID

Data can be
uploaded in
standard
database
environments,
e.g. Oracle or
SQL Server

No out-of-the-box
tools to read format

No out-of-the-box tools
to read format (A GDF
Viewer is available,
which allows browsing
the GDF file; the viewer
is not a GDF parser)

Available in 3
forms: MapInfo,
ArcView and Oracle
Spatial Data Object

XML POIs are

intended to be
able to deliver
POIs in a
neutral data
format that can be
added on top of
any of the map
formats.

Ability to upload
data in
commercially
available GIS tools

Tools Available

No

No

Yes

Yes

Yes

Development
Environment

C++ or Java code to

parse GDF file

C++ or Java code

to parse SIF+ file

GIS database to
store data

Loaded on top of
any map format

File based customer

data structure; C++
based code to fill data
structure or Relational
environment, filled from
parsed GDF file, using
C++ or Java (less
typical)

File based
customer data
structure, C++
based code to fill
data structure or

Relational
database to
store data

Requires customer to
develop code that reads
the ASCII GDF files and
parses out relevant
contents to be used in
compilation process

Requires customer
to develop code
that reads the
ASCII SIF+ files
and parses out
relevant contents to
be used in
compilation process

Effort to initially
load data

Relational
environment, filled
from SIF+ file, using
C++ or Java (less
typical)

SQL and/or
Java / C++
code to fill
customer
database

Install
relational
database
Full RDF
Oracle (9i or
higher)
installation
available

Language
supported by GIS
package (e.g.
Visual Basic,
MapBasic)

Install GIS software

(MapInfo, ArcView)
or install Oracle
database

Loaded on top of
any map format

Installation
available for
MapInfo, ArcView,
Oracle 9i

Upload into
other relational
databases
possible by
using standard
db load tools

NAVTEQ Network for Developers

58

CONFIDENTIAL