BRPI0612689A2 - provision of traffic information, including current traffic data for a call, and use of this - Google Patents

Abstract

PROVIDING TRAFFIC INFORMATION, INCLUDING CURRENT TRAFFIC DATA FOR A CONNECTION, AND USING THIS This is a method for identifying traffic information, including receiving traffic data, including a first identifier, the amount of time currently required to travel. a particular link, and information that corresponds to a location associated with the particular link. The first identifier allows you to determine the type of information that is included within the received traffic data. The method also includes determining a type of information included in the received traffic data based on the first identifier, and determining the current travel time information based on the information included in the received traffic data only if the first identifier allows a determination that the traffic data received includes an amount of time. The method further includes determining location information based on the information included in the traffic data received corresponding to the location associated with the particular connection, and identifying traffic information based on the determined current travel time information and the determined location information.

Description

"PROVISION OF TRANSIT INFORMATION, INCLUDING CURRENT TRANSIT FOR A CONNECTION, AND USE OF THIS"

1. TECHNICAL FIELD

This disclosure relates to the provision of traffic information, including traffic data for a link, and the use thereof.

2. State of the art

With advances in communication technologies and digital signal processing, radio and TV broadcasts are being digitized. Digital broadcasting enables the provision of various information (eg news, stock prices, weather forecast, traffic condition, etc.) as well as audio and video content.

3. DISCLOSURE OF INVENTION

In general, a method is provided for identifying traffic information. The method includes receiving traffic data including a first identifier, an amount of time currently required to navigate a particular connection, and information corresponding to a location associated with the particular connection.

The first identifier allows to determine the type of information that is included within the received traffic data. The method also includes determining a type of information included in the traffic data received based on the first identifier, and determining the current travel time information based on the information included in the received traffic data only if the first identifier allows a determination of traffic time. traffic data received includes a set amount of time. The method additionally includes determining location information based on the information included in the received traffic data corresponding to the location associated with the particular connection, and identifying traffic information based on the current travel information and the determined location information. .

Implementations may include one or more additional aspects. For example, determining current travel information may include accessing incoming data corresponding, inter alia, to results of measurements made in relation to previously traveled traffic, and calculating an amount of travel time based on the received data. Determining current travel time information may involve accessing information provided within the traffic data received and recognizing that data as the amount of travel time.

The method may also include receiving information corresponding to a message management framework, including information corresponding to a generation time of the information reflected in the traffic data. The generation time included within the incoming message management framework may relate to a multiplicity of message component structures that correspond to more than one current or expected traffic trend, a current amount of traffic. or anticipated, a current or anticipated speed city, or a current or anticipated time to make a particular connection. Each message component structure may also include an identifier specific to the type of information, and the first identifier may be an identifier, in a message component structure, specific to the amount of travel time for the particular connection.

In addition, in the method, the current travel time information and location information can be determined in one step. Location information can be determined before current time information should be determined. Receiving off-road data may include decoding the traffic data, so that the received traffic data becomes decoded traffic data. Receiving information corresponding to a current amount of travel time may include receiving a value associated with a textual description of a travel time amount, and determining, with the received value, the textual description. Receiving information corresponding to a current travel time amount may include receiving a current travel time amount for the call, including a textual descriptor. The amount of time currently required to travel a particular call may reflect the current amount of travel time.

Furthermore, in the method, the amount of time currently required to travel the connection can be reflected in a number of seconds. The amount of time currently required to travel the call can be reflected in a unit of time that is less than one second. The amount of time can be reflected in one or more bytes, each byte including a first part of the byte, which gives it a value in terms of minutes, and a second part of the byte, consisting of five bits or less, which determines a number of tens of seconds. Receiving a time amount may include receiving a flag value that determines whether the associated data is in terms of a first unit or a second unit. The first unit may be minutes and the second unit may be in seconds. The reception of an amount of time may include receiving a flag value that determines whether the associated data will include one or more additional information packets. The valorsignal may indicate that the associated data will be distributed with an additional single byte.

