IES84301Y1 - Travel information system that caters for a multiplicity of travel modes - Google Patents

Abstract

ABSTRACT According to the invention the travel information system will 1. Produce specific details regarding each point in the underlying database, these including travel modes that service this point but also some recreational details that may be of interest to new residents or tourists. 2. A second section of the invention serves as a route planner. Each journey will be between two selected points and will commence either at, or as close as possible, to the estimated time of departure as selected by the user. The (2) points maybe inputted manually (via mouse click, a voice recognition system, touch screen interaction, typing or any other form of input past present and future) or alternatively inputting may only require (1) point as the other point may be implicit depending on location; e. g. using a touch screen unit in an airport the departure point would be implicit. An alternative on screen to allow a user full database access must also be included in this instance if lets say this particular user wants to plan a journey from some future departure point to a future destination point. 3. A third section of the invention allows a user to select travel modes and their respective schedules from the database and view these detailed schedules. The schedules show not only the times it begins its journey but also the times that it reaches its intermediary points if appropriate. The times between these points can be updated on a real-time basis.

Description

Travel Information System that caters for a multip_licig_v_ of travel modes BACKGROUND TO THE INVENTION The general consensus on a real long-term solution to the current perennial car-culture mentality in which we live is to increase the use of alternative travel means. Alternative travel means include cycling, walking, taxis, buses, trains, water taxis or any other form of trafiic limiting travel modes. However, to deter people from using their cars you must make alternative travel modes more accessible, attractive and convenient.

To make altemative travel means the first mode of choice for the everyday traveller a travel information system must exist, which makes the use of alternative travel modes more integrative, attractive and easier to utilize.

The preferred travel information system will consist of an interactive interface, with 2- way communication to a processing unit. The processing unit may possibly have access to a real-time database of travel information. On completion of triggered processing the processing unit will relay appropriate information back to the interactive interface.

FIELD OF THE INVENTION This invention relates to providing travel information on some geographic area/s to a user preferably on a real time basis.

SUMMARY OF THE INVENTION According to the invention the travel information system will produce travel infonnation for each geographic area (referred to as a point), these including travel modes that service this point (travel modes need not adhere to timetables e.g. taxis), cancellations, delays, disruptions and other additional data. Also some recreational details that maybe of interest to new residents or tourists can be made available to a user.

The travel information system has the ability to perform computational tasks on travel information. A section of the invention serves as a means of proposing journeys, each journey being possibly between two selected points. Another section of the invention allows a user to View travel modes and their respective schedules (if they adhere to schedules) from the database and view these detailed schedules. The schedules can show not only the times a route number begins its journey but also the times that the route number reaches its intermediary points if appropriate. The times between these points can be updated on a real-time basis.

BRIEF DESCRIPTION OF THE DRAWINGS A guide to the preferred forms of the invention will be described with reference to the accompanying figures.

Figure 1; How the invention maybe accessed.

Figure 2; How the invention maybe accessed showing the possibility of separate processing units being required depending on means of access.

Figure 3; Displays an implementation where the client stores the travel information system.

Figure 4; Displays the possibility of the either the database and/or processing logic/unit to be located on the front-end.

Figure 5; Displays a possible implementation where the client communicates with a database only.

Figure 6; Displays a possible implementation where the client communicates with a processing unit only.

Figure 7; Displays an implementation model whereby the travel information system would exist on disk storage.

Figure 8; Illustrates a preferred flowchart of the invention.

Figure 9; Shows a possible format for accepting user input for plotting a journey.

Figure 10; Shows and exemplifies a graph representing routes between two geographic points that could be produced by the processing unit.

Figure 11; Displays a possible format for displaying travel itinerary for a journey involving only one leg.

Figure 12; Displays a possible format for displaying travel itinerary for a journey involving more than one leg.

Figure 13; Displays a possible format for displaying “stop” information about particular geographic areas.

Figure 14; Displays a possible format for displaying timetable information.

