WO2000038129A1 - Device for transmitting route recommendations and receiver - Google Patents

Abstract

The invention relates to a device for transmitting route recommendations of at least one public transport network to receivers. The coding is carried out by means of at least one location databank which displays at least parts of the traffic network.

Description

Device for the transmission of route recommendations and recipients

The invention relates to a device for transmitting route recommendations to at least one network of public transport to receivers and a receiver for route recommendations.

An obstacle to the use of public transport is often the lack of knowledge of the individual lines, their transfer points and the cycle times of the individual lines. The carriers of these public transport systems issue suitable route inquiries via the Internet or via T-Online. However, this generally requires a computer on the receiving end that is suitable for these types of communication.

The object of the present invention is to transmit such route recommendations if necessary in such a way that they can be received in a simple manner by many receiving devices. In the device according to the invention, this object is achieved in that coding is carried out by means of at least one location database that maps at least parts of the traffic network. A first embodiment of the device according to the invention consists in that data protocols provided for the transmission of digitally coded traffic reports (TMC) are used. In particular, it is provided that data protocols provided for diversions are used.

In a second embodiment of the device according to the invention, an RDS-ODA protocol is used for the transmission.

The device according to the invention has the advantage that the route recommendations can be received and decoded by a large number of receiving devices. Car radios are currently designed to receive digitally coded traffic reports - both in connection with RDS (radio data system) and DAB (digital audio broadcasting). Since there is no return channel here, this group of receivers will essentially use the transmission of route recommendations that are of interest to many users of such receivers, for example for trade fair visitors arriving by motor vehicle, the recommendation to visit a parking space on the outskirts and one or use multiple lines of public transportation. The invention can also be used with other mobile radio media, such as GSM, SWIFT, UMTS.

The device according to the invention also has the advantage that the known receivers, which are inexpensively manufactured in large numbers, can also be used for receiving route recommendations from public transport networks, and can also be linked to the road network. For this purpose, it is provided in the device according to the invention that for the transmission of travel route recommendations, Different locations of stored locations relate to locations, records of those locations that have at least one neighboring location in at least one of the other location databases contain at least one reference to at least one such adjacent location by means of a cross-reference.

With this development, it is then possible, for example, that a route recommendation describes a route to be covered by the motor vehicle up to a so-called park and ride parking lot and a subsequent route by public transport.

In addition, suggestions are already known in the TMC system not only to broadcast these from radio stations, but also to send them to the devices in each case on demand via mobile radio networks. In this case, specific inquiries can be answered by transferring route recommendations.

By coding the route recommendations according to the TMC system, further functionalities known in the TMC system or feasible by a registered RDS-ODA application are available, for example the management of traffic reports, namely storage in the memory and deletion when a message is out of date . It is also possible to output the decoded message using a speech synthesizer in a language that is understandable to the user.

If the receiver is installed in a vehicle that has a location system (for example GPS) or a navigation system, the route route recommendations can also be selected in accordance with the selection of the traffic reports in such a way that the receiver only receives those route route recommendations that are likely to be of importance to the user.

The device according to the invention also has the advantage that for route recommendations, for which data from road networks are also required, for example the flow of traffic on the streets and highways is taken into account, the data automatically acquired for the TMC system or similar systems can be used.

As a rule, the route recommendations are longer than a traffic message transmitted by the TMC system, e.g. traffic jam, 5 km in length, A7 motorway, Hildesheim junction. Therefore, according to a further development, it is provided that the route recommendations are transmitted as multi-group messages.

An advantageous receiver for route recommendations of at least one public means of transport consists in that at least one location database which depicts at least parts of the traffic network is provided for decoding in the receiver. Such a location database is preferably stored on an exchangeable data carrier, so that the user of a recipient has the most interesting traffic networks available to him, without having to purchase location databases for all traffic networks, for example a country.

However, the receiver according to the invention can also be designed such that the location database can be updated via an air interface. In an advantageous embodiment of this receiver, devices for managing and decoding digitally coded traffic reports (TMC) are provided for managing and decoding the route recommendations. For linking to other location databases, the receiver according to the invention can provide that at least parts of a further location database that does not contain locations listed in the location database that maps the network, and that codes for the locations of the location database and the further location database are combined in a common location database .

Exemplary embodiments of the invention are shown in the drawing using several figures and are explained in more detail in the following description. It shows:

1 shows a multi-group message for the implementation as an RDS-ODA application, which contains a route recommendation,

2 is a schematic representation of a line plan,

3 shows a multi-group message for the implementation as a TMC application, which contains a route recommendation, and

Fig. 4 shows a section of a location database for the device according to the invention.