In another general aspect, a method is provided for identifying traffic information. The method includes extracting a traffic information message, including message segments, and extracting a first component, including condition information, from the extracted traffic information message. The method also includes extracting, the first component, congestion information for a link from the condition information, and extracting a second component, including condition information, the extracted traffic information message. The method also includes extracting, from the second component, speed information for a connection from the condition information, and extracting a third component, including condition information, from the extracted traffic information message. it includes extracting third party travel time information for a link from the condition information, and identifying, based on the extracted information, congestion information, speed information, and travel time information for the link.

In another general aspect, an apparatus is provided for identifying traffic information. The apparatus includes an interface configured to receive traffic data, including a first identifier, information corresponding to the amount of time currently required to traverse a particular connection, and information corresponding to a location associated with the connection. in particular. The first identifier allows you to determine the type of information that is included within the received transistor data. The apparatus also includes a processor configured to determine a type of information included in the received traffic data based on the first identifier, and determine the current travel time information based on information included in the received traffic data only if the first identifier. allow a determination that the traffic data received includes an amount of time. The processor is also configured to determine whether the received traffic data includes a time amount based on the information included in the received traffic data that corresponds to the location corresponding to the particular connection, and to identify traffic information based on the current travel time information. and location information.

Implementations may include one or more additional aspects. For example, on the apparatus, the processor may be configured to receive traffic data, including information corresponding to a version number of the information reflected in the traffic data. The version number may be associated with a specific data syntax, where any of several syntaxes may be used.

In addition, on the device, the processor may be configured to receive information corresponding to a message management structure, including information corresponding to a generation time of the information reflected in the traffic data. The processor may be configured to receive information corresponding to a length of the received data.

In addition, in the apparatus, the processor may also be configured to determine the amount of travel time for a particular connection only if the first identifier allows a determination that the traffic data relates to a current travel time for a particular connection. .

Details of one or more implementations are given in the accompanying drawings and the following description. Other aspects are apparent from the description, drawings and claims.

4. BRIEF DESCRIPTION OF DRAWINGS

Fig. 1 illustrates a schematic diagram of a network through which traffic information is provided;

Fig. 2 illustrates a format of wireless information transmitted wirelessly;

Fig. 3 illustrates a congestion control and travel time information structure included in a CTT event recipient;

Figs. 4a to 4c illustrate the average speed in a link, the travel time for the link, and the syntax for the level of congestion included in the conducting component of the CTT event container of Fig. 3;

Figs. 5a to 5c illustrate structures of a condition component by distributing the average velocity in one connection;

Figs. Figures 6a to 6e illustrate information structures for the travel time for a connection;

Fig. 7 illustrates a block diagram of a navigation terminal receiving traffic information transmitted from a server;

Figs. Figures 8a and 8b illustrate examples of graphical user interfaces configured to display average speed on a call;

Fig. 9a illustrates an example of a graphical user interface configured to display average speeds on multiple calls with more accurate accuracy than, for example, 1.8 km / h; and

Fig. 9b illustrates an example of a graphical user interface configured to display travel times for calls. MODES FOR CARRYING OUT THE INVENTION

One of the uses for digital transmissions is to satisfy an existing demand for traffic information. Proposals that involve the use of digital transmissions for this purpose include the use of standardized formatting of traffic information to be transmitted. This approach can be used to allow the use of traffic information reception terminals manufactured. by different manufacturers, each of which can be configured to detect and interpret transit information in the same way.

Fig. 1 is a schematic diagram of a network through which traffic information is provided. A traffic information provider server 100 in a transmission station may transmit traffic information collected from various sources (e.g. , operator input, or information received from another server or sensor-equipped car via a network 101) without the use of wires, such that a traffic information receiving terminal (for example, a navigation system installed on a car 200) can receive traffic information.

As illustrated in FIG. 2a, the wireless information transmitted wirelessly from the traffic information provider server 100 may be a transport protocol expert group - congestion and travel-time information (TPEG-CTT) message sequence. Information - Travel Time and Congestion Information)). A message segment of the sequence, that is, a TPEG-CTT message, whose syntax is illustrated in FIG. 2b, may include a message management container 21, a CTT (or Application Event Recipient) 22 event container, and the TPEG-CTT location container 23. The TPEG-CTT message may include It is also a different type of container instead of or in addition to the CTT event container, as in message TPEG-CTT 30.