Figure 15; Displays a possible format that allows users to request information on particular geographic areas.

Figure 16; Displays a possible format for displaying travel modes that service particular geographic areas.

Figure 17; Is a preferred database schema.

Figure 18; Displays a possible format for a DBA to perform real-time updates to the database.

Figure 19; Displays a possible format for providing ‘Help’ information.

DETAILED DESCRIPTION OF PREFERRED FORMS Possible methods of client access include PC terminals, laptops, notebooks, voice recognition units, touch screen units, audio units, handsets (phone, PDA, palmtops).

Clients will typically need a central processing unit of their own, a communication medium for input such as a screen and keyboard or selection devices, output capabilities such as a screen, printer or sound device with the possible capabilities of storage in the form of a hard disk, zip disk, compact disk, floppy disk or optical disk.

Preference is for one processing unit to cater for all clients and this processing unit being in communication with one database as seen in Figurel. Depending on client capabilities, design and technologies used this may not always be possible and a scenario as depicted in Figure2 would be developed where different clients would interact with different processing units. It will be respected that difi”erent processing units could alternatively access the same database. A bridge between any client and any processing unit (known as a server) may exist in the form of a LAN, web server or an appropriate bridging technology. The server may house the processing unit and the database of required information.

Figure 3 shows how the client could store the travel information system. The travel information system may or may not be updateable. Updateable travel information systems receive real-time or new data either through an “always on” wire or wireless connection to an information server or else connection to an information server via a physical socket, for example, a phone connection socket. Non-updateable travel information systems, for example, could be bought off the shelf but are given an expiry date i.e. a date when data on that travel information system will be invalid.

Figure 4 displays the possibility of the either the database and/or processing logic or unit to be located on the front-end. Using a meta-language for a travel information system would result in a similar model.

Figure 5 displays a model where a client of the travel information system would trigger requests from the database only. All data could be retrieved using database queries and displayed on database forms. Figure 6 displays an implementation model where a client of the travel information system would trigger requests from the processing unit only. All data could be “hardcoded” in the processing unit so no database would be involved in the implementation. Figure 7 displays an implementation model whereby the travel information system would exist on disk storage, for example, CD, DVD, 3.5” Floppy, Zip disk. The disk could be purchased off the shelf and designed in different versions, if required, for the multi- platform market. Subsequently the travel information system would exist as Figure 3.

Figure 8 shows the preferred implementation methodology of the invention with use of a control flow diagram.

A user of any embodiment can perform many computational tasks including the following I. Arranging a journey II. Search what travel routes serve an area IH. Request a schedule a) Input . Arranginga journey Once the system has been launched Figure 8 [1] a request is obtain from the user. If the request is to arrange a journey Figure 9 shows a possible format for accepting user input for plotting a journey. In order to plan a journey a user may have to select a departure point, destination point, day category and an estimated time of departure (ETOD). User preferences are also accepted at this stage of the control flow diagram. Each journey will be possibly between two selected points and will preferably commence either at, or as close as possible, to the estimated time of departure as selected by the user. The 2 points maybe inputted manually, for example, via mouse click, a voice recognition system, touch screen interaction, keyboard/keypad or alternatively inputting may only require 1 point or no points as the other point/s maybe implicit depending on location; such as using a touch screen unit in an airport arrivals lounge the departure point would be implicit ie. the airport.

Along with the area name extra information maybe submitted such as location type (station or stop, post code, place of interest, address) and location name, for example Area; City Centre (Dublin) Location Type; Place of interest Location Name; Millenium Spire An alternative onscreen to allow a user plan a journey from some future departure point to a future destination point ie. an onward journey may also be included.

The user can base proposed journeys upon options, preferences or criterion such as, a) Optimizing certain forms of travel, for example, walking and cycling with a choice of speed and max time tolerated b) Selecting means of travel, c) Selecting route types, for example, fastest, cheapest, least inconvenience, least interchange, least walking (1) Other individual requirements, for example, cannot use stairs, lifts, escalators, wheelchair required, baby-changing facilities, meals served. b) Data Processing Once a complete request is obtained from the user Figure 8 [2], in this instance a request for possible journeys between 2 points the backend processing unit Figure 8 [3] is triggered.

