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

1

NAVTEQ Map Data ................................................................................................................. 1 1.1 1.2

1.3 1.4

1.5 1.6

1.7

1.8

2

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 Parent–Child 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

3

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

4

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

5

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

6

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


v

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

1

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.


2

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


3

CONFIDENTIAL

– Destination

X

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


4

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


5

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


6

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


7

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.


8

CONFIDENTIAL

FC 1–2 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 1–3 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.


9

CONFIDENTIAL

FC 1–4 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 1–4 TO FC 1–5 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., nat’l, 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

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


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 Parent–Child 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 faces—the 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

1

2

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

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

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


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 customer’s 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)

N

Extended Lane

N (Available Q3, 2007)

City Models and 3D Landmarks

N (City Models available Q3, 2007)

Long Haul support

N

(Long Haul / Stub Link) 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.


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

X

SIF+

RDF

NAVSTREETS

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

X

X

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

X

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

X

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

N

N

Y

(via lookaside)

(via lookaside)

International standard

Y

N

N

N

Geometry OpenGIS (OGC)

N

N

Y

Y

(via Oracle geometry objects (SDO))

(via Oracle geometry objects (SDO))

Y

Y

*

N*

N (via look-aside)

Compliant Map display via standard tools?

NAVSTREETS

N

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


47

CONFIDENTIAL

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


48

CONFIDENTIAL

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 NAVTEQ’s 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 company’s 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 NAVTEQ’s 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


Integrated


Postal Code add-ins

Look-aside by Country


Integrated


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



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

Recommend Documents