Navteq Data Format Extraction Guide Public

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
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
iv
CONFIDENTIAL
Revision History
Version
Date
Comments
Public
3/14/07
Public Version
CONFIDENTIAL
This page intentionally left blank
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
- 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.
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
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
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
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).
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
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.
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.
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
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.
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
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)
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
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
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
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
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
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
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
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
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.
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.]
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.
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
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.
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.
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
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.
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:
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.
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
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.
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.
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:
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
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.
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
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.
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)
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
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 )
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
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
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.
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.
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.
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
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.
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
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
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.
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
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.
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
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
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
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
58
CONFIDENTIAL

Navteq Data Format Extraction Guide Public

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Navteq Data Format Extraction Guide Public

Transféré par

Droits d'auteur :

Formats disponibles

Network for Developers

Data Extraction Format Guide

NAVTEQ Network for Developers

DATA EXTRACTION FORMAT GUIDE

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

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

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

NAVTEQ Network for Developers

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

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

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

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

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

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

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

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

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

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

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

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

NAVTEQ Network for Developers

NAVTEQ Network for Developers

This page intentionally left blank

NAVTEQ Network for Developers

NAVTEQ Map Data

NAVTEQ Database Worldwide Structure

NAVTEQ Network for Developers

- Links, nodes, shape points, relative elevation,

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

NAVTEQ Network for Developers

Link attributes include:

Enable vehicle specific applications

Supported vehicle types include:

through traffic (see the following diagram)

NAVTEQ Network for Developers

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

Supported display characteristics include:

detailed city inclusion

multi-digitized (see the following diagram)

poi access road

NAVTEQ Network for Developers

special traffic figure

undefined traffic area

Real world representation of lanes diverging

Digitization of lanes diverging

Detailed city, Paved

NAVTEQ Network for Developers

Address range: Left: 66-5 (Mixed)

Right: Valid un-addressed

Node attributes include:

Represents relative elevation

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)

Used to edge-match two adjoining sub-regions

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

NAVTEQ Network for Developers

The navigation part of the database includes the following attributes:

NAVTEQ Network for Developers

NAVTEQ Network for Developers

NAVTEQ Network for Developers

NAVTEQ Network for Developers