Message management container 21 can be used to manage date and time information. Time information may include the message generation time (for example, a chronological time indication). The message generation time may be included in each TPEG-CTT message when the corresponding message is transmitted. The CTT 22 event container may include travel time and congestion condition and predicted travel time and congestion condition, i.e. road segments. Travel and congestion management condition may include average connection speed, connection travel time, connection delay, type of congestion, etc.

The TPEG-CTT locating container 23 may employ various reference processes. For example, a location reference process can be used using a coordinate system or a location reference process using pre-promised bonds. When a decoordinated system is used, the coordinates (latitudes and longitudes) of the start and end positions of a link for which the TPEG-CTT message is created can be transmitted. When a referral process using pre-promised calls is used, a unique ID for a specific call on a receiving device may be transmitted. For example, a receiving device may include a network of locally stored connections, where each connection may be identified by a unique identifier. A link may refer to a road segment that starts and ends and crosses and has no intersections between it. The coordinate system may be model WGS 84. A text formatted name of the link may be transmitted.

In various implementations, a CTT event container and a TPEG-CTT location container as shown in FIG. 2c, are composed of one or more CTT components 201. Each of the CTT components may be constructed according to the syntax shown in FIG. 2d if it has congestion condition information, whereas it can be constructed according to the syntax given in FIG. 2e if the component has location information.

A CTT 22 event container may be composed of one component or a plurality of CTT components. In many implementations, CTT components that include an 80h ID (the notation "h" stands for hexadecimal) or 84h include one or more condition components that include basic transit information, such as average connection speed, link travel time , call delay, or jam type. In the description, specific IDs are described as designations of structures associated with specific information. The actual value of a designated ID (e.g., 80h) is exemplary, and different implementations may assign different values to specific associations or circumstances.

In various implementations, CTT components that include an 8Ih ID include one or more condition components, including predicted CTT condition. The anticipated CTT condition may include the predicted average link speed, the predicted link travel time, or the congestion acceleration tendency. The congestion management acceleration trend may include information that indicates the tendency of the congestion condition. The congestion acceleration trend will be described as a kind of forecasting information, since the congestion condition in the near future can be predicted from it.

In various implementations, the TPEG-CTT message may comprise CTT component structures as in FIG. 2f to distribute additional information or transit information. As illustrated, an 8Ah identifier may be designated for the CTT component containing additional information, and a language code indicating the language used for the additional information may also be included in the CTT component.

Fig. 3 illustrates a syntax according to various implementations of a structure of a travel and congestion information component (hereinafter referred to as the CTT component) belonging to a CTT event container (e.g. in reference numeral 22 to Fig. 2). The CTT component of Fig. 3 has an ID of "0x80" 3a, includes condition components 3c, and has a field expressed in byte 3b indicating the length of all condition component data included therein.

The condition components may, for example, use 8 bits to transfer the average speed in a call, the travel time for a call, and / or information about the level of congestion in a format illustrated in the IFFIs. 4a to 4c. In one implementation, an ID of "00" is assigned to the average speed in a call; an ID of "01" is assigned to the travel time for a call; and an ID of "03" is assigned to the congestion level.

A numerical value expressed in units, for example 0.5 m / s (ie 1.8 km / h), can be loaded in field 41 for average speed on a link ("intunti" indicates byte size) and a numerical value expressed in units, such as minutes, is loaded into the field for travel time for a call 42. Information about travel time for a call can be obtained by recouping the length from a base link information data (e.g., link length, link width, etc.) built into server 100 and dividing the link length by the average speed in the corresponding link obtained from the traffic information collected from various sources and are provided after additional rounding to minute units (eg a travel time exceeding 30 seconds is rounded to one minute). In one implementation, if the average speed on a link is transmitted In units of 0.5 m / s (1.9 km / h), the permissible speed range in the 8-bit expression may be 0 ~ 459 km / h. Since it may be unnecessary to express the average speed to a very high value (eg above 200 km / h), it may be better to consider a very high speed (eg higher average speed 200 km / h) as being due to the acceleration of the drivers on the corresponding link instead of the current traffic condition. Therefore, from the perspective of providing traffic congestion information, it is not necessary to provide information indicating up to a very high speed.

