Navteq Data Format Extraction Guide Public

CONFIDENTIAL

Network for Developers

Data Extraction Format Guide

NAVTEQ Network for Developers ii 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 iii CONFIDENTIAL

DATA EXTRACTION FORMAT GUIDE

Table of Contents

1 NAVTEQ Map Data ................................................................................................................. 1 1.1 Structure Overview .........................................................................................................................1 1.2 Geometry ........................................................................................................................................2

1.2.1 Link Attributes......................................................................................................................3 1.2.2 Node Attributes....................................................................................................................6

1.3 Navigation .......................................................................................................................................7 1.4 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

1.5 Administrative ...............................................................................................................................14 1.6 Cartography ..................................................................................................................................15

1.6.1 Cartography Attribute Size ................................................................................................17 1.6.2 Polygon Formation ............................................................................................................18

1.7 Points of Interest (POI) .................................................................................................................19 1.7.1 POI Attributes ....................................................................................................................20 1.7.2 POI ParentChild Relationships ........................................................................................21

1.8 Traffic Codes.................................................................................................................................21

2 NAVTEQ Extraction Formats .............................................................................................. 24 2.1 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

2.2 RDFTM Overview ...........................................................................................................................27 2.2.1 Target Developer Profiles and Business Markets..............................................................28 2.2.2 Benefits of RDF .................................................................................................................29

2.3 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

2.4 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 iv CONFIDENTIAL

2.5 NAVSTREETS Overview ............................................................................................................38 2.6 POI XML Overview .......................................................................................................................39

2.6.1 Delivery Package...............................................................................................................40 2.6.2 Content Attributes..............................................................................................................41

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

4 Choosing an Extraction Format.......................................................................................... 43 4.1 Availability of Out-of-the-Box Tools...............................................................................................43 4.2 Adherence to International Standards...........................................................................................44 4.3 Geographic Availability .................................................................................................................44 4.4 Content Availability .......................................................................................................................45 4.5 Lifetime of Extraction Formats ......................................................................................................45 4.6 Extraction Format Flavors .............................................................................................................45 4.7 Other Considerations ....................................................................................................................46

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

6 Technical Customer Support .............................................................................................. 49 6.1 TCS Assistance ............................................................................................................................49 6.2 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 v CONFIDENTIAL

Revision History

Version Date Comments Public 3/14/07 Public Version

NAVTEQ Network for Developers vi CONFIDENTIAL

This page intentionally left blank

NAVTEQ Network for Developers 1 CONFIDENTIAL

1 NAVTEQ Map Data

1.1 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

TRAFFIC CODES

POINTS OF INTEREST

CARTOGRAPHY

ADMINISTRATIVE

PATH

NAVIGATION

GEOMETRY

CUSTOMER SPECIFIC

- Railroads, rivers, canals, lakes, golf courses, shopping centers, woodlands etc.

- Country, state, city, settlement, province, postal codes, etc.

- Street names, route number and address ranges

- Hotels, restaurants, tourist attractions, transportation terminals etc.

- Arterial classification, dividers, barriers, one-ways, speed limits, road signs, turn restrictions, ramp signs, time of day and flow restrictions

- Links, nodes, shape points, relative elevation, connectivity

- Special requests aggregated to underlying geometry

- RDS-TMC codes from national providers


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.


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

Trafalgar Square

Link 25307534

Node


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

X

X2

Destination

X1


ramp

roundabout

special traffic figure

tollway

tunnel

undefined traffic area

urban

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

Multiple Digitization

Real world representation of lanes diverging

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

CO

NFI

DEN

TIAL


Addresses

Name: Trafalgar Square

Address range: Left: 66-5 (Mixed) Right: Valid un-addressed

1.2.2 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)

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

Z-level = 0