FIG. 2 shows an example of a route network that partially extends through the area of a large city 1 and partially through the surrounding area 2. A tram line 3 leads from a first end point 6 via stops 7, 8, 9, 10 to a second end point 11. Stop 8 is a transfer point to a bus line with end points 12, 15 and further stops 13, 14. Stop 10 serves as a transfer point to a P + R car park at the junction of a motorway 5, of which further junctions 16, 17, 18 are shown. The route network shown can be coded in the same way as the road networks in the TMC system, that is, location databases, as described in the ALERT C standard, list the individual locations in connection with a line, with each location, for example, to the stop 7, a predecessor 6 and a successor 8 are provided as a cross-reference. Since the transfer point 8 is also a location on the bus line 4, additional referencing takes place here, as is shown, for example, in patent application 196 06 010.

If, for example, lines 3, 4 of the public transport network are shown in a location database specially provided for this purpose or integrated into an existing location database, while highway 5 is stored in a conventional location database within the TMC system, corresponding cross-references can be made at location 10 in each case indicate the other route (highway or tram line). This means that a message that reads, for example, "use the motorway to junction 10, then change to tram line 3 in the direction of end stop 6 to transfer point 8 and then use bus line 4 in the direction of end point 12 to stop 13" with those in the TMC - System-standard protocols or protocols defined in the context of ODA applications are coded and transmitted to the recipient, who can then use his location database (s) to encode and convert them into text or speech.

Overall, a message serving as a travel recommendation can have the following message elements:

Message element meaning

Destination location code in TMC location database, usually a so-called point of interest (POI);

Coding: location code (eg "FAIR")

Transport means of transport of the route network

(e.g. subway, S-Bahn, bus, ...)

Coding: part of the location code

Line designation indicates the line in the route network

(e.g. "S6")

Coding: part of the location code

Line end point specifies the end stops of lines in order to be able to indicate the direction of travel. Serves the user

Orientation when changing the

Means of transport.

Coding: location code

Stop / Ummsteig indicates the point of entry or departure at which the means of transport can be boarded or left

(e.g. stops or train stations)

Coding: location code

Cycle time gives the average time interval between the

Departure times of the means of transport

Coding: 3 bit (example)

000 no 100 15 min

001 1 h 101 10 min

010 0.5 h 110 5 min

011 ^• 20 min 111 2 min

Period specifies the period in which the above Cycle time applies (e.g. from <hh: mm> to <hh: mm>)

Coding: 2x8 bit (example) according to ALERT C multi-group messages,

Label 7/8

Total trip time gives the planned trip time for the entire trip recommendation in

Minutes Coding: 4 bit (example)

0000: none 0110: 30 1100: 60 0001: 5 0111: 35 1101: 70 0010: 10 1000: 40 1110: 80 0011: 15 1001: 45 1111: 90 0100: 20 1010: 50 0101: 25 1011: 55 total costs / Tariff zone gives the total price for the

Recommended route (e.g. in [DM] or as a tariff zone in one

Transport network) .

Coding tariff zone: 3 bit (example)

000: not specified ...: ...

001: Zone 1 111: Zone 7

010: Zone 2

TypeTime specifies the coding types _. the

Departure time at:

Coding: 2 bit (example)

00: not specified

01: reference to CT signal (ALERT C), i.e. Difference time in <min> (see DE 42 08 277 A1: CT + 2n; n in 6 bit)

10: Indication of the departure time in the

CT format (ALERT C) with 11 bits

11: Indication of the period (see above) and the cycle time (see above) with a total of 19 bits

When coding after 10/11, the

Number of transfer points can be reduced accordingly.

Departure time gives the departure time of the

Means of transport

Coding: see <TypeTime> Depending on the version in detail, the amount of information to be transferred can also deviate from this table. In addition, because of the very compact coding, not all message elements need to be transmitted. For example, message elements such as means of transport, line name, line end point for decoding can be taken from the location database.

1 shows an example of a message from an RDS-ODA application that occupies five groups and is suitable for coding five transfer points. Each of the groups is led by a header consisting of a bit T, a bit F, three bits CI, a bit 1 or 0 and a further bit. Bit T means the type of message (for messages according to ALERT: 0 = ALERTC, 1 = ALERTplus). For this RDS-ODA application, T = 0 is set. Bit F is used to subdivide into single (C = 1) and multi-group messages. Further components of the header are CI = Continuity Index and SG = Second Group Indicator, which, however, need not be explained to understand the invention. The bit at position Y15 identifies the first group of a message.

Each group has a length of 37 bits, which are designated in the example with X4 to X0, Y15 to 0 and Z15 to Z0.