On the other hand, in the case of traffic congestion, even a 1 km / h difference in average speed can be an important factor for the driver to choose a specific route. In this respect, an accuracy of 1.8 km / h cannot distinguish a difference of lkm / h in the average speed. Therefore, when average speed on a link becomes low, average speed information, expressed in units of 0.5 m / s (= 1.8 km / h) may not meet the accuracy requirements of drivers. .

Similarly, if the travel time for a connection is given in units of minutes, the rounding error may become large when the connection length is short. For example, if the link length is 500 meters and the average link speed is 20m / s (= 72km / h), the travel time for the link will become 25 seconds; If the link length is 1000 meters and the average link speed is 20 m / s, the trip time for the link will become 50 seconds; as another example, if the length of the link is 2900 meters and the average speed at the link is 20 m / s, the time taken for the link is 145 seconds; In these cases, the travel time for the distributed link to the condition component is 0.1 and 2 minutes, respectively, so the difference between the actual travel time and the travel time provided by the traffic information equals a25, 10 and 25. seconds These errors can become more prominent in short length links.

Therefore, in many implementations, when distributing information about the average speed in a connection, the maximum speed is lower than that which can be introduced to improve accuracy in low speed connections. Similarly, with respect to the distribution of travel time information for a connection, information expressed in units of seconds may be permitted, an 8-bit representation may be employed to distribute travel time information for an express connection. in units of a second; however, additional bits may also be assigned to distribute the information expressed in units of a second.

As illustrated in Fig. 5a, in one implementation, the following format may be employed to distribute information about the average speed over a link: 0.25 m / s (= 0.9 km / h). When using the speed unit, the maximum speed that an 8-bit field indicating the average speed51 can represent becomes 229.5 km / h.

The 0.25 m / s unit is just an arbitrary example / therefore, in order to increase the speed accuracy in a low speed connection, a much smaller unit, for example 0.2 m / s (the maximum speed permissible for representation is 183 km / h) or 0.15 m / s (maximum permissible speed for representation is 137 km / h) can be used. It is advantageous to increase speed accuracy by reducing the speed unit in cases where traffic regulations restrict the top speed (eg up to 110 km / h).

As shown in Fig. 5b, the average speed on a link can also be provided in units of 1km / h. According to this implementation, the allowable range that the average speed field 52 may represent becomes 0 - 255 km / h, and numbers below a decimal point do not occur. Although the maximum allowable speed for representation is reduced in the implementation of Fig. 5b compared to the example of Fig. 4a (459 km - »255km / h), the accuracy of the speed is improved by 0.8 km / h (1, 8km / h - »1km / h).

Speed accuracy can play an important role depending on the magnitude of the current average link speed. As described earlier, when the average speed on a link is low, the driver may be responsive to a slight change in average speed, while the driver may be less sensitive to a slight change in average speed if the average speed on the link is high. Therefore, in various implementations, a variable speed unit may be employed according to the average velocity magnitude.

Fig. 5c illustrates an example of a mean velocity field structure of a condition component according to an implementation. The most significant bit (F) means a speed unit on which the average speed represented by the remaining 7 bits (Speed_Value) is based. For example, if the most significant bit (F) is 0, this implies that the value contained in the remaining 7 bits (Speed_Value) corresponds to the average speed expressed in units of 0.5 km / h; when the most significant bit (F) is 1, the value contained in the remaining 7 bits (Speed_Value) corresponds to the average speed expressed in units of 1 km / h.

In the implementation of Fig. 5c, since the maximum speed that can be expressed in units of 0.5 km / h is 63.5 km / h (= 127 * 0.5 km / h), when the highest bit Significant (F) is 1, the average speed equals the sum of the remaining 7 bits and 63.5 km / h. For example, if the average speed field is 1: 0001100, the average speed to be distributed would be 759.5 km (= 12 km / h + 63.5 km / h) or 759 km / h (= 12 km / h + 63 km /H).

Specifying the speed accuracy with two units other than 0.5 km / h and 1 km / h in the implementation of Fig. 5c is just one example, and it is possible to employ a different accuracy than the specified unit. Therefore, a varying accuracy, depending on the magnitude of the average speed in a connection, should be considered within scope, although a speed accuracy employed may differ from that described in this disclosure.