Z-level = 1


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


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 very-long-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 high-speed, 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.


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 intermediate-distance 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 higher-level 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.


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


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.


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 { Main St not Main

{ N Tully Ave not Tully Ave

1.4.2 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


{ Commercial

{ Old

1.4.3 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 { Applied in Europe

{ Only the addresses of existing structures are included

1.4.4 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 100-

198

Arques Ave 20200-20298 (base)

Arques Ave 101-199

Arques Ave 100-198 (base) 20200-20398

CCii tt yy

ooff

SSaa nn

JJoo ss

ee

UUnn ii nn cc oo rr pp oo rr aa tt ee dd

AArr ee aaArques Ave

20201-20299 (base)

Santa Clara County

San Mateo


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

1 2 3 4 5

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


{ 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


{ 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


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.

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

Municipal (city) park County park State park National park National monument Named/unnamed islands, or

islands with navigable features regardless of size.

Lakes

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

Cemetery Golf courses Hospital complexes Industrial complex Universities Shopping center Sports complexes Military bases Native American Indian Reservations 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

This section meets the criteria for polygonal

inclusion

The change between linear and polygonal inclusion is

generalized within 25 metres


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

Airport Polygon

Enclave

Aircraft Roads Polygon

Aircraft Roads

Airport

Airport is Outline Formation

Aircraft Rd is Full Formation

Layer polygons for correct display


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 Amusement park ATM Automobile dealership new cars Auto dealership used cars Auto service and maintenance Automobile Club Bank Bar or pub Book store Border crossing Bowling center Bus station Business facility Casino Cemetery (Q2, 2007) Cinema City hall Civic/community center Clothing store (Q2, 2007) Commuter rail station Consumer electronics store

(Q2, 2007)

Convenience store (Q2, 2007) Convention/exhibition center County council Court house Department store (Q2, 2007) Embassy Ferry terminal Golf course Grocery store

Home specialty store (Q2, 2007) Hospital Hotel Ice skating rink Library Medical service Museum Named place Night life Office supply and services store

(Q2, 2007)

Park and ride Park/recreation Parking garage Parking lot Performing arts Petrol/gasoline station Pharmacy Place of worship (Q1, 2007) Police Station Post office Public sport airport Rental car agency Residential area/building (Q1, 2007) Rest area Restaurant School Shopping Ski resort Specialty store (Q2, 2007) Sporting goods store (Q2, 2007) Sports center


Guest house Hamlets Higher education Historical monument Home improvement & hardware store

(Q2, 2007)

Sports complex Tourist attraction Tourist information Train station Winery

1.7.1 POI Attributes

POIs can have the following attributes:

Accessible for heavy good vehicles Actual address Address Airport type ATM available Building type Capital indicator Car wash available Chain name and ID 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

National importance Open 24 hours Parent/child (see the following

diagram)

Percent from reference node Phone number Place of worship building type POI exonyms POI lat/long coordinate (calculated

based on address attributes)

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


1.7.2 POI ParentChild Relationships

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

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

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

Addison St

ST Parking

LT Parking

Parent POI

LAX

ATM

Child POI with Physical Association

Child POIs with Logical Associations


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.


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


2 NAVTEQ Extraction Formats

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


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


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.


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.


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


2.2.2 Benefits of RDF

Using RDF can benefit developers at multiple levels.

Traditional Compilation

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

Stitching of data into seamless database is required

Continental data integrity needs to be validated by customer

RDF-Accelerated Data Compilation

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

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

Look-aside content can be integrated into RDF

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.


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:


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.


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 user-defined 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


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.


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.


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 (non-base) 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:


{ 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


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.


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


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 product-specific additions to the data delivery format will be detailed in a product-specific documentation delivery.


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)

Category_Code_Desc xs: string Required Name of the Category Reference File used

Cuisine_Type_Desc1 xs: string Required Name of the Cuisine Type Reference File used

Chain_Brand_Desc2 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) 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)


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


3 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 Typical architecture

GDF - 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+ file, using C++ or Java (less typical)

RDF 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)


4 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


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: 60+ files, NA: 34 files, WM: 20 files, China: 1 file)

SIF+ EU, NA, WM, China

SIF+ file per sub-region (EU: 60+ files, NA: 34 files, WM: 20 files, China: 1 file)

RDF EU, NA, WM, China

Seamless continental dataset (EU: 1 file, NA: 1 file, WM: 1 file, Mexico: 1 file, India: 1 file, Thailand: 1 file, Indonesia: 1 file, China: 1 file)

NAVSTREETS EU, NA, WM NAVSTREETS file per sub-region (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


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)

N

Extended Lane N (Available Q3, 2007)

City Models and 3D Landmarks

N (City Models available Q3, 2007)

Long Haul support (Long Haul / Stub Link)

N

Daylight Saving Time N

Time Zone N

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.


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 SIF+ RDF NAVSTREETS

Sectioned / Unsectioned Ability to deliver GDF as smaller sub-files, cut by country-specific Administrative level.

X

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.

X (Option only for EU and World Markets)

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

X (Standard will cease to exist as delivery option from Q3, 2006)

State Level Delivery North American option only to deliver State level NAVSTREETS products.

X

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.


Format

Topic GDF SIF+ RDF NAVSTREETS

Unicode-enabled format

N (via look-aside)

N (via look-aside)

Y N (via look-aside)

International standard

Y N N N

Geometry OpenGIS (OGC) Compliant

N N Y (via Oracle geometry objects (SDO))

Y (via Oracle geometry objects (SDO))

Map display via standard tools?

N* N Y Y

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


5 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 N Requires customer to develop code that reads the ASCII GDF files and parses out relevant contents to be used in compilation process

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

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

NAVSTREETS Y Install GIS software (MapInfo, ArcView) or install Oracle database Installation available for MapInfo, ArcView, Oracle 9i


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


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


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.

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

CONTENT

PROVIDERS MOBILE

DEVICES NETWORK

DEVELOPMENT TOOLS

LBS VALUE CHAIN LOCATION

PLATFORMS AND SUPPORT SVCS

APPLICATION DEVELOPMENT

PLATFORM PROVIDERS

PLATFORM PROVIDERS

WIRELESS CARRIERS

SPECIALTY NETWORKS

MOBILE PHONES

IN-VEHICLE PNDs/PDAs

Source: E911-LBS Consulting


More information on these services is available at: http://developer.navteq.com/site/global/30_developingwnav/70_bussupportsvc/p_bussupsvc.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.


Appendix A.3 NAVTEQ Data Compilation

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

Quality-In-Line and Product Validation

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

Quality-In-Line (QIL) & Product

Validation

QUEST Testing

Product

Functionality Testing

NAVTEQ Map

ReporterTM

Rigorous Release Validation Design Quality In

Find & Evaluate Sources

Create Consistency

Find the Ground Truth

Link Attributes to the Map

Validate

Create & Deliver

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

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

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


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.

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.

Cities

Miles driven

Links

Formulate

strategic collection programs

Ensure efficiency Implement

corrective action

Results feed investment


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-web-external/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:

Address

address is missing

address appears in the wrong location

address should be removed

Point of Interest (POI) (bank, store, etc.)

POI is missing

POI has incorrect details (location, category, phone number, etc.)

POI should be removed

Road and Road Feature

road is missing

road has the wrong name

road is in the wrong place or has the wrong shape

Traffic Restriction

add restriction

incorrect restriction

remove restriction

Other

NAVTEQ Network for Developers 56 CONFID

Documents

Navteq Data Format Extraction Guide Public