In the first group, bits Y13 to Y11 are provided for the number of transfer points. In bits Y10 to YO there is a so-called event marking that this message represents a travel recommendation FE. This is followed by the location of the start S, for example the location code for location 10 when there is a recommendation to leave the motorway at 10 (FIG. 2) and continue on the tram. In the second group, Y13 to Y12 indicate that it is the second group. This is followed by the destination information Z and the location code of the first transfer point U1, which extends into the third group. The location code of the changeover point U2 is then transmitted (bits Y7 to Z8) and the location code of the changeover point U3 (bits Z7 to ZO and bits Y11 to Y4 of the next group). Finally there is the location code of a changeover point U5, which is also partially transmitted with the fifth group. Subsequently, the travel time T, the tariff zone TZ, the time type TYPE and the departure time ST are transmitted, whereupon one bit remains free at ZO of the fifth group.

FIG. 3 shows a route recommendation similar to that of FIG. 1, but the coding is in a form compatible with RDS-TMC, in which case only a maximum of four changeover points U1 to U4 can be coded. The transmission of additional information is also limited to one entry, in the present example to the train sequence ZF. According to ALERT, the individual location codes are identified by labels. Label 11 means the destination, label 10 a waypoint and label 6 additional information. In addition, use is made of the so-called "silent event (1907)" in the example shown in FIG. 3. The link to the "normal" TMC message is made via the location code S transmitted in the first group. This is the place where a transition to public transport is appropriate.

Fig. 4 shows parts of a location database for public transport in the Hanover area. The location codes (LocCode) 45004 to 46009 refer to an S-Bahn line, which has the "Road No." 4 is assigned. Location code 22001 relates to a location (point) on road No. 2, which is the federal road B2. The name of this place is "airport". "ÖV-Point" is entered as information on the type of location (LocType) for the locations on the S-Bahn line, the location type "Line" for the S-Bahn line overall in one direction. A blurred area - hence the type of place "Fuzzy" - with the location code 41922 characterizes the area that is to be counted as part of the operation of public transport.

As usual in location databases, the name of the location type (RName), one or two names (Name, Name2) and references to other location codes (Offset +, Offset-, RefL and RefA) are given for the individual location codes where applicable. In order to link the network for public transport with the road network, an "intersection code" is specified for some of the location codes, for location code 22001 a reference to location code 45775 and vice versa.

A travel route recommendation transmitted according to the TMC standard is then, for example, as follows:

"A7, Kassel motorway in the direction of Hanover, between the Hildesheim-Drispenstedt junction and the Hannover-Ost motorway junction, <unspoken event>" (used to assign the normal fault message).

"Detour for travelers in the direction of Hannover-Messe, drive via the Hildesheim-Drispenstedt junction to P&R Platz Hildesheim-Flughafen and change to S-Bahn line 4, in the direction of Hannover to Kreuzstrasse stop and change to bus line 78 in the direction Laatzen to the Messe stop, departure every 10 minutes. " Since traffic reports often occupy more than one group, so that within a sequence of five groups there is not enough space for the route route recommendation coded as a detour recommendation, in the example the route recommendation was initiated with a special traffic report with an unspoken event. This also has the advantage that an event based on public transport is not disturbed by users without a location database for public transport. This would be the case, for example, if a traffic jam ends behind a junction, which could be used as a detour with the motor vehicle, but a previous junction is more appropriate for a route recommendation using public transport.

Claims

Expectations 1. A device for the transmission of route recommendations of at least one network of public transport to receivers, characterized in that coding is carried out by means of at least one location database depicting at least parts of the transport network. 2. Device according to claim 1, characterized in that provided for the transmission of digitally coded traffic reports (TMC) provided data protocols. 3. Device according to claim 1, characterized in that an RDS-ODA protocol is used for the transmission. 4. Device according to claim 2, characterized in that data protocols provided for diversions are used. 5. Device according to one of the preceding claims, characterized in that for the transmission of route recommendations which relate to locations stored in different location databases, data records those locations which have at least one adjacent location in at least one of the further location databases contain at least one reference to at least one such adjacent location by means of a cross-reference. 6. Device according to one of the preceding claims, characterized in that the route recommendations are transmitted as multi-group messages. 7. Receiver for route recommendations at least one network of public transport, characterized in that at least one at least part of the traffic network mapping location database is provided for decoding in the receiver. 8. Receiver according to claim 7, characterized in that for the management and decoding of the route recommendations facilities for the management and decoding of digitally coded traffic reports (TMC) are provided. 9. Receiver according to one of claims 7 or 8, characterized in that at least parts of a further location database that does not contain locations listed in the location database depicting the network, and that codes for the locations of the location database and the further location database are combined in a common location database become. 10. Receiver according to one of claims 7 to 9, characterized in that a device for outputting the route recommendations as text, language and / or graphics is provided using transfer points. 11. Receiver according to one of claims 7 to 10, characterized in that the location database is stored on an exchangeable data carrier. 12. Receiver according to one of claims 7 to 10, characterized in that the location database can be updated via an air interface.