An implementation of a format distributing travel time information for a connection is illustrated in Figs. 6a to 6d.

In the implementation of Fig. 6a, the upper 5 bits of the 8 bits are reserved for minutes and the lower 3 bits are reserved for seconds. Since the allowable range that the lower 3 bits can express is 0 to 1, the lower 3 bits 61 record the value of the tens of elements expressed in seconds of travel time for a link. That is, from the three examples described above, since the travel time for the call is 25, 50 and 145 seconds (2 minutes and 25 seconds), the lower 3 bits 61 register 3 (which corresponds to 30- - 5 seconds), 5 (corresponding to 50) and 3 (corresponding to 30), the upper 5 bits register 0, 0 and 2, respectively. In the present implementation, the respective errors become 5, 0, and 5 seconds and the relative error quantities are reduced to 20% (= 5/25), 0% (= 0/10), and 20% (= 5/25) to a13 % on average compared to the case expressed in minutes.

In the implementation of Fig. 6b, the time unit for the 8-bit expression is varied as needed.

More specifically, the lower 7 bits are reserved to represent the travel time for a connection in minute or second units; the most significant bit 62 is used as a flag to designate whether the content recorded in the 7 bits is measured in units of minute or second. When the content is expressed in minutes, 0 is assigned and a- if 1 when the * content is expressed in seconds. Since the travel time for the link is 25, 50, and 145 seconds from the previous three examples, 10011001 (signal = 1), 10110010 (flag = 1), and 00000010 (signal = 0) ( = 2 minutes) or 11111111 (flag = 1) (= 127 seconds) are written to 8 bits respectively. In the present implementation, the respective errors become 0.0 and 25 seconds (or 18 seconds) and the relative error quantities are 0%, 0% and 100% (or 72%), being reduced to 33.3% (or 24). %) on average compared to the case expressed in minutes.

In the implementation of Fig. 6c, all 8 bits are used to record the travel time for a call, with the recording unit being less than 60 seconds and greater than 1 second (for example, 10 seconds). Since the travel time for the connection is 25, 50 and 145 seconds from the previous three examples, 3 (5 rounded seconds), 5 and 15 are recorded in the 8 bits according to the implementation of Fig. 6c. In the present implementation, the respective errors become 5, 0 and 5 seconds and the relative error quantities are 20%, 0% and 20%, being reduced to 133.3% on average compared to the case expressed in minutes. Although the present implementation presents results similar to the implementation of Fig. 6a, the maximum allowable time to express the travel time for a call is 2550 seconds (4 minutes and 30 seconds), thus being greater than 31 minutes and 50 seconds of the connection. implementation of Fig. 6a.

Additional bits may be designated by a mechanism as shown in Fig. 6d. Fig. 6d is an implementation in which a one bit flag symbolizing the unit of time is added.

In the implementation of Fig. 6d, all 8 bits are reserved for the travel time for a connection and an additional one bit signal 63 (for example, that flag is set to 0 when the time unit corresponds to minutes, and 1 when the time unit is seconds) is then assigned to specify whether the time recorded in 8bits is expressed in minutes or seconds. Since the trip time for the connection is 25, 50, and 145 seconds from the previous three examples, 1: 8 bits (flag: data), according to the implementation of Fig. 6d, contains 1: 00011001, 1 : 00110010 and 1: 10010001, respectively. The error of each case becomes 0 in the present implementation, with the error rate being reduced by 100% compared to the case expressed in minutes.

When the one additional bit does not constitute the 8 bits so that actual information is transmitted in the other 7 constituent bits, the 7 bits may be discarded for simplicity of information processing. Therefore, when actual information is not included in the 7 constituent bits and thus is distributed to the condition component (ID 0x01), it may be useful to allocate travel time for a 16-bit connection instead of additionally distributing it only. the one-bit flag as shown in Fig. 6e ("intunti" in Fig. 6e indicates 16-bit size). In the implementation of Fig. 6e, all 16 bits represent the travel time for the 64-link connection fully in seconds. In the implementation of Fig. 6e, where all 16 bits are used to express the travel time for a call, the maximum allowable time becomes 18 hours, 12 minutes and 16 seconds. This representation capability can accommodate the travel time for one call for almost all calls without error.

