Map database management
Moreover, they are playing an increasingly important role in the emerging areas of location-based services, active safety functions and advanced driver-assistance systems.
Common to these functions is the requirement for an on-board map database that contains information describing the road network.
When designed well, a map database enables the rapid indexing and lookup of a large amount of geographic data.
Map providers generally collect, aggregate and supply data in a well-defined and documented file format that is specifically intended for information interchange, e.g. Navteq uses Standard Interchange Format (SIF)[2] and Geographic Data Files (GDF), while Tele Atlas uses a proprietary form of GDF.
Each record type consists of a sequence of fields, which are either fixed length or delimited by a punctuation character such as a comma.
Other record types are used to represent address information, shape-points for a link, cities and states, points of interest (POI's), etc.
[4] Companies involved include TomTom, BMW, Volkswagen, Daimler, Renault, ADIT, Alpine Electronics, Navigon, Bosch, DENSO, Mitsubishi, Harman Becker, Panasonic, PTV, Continental AG, Navteq and Zenrin.
The wireless channel might be bi-directional, such as Wi-Fi and cellular phone, broadcast, such as satellite radio, FM sub-carrier or ATSC datacasting, or a combination of both.
In any case it would be impractical or extremely inefficient to transmit the entire new database to replace an existing version, since it is likely to be several gigabytes in size.
In this case, basic changes are also transmitted to the vehicle, but are placed into a separate memory location called a look-aside store.
The changes are also represented in transactional form but may appear in any convenient format, which is not necessarily either interchange or run-time.
During operation of the navigation unit, the look-aside store is searched each time the main database is accessed.
The necessity of examining the look-aside store and applying changes for each database access of course complicates the navigational algorithms and lengthens their computation time.
It is quite possible that a small number of entity changes will require the transmission of almost all tiles, thereby defeating the purpose of incremental updates.
It will generally consist of a list of map elements of a specific type (e.g., links, intersections, point-of-interest locations, etc.)
As a practical matter the result will represent a small subset of the elements of the given type that are available in the map databases and will consist of those that are more important to the application area.
TMC, which stands for Traffic Message Channel,[8] is part of the Radio Data System (RDS), which is implemented as a sub-carrier modulation of a commercial FM broadcast signal.
Traffic-based route planning, on the other hand, requires coverage of all or almost all major roads and, therefore, is not adequately supported by TMC location code tables as they are currently formulated.
For example, if the map element is a link connecting two intersections, then one or both cross streets could be appended for the sake of the search.
Although the procedure is quite heuristic, a proposed standard called Agora outlines the strategy for choosing neighboring elements to append.
The ActMAP consortium comprises ERTICO (coordinator), BMW, CRF Fiat Research Centre, DaimlerChrysler, Navigon, Navteq, Tele Atlas, and Siemens VDO Automotive.
They resolve this by using an open intermediate map format expressed with XML and based on the concepts of the ISO standard GDF 4.0.
Another issue not resolved by ActMAP is the inability to reference and characterize subsections of road segments (for example, curves, hills, maneuver lanes, etc.)
