Upload
danarcana
View
371
Download
102
Embed Size (px)
DESCRIPTION
Navteq Data Format Extraction Guide Public
Citation preview
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
NAVTEQ Network for Developers 2 CONFIDENTIAL
1.2 Geometry
The key dimensions of the geometry portion of the database include:
Link road segment beginning and ending at a node Node intersection, termination of a link, or change of attribution (a square in the
diagram)
Shape point adds shape to a segment (a circle in the diagram)
The database geometry is organized around the link-node relationships. Each link has a reference node and a non-reference node. A reference node determines the left/right side of a link, and is a node with the lower latitude. If the latitudes of both end nodes are identical, the reference node is the node with the lower longitude. Each link has a variety of attributes.
NAVTEQ Network for Developers 3 CONFIDENTIAL
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
NAVTEQ Network for Developers 4 CONFIDENTIAL
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
NAVTEQ Network for Developers 5 CONFIDENTIAL
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
NAVTEQ Network for Developers 6 CONFIDENTIAL
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
NAVTEQ Network for Developers 7 CONFIDENTIAL
1.3 Navigation
The navigation part of the database includes the following attributes:
Arterial classification (functional classes) Dividers/barriers location, legal One-ways/direction of travel Speed information (speed limits, special speed situation, special speed limits) Signs Lane information (number of lanes, extended number of lanes, connected lanes) Scenic routes Time of day
NAVTEQ Network for Developers 8 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 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.
NAVTEQ Network for Developers 9 CONFIDENTIAL
FC 12 Example
FC 3 Major routes between minor cities or towns, and through city districts. The FC 3 network complements the FC 1 and 2 networks to form connections between the higher level networks and minor cities. In metropolitan areas, roads used for 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.
NAVTEQ Network for Developers 10 CONFIDENTIAL
FC 14 Example
FC 5 Roads that are not efficient through routes. The lowest level and final category is FC 5, which comprises roads not considered to be arterials or transportation corridors. Local streets, including most minor collectors, roads in areas with few outlets, low-speed neighborhood streets, most indirect routes, and dead-end streets are coded FC 5.
FC 14 TO FC 15 Example
NAVTEQ Network for Developers 11 CONFIDENTIAL
1.4 Path
Path attributes refer to street names, route numbers, and address ranges, and include:
Names/addresses { Address range
{ Address format
{ Address scheme
{ Address type
{ Feature type
{ Route type
{ Base name
{ Language code*
{ Prefix
{ Suffix
{ Direction on sign
{ Street type
Name Status { Exit number
{ Explicatable
{ Junction name
{ Name on road sign
{ Postal name
{ State name
{ Vanity name
* Language codes include Unicode. Unicode refers to a character code that defines every character in most of the speaking languages in the world. It is a standard for representing characters as integers. Unlike ASCII, which uses 7 bits for each character, Unicode uses 16 bits, which means that it can represent more than 65,000 unique characters.
NAVTEQ Network for Developers 12 CONFIDENTIAL
1.4.1 Naming
NAVTEQ uses various naming rules, with many dependent on the country. Most do not apply to postal-only names. In the U.S., the naming rules include:
Abbreviations { Mount > Mt; Saint >St
{ If a name exceeds 35 characters, other abbreviations are used (i.e., natl, lndg, etc.)
Punctuation { Sunnyvale-Saratoga Rd
Normalizing names { 1st Ave not First Ave
{ CA-82 not Hwy 82
Most complete name { 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
NAVTEQ Network for Developers 13 CONFIDENTIAL
{ 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
NAVTEQ Network for Developers 14 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
NAVTEQ Network for Developers 15 CONFIDENTIAL
{ Canada: L7L 6R1 (3 digits are available in the core map; 6 digits as an external file)
Postal code is provided for both sides of each link Postal codes are often generalized
{ US: only the first 5 digits are published (i.e., code is 95054-1163; NAVTEQ publishes 95054)
{ England: only the first 4 digits are published (i.e., code is WD6 4RN; NAVTEQ publishes WD6 4)
External file for postal centroids that can be used for the UK and The Netherlands
1.6 Cartography
Cartography attributes capture the location and description of geographical features.
Attributes include:
Administrative boundaries { Aircraft roads
{ Airports
{ Bay/harbor
{ Built-up area
{ Canal/water channel
{ Cemeteries
{ Golf courses
{ Hospitals
{ Industrial complexes
{ Islands
{ Lakes
{ Military bases (North America only)
{ Native American Reservations (North America only)
{ Oceans
{ Parks (city/county, national, state)
{ Pedestrian area
{ Railroads
{ Rivers
{ Shopping centers
{ Sports complexes
{ Undefined traffic areas
NAVTEQ Network for Developers 16 CONFIDENTIAL
{ Universities/colleges
{ Woodlands
Boundaries/Landmarks { Cartographic country boundary
{ Business/commerce building/landmark
{ Convention/exhibition building/landmark
{ Cultural building/landmark
{ Education building/landmark
{ Historical building/landmark
{ Medical building/landmark
{ Park/leisure building/landmark
{ Residential building/landmark
{ Retail building/landmark
{ Sports building/landmark
{ Tourist building/landmark
{ Transportation building/landmark
{ Elevation contours
{ Cartographic state/province boundary (North America only)
{ Park in Water
NAVTEQ Network for Developers 17 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.
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
NAVTEQ Network for Developers 18 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
Airport Polygon
Enclave
Aircraft Roads Polygon
Aircraft Roads
Airport
Airport is Outline Formation
Aircraft Rd is Full Formation
Layer polygons for correct display
NAVTEQ Network for Developers 19 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 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
NAVTEQ Network for Developers 20 CONFIDENTIAL
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
NAVTEQ Network for Developers 21 CONFIDENTIAL
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
NAVTEQ Network for Developers 22 CONFIDENTIAL
Traffic codes are used in conjunction with a traffic table (not part of the map data itself). In North America, the table is provided by NAVTEQ; in Europe, the tables are obtained from individual governments. That said, NAVTEQ has modeled the North American table after the European traffic tables for consistency. Key points:
The table consists of an area identifier, road names, previous and next traffic locations, and lat/long
A traffic provider transmits messages in the form of an event, an event location, and an extent
The navigation system receives traffic information through a variety of inputs and uses this data in many ways, including:
{ display of problem areas
{ dynamic route guidance
Some customers need the database, some need the table, and some need both. The following table provides an illustration of a traffic table.
NAVTEQ Network for Developers 23 CONFIDENTIAL
Traffic Table Example (U.S)
[ed note: inconsistent font size in table; don't have original art for the table and can't fix word breaks for "reference", etc.]
NAVTEQ Network for Developers 24 CONFIDENTIAL
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.
NAVTEQ Network for Developers 25 CONFIDENTIAL
There are a variety of reasons to offer multiple extraction formats, including:
A given format targets a specific user-profile, often related to the business in which a customer operates
A variety of customer development environments trigger the need to support different flavors of extraction formats
Historical reasons, which created dependency on specific extraction formats The following summarizes the formats offered by NAVTEQ, and provides links to additional information.
2.1.1 RDF (Relational Data Format)
RDF is a delivery format that enables customers to load NAVTEQ data directly into a relational database environment. RDF publishes NAVTEQ data in an easy to understand and well-defined relational structure.
RDF combines various NAVTEQ data sources into a single repository per NAVTEQ region (North America, European Union, Mexico, World Market, India, Thailand, and Indonesia) and presents it in a seamless relational format. The content is delivered to RDF customers via DVD media with database installation scripts. Highlights include the ability to:
Work with NAVTEQ data directly using commercially available relational databases Load NAVTEQ data directly into a RDF database, with the latest NAVTEQ data content Look-aside content integrated into RDF
NAVTEQ Network for Developers 26 CONFIDENTIAL
Deliver RDF as a seamless product Provide data validated by NAVTEQ, as part of the RDF release process, on a
continental level
Provide data conversion focused on contents, without overhead for database management tasks
The key benefit of RDF is the ability to accelerate the product development lifecycle and reduce the associated costs by simplifying the processes involved with loading, compiling, integrating, and using/visualizing map data.
2.1.2 GDF 3.0 (Geographic Data Format)
GDF 3.0, a European standard created by Comit European de Normalisation (CEN), is emerging as the de facto international standard for exchanging navigable databases. GDF has multiple versions, which prevents usage of a single GDF compiler worldwide to serve all map suppliers. GDF highlights include:
Standard defines both the structure and the content of the file ACSII file structure with record types related by pointers Sequentially ordered by ID within the record type; however, the record types are not
in sequential order
No out-of-the-box tools for reading format (a GDF viewer is available, which allows browsing the GDF file; the viewer is not a GDF parser)
Relationally-organized using pointers Cumbersome, but flexible and easy to expand
The GDF conceptual data model comprises three entities: levels, attributes, and relationships.
2.1.3 SIF+ (Standard Interchange Format)
SIF+ is a NAVTEQ proprietary format and is based on the NAVTEQ Internal Data Model, previously known as DNDC. The SIF+ is a textual file, composed of 164 byte fixed-length records. The standard defines both the structure and the content of the file. SIF+ highlights include:
ACSII file structure, with record types related by pointers No out-of-the-box tools to read or parse SIF+ files Relationally-organized using pointers Link information is grouped together, as a result of file sequence structure being
dictated by Link ID (unique ID per segment)
Each position is predefined; thus SIF+ is an inflexible data model Four categories of records make up a SIF+ file: Interchange File Records, Node Records, Link Records, and Composite Road Feature Records. Each record is a 164-byte text file.
NAVTEQ Network for Developers 27 CONFIDENTIAL
2.1.4 NAVSTREETS
NAVSTREETS is a NAVTEQ defined format that enables NAVTEQ data to be uploaded into commercially available GIS tools. It is a layered, Geographic Information System (GIS) focused representation of NAVTEQ data currently delivered in two GIS formats, specifically:
ESRI Shapefile Format - layered, GIS-oriented, representation of NAVTEQ data, delivered in ESRI Shapefile format. Compatible with ESRI ArcView 3.x and ArcGIS 8.x 9.x software suites
MapInfo Table Format - layered, GIS-oriented, representation of NAVTEQ data, delivered in MapInfo's native (TAB) format. Compatible with MapInfo Professional 5.x and above
NAVSTREETS highlights include:
GIS database to store data Programming language supported by commercially available GIS packages (e.g.,
Visual Basic, MapBasic)
Out-of-the-box functionality for mapping and spatial analysis using commercially available GIS tools
Relatively little secondary compilation required to enable routing and geocoding software utilization on a set of NAVSTREETS data tables
2.1.5 POI XML
NAVTEQ Points of Interest (POIs) and associated reference data are delivered in an Extensible Markup Language (XML) format. The data in this format include NAVTEQ Core POIs (North America) and Extended Listing POIs (North America). European POI data is slated for delivery in XML format in Q3, 2007.
NAVTEQ will use the general specification for the delivery of additional POI data sets, including ACSI, Fodor's, Zagat, and more as product plans are announced. Any product specific additions to the data delivery formats will then be detailed in a product-specific documentation delivery.
2.2 RDFTM Overview
RDF (Relational Data Format) is a delivery format enabling customers to directly load NAVTEQ data into a relational database environment. RDF publishes NAVTEQ data in an easy-to-understand and well-defined relational structure.
RDF combines various NAVTEQ data sources into a single repository per NAVTEQ region (North America, European Union, Mexico, WM, India, Thailand, and Indonesia) and presents it in a seamless relational format. The content is delivered to RDF customers via DVD media with database installation scripts.
NAVTEQ Network for Developers 28 CONFIDENTIAL
2.2.1 Target Developer Profiles and Business Markets
Developers with the following profiles will receive great value from RDF:
NAVTEQ customers developers that convert NAVTEQ data using a relational database benefit directly from using RDF.
Content integrators developers that integrate third-party data in addition to NAVTEQ data will find it easier to integrate data with RDF.
Multiplatform vendors developers that have both media-based solutions and server-based solutions or a variety of media-based solutions will find it easier to support them through RDF.
Markets and application categories that lend themselves to using RDF include:
In-vehicle markets system vendors vendors wishing to establish a common database for multiple platforms and offerings can do so more easily with RDF than with traditional formats
Consumer markets { Service providers integration of third-party content is simplified through the use
of relational technology
{ Independent software vendors (ISVs) custom-compiled databases can be done more quickly and easily using RDF
Enterprise markets RDF is well suited for fleet applications in which integration with other data sources is a requirement
NAVTEQ Network for Developers 29 CONFIDENTIAL
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.
NAVTEQ Network for Developers 30 CONFIDENTIAL
2.3 GDF 3.0 Overview
GDF 3.0 (Geographic Data Format), a European standard created by Comit European de Normalisation (CEN), is emerging as the de facto international standard for exchanging navigable databases. GDF has multiple versions, which prevent usage of a single GDF compiler worldwide to serve all map suppliers. Highlights are as follows:
Standard defines both the structure and the content of the file ACSII file structure, with record types related by pointers Sequentially ordered by ID within the record type; however, the record types are not
in sequential order
No out-of-the-box tools for reading the format (a NAVTEQ GDF viewer is available, which allows browsing the GDF file; the viewer is not a GDF parser) To access the viewer go to http://www.navteq.com/gdf/login.jsp ;'(username: ntcustomer, password: g3tgdf)
Cumbersome, but flexible and easy to expand The GDF conceptual data model comprises three entities: levels, attributes, and relationships.
2.3.1 Levels
The GDF levels represent real-life objects that have locations, such as roads, railways, states, and water elements. GDF has three feature levels:
Level 0 representation is geometry Level 1 representation is simple features Level 2 representation is complex features
Level 0 - Geometry
Level 0 describes the geometry of the map in terms of the cartographic primitives. It breaks the map down into its most basic form for representation. Geometric features (level 0) are nodes, edges, and faces. XYZ coordinate records define the longitude, latitude, and relative altitude of the nodes and/or shape points of an edge. One XYZ record for each node identifies its geometric location, while a single XYZ record identifies the location of all shape points of an edge. An edge is bound by two nodes identifying its end points. A face consists of one or more edges identifying its boundaries.
Level 1 - Simple Features
Level 1 describes the map in terms of simple features, which can take the form of points, lines, or areas. For example, a road element is a line feature and a junction is a point feature. On level 1, the level 0 elements receive real world significance. The following relationships exist between level 1 and level 0:
NAVTEQ Network for Developers 31 CONFIDENTIAL
Each point in level 1 corresponds to one node from level 0 Each area corresponds to zero, one, or multiple faces from level 1 Each edge either corresponds to a line or bounds a face
Level 2 - Complex Features
Complex features comprise a group of simple or complex features. For example, the United States is a country, which is made up of a group of states. This is level 2 of the GDF. The GDF feature representation schema specifies how the individual features should be represented by nodes, edges, and facesthe cartographic primitives.
2.3.2 Attributes
The properties of features are referred to as attributes. A feature can have zero or more attributes. Except for a few cases, attributes apply to specific features. For instance, the form of way attribute is valid only for the feature category roads and ferries, while the official name attribute may apply to any feature category (e.g., roads and ferries," services, etc.).
The two types of attributes are simple and composite. Simple attributes have one component. For instance, form of way is a simple attribute. Composite attributes have more than one attribute, each of which can be a simple attribute or another composite attribute. All components of a composite attribute have to be taken into account; otherwise, the incorrect representation may result. Each set of composite attributes is represented by its own segmented attribute (SATT) record. House number range is an example of a composite attribute, which consists of:
Address format left (user defined) Address format right (user defined) Address scheme left Address scheme right Address type (user defined) First house number left First house number right House number structure Last house number left Last house number right
Note: The house number range listed is in addition to the ON, AN, or $R in the same SATT record. CEN GDF 3.0 also allows user-defined attributes and their associated values.
NAVTEQ Network for Developers 32 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 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
NAVTEQ Network for Developers 33 CONFIDENTIAL
World markets including Mexico, Brazil, Taiwan, Macau, Hong Kong, Singapore, Malaysia, South Korea, Thailand, Qatar, Saudi Arabia, Kuwait, United Arab Emirates, Oman, Bahrain, South Africa, India, Indonesia, Thailand, and Australia, 20 files
China, 1 file The region counts listed are based on fourth quarter 2006 databases and are published as a reference only; regions are expected to grow with continued increased coverage worldwide. China is available through the NAVTEQ/NavInfo joint venture NAV2.
2.4 SIF+ Overview
The SIF+, Standard Interchange Format, is a NAVTEQ proprietary format based on the NAVTEQ internal data model, known as DNDC. SIF+ is a textual file, composed of 164-byte fixed-length records. The standard defines both the structure and the content of the file.
SIF+ highlights include:
ACSII file structure with record types related by pointers No out-of-the-box tools needed to read or parse SIF+ files Relationally organized using pointers Link information grouped together, as a result of file sequence structure being
dictated by link ID (unique ID per segment)
Each position predefined, thus an inflexible data model
2.4.1 File Content
The SIF+ file schema is shown below. Four categories of records make up an SIF+ file: interchange file records, node records, link records, and composite road feature (CRF) records. Each record is a 164-byte text file.
NAVTEQ Network for Developers 34 CONFIDENTIAL
Interchange File Records
Interchange file records contain information about the interchange file as a whole. Every SIF+ file has the following interchange file records:
File identification records contain information that uniquely identifies a particular SIF+ file, including the date the SIF+ file was created, the SIF+ file version, and the geographical area represented in the file. These are the first two records of every SIF+ file
Reference records and compound reference records contain reference information, including the unique coding schemes used in the SIF+ file
Cross reference records contain point of interest (POI) categorization information for premium business listings products. These records relate facilities to categories and subcategories to parent categories
Area records contain the definition of all the administrative areas included in the SIF+ file. Area records are referenced by link basic main, link POI attribute, and zone records. Two types of area records are defined:
{ Area main records contain the primary information about an administrative area, including the area name, government code, administrative level, and administrative hierarchy
{ Area daylight savings time records contain information about when daylight savings time is in effect for the administrative area.
NAVTEQ Network for Developers 35 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 (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:
NAVTEQ Network for Developers 36 CONFIDENTIAL
{ Link POI main records contain the primary information about a POI, including facility type, chain ID, street address, and phone number.
{ Link POI name records contain the facility name and any synonym or exonym names that might exist for the POI
{ Link POI attribute records contain various types of attribute information about a POI, including food type, vanity city, population, capital city, diesel, 24-hour indicator, building type, rest area type, and airport type attributes.
{ Link POI actual address records contain optional actual address information for a POI
{ Link POI parent records contain references to the parent POI(s) for POIs that are themselves children
{ Link POI child records contain references to the child POI(s) for POIs that are themselves parents.
Link sign records describe the road signs that are associated with a particular link. The link sign records are attached to the sign destination link.
Link condition/driving maneuver (CDM) records describe the exception conditions and the preferred or restricted driving maneuvers associated with a particular link or group of links. The link CDM records are attached to the CDM source link. Three types of link CDM records are defined:
{ Link CDM main records contain primary information describing the condition or driving maneuver.
{ Link CDM date/time modifier (DTM) records contain optional information about the time period when the CDM is in effect.
{ Link CDM maneuver link records contain additional maneuver link information if more than one maneuver link exists for the CDM. The link CDM main record contains the first maneuver link.
Link CDM lane traversal records contain lane connectivity information between lanes of the source link and lanes of the destination link (i.e., final maneuver link). This record is applicable only to lane traversal conditions.
Link CDM lane template records contain the values in the lane representation. A lane template record exists only if a lane condition is defined.
Link CDM modifier records contain modifier information for modifier types 10 and higher.
CRF Records
CRF records enumerate the components (i.e., the links and nodes) that make up CRFs. These records contain link IDs and node IDs that are references to link records and node records. Three types of CRF records are defined:
CRF main records contain primary information about the CRF, including CRF type, number of components, number of lanes, number of names, landmark point X and Y
NAVTEQ Network for Developers 37 CONFIDENTIAL
coordinates (for CRF objects only), and ref and nref CRF intersections (for CRF roads only)
CRF component records contain the components (links and/or nodes) that make up the CRF
CRF name records contain names for a CRF object. If the CRF object is unnamed, this record is not published.
2.4.2 Usage of SIF+ Data
NAVTEQ customers may have a proprietary data structure for publishing navigable map contents, as used by their application. Data contained in an extraction format must be converted into this proprietary data structure. Customers must build or buy a compiler that reads the extraction format, interprets the data in the format, and publishes the content into their proprietary data structure.
2.4.3 Data Availability/Distribution
NAVTEQ Map Data are available in SIF+ format as follows:
Europe, 60 files North America, 34 files World markets including Mexico, Brazil, Taiwan, Macau, Hong Kong, Singapore,
Malaysia, South Korea, Thailand, Qatar, Saudi Arabia, Kuwait, United Arab Emirates, Oman, Bahrain, India, Indonesia, South Africa, Australia, 20 files
China, 1 file. These region counts are based on second quarter 2006 databases and are published as a reference only; regions are expected to grow with continued increased coverage worldwide. China is available through the NAVTEQ/NavInfo joint venture NAV2.
NAVTEQ North America provides a SIF+ statistics file with each delivery:
Record counts Feature counts Attribute counts.
NAVTEQ North America also provides a named place POI Report with each delivery. Both are located on the NAVTEQ database CD-ROM.
NAVTEQ Network for Developers 38 CONFIDENTIAL
2.5 NAVSTREETS Overview
NAVSTREETS is a NAVTEQ-defined format that enables NAVTEQ map data to be uploaded into commercially available GIS tools. NAVSTREETS is a layered representation of NAVTEQ map data and is available in two GIS formats:
ESRI Shapefile Format layered, GIS-oriented, representation of NAVTEQ data, delivered in ESRI Shapefile format; compatible with ESRI ArcViewTM 3.x and ArcGISTM 8.x 9.x software suites
MapInfo Table Format layered, GIS-oriented, representation of NAVTEQ data, delivered in MapInfo's native (TAB) format; compatible with MapInfo Professional 5.x and above
NAVSTREETS provides the most navigable attributes available in a database. Utilizing the data to its fullest allows the user to access features such as expressway ramps; complete and correct connectivity of all roadways; one-way streets; physical, logical, and legal turn restrictions; construction projects; and physical and painted lane dividers. In addition to these navigable attributes, NAVSTREETS provides address ranges down to the level of the correct side of the street. Mapping applications are enhanced with five functional classifications of roads, and polygonal representation of features such as airports, aircraft roads, cemeteries, golf courses, hospitals, military bases, parks, national monuments, public use areas, pedestrian zones, shopping centers, sports complexes, undefined traffic areas, university/colleges, and woodlands.
Additional NAVSTREETS highlights include:
Programming language supported by commercially available GIS packages (e.g., Visual Basic, MapBasic)
Out-of-the-box functionality for mapping and spatial analysis using commercially available GIS tools
Based on SIF+ Extract (ASCII Flat file) of the NAVTEQ database Data tables allow unlimited modification by the end user Secondary compilation is required to enable routing and geocoding software
utilization on a set of NAVSTREETS data tables
NAVSTREETS is delivered as a premium product on DVD media. The delivery includes the NAVTEQ map data and database statistics files. There are also supplementary DVDs that contain the NAVSTREETS Customer Technical Reference Manual (CTRG), electronic scope book, and data product release notes. The NAVSTREETS Premium product includes the following data layers:
Signs Z-levels Condition/driving maneuvers (date/time modifiers and maneuver links) Traffic location codes
NAVTEQ Network for Developers 39 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 product-specific additions to the data delivery format will be detailed in a product-specific documentation delivery.
NAVTEQ Network for Developers 40 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)
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)
NAVTEQ Network for Developers 41 CONFIDENTIAL
2.6.2 Content Attributes
The key content attributes describing the POIs include:
Action describes the action to be taken for a specific POI (e.g., add, delete, update)
Supplier ID describes the source of the POI Identity contains information about the identity of a POI and is categorized as:
{ POI_Entity_ID
{ Names
{ Chain_ID
{ Category_ID
{ Product_Type
Relationship identifies relationships between two or more POIs { Association_Type
{ POI_Entity_ID
Locations defines a POI location by address, geo-position, and NAVTEQ link ID and may have more than one location (i.e., main entrance and service entrance). Information is categorized as:
{ Address
{ Actual Address
{ GeoPosition
{ MapLinkID
{ Confidence
Contacts contains all contact information about a POI (e.g., phone number) Revision History
NAVTEQ Network for Developers 42 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 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)
NAVTEQ Network for Developers 43 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
NAVTEQ Network for Developers 44 CONFIDENTIAL
RDF - data can be uploaded into standard database environments (e.g. Oracle or SQL Server, with associated tools)
NAVSTREETS - layered GIS focused, representation of NAVTEQ data in various standard GIS formats, with ability to upload data in commercially available GIS tools (e.g., MapInfo, ArcGIS, Oracle Spatial). In addition, data can be added in from Excel files with relative ease. As long as the basic geometry of roads, POIs, and polygons are supported, then either NAVTEQ or a third-party can add infinite information to a customers final product.
4.2 Adherence to International Standards
Adherence to international standards is key to many customers. These standards increasingly include map data standards. For example, GDF 3.0 is an European standard, emerged as the de-facto international standard for exchanging navigable databases.
Note: Despite the status of an international standard, GDF has flavors prevent the usage of a single GDF compiler worldwide to serve all map suppliers.
4.3 Geographic Availability
Not all regions are covered by all formats. In particular China is not available in the NAVSTREETS format. Also, the RDF format has one file per region, so even if only selected countries within one region are wanted, the entire regional file must be acquired.
Format Regions Covered Delivery Method
GDF 3.0 EU, NA, WM, China
GDF file per sub-region (EU: 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
NAVTEQ Network for Developers 45 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 (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.
NAVTEQ Network for Developers 46 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 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.
NAVTEQ Network for Developers 47 CONFIDENTIAL
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.
NAVTEQ Network for Developers 48 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
NAVTEQ Network for Developers 49 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 NAVTEQs tools Assisting in test driving (Locations: Europe, Japan and North America)
TCS also informs customers about modifications in the NAVTEQ database via Technical Notification Memorandums (TNMs) on topics including:
New Data Improved Representation Bug and Processing Fixes Version Numbers Dataset IDs Database Enhancements
6.2 Changes to Extraction Formats
Although extraction formats are stable and generally do not change, smaller modifications can be implemented. Any change to an extraction format is communicated via a standard procedure (e.g., TNMs), generally with a 6-month notification timeframe.
NAVTEQ Network for Developers 50 CONFIDENTIAL
Appendix A.1 Glossary
Term Description
CDM Condition/driving maneuver
CTRG Customer Technical Reference Guide
DC Detailed Coverage
DSS Data Server Suite
DTM Date/time modifier
FC Functional Class
GDF 3.0 Geographic Data File
GIS Geographical Information System
GPP Geographical Platform Provider
Link A road segment beginning and ending at a node
Look-Aside Files Data components that are not published in the core extraction formats
Node Indicates and intersection, termination of a link, or change of attributes
OGC Open Geospatial Consortium
POI Points of Interest
RDF Relational Data Format
Reference Node Node with the lower latitude
RNC Road Network Coverage
SDAL Shared Data Access Library
Shape Point Adds "shape" to a segment.
SIF+ Standard Interchange Format
TCS Technical Customer Service
TNM Technical Notification Memorandums
XML Extensible Markup Language
NAVTEQ Network for Developers 51 CONFIDENTIAL
Appendix A.2 NAVTEQ Overview
Background
Founded in 1985 in Silicon Valley, California, NAVTEQ has a unique and eventful history rooted in technology, geography, hands-on research, and an infectious entrepreneurial spirit. From the beginning, NAVTEQ has been focused on capturing the reality of the road network to enable dynamic turn-by-turn routing. The company began by collecting detailed data for large metropolitan city areas. After Philips Electronics signed on as an early investor, the company grew strategically, establishing its first European office in 1991. The companys significant growth led to the opening of offices in Yokohama, Japan in 1996.
Today, NAVTEQ, headquartered in Chicago, Illinois, USA has approximately 2,100 employees worldwide, and has major production facilities in Fargo, North Dakota, USA, and a support center in Yokohama, Japan. NAVTEQ has achieved ISO 9001: 2000 certification of all of its main operating locations.
NAVTEQ provides products and services that address several parts of the location-based services (LBS) value chain. At its core, it provides the digital map data content that forms the heart of all location-based services. NAVTEQ provides this data in a variety of formats directly to customers as well as to geospatial platform providers such as Autodesk and deCarta who in turn offer developers various tools to develop their LBS applications.
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
NAVTEQ Network for Developers 52 CONFIDENTIAL
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.
NAVTEQ Network for Developers 53 CONFIDENTIAL
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
NAVTEQ Network for Developers 54 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.
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
NAVTEQ Network for Developers 55 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-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