The implementations of Figs. 6a to 6, where the travel time for a call is expressed as 8 bits, has improved aspects compared to the case where 8 bits are used to express the travel time for connection only in units of minutes. However, for the implementation of Figs. 6a and 6c, since the maximum allowable time for each case is 31 minutes and 50 seconds and 52 minutes and 30 seconds, respectively, if a portion of the connection becomes congested and, as a result, the travel time is increased, one case may occur. information distribution fails due to the inability to represent the travel time for the connection. For the implementation of Fig. 6b, there is the problem that, with respect to the travel time for a connection over 127 seconds, an error occurs similar to the case where the travel time for a connection is distributed. in units of minutes. It may be particularly advantageous to employ daFig solutions. 6c to 6e when a larger or more accurate range is required.

Fig. 7 is an exemplary block diagram of a navigation terminal receiving traffic information transmitted from server 100. Figs. 7 to 9 illustrate a system and graphical user interfaces that appear in exemplary implementations of systems for receiving and using traffic information. Other systems may be organized differently, or include different components.

The navigation terminal comprises a tuner 1 which receives, upon resonance in the frequency band, modulated traffic information signals; a demodulator 2 for emitting traffic information signals by demodulating the modulated signals from tuner 1; a TPEG-CTT 3 decoder for obtaining traffic information by decoding the demodulated traffic information signals; a GPS module 8 for calculating the current position (ie latitude, longitude and altitude) by receiving signals from a plurality of satellites; a storage structure 4 for storing various graphical data and an electronic map including information about links and nodes; an input unit 9 for receiving user input; a navigation mechanism 5 for controlling the screen display based on user input, current position and traffic information obtained; a memory 5a for temporarily storing the data; a LCD 7 screen for displaying data; and an LCD controller 6 for activating the LCD screen 7 according to the data to be presented. Input unit 9 can be a touch screen integrated with LCD screen 7.

Tuner 1 tunes to the frequency of signals transmitted by server 100, and demodulator 2 de-modulates tuned signals in a predetermined manner. The TPEG-CTT 3 decoder decodes demodulated signals into a TPEG message sequence as shown in Fig. 2, interprets each TPEG message in the sequence, and then distributes required information and / or control signals from according to the message content, for the navigation mechanism 5. Although TPEG-CTT decoder 3 provides various types of information to the navigation engine5, for brevity, the following description focuses on its processing procedure.

The TPEG-CTT 3 decoder extracts data / time and message occurrence time included in the message management container of each TPEG-CTT message, and determines if the next container is a CTT event container based on the information from the "message element" (that is, an identifier). If it is determined that the following container is a CTT event container, theTPEG-CTT 3 decoder, by extracting each CTT component and the conditioner component included in the CTT component, provides the navigation engine 5 with the information obtained from the container so that the navigation engine 5 can display travel time and congestion information, which will be described below. Providing the information to the navigation engine 5 may include determining, based on identifiers, that traffic information includes a message management container including condition information within various message components within the message management container. Each of the components may include different condition information associated with different links or locations, and identifiers associated with different condition information. Each of the containers and components may include information associated with a generation time, version number, data length, and identifiers of the information included.

The TPEG-CTT decoder 3 then obtains information about the location of the link around which previously obtained information is created from the following TPEG-CTT location container. The deposition information may be, for example, coordinates (i.e. latitudes and longitudes) of the start and end positions, or a deletion ID depending on the type of the location containerTPEG-CTT. If the navigation terminal is equipped with storage structure 4, navigation mechanism 5 finds the location of the link around which the incoming information is created with reference to the information about each link and node stored in the structure. 4. The navigation engine 5 can convert the coordinates on the link to the link ID, or vice versa.

The navigation mechanism 5 reads a portion of the electronic map centered around the position coordinates received from the storage module 4 GPS module 8 and displays the map on the LCD screen 7 via the LCD controller 6. A specific graphic symbol is displayed at the location that match the current position on the LCD screen 7.

