Road Link String Conversion for Map Data Compatibility

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing navigation systems face challenges in efficiently processing and converting road link information between devices with different map data formats, leading to increased processing load and potential delays in traffic information delivery due to the use of coordinates-of-position strings, which require decoding processing on the terminal device.

Innovation Solution

A road information providing system that includes a server device capable of encoding and decoding road link strings, allowing for the conversion of road links between different map data formats, reducing the processing burden on the terminal device by using encoding and decoding processing units to match road links between the server and terminal maps.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If coordinates-of-position strings are used to specify road sections between different maps, then position specification is achieved, but the code size for expressing position information becomes much greater and processing load increases

Engineering Contradiction:
Improveposition specification accuracyVSAvoidprocessing load
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The patent segments the road network into discrete road links, each assigned a unique identifier. Instead of transmitting full coordinate strings, the system divides the road specification task into: (1) defining road links with simple identifiers on the server side, and (2) transmitting only these compact identifiers to the terminal device, which then matches them to local map data. This segmentation reduces data size while maintaining position specification accuracy.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces an intermediary conversion table that maps between road link identifiers from different map data versions. This intermediary structure allows the system to translate road specifications without transmitting full coordinate information, reducing communication overhead and processing load while maintaining accurate position specification across different map versions.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If VICS link numbers are allocated to road sections, then traffic information can be provided, but roads without VICS link numbers cannot receive traffic information and may have unexpected congestion

Engineering Contradiction:
Improvetraffic information coverageVSAvoidroad coverage
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent creates a universal road identification system using road link identifiers that can represent both VICS-defined roads and other roads without VICS link numbers. The conversion table structure allows any road to be assigned an identifier, making the system universal and applicable to all road types, thereby improving both traffic information coverage and road coverage adaptability.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system performs preliminary action by pre-defining road links and their identifiers on the server side before traffic information transmission. The conversion table is prepared in advance to map between different road identification systems, ensuring that all roads (including those without VICS link numbers) are pre-assigned identifiers that can be used for traffic information provision.

Inventive Principle:
Principle #10Preliminary action

3Adaptability or versatility

If road link conversion is performed between different map data formats, then information sharing is enabled, but decoding processing on the terminal device increases communication costs and processing time

Engineering Contradiction:
Improvemap format compatibilityVSAvoiddecoding processing time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent inverts the traditional conversion approach by performing the complex conversion table generation and road link matching on the server side rather than on the terminal device. The server prepares conversion tables that map road links from its map data to the terminal's map data format, then transmits only the necessary identifier mappings. This inversion shifts the processing burden from the terminal to the server, reducing terminal decoding time and communication costs.

Inventive Principle:
Principle #13The other way round (Inversion)

4Measurement precision

If shape matching processing is performed to search for agreeing road sections, then road section correspondence is established, but the processing burden on the terminal device increases

Engineering Contradiction:
Improveroad section matching accuracyVSAvoidprocessing efficiency
Core Design Contradiction:
Measurement precisionVSProductivity

Solution Approach 1:

The patent performs preliminary action by pre-establishing road link definitions and their geometric characteristics on the server side. The server prepares conversion tables that include pre-computed matching information between road links of different map versions. This preliminary preparation eliminates the need for terminal devices to perform complex shape matching processing, thereby improving processing efficiency while maintaining matching accuracy.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentEP2385348B1Road link string conversion method, road information providing device and road information providing system
Publication Date: 2014.05.14 HITACHI LTD
  • EP2385348B1 patent drawingFigure 1
  • EP2385348B1 patent drawingFigure 2
  • EP2385348B1 patent drawingFigure 3

AI summary

A road link string conversion method for converting first road link string data included in first map data into second road link string data included in second map data: deciding whether or not first coordinates-of-position strings corresponding to the first road link string data correspond to the second road link string data; constructing a second coordinates-of-position string by combining together the first coordinates-of-position strings decided as not corresponding to the second road link string data; establishing correspondence between the second coordinates-of-position string and the second road link string data; and converting the first road link string data including the first coordinates-of-position strings decided as not corresponding to the second road link string data, to the second road link string data to which the second coordinates-of-position string corresponds.