In order to compute journeys between geographic points a graph methodology may be used as in Figure 10. In order to produce the most cost-effective path, the system creates a graph possibly using a database of travel information data Figure 8 [4]. The processing unit must establish which is the best path across the graph/network. Nodes in the graph are referred to as vertices and they are connected via edges. Obviously every vertex has at least one link to another vertex otherwise it would be impossible to navigate to that vertex. Any two vertices may have an arbitrary amount of links between them, one representing each type of travel mode between the two vertices.

The composed graph is a directed graph. When a graph is produced by the system, that contains possible paths satisfying a users input, the graph can undergo further computation in order to arrange possible paths in order of best to worst, depending on a users input/preferences. If a user wants possible journeys to be returned starting with the shortest the composed graph with associated values on every edge, must under go computation in order to find the shortest route through it. This can be performed using Dijkstra’s algorithm or another shortest path finding algorithm. Supplied to Dijkstra’s algorithm are the destination and departure points and the created graph between the two points. Dijkstra’s computes the path of least cost across the graph. c) Output When possible journeys between two selected points are produced they can be returned to the user Figure 8 [5] in a format similar to that in Figure 11. Figure 11 shows an example of a journey only requiring one leg in order to complete it. Figure 12 shows an example of a journey requiring more than one leg. Any journey may have an arbitrary amount of legs. The output produced after planning a journey contains the itinerary for the user’s journey. lt is necessary for each leg to state its departure point, destination point and the mode of travel being used. Aligned with the departure point must be the departure time from the named departure point. Aligned with the destination point must be the arrival time at the named destination point.

Other alternatives that maybe available to a user on his/her communication unit regardless of embodiment would be Choose a different departure time Search Return Route o Plan another Journey Search what routes service an area Plan an onward journey Display earlier/later journeys Display earliest/latest journey Buy a ticket for this journey Help Print The following information must also be available on this page: The cost of each leg of the journey must be displayed as well as the total cost of the journey.

The length of time the journey will take.

Any other details relative to user favoritisms selected pre-search.

This page may also contain a map. On the map an animated presentation (possibly using Flash) may appear outlining the user’s journey route. The animation must illustrate the travel modes involved over each leg. When a route involves more than one leg each leg will have its own corresponding map displaying the appropriate illustration. When viewing the information on the output page the area names appear interactive. Initializing interaction with these names results in a pop-up window appearing containing a map of the area Figure 13. These maps are to highlight where the allocated travel mode for this point is. All route numbers contained on the output page are interactive. If the user initializes interaction with these route numbers the travel information system brings them to a new page containing the schedule details for that route and the named departure stops as seen in Figure 14.

For any proposed journey produced by the system the facility to purchase a ticket for this journey exists. This integrated ticketing facility, which on receipt of payment by credit card, would produce a unique “ticket number” which when quoted, would entitle the traveler access to the required mode of transport to complete a leg of a journey. The option of having one ticket number to complete journey or having a different ticket number for each leg (if there is more than one leg in the journey) exists.

. Search what travel routes serve an area If there is a request from the user to search what routes serve an area all points in the travel information system are retrieved. The user can select desired area name in a similar format to Figure 15. Alternatively point selection maybe completed using an interactive map. On selection of a point name, all travel modes associated with that point are retrieved and displayed similar to Figure 16. All route numbers contained on this page are interactive. If the user initializes interaction with these route numbers the travel information system brings the user to a new page containing the schedule details, if applicable, for that route and the named departure stops similar to Figure 14.

Any embodiment may host a departure board facility whereby the user can select a desired area name as above, a time and other required details and a list of travel modes departing from the chosen area are listed with respective departure times.