The navigation engine S displays the average speed on a call received from the TPEG-CTT 3 decoder at a location that corresponds to the coordinates or link ID distributed via the TPEG-CTT location container next to the container that distributes the speed information. - average city. As shown in Fig. 8a (typeface display) and 8b (graphical display), the display method uses different colors according to the average speed on a link (for example, red, orange, green and blue colors indicate average speeds of 0 10 km / h, 10 to 20 km / h, 20 to 40 km / h and above 40 km / h respectively). If the driver requests the average speeds on the connections along a travel route to be displayed, the navigation engine 5 may display the average speed information that corresponds to the links in front of the current travel route (or the links belonging to a travel route, if the route has already been determined) from the average speed information received from the TPEG-CTT 3 decoder in the graphical display as shown in Fig. 9a. If the driver requests the display of travel time for connections along a travel route, navigation engine 5 can show travel time information that corresponds to connections in front of the current travel route. (or links belonging to a travel route, if the route has already been determined) among the travel time information received from the TPEG-CTT 3 decoder in the graphical display, as shown in Fig. 9b.

Fig. 9a illustrates an example of when the average speed in a link is distributed with a more precise definition than 1.8 km / h (for example, the implementations of Figs. 5a to 5c), the average speed is displayed in LCD screen 7 by the value included in the corresponding field according to predetermined appreciation (1 km / h in Fig. 5b). Since the appreciation is 1 km / h, the difference in average speed between neighboring connections is expressed as an accuracy of 1 km / h (area marked "A") or a multiple of accuracy. If the average speed information expressed in another predetermined accuracy (0.9 km / h in Fig. 5a, or 0.5 km / h and 1 km / h in Fig. 5c) is received, the average speed is obtained by multiplying it. the information received by the predetermined accuracy is assumed, and the difference in mean velocity between two neighboring links becomes a multiple of the accuracy.

Fig. 9b illustrates an example of when the travel time for a call is provided along with information expressed in units of seconds (for example, the implementations of Figs. 6a to 6e), information in units of seconds is also provided. displayed on the LCD screen 7. If time information expressed in units of seconds is received only, the travel time received for the call can be converted to the units of minutes format: units of seconds when required.

The average speed, or travel time, for the connection can be displayed on the map as shown in Fig. 8a, along the forward direction or on predetermined links.

In the implementations of Figs. 5a and 5c, although the average speed on a call may differ by less than 1km / h since the numerical value of the average speed is displayed separately on the screen, a controller based on the information displayed or in the travel time, which is the length of the corresponding link divided by the average speed, including the same accuracy, can choose a link to be traversed.

According to an implementation for a simplified display, according to the user's choice, the average speed on a call may be displayed after discarding the location values below one decimal point. Similarly, for travel time, only the minute element can be kept as shown, the second element being discarded.

Since travel time for a link within a decoded condition component (ID = Ol) may contain information expressed in units of seconds when the TPEG-CRR 3 decoder distributes the travel time to the navigation mechanism 5 , the TPEG-CTT decoder 3 can distribute two-byte information to the navigation mechanism 5 by allocating one byte for each minute to minute or by converting travel time to seconds (when 16-bit information expressed in received, the information is distributed as received). Therefore, when server 100 also provides the travel time for a connection as the information expressed in units of seconds (for example, the implementations of Figs. 6a to 6e), the TPEG-CTT3 decoder allows the navigation mechanism 5 to express the travel time. to call in seconds; When a route search function is provided, the TEPG-CTT decoder 3 allows the navigation mechanism 5 to find the shortest route using the travel time for the calls, including appreciation in seconds.

If the terminal in Fig. 7 is equipped with a voice output medium, the terminal may voidly output received average speed information or the time required for the specified call or connections included in a travel route.

The foregoing description has been presented for illustration purposes. Thus, various implementations with refinements, modifications, substitutions or additions may be made within the spirit and scope defined by the following appended claims.

Claims (25)

1. Method for identifying traffic information, the method being characterized by: receiving traffic data, including a first identifier, the amount of time currently required to travel a particular connection, and information corresponding to a location associated with the particular connection. - determine; determine current travel time information on the basis of the information included in the received traffic data; determine location information based on the information included in the received traffic data corresponding to the location associated with the particular connection; and identify traffic information based on the determined current travel time information and determined location information. Method according to claim 1, characterized in that determining current travel information includes accessing incoming data corresponding, inter alia, to the results of measurements made in relation to the traffic previously traveling through connection, and calculate an amount of travel time based on the data received. Method according to claim 1, characterized in that determining current travel time information involves accessing information provided within the traffic data received and recognizing such data as the amount of travel time. Method according to claim 1, characterized in that it further comprises receiving information corresponding to a message management structure, including information corresponding to a time of generation of the information reflected in the traffic data. A method according to claim 4, characterized in that the generation time included within the incoming message management structure relates to a plurality of message component structures corresponding to more than one of a traffic trend. current or predicted, a current or predicted amount of traffic, a current or predicted speed, or a current or predicted time to travel a particular connection. A method according to claim 5, characterized in that each message component structure additionally comprises an identifier specific to the information type, and the first identifier is an identifier, in a message component structure, specific to the current amount of travel time for the particular call. Method according to claim 1, characterized in that the current travel time information and location information is determined in a single step. Method according to claim 1, characterized in that the location information is determined before the travel time information is determined. A method according to claim 1, characterized in that receiving traffic data includes decoding the traffic data so that the received traffic data becomes decoded traffic data. A method according to claim 1, characterized in that receiving information that corresponds to a current travel time amount includes receiving a value associated with a textual description of a travel time amount, and determining, with the received value, the textual description. A method according to claim 1, characterized in that receiving information that corresponds to a current travel time amount includes receiving a current travel time amount for the connection, including a textual descriptor. Method according to claim 1, characterized in that the amount of time currently required to travel a particular call reflects the current amount of travel time. A method according to claim 1, characterized in that the amount of time currently required to travel the call is reflected in a number of seconds. A method according to claim 1, characterized in that the amount of time currently required to travel the call is reflected in a time unit of less than one second. A method according to claim 1, characterized in that the amount of time is reflected in one or more bytes, each byte including a first part of the byte, which determines a value in terms of minute. and a second part of the byte, consisting of five bits or less, that determines a number of tens of seconds. A method according to claim 1, characterized in that receiving a time amount includes receiving a flag value which determines whether the associated data is in terms of a first unit or a second unit. Method according to claim 16, characterized in that the first unit is in minutes and the second unit is in seconds. A method according to claim 1, characterized in that receiving a time amount includes receiving a flag value which determines whether the associated data will include one or more additional information packets. A method according to claim 18, characterized in that the flag value indicates that the associated data will be distributed with a single byteditional. 20. Method for identifying traffic information, the method being characterized by comprising: extracting a traffic information message, including message segments, extracting a first component, including condition information, from the ex traffic information message. extract, from the first component, congestion information for a connection from the condition information; extract a second component, including condition information, from the extracted traffic information message; extract from the second component information speed for a connection from the condition information; extract a third component, including condition information, from the extracted traffic information message; extract, from the third component, time travel information to a link from the condition information; identify, on the basis of the extracted information, information from traffic jam, speed information, and travel time information for the call. 21. Apparatus for identifying traffic information, the apparatus being characterized by comprising: an interface configured to receive traffic data, including a first identifier, information corresponding to the amount of time currently required to traverse a particular connection, and information that correspond to a location associated with the particular bond; A processor configured to: determine current travel time information based on the information included in the received traffic data, determine whether the received traffic data includes an amount of time based on the information included in the received traffic data. which correspond to the location corresponding to the particular connection; and identify traffic information based on the determined current travel time information and determined location information. Apparatus according to claim 21, characterized in that the processor is configured to receive traffic data, including information corresponding to a version number of the information reflected in the traffic data, where the version number is associated. - given a specific data syntax, where any of several syntaxes can be used. Apparatus according to claim 21, characterized in that the processor is configured to receive information that corresponds to a message management structure including information that corresponds to a generation time of information reflected in traffic data. Apparatus according to claim 21, characterized in that the processor is configured to receive information corresponding to a length of the received data. Apparatus according to claim 21, characterized in that the processor is further configured to: determine the amount of travel time for a particular connection only if the first identifier allows a determination that the traffic data is relate to a current travel time for a particular connection.