Any embodiment may host an arrivals board facility whereby the user can select a desired area name as above, a time and other required details and a list of travel modes arriving to the chosen area are listed with respective arrival times.

HI. Request a schedule lfthere is a request from the user to view a schedule, a new page containing the schedule details for that route and the named departure stops as seen in Figure 14 is produced.

Database requirements: In order to perform any computational request from a user constant interaction with a database maybe required. Figure 17 represents a preferred database schema for the invention. The database can be implemented as a relational database that is used to store the points, route numbers, route times, route journeys and the links between the different points. Primary keys can be installed in tables that are referenced by a foreign key constraint. Additional information maybe stored in the database. This may include geological information, historical information, accommodation availability, places of interest, places to eat, entertainment and other such information that maybe of interest with also the possibility to purchase or book tickets where applicable.

Database updating allows such a travel information system to be real-time. Ideally all embodiments must be engineered to be real time systems. Thus the system must be able to incorporate with ease any new journey times that are a result of “real-time” events occurring. Events such as traffic accidents, extra heavy trafiic, bus lane or track closures can have a serious affect on journey times. Other occurrences can have the opposite affect and result in a journey time being shorter. Given the stochastic and time- dependent nature of travel times in transit, real-time information about the transit service will assist passengers in making the best possible path choices. Should a DBA (database administrator) have a requirement to perform “real-time” updates, database forms are included to aid with the update development process as seen in Figure 18 Access to real- time data may be displayed using a complete interactive real-time map, pinpointing the area of unusual activity. Real-time data may also be accessed via text only i.e. real—time delays listed on page/s. Requests such as the plotting of a journey, searching what travel routes serve an area, and requesting a schedule would all involve interrogating a real—time database.

In all embodiments a comprehensive help tool maybe made available to users. The help tool may contain complete information on using the travel information system. The user should only have to perform some simple interaction to be brought to an all—inc|usive help section. This maybe in the form of a video or animation or may simply be in text only format as in Figure 19.

All embodiments may have a mu|ti—lingua| facility, which allows users to request and receive information in the language of their choice.

All embodiments may have a visually impaired facility whereby text and or maps are enlarged and graphics are reduced.

All embodiments will have travel facility maps. Examples of these include a map that . Displays all car parks with the possibility of displaying amount of spaces available at the particular time 2‘ Displays all taxi ranks and pickup points . Displays bicycle parking facilities and cycle lanes

Claims (5)

Claims

1. A travel information computer apparatus, comprising a central processing unit and an associated memory, a user input and display unit, both of which are connected to the central processing unit, the user input being linked to a suite of software modules stored in the memory, in which at least one software module: upon user selection of any geographical area, retrieves database listing of travel modes which service the selected area; calculates possible travel routes between geographical areas based upon user input, with defaults existing if input is optional; creates schedules for the user selected travel modes, the schedule containing departure and arrival times at listed geographical points on the chosen route; generates and displays interactive and/or static maps and/or visual messages detailing disruptions such as cancellations, delays, non-availability of the chosen travel mode; computes and displays arrival/departure time board schedule for all applicable selected travel modes in the selected geographical area at any given time; includes display language option; includes a help facility; includes a ticket booking facility for the chosen travel modes on the chosen routes, with a real time link to the transport mode carriers database; includes a visually impaired accessibility option; includes real time link to municipal car park management system database to quantify availability; compiles and displays tourist information for the chosen geographical area of the travel route.

2. A travel information system as claimed in claim 1 wherein the system modules can be accessed locally or remotely via a communication device allowing user data input/output by means of text, graphics, sound or touch screen imagery, these remote communication devices being updateable on a real time basis or using an offline version of the travel information system with disk storage.

3. A travel information system as claimed in claim 2 wherein the system module’s connections to external databases can be continually updated online for exact information or periodically updated on an offline basis.

4. A computer program which when run on a computer is adapted to carry out the functions as stated in claim 1.

5. A travel information system as herein described with reference to and as shown in the accompanying drawings. DRAWINGS: