Intermodal Journey Planner Business Rules · Journey Planner Business Rules JP Business Rules Page 2 of 168 2005-2010 Mentz Datenverarbeitung GmbH. All Rights Reserved. 2010-01-11

Journey Planner Business Rules

JP Business Rules Page 1 of 168 2005-2010 Mentz Datenverarbeitung GmbH. All Rights Reserved. 2010-01-11

Intermodal Journey Planner

Business Rules

Content

1 Introduction__________________________________________________________ 8 1.1 Introduction to Inter-modal Journey Planning ___________________________________ 8 1.2 Purpose of this Paper _____________________________________________________ 8 1.3 Naming EFA ____________________________________________________________ 9 1.4 Used Examples and Links _________________________________________________ 9

2 Data _______________________________________________________________ 10 2.1 General Data Flow ______________________________________________________ 10 2.2 Model of Stops and Interchange ____________________________________________ 11 2.3 Location hierarchy _______________________________________________________ 17 2.4 Geographic Data ________________________________________________________ 21 2.5 POIs _________________________________________________________________ 23 2.6 Addresses _____________________________________________________________ 26 2.7 Referencing of Links _____________________________________________________ 26

3 Basic Architecture ___________________________________________________ 29 3.1 Standard Configuration ___________________________________________________ 29 3.2 Basic modules of the Inter-modal Journey Planner _____________________________ 29 3.3 The Layered Architecture _________________________________________________ 31 3.4 Operational Requirements ________________________________________________ 35 3.5 The XML-Interface ______________________________________________________ 36 3.6 The Session Technique __________________________________________________ 42

4 Routing in Space and Time ____________________________________________ 44 4.1 The Fundamental Algorithm _______________________________________________ 46 4.2 Frequency calculation ____________________________________________________ 60

4.2.1 Frequency Leg _______________________________________________________ 60 4.2.2 Penalty Frequency Leg _________________________________________________ 60 4.2.3 Display Rules ________________________________________________________ 61 4.2.4 Penalty Frequency Buffer _______________________________________________ 61 4.2.5 Frequency Calculation _________________________________________________ 62

4.3 Assigned stops _________________________________________________________ 64 4.4 Gain of processing speed by stop pre-selection ________________________________ 67 4.5 Showing Results ________________________________________________________ 75

4.5.1 The XML-Structure of the result __________________________________________ 75 4.5.2 Number of Trips, Collecting Journeys, _____________________________________ 75 4.5.3 Earliest and Latest Journey _____________________________________________ 77 4.5.4 Return Journey and Onward Journey ______________________________________ 79 4.5.5 Overview and Detail ___________________________________________________ 81 4.5.6 Hiding trips __________________________________________________________ 93



4.5.7 Printing the result _____________________________________________________ 94 4.6 Filters ________________________________________________________________ 99

4.6.1 Number of interchanges ________________________________________________ 99 4.6.2 Least Walking _______________________________________________________ 101 4.6.3 Line restrictions______________________________________________________ 102 4.6.4 Spatial filters ________________________________________________________ 111 4.6.5 Via London _________________________________________________________ 122 4.6.6 Mobility impaired _____________________________________________________ 123 4.6.7 Footpath speed ______________________________________________________ 128

4.7 Footpaths ____________________________________________________________ 131 4.7.1 General strategies for point to point journey planning ________________________ 131 4.7.2 Addresses based on house number intervals _______________________________ 143 4.7.3 Optimised walking for stop-to-stop journeys ________________________________ 144 4.7.4 Point POIs _________________________________________________________ 144 4.7.5 Area POIs __________________________________________________________ 145 4.7.6 Post codes _________________________________________________________ 147 4.7.7 Journey planning with centre of locality ___________________________________ 148 4.7.8 Input on map ________________________________________________________ 150

4.8 Bicycle access ________________________________________________________ 158 4.8.1 Bicycle routes _______________________________________________________ 158 4.8.2 Bike and Ride _______________________________________________________ 161

4.9 Park & Ride, Kiss & Ride, Taxi & Ride ______________________________________ 165 4.10 Demand responsive services _____________________________________________ 167 4.11 Real-Time ____________________________________________________________ 167

5 Specification of Origin and Destination _________________________________ 168 5.1 General Technique _____________________________________________________ 168 5.2 Localities _____________________________________________________________ 168 5.3 Stops ________________________________________________________________ 168 5.4 Addresses ____________________________________________________________ 168 5.5 POIs ________________________________________________________________ 168 5.6 Input on Maps _________________________________________________________ 168



Document history Document version

Date Name Revisions cause

0.1 01/01/2005 M Initial Version

0.2 07/03/2005 GW Privat Transport

0.3 10/03/2005 M More algorithm

0.6 24/04/2005 MH Graphs included

0.7 25/03/2005 M More algorithm

0.8 01/04/2005 MH Graphs included

0.9 08/04/2005 MH Point-to-Point journey planning

11 27/04/2005 MH Footpath speed, Hiding trips, update footpath description,

bike transport rules Munich, Via stop time Stuttgart, tariff zone

filter

13 16/08/2005 WK Locality journey planning explained in more detail

14 01/09/2005 MO Locality naming (Chapter 2.3)

15 26/09/2005 MO Locality naming without parents

16 03/10/2005 M Footpath rules and chapter 5

17 04/10/2005 AK Version for TfL

18 04/10/2005 OP empty chapters restored (had been deleted in previous

version)

19 16/22/2005 OP

FW

Added parameters in section 5.5.6 Hiding trips

Via options extended (Chapter 5.6.3.3)

20 01/03/2006 LB Chapter 2.3: integration of unitary counties

21 ? ? ?

22 30/01/2007 LB Chapter 5.1: The fundamental Algorithm

23 13.06.2008 OP Corrections to escalation strategy

24 20.11.2008 LA Complete Update: IJP into EFA, Introduction, Removed

Section “Monitoring”

25 28.11.2008 M Via

26 18.12.2009 OP Least Interchange

27 11.01.2010 OP Least Walking



Figures

Fig. 2-1 Data flow ................................................................................................................................. 10 Fig. 2-2 Logical model of the DIVA stop “Wimbledon” ......................................................................... 11 Fig. 2-3 Geographic locations of the different areas and stop points ................................................... 12 Fig. 2-4 Map with footpath and footpath description to Wimbledon ..................................................... 13 Fig. 2-5 Overview of footpath matrix .................................................................................................... 14 Fig. 2-6 Footpaths between areas at the same level ........................................................................... 14 Fig. 2-7 Footpaths between areas connected with elevators ............................................................... 15 Fig. 2-8 Footpaths between areas connected with stairs ..................................................................... 15 Fig. 2-9 Locality tree ............................................................................................................................. 19 Fig. 2-10 Locality tree London .............................................................................................................. 20 Fig. 2-11 POI as Origin or Destination ................................................................................................. 23 Fig. 2-12 POI as areas or points in DIVA Geography .......................................................................... 23 Fig. 2-13 POIs as a helpful orientation points on maps ....................................................................... 24 Fig. 2-14 Example of parks as an area on a map ................................................................................ 25 Fig. 2-15 Example of a buildings as areas on a map ........................................................................... 26 Fig. 2-16 Link between two stops before referencing .......................................................................... 27 Fig. 2-17 Link between two stops after referencing ............................................................................. 28 Fig. 3-1 System configuration ............................................................................................................... 29 Fig. 3-2 Journey Planner architecture .................................................................................................. 30 Fig. 3-3 EFA layered architecture ......................................................................................................... 32 Fig. 3-4 HTML application process ....................................................................................................... 37 Fig. 3-5 Public user interface ................................................................................................................ 39 Fig. 3-6 Call centre interface ................................................................................................................ 40 Fig. 3-7 Interface for visual impaired users .......................................................................................... 41 Fig. 4-1 Description of the three dimensional Dijkstra algorithm .......................................................... 46 Fig. 4-2 Timetable graph ...................................................................................................................... 48 Fig. 4-3 Simple Interchange ................................................................................................................. 48 Fig. 4-4 Complicated Interchange ........................................................................................................ 49 Fig. 4-5 Access Network ....................................................................................................................... 50 Fig. 4-6 Interchange Network ............................................................................................................... 50 Fig. 4-7 If the lead time is large enough, the tree branch may be broken ............................................ 52 Fig. 4-8 Some times, a trip, which arrives later, is needed .................................................................. 53 Fig. 4-9 Alternatives to the fastest journey ........................................................................................... 55 Fig. 4-10 Forward and backward search .............................................................................................. 56 Fig. 4-11 Example overrun time ........................................................................................................... 57 Fig. 4-12 Single start and destination points ........................................................................................ 64 Fig. 4-13 Route between DIVA Stops .................................................................................................. 65 Fig. 4-14 Multiple start and destination points ...................................................................................... 66 Fig. 4-15 Origin and Destination districts with vicinity areas ................................................................ 68 Fig. 4-16 Origin and destination counties with vicinity areas ............................................................... 69



Fig. 4-17 Origin and destination districts and vicinity areas in London with corridor ........................... 70 Fig. 4-18 Example route from Southend-on-Sea to London Harrow .................................................... 71 Fig. 4-19 Example vicinity areas for route from Southend-on-Sea to London Harrow......................... 72 Fig. 4-20 Common data server: route information Bus 21: Local bus .................................................. 73 Fig. 4-21 Common data server: route information Bus x1: Regional Bus ............................................ 74 Fig. 4-22 First request .......................................................................................................................... 76 Fig. 4-23 Following request .................................................................................................................. 77 Fig. 4-24 Earliest and latest .................................................................................................................. 78 Fig. 4-25 Buttons for onward and return journey .................................................................................. 79 Fig. 4-26 Onward Journey .................................................................................................................... 80 Fig. 4-27 Return Journey ...................................................................................................................... 81 Fig. 4-28 Result overview ..................................................................................................................... 82 Fig. 4-29 Result details ......................................................................................................................... 83 Fig. 4-30 Overview and details in one page ......................................................................................... 84 Fig. 4-31 Overview VVS ....................................................................................................................... 85 Fig. 4-32 Overview map ....................................................................................................................... 86 Fig. 4-33 Detailed tariff information ...................................................................................................... 87 Fig. 4-34 Journey details ...................................................................................................................... 88 Fig. 4-35 Map of the departure stop ..................................................................................................... 90 Fig. 4-36 Detailed information with hints .............................................................................................. 91 Fig. 4-37 Detailed information with hints in Frankfort ........................................................................... 92 Fig. 4-38 Parameters for longest wait time at an interchange point ..................................................... 94 Fig. 4-39 TfL implementation of print function ...................................................................................... 95 Fig. 4-40 MVV implementation of print function ................................................................................... 96 Fig. 4-41 Print output MVV: overview of all trips .................................................................................. 97 Fig. 4-42 Print output MVV: details about one trip ............................................................................... 98 Fig. 4-43 Option selection: number of interchanges ............................................................................ 99 Fig. 4-44 Option selection: least interchanges ................................................................................... 100 Fig. 4-45 Options: selecting/deselecting means of transport ............................................................. 102 Fig. 4-46 Journey using Tube ............................................................................................................. 103 Fig. 4-47 Journey excluding tube ....................................................................................................... 103 Fig. 4-48 Route 1 operated by Carousel Buses ................................................................................. 104 Fig. 4-49 Route 1 operated by Walters Limousines ........................................................................... 105 Fig. 4-50 Journey results Route 1 operated by Carousel Buses ........................................................ 105 Fig. 4-51 Journey results Route 1 operated by Walters Limousines .................................................. 106 Fig. 4-51 Selection of operators .......................................................................................................... 106 Fig. 4-52 Options: selecting/deselecting the ICE ............................................................................... 107 Fig. 4-53 Journeys with ICE ............................................................................................................... 108 Fig. 4-54 Journeys without ICE .......................................................................................................... 108 Fig. 4-55 Data set entry in extra file ................................................................................................... 109 Fig. 4-56 Parameters Privat Transport ............................................................................................... 109 Fig. 4-57 Journey without bike transport in Munich ............................................................................ 110 Fig. 4-58 Journey with bike transport in Munich ................................................................................. 110 Fig. 4-59 Journey request with bike transport within peak hours ....................................................... 111



Fig. 4-60 Personal schedule with routes through different zones ...................................................... 112 Fig. 4-61 Selected Tariff zone ............................................................................................................ 113 Fig. 4-62 Personal schedule with tariff zone filter............................................................................... 114 Fig. 4-63 Cut-out of DIVA Stop management ..................................................................................... 115 Fig. 4-64 Via Option (1) ...................................................................................................................... 116 Fig. 4-65 Via Option (2) ...................................................................................................................... 116 Fig. 4-66 Via Option (3) ...................................................................................................................... 117 Fig. 4-67 Journey request with via stop in Esslingen ......................................................................... 118 Fig. 4-68 Journey results with via stop in Esslingen .......................................................................... 118 Fig. 4-69 Via-Journeys, no fare computation possible ....................................................................... 119 Fig. 4-70 Via-Journey with dwell time (Request) ................................................................................ 120 Fig. 4-70 Via-Journey with dwell time (Result) ................................................................................... 121 Fig. 4-71 Journey request ................................................................................................................... 122 Fig. 4-72 Journey results without Via London option ......................................................................... 123 Fig. 4-73 Via London Option ............................................................................................................... 123 Fig. 4-74 Journey results with Via London option .............................................................................. 123 Fig. 4-75 Journey request without options ......................................................................................... 124 Fig. 4-76 Result overview without options .......................................................................................... 125 Fig. 4-77 Result details without options .............................................................................................. 125 Fig. 4-78 Mobility impaired options ..................................................................................................... 126 Fig. 4-79 Result overview with options ............................................................................................... 127 Fig. 4-80 Result details with options ................................................................................................... 127 Fig. 4-81 Input of journey request ...................................................................................................... 128 Fig. 4-82 Walking Options: footpath speed fast .................................................................................. 128 Fig. 4-83 Details of the journey result with footpath speed fast ......................................................... 129 Fig. 4-84 Walking Options: footpath speed slow ................................................................................ 129 Fig. 4-85 Details of the journey result with footpath speed slow ........................................................ 130 Fig. 4-86 DIVA Geo with single houses .............................................................................................. 132 Fig. 4-87 Door-to-Door journey planning ............................................................................................ 133 Fig. 4-88 Protocol of the stop search in the vicinity of the address Grillparzerstr 18 .......................... 134 Fig. 4-89 Journey planner results ....................................................................................................... 134 Fig. 4-90 Parameter in the definition file ............................................................................................. 135 Fig. 4-91 Origin S, Destination D and the stops which are connected by walk .................................. 137 Fig. 4-92 Solution with walk only ........................................................................................................ 138 Fig. 4-93 Useless PT legs .................................................................................................................. 139 Fig. 4-94 Inter-modal solution with 6+1+1=8 mins journey duration .................................................. 140 Fig. 4-95 Inter-modal solution, passing M, but longer than walk sum ................................................ 140 Fig. 4-96 Mono-modal solution, walk to destination is faster than walk to stops ............................... 142 Fig. 4-97 inter-modal solution, overall walking time of PT journey is smaller than direct walk .......... 143 Fig. 4-98 Optimized walking at TfL ...................................................................................................... 144 Fig. 4-99 Modelling of POI area ......................................................................................................... 145 Fig. 4-100 Result of POI area modelling in the journey planner ........................................................ 146 Fig. 4-101 Alternative result of POI area modelling in the journey planner ........................................ 146 Fig. 4-102 Journey planning with POIs .............................................................................................. 147



Fig. 4-103 Journey planning with postcodes ...................................................................................... 148 Fig. 4-104 Journey planning with centre of locality ............................................................................ 149 Fig. 4-105 Link to network plan .......................................................................................................... 150 Fig. 4-106 Network plan ..................................................................................................................... 151 Fig. 4-107 Selection of origin on the network plan ............................................................................. 151 Fig. 4-108 Link to interactive map ...................................................................................................... 152 Fig. 4-109 Overview map ................................................................................................................... 153 Fig. 4-110 Selection of a particular point on the map ......................................................................... 154 Fig. 4-111 Submission of journey request .......................................................................................... 154 Fig. 4-112 Overview of journey results ............................................................................................... 155 Fig. 4-113 Details of journey results ................................................................................................... 156 Fig. 4-114 Area map with footpath to the selected point .................................................................... 157 Fig. 4-115 Input of a journey request ................................................................................................. 158 Fig. 4-116 Biclycle options in the request ........................................................................................... 158 Fig. 4-117 Bicycle route result details ................................................................................................ 159 Fig. 4-118 Bicycle route map .............................................................................................................. 160 Fig. 4-119 Bicycle route description ................................................................................................... 161 Fig. 4-120 Input of the journey request .............................................................................................. 161 Fig. 4-121 B+R Option in the journey request .................................................................................... 162 Fig. 4-122 Overview of journey results ............................................................................................... 162 Fig. 4-123 Details of journey results ................................................................................................... 163 Fig. 4-124 Bicycle map to the station ................................................................................................. 164 Fig. 4-125 Bicycle route description ................................................................................................... 164 Fig. 4-126 Door to Station journey with taxi – result details ............................................................... 165 Fig. 4-127 Door to Station journey with taxi – taxi route map ............................................................ 166 Fig. 4-128 Door to Station journey with taxi – taxi route description .................................................. 167



1 Introduction

This document explains the business rules of the mdv Journey Planner EFA.

It is a general description of the system features. However in the current document we are focussing on the Journey Planner in UK, being used by Traveline South-East. In start of 2009 2 more Traveline Regions will join the Journey Planner system: East Anglia and East Midlands.

1.1 Introduction to Inter-modal Journey Planning A user of public transport needs more information than a user of private transport. Examples of additional information generally required are:

• Where is the nearest stop and how can he find it?

• When does the service start and how long will the journey take?

• When is the last service?

• How much will it cost?

Scientific and market research has revealed that given the correct information, 10 percent more people could switch from private to public transport. The Intermodal Journey Planner (EFA) will enable a passenger to input an origin and destination, which can be a stop, station, address, street, crossing, or place of interest, by typing in the name or a point by clicking on a map. The journey planner will calculate the footpaths to all stops in the area, and thereafter provide the most suitable stop from which to begin the trip. This information will be displayed as a table of journey legs, a number of maps for the footpaths, and even walking descriptions between stops at change-over points. By utilising this information and providing it on a number of channels, including the Internet, WAP, SMS and PDA, more travellers should be encouraged to use the public transport services available.

If available the EFA will use real-time information too, to compute up-to-date journeys.

1.2 Purpose of this Paper This paper shall describe the behaviour of the EFA and explain the underlying business rules. It shows the details of the setting of parameters and explains the influence on the results. This can only be understood, if the reader understands the basic algorithms and the way different functions work together.



1.3 Naming EFA The Inter-modal Journey Planner was developed in Germany since 1983. The first public release took place in 1988 in Munich.

In these days, the system was named EFA (Elektronische Fahrplanauskunft) which means electronic timetable information. This name became a registered label, which belongs to the Munich Transport Authority (MVV, Münchner Verkehrs- und Tarifverbund). Until 2000 the system was owned by MVV, VVS (Verkehrs- und Tarifverbund Stuttgart) and mdv together. In 2000 mdv took over the economic rights and the intellectual property rights and became owner of the name EFA.

This paper will use the name EFA.

The first productive version of EFA in 1988 was version 2. A client server system was available with version 4. The main development with intermodality was subject of version 8.

With the current version 9 large emphasis was laid on parallel processing using multithreading techniques wherever possible.

1.4 Used Examples and Links

Many examples are used in this document. Examples of following Journey Planner customers are used:

Transport for London www.londonjourneyplanner.org

Traveline South East www.traveline.org.uk

Munich Transport Authority MVV www.mvv-muenchen.de

Stuttgart Transport Authority VVS www.vvs.de

Rhine/Main Transport Authority RMV www.rmv.de

Region Hannover Authority (Lower Saxonia, Bremen, Hamburg) www.efa.de

Journey Planner Baden Wurttemberg www.efa-bw.de

Journey Planner San Francisco Bay Area transit.511.org



2 Data

2.1 General Data Flow The following figure shows the data flow from the data import to the Journey Planner engine and to the end user.

Fig. 2-1 Data flow

Timetable data

Stops and Localities

GIS

Timetables Stops and Interchange Info

Timetableadmin

Stop admin

GIS admin

Conversion

Binary Data

Journey Planner

Internet

Customer Service

Internet

Real Time



The administration and collation of data is done using the DIVA system, which is a suite of programs specifically designed for the efficient management of high quality public transport data.

The stop data is the data set, linking timetables and geography together. The underlying model of stops is explained in the following section.

2.2 Model of Stops and Interchange Stops are the fundamental elements for data collation. In DIVA a stop may be broken down into three levels. This structure is explained in the following example based on the Wimbledon stop in London.

The whole “stop object” has the name “Wimbledon” and belongs to a certain locality. The stop Wimbledon is then divided in areas into a number of areas, which belong to particular modes of transport, bus, tram, etc. or to entrances. Areas themselves may then be divided into stop points.

Fig. 2-2 shows the logical model, of the Wimbledon stop and Fig. 2-3 shows its specific layout.

Fig. 2-2 Logical model of the DIVA stop “Wimbledon”

DIVA Stop DIVA Stop Areas DIVA Stop points

Wimbledon

1. Bus

2. Croydon Tramlink

3. Main Station Entrance

4. Undergroud

5. Booking Hall

6. BR (British Rail)

C P

20026

86286

86738



Fig. 2-3 Geographic locations of the different areas and stop points

Each DIVA area and each stop point has a coordinate and is linked with the underlying geographic network. This allows the computation of footpaths by the system. As a result, the system is able to compute a walking route from any given point to the appropriate stop and/or entrance. The system will find the nearest stops via routing computations over the geographic network.



Fig. 2-4 Map with footpath and footpath description to Wimbledon

In DIVA, special areas within a stop may be defined

• Entrances

• Park+Ride Places

• Bike+Ride Places

• Mezzanines

The first three types are needed in order to link with the street network (e.g. main station entrance). A person on foot can use an entrance. A Bike+Ride Place is a



point to store the bicycle and to continue the journey inside the building. The Park+Ride place is used for car access. Mezzanines are intermediate points to structure the building (e.g. booking hall).

Footpaths link all DIVA-areas within a building. Each DIVA-area has a level of altitude. It may have street level or –1, -2, etc. Because footpaths link DIVA-areas this may be an even level link or with a stair, an escalator, or elevator. This is coded in a matrix for each type of link. The following figures show the matrices for the Wimbledon example.

Fig. 2-5 Overview of footpath matrix

Fig. 2-6 Footpaths between areas at the same level



Fig. 2-7 Footpaths between areas connected with elevators

Fig. 2-8 Footpaths between areas connected with stairs

It is possible to compute routes within the building. These routes are necessary for interchanges. The possibilities for changing levels can be computed based on special user scenarios:

• Can use stairs (yes/no)

• Can use Escalators (yes/no)

• Can use Elevators (yes/no)

All combinations of the restrictions defined above are necessary. The wheelchair user needs elevators but the blind user with a guide dog will prefer stairs. In addition, the ability to use escalators is also a valuable comfort for the normal user.



The interchange footpaths are defined on time. Depending on a user profile factors for slow and fast may be applied. The interchange time will be composed out of this time and buffers, e.g. to take into account a delay of the incoming vehicle.



2.3 Location hierarchy Each stop is assigned to a locality. Localities are structured in the location hierarchy. The location hierarchy is structured as follows:

31 UK

1 England

2 Wales

3 Scotland

4 Northern Ireland

5 Isle of Man

6 Guernsey

7 Jersey

XX Admin Area: Counties (e.g. Buckinghamshire, Bedfordshire, Kent, London) and Unitary Districts (e.g. Milton Keynes, Luton, Medway)

XXX District (e.g. High Wycombe, Bletchley Park)

The data source is the National Public Transport Gazetteer (NPTG).In the set up phase, the items

• Admin areas and

• Districts

have been imported together with the localities.

Currently localities are updated once a week with the mdv program NPTG import.

The following table shows the main record of the NPTG data.



NPTG field Used in DIVA

National Gazetteer ID Yes, saved for import

Locality Name Yes

District ID Yes

Admin Area ID Yes

Locality Type No

Easting Yes

Northing Yes

Date of Last Change No

Date of Issue No

Issue Version No

In DIVA a tree structure is used to identify localities. It has an 8 digit district number and an 8 digit locality code. Both specify the locality. The structure of the district code is shown in the following table

• Country (3 digits)

o Admin area (2 digits)

District (3 digits)

The NPTG admin areas are mapped to the admin areas of the DIVA. There is a 1:1 assignment between DIVA districts and the districts or unitary units from NPTG.

Unitary district are treated like admin areas, they will always have a 000-district code.

The following figure shows an example of the structure of the codes.



Fig. 2-9 Locality tree

Each district has therefore a unique 8 character ID and each Locality has a NPTG ID.

31 Great Brittain

Country Admin Area (County / Unitary Districts)

District Locality

31 104 Bucking-hamshire

31 104 045 Chiltern

31 104 237 Wycombe

31 175 000 Milton Keynes

Bow Brickhill E0053441

Newport Pagnell E0053463

Olney E0053466

Bletchley Park N0064996

311 England

Milton Keynes E0039308

31 175 Milton Keynes

High Wycombe E0000708

Little Kimble E0059810

Ibstone E0043646



Each NPTG locality is a leaf of the location tree. Within the location tree, each locality belongs to a District, each District belongs to an admin area and each admin area belongs to a country, which is England, Scotland etc.

The following figure shows an example of the location tree of London.

Fig. 2-10 Locality tree London

DIVA and the Journey Planner need unique names. In the past, the data downloaded from the national database did not always follow these rules. If the Import procedure encounters non-unique names, they are made unique, using the following rules:

• Name as in NPTG: e.g. “Tenterden”.

• If the result name is not unique in all locations, then the abbreviation of the admin area is added in brackets: e.g. “Aldington” --> “Aldington (Kent)”, because there is a further Aldington in Worcestershire.

31 Great Brittain

Country County Borough Locality

31117 London 31117002 Camden

31117004 Hammersmith& Fulham

31117003 Hackney

Haggerston E0034350

Homerton E0034352

Kingsland E0034354

311 England



• If the result name still is not unique in the admin area, then the district name is added in brackets: e.g. “Stoke”, both in Hampshire --> “Stoke (Basingstoke)” and “Stoke (Havant)”.

• If the result name still is not unique in the district, then another locality nearby is searched on a map: e.g. “Hendra”, both in Restormel --> “Hendra (nr Newquay)” and “Hendra (nr St Dennis)”.

• If a name is twice in the NPTG, both with same coordinates, same admin area and same district, then a number sign will be added to one of it: e.g. there are two “Old Bosham” in West Sussex with the same data, one of it will be “Old Bosham #2”.

• There are some exceptions not covered by the rules above, which need a special rule: e.g. “Woodmanscote, Dursley” --> “Woodmanscote (Dursley)”.

2.4 Geographic Data The journey planner uses geographic data for routing, for finding the appropriate stops for a given origin or destination, and for the display of maps. Maps are created on-the-fly from vector data, the information about the computed trip is added to the map before the map is displayed.

The journey planner accesses the geographic data in a binary format. (which is suitable for this purpose). The geographic data is imported. Interfaces to common formats like Shape or MapInfo are available. Since data which was bought is in most cases incomplete for the purposes of Public Transport, an editor (DIVA Geo) is available to add missing items.

The basic data layer is the integrated network. This is a layer which consists of:

• the street network

• the rail network

• footpaths and cycle paths.

It consists of nodes and edges. The edges have attributes which define whether they can be used by:

• motorized traffic

• privileged motorized traffic

• bicycles

• pedestrians

• rail



• underground rail

Other attributes describe the type of the street or a speed class. An extra table for forbidden manoeuvres is needed. This network will be imported from external data (e.g. from Navteq). Missing objects, very often footpaths to access the stations, footbridges and tunnels are added.

This network will be linked with the stop points and the entrances as described above.

It is important that the links have so-called “permanent link IDs”. This means that the IDs are the same after an update of the GIS data. Only new links should have new IDs. This is guaranteed e.g. with data bought from Navteq.

To draw maps, additional layers are needed like

• rivers and water areas

• wood and parks

• land use.



2.5 POIs POIs have two representations in the system. They are

• Logical objects for origin and destination.

Fig. 2-11 POI as Origin or Destination

• Areas or points on the maps.

Fig. 2-12 POI as areas or points in DIVA Geography

Even if a POI is not used by a journey, it is a helpful orientation, to see it on the map. In the following figure, the POIs London Aquarium and Marriot Hotel are helpful orientation points.



Fig. 2-13 POIs as a helpful orientation points on maps

DIVA has tools, to administer POIs in the logical and in the geographic representation.

Points can only be displayed as symbols on the map. In addition, there are some POIs which represent landmarks and should be displayed as areas, such as

• Parks

• Cemeteries

• Large buildings

This type of POI is normally missing in the data bought from NavTech or a similar provider. Mdv can deliver area-POIs with the help of a subcontractor.



The following figures give examples for parks and buildings.

Fig. 2-14 Example of parks as an area on a map



Fig. 2-15 Example of a buildings as areas on a map

2.6 Addresses There are two ways to get address data

• The Navteq data contains address intervals for each street segment

• An extra layer for single houses can be bought

2.7 Referencing of Links The timetable, especially the routes, must be linked with the geographic data. This is achieved with two steps:

• Geographic referencing of stops

• Geographic referencing of route options



To show the geometry of a route, the path of a bus must obtain the geometry of the road. This is done with routing. The following figures show this process:

Fig. 2-16 Link between two stops before referencing



Fig. 2-17 Link between two stops after referencing

This process can be automated to a great extend. However, if coordinates of stops do not match roads, or if roads are missing in the GIS data the referencing will not be possible.



3 Basic Architecture

3.1 Standard Configuration The following figure shows a standard configuration

Fig. 3-1 System configuration

The shown configuration consists of a server farm with several servers and a server for administration.

The data administration team accesses the administration server via terminal server clients. The system administration and mdv must also have access to all servers via terminal server clients.

The administration server will be used as a test system too.

3.2 Basic modules of the Inter-modal Journey Planner The journey planner system itself is composed of several components, shown in the following figure.



Fig. 3-2 Journey Planner architecture

HTTP Server Watchdog

PT Kernel IT Kernel EFA Fares

Dispatcher

EFA PSched

Statistik Logger

Travel Agent

EFA TTB LVP SPAEFA SST

Distiller

CORBA CORBA CORBA

Mailslot Mailslot HTTP

Controls: PTKernel ITKernel EFAFares



3.3 The Layered Architecture The EFA Server itself has a layered architecture. The servers are parameter controlled. The program language is C++.

The system does not need the Microsoft Internet Information Server (IIS) or any other web server. It has its own built-in HTTP-Server. The reason for this design is:

• higher security because the server only accepts known requests and nothing else

• gain of performance, because the interface between the server and the application is much closer

• gain of performance by using special techniques such as caching of special requests.

However, the Journey Planner server can cooperate with an IIS or any other web server. In this case, the IIS would forward the journey planner requests to the EFA Server. This model is used when the journey planning system is part of a larger portal.

The following figure shows the layered architecture



Fig. 3-3 EFA layered architecture

The first layer is EFA HTTP Server. This layer analyses the requests and passes them on to the EFA Controler. If, for example, the download of an image or a static HTML-page is requested, the request will be handled in this layer.

The TCP/IP layer is situated within the HTTP-layer. This layer has a so-called “listener”, which accepts incoming requests; it creates a “thread” which handles the request until the answer is complete and sent to the user.



The HTTP-server can accept a maximum number of threads, currently set to 100. If more than the maximum number of requests tries to access the server, the server will answer “ERROR 503”

The lifetime for a thread is very short if it is a request for an image. If it is a TRIP_REQUEST, it will be longer, depending on the time the EFA Controller needs to process the request. It is natural that with increasing load, the number of threads will increase due to a larger number of incoming requests and due to increasing process time.

The EFA Controller creates a “session” for each new request. This is needed to avoid the transportation of the context of a request. If a user requests the trip later, the server already knows what the previous trip was. Origin, destination and time must not be transmitted again to the server. This session is identified by a session number, which is passed on to the client after the first request. For each session, a certain amount of memory is needed. If 1000 users send requests to the system, the system will need storage for 1000 session contexts. To prevent endless growth of memory, a session context will be deleted if it was not used for a given time. This time is currently set to 60 minutes.

The EFA Controller analyses the HTTP-requests and creates requests to the basic services. Examples of the basic services are:

Place identification

Stop identification

Address identification

POI identification

Computation of foot paths of journeys with public transport

Departure monitor

Etc…

The requests use the CORBA technique (Common Object Request Broker Architecture). The basic services like place and stop identification and computation of PT-journeys are performed within the third layer, the EFA Location Server and EFA PT Kernel. Other requests for addresses, footpaths and maps are sent to the EFA Location Server and EFA IT Kernel, which are another programs running on the same PC.

Some of the requests may be processed in parallel, for example six PT-journeys may currently be computed in parallel. It makes no sense to increase this number because the threads have very little waiting time. This waiting time may occur with access to the hard disk, but the usage of the hard disk for the PT-Kernel is infrequent.



The EFA IT kernel is also designed for parallel processing. He can perform the following tasks:

• Identify an address and return the coordinates

• Identify a POI and return the coordinates

• Routing from a given point to a list of stop points in the surrounding area (1 : m) considering the means walk, bicycle, or car

• Routing from point to point with the means mentioned above

• Create detail maps for the start and end point and all interchange points of a trip

• Create overview maps for the whole trip.

After the EFA Controller has collected all the information to answer a request it builds an XML-file which contains the answer. This XML-file is processed in a further step with XSLT (extensible Stylesheet Language Translation) to create a HTTP-page, which is finally sent back to the user.

Parameters to configure the HTTP-Server

MaxParallelRequests 50 (default value) Maximum number of threads working parallel. If this value is too high, memory problems may appear

Port 80

Timeout 300 (default value) Timeout for sockets

KeepAlive 1

KeepAliveTimeaout 10

MaxKeepAliveRequests 100

FileCache 1

FileCacheMaxSizeKB 10240

FileCacheMaxSizeFileKB 100

FileCacheMaxFiles 1000

This is only a selection of the existing parameters. The configuration of the system must take in account the expected load. The configuration of the servers must fit to the configuration of the firewall.

It is possible to specify special HTML-Pages for the most common server errors like



400 bad request

404 object not found

500 internal server error

501 not implemented

503 service unavailable

The errors 400 and 404 will usually only appear, if the layout implementation is faulty.

500 and 501 should not appear. 501 may appear if somebody tries to request with a method other than GET and POST, which makes no sense for a JP request.

503 is an indication of server overload

3.4 Operational Requirements Normally an availability of more than 99.7 % is requested. A system should consist of load-balanced servers. The load-balancer checks the servers. If they do not answer to a ping, they will be taken out. The load-balancer will automatically detect if a server is up again.

However, other problems may occur. For example, a server may answer a ping but is not able to compute a journey. Therefore, the system comes with a surveillance program called “watchdog” (see Fig. 3-2 Journey Planner architecture). This program checks all parts of the system on several levels:

• Operating system level: whether or not the program appears in the lists of the operating system

• Communication level: whether or not the program answers

• Logical level: whether or not the program answers a test request properly

In addition, the “watchdog checks the availability of disk space and the consumption of memory and handles.

If the “watchdog” detects a problem, it will restart the program. If the problem does not go away, it restarts the whole system.

System managers can communicate with the watchdog. The watchdog can also send mails or phone messages, and answer phone calls. Additionally, it creates a log file and statistics.

In addition to the “watchdog”, mdv offers 24/7 service, which means that the system is externally checked and someone from the support team is always available.



A backup of the data of the productive system is possible but not needed because the system data is built on the administration server. The backup of the administration server has to be defined.

On the productive system only log-files and statistic files are produced. Log-files are deleted after a defined time to prevent the system from running out of disc space. Statistical files, which can be viewed with Excel, must be copied from time to time.

The system does not use a database.

3.5 The XML-Interface The Journey Planner Engine (EFA Server) is normally accessed by the XML-Interface. The XML-Interface does not define the design of the user-interface but offers the functionality. The technique used is the principle of request and answer. The protocol to transport the information is the HTTP-protocol.

The Journey Planner System supports different types of information which use different requests. Usually, requests are implemented in a user dialog, but other applications also initiate requests (e.g. the request for departures to be shown on a dynamic passenger information screen). To prevent the user dialog from sending all information at every stage from the server to the client and back, a session technique is implemented which creates for each session a user context in the storage area of the kernel. In this case, the dialog is static.

The Journey Planner System (EFA Server) supports personal profiles in order to consider personal preferences and restrictions for the user and to simplify the dialog. In this case the user must log in and log off. The system creates a temporary user ID that is transported to the dialog using cookies. The profile itself is added to the user context of the session.

The following figure describes the HTML application process. The input is sent as form data set from the browser to the server. The server processes the request and produces XML output. If desired, this output is transformed by an XSLT-Processor back into HTML and sent to the browser. (XSLT means eXtensible Stylesheet Language Transformations)

Every other form of output can be produced in the same way for example

• HTML for touch screens

• WML

• pure XML



Fig. 3-4 HTML application process

Why is a script language used?

The users of the EFA system request to presentation the produced information in a layout which is specified by the owner of the system and is normally conform to the corporate identity of the information provider. The script language can satisfy this demand by transforming the structured information provided by the server to the specific layout.

The advantages of this method are that the adaptation of the layout is not integrated in the server and the same server can be used in different surroundings. One server can provide different layouts, e.g. one for general web interface one for the customer service centre, and one for visually impaired users. The layout selection is performed by sending the request to virtual dictionaries.

Why XSLT?

XSLT was chosen because this language was developed exactly for the purpose of transforming XML documents into other structures such as HTML.

The interaction between client (browser) and server begins with an initial request from the browser of a different type. Receiving this, the server creates an XML-



document which is delivered to the integrated XSLT-processor. The XSL-processor creates a HTML-document, which is sent back to the browser.

The user then fills in the input fields of the HTML document and, using the submit button, sends the form data to the server. The server now creates a new XML-document, which considers the user input and the process starts again.

The principle of this method is that the XML-document created by the server always has the same structure and always contains all relevant items for the answer of the request (all inputs of the user and the information items computed by the server). In contrast, the browser will only send items which were changed by the user or which could have been changed by the user.

After the first request, there may be still some empty items, because there is not yet any information. Other items like date or time or some trip options may be given default values by the server. The content of the document will be filled step by step following the user requests.

The different layouts which are created by the servers are subject to so called virtual directories.

For example for TfL

http://www.journeyplanner.org/user/XSLT_TRIP_REQUEST2?language=en

create the public user interface



Fig. 3-5 Public user interface

http://www.journeyplanner.org/ticc/XSLT_TRIP_REQUEST2?language=en

create the call centre interface



Fig. 3-6 Call centre interface

whilst

http://www.journeyplanner.org/bcl/XSLT_TRIP_REQUEST2?language=en

create an interface for visual impaired users, which is readable by a screen reader.



Fig. 3-7 Interface for visual impaired users

Even a wap interface for mobile phones may be created via XSLT-Transformation.

The parameter settings to achieve this are as follows

[VirtualEFA91]

AliasName “user”

AliasDir Directory for script files

[VirtualEFA92]

AliasName “ticc”


[VirtualEFA93]

AliasName “bcl”




There is no real limit to the number of layouts. This technique offers the usage of the journey planner engine and its data to various organisations, each of them showing different layouts with its own branding.

3.6 The Session Technique The server stores all the information in order to prevent transmission from the initial request to the result from the server to the browser and back again. Therefore, the server creates storage areas belonging to sessions, the so-called user context. Since there is a lot of parallel usage of the system, the EFA server provides SessionIDs which have to be included in each request to enable the server to assign the write storage area and the stored data.

A session may consist of several requests. These requests are distinguished by the requestID. Some requests may belong to a chain of trips. The request for the return trip of a given request is a new request but it belongs to the same session. This means, that the request may inherit the origin and destination from the previous trip. Another example may be the request "Onward Journey", where the destination of the previous trip is the origin of the next trip.

Example: A user considers his computed trips on the browser screen and wants a trip that departs later than the ones shown. He only needs to transmit the sessionID, the requested, and the command "tripNext". The reply XML-document contains the complete information, such as the origin and destination, the selected options, and, of course, all the computed trips including the newly requested one.

If an application uses more than one server and load balancing, it must be assured that a session always runs on the same physical server. This means that all requests must be transmitted to the server which was initially asked. Intelligent load balancers are able to do this. The most common method is to use the IP-address of the caller. A second method to do this with the help of cookies is available too. These cookies are not stored on the client server.

In addition, there are some special requests, which do not use the session technique, because no dialog is needed.

Since each session needs memory, this memory must be released after a certain time. This time is defined by the parameter DeleteItdSessionsAfterSeconds with a default value of 900. However deletion of sessions starts at a minimum of MaxItdSessions (default 500). There is no real maximum of sessions, which can be hold. Care is needed, to assure that enough memory is available.

Parameters

MaxItdSessions (500 default value)



DeleteItdSessionsAfterSeconds (900 default value)

ServerId Server prefix to identify sessionID



4 Routing in Space and Time

Finding the optimal journey for a single user is a difficult task because the notion of what is ‘optimal’ depends on each person’s preferences. Therefore the EFA allows the user to select from a variety of options, for example: walking speed, maximum walking time, avoiding stairs or other obstacles, exclusion of modes, maximum number of interchanges, via or must-avoid options, or de-selection of expensive fare zones or express lines.

It is also possible to exclude certain stops as interchange points. Proximity footpaths may be restricted to daylight times, which are adjusted according to the day in the year. For the mobility impaired, interchange links via stairs or elevators can be taken into account. The accessibility of certain vehicle types for the mobility impaired can also be taken into account. More information is given later. These individual settings can be stored in personal profiles to keep them for future requests.

To meet the user’s requirements it is important to present not only one theoretically optimal solution, but also more alternatives where the user can choose a favourite. This includes giving journey options which are slower (within a specified time frame) than the fastest solution but more comfortable or to showing solutions for different times.

Besides the user options there are additional conditions to be taken into account. For interchanges between stop areas exact interchange times can be defined. Where no stop areas have been defined the interchange time is taken out of the mode dependent matrix (changing from urban bus to urban bus takes two minutes, form urban bus to regional bus three minutes, etc ...).

It is also possible to define guaranteed interchanges, where when normally the interchange time is not enough to catch the connection but the operator assures that vehicles will wait for each other. Moreover, buffer time can be defined for every line. This is used for lines that are frequently delayed. The buffer time is added to the interchange time, thus influencing the possible connections to other lines.

All the above conditions and user options create an abstract set of feasible solutions, out of which the journey planner has to find the optimal solution.

The EFA is able to compute optimal journey solutions according to the following target functions which can be selected by the user:

• minimum journey time (fastest journey)

• minimum number of interchanges

• least walking.



The search for a cheapest journey depends very much on the local fare system. The definition of the term ‘cheapest journey’ is often hard to find. Assuming that it can be defined we can offer the search for the cheapest journey in a future stage of the project on current account.



4.1 The Fundamental Algorithm This section describes the routing from point to point, for public transport, this means stop to stop. This functionality is call 1:1-routing too.

The Journey Planner has a target function. Every primary target function uses additional (secondary) optimisation criteria. If the fastest journey is required, which is the normal case, a strict Dijkstra algorithm is used. Its optimisation goal respects the following hierarchy of requirements (business rules):

• Minimise the overall journey time (earliest departure by latest arrival)

• If there are two solutions with the same journey time, minimise the number of interchanges

• If there are two solutions with the same journey time and the same number of interchanges, minimise the time in vehicles and especially the walking times. (This can be weighted)

• If the two solutions are still equal, choose the one where the comfort at the interchange stops is maximised.

The last point is used to weight interchange points and can take into account protection against bad weather, lightning, shopping facilities, etc, if this information is available.

Fig. 4-1 Description of the three dimensional Dijkstra algorithm

time



The figure shows the technique.

Dijkstra's algorithm solves the single-source shortest-path problem on a weighted graph (directed or undirected), provided all edge-weights are nonnegative.

Dijkstra's algorithm maintains a set of nodes whose final shortest-path weights from the source have already been calculated, along with a complementary set of nodes whose shortest-path weights have not yet been determined. The algorithm repeatedly selects the node with the minimum current shortest-path estimate among those whose shortest-path weights have not yet been determined. It updates the weight estimates to all nodes adjacent to the currently selected node (this updating is commonly referred to as "relaxation" of the edges between these nodes). The node is then added to the set of nodes whose final shortest-path weights have been calculated.

It continues to do this until all nodes' final shortest-path weights have been calculated (until the set of nodes whose shortest-path weights have not been determined is empty).

The Dijkstra algorithm is a well known mathematical algorithm. A web search will provide hundreds of matches. The algorithm has the advantage to be free of iterations, which allows very effective programs. It provides always exact results which can be proved. The graph may be divided allowing distributed computing on more than one server.

The problem to be solved is, how the use this algorithm for public transport. A timetable can be presented as a graph, showing the trips in a chart.



Fig. 4-2 Timetable graph

A journey going from A to B to C to D will be a line. A timetable is a bundle of such lines.

Interchange may happen at one point, in this case the arriving mean and the departing mean will stop at the same point (a DIVA stop point or a NaPTAN stop).

Fig. 4-3 Simple Interchange

A B C D

time

stops

stop



Fig. 4-4 Complicated Interchange

An interchange may need a footpath in this case two points are needed. (DIVA stop areas)

Footpath may also appear between different stops.

This modelling is based on the DIVA stop modelling. A point (node) is a DIVA stop or a DIVA area. Between these nodes, footpaths may exist. If a DIVA stop or a DIVA area has more than one stop point (which is equal to a NaPTAN stop) these points belong to the same node of the network and interchange is possible without adding a footpath. However, if the precise the stop point is known, it will be the attribute of a trip and will be added to the journey description before the journey trip displayed.

All these elements together build a three-dimensional network, a network in space and time. For one day the TfL network consists of x nodes and y edges. It is the characteristic of the mdv EFA technique to perform an integrated search in space an time which is called a one step technique. Former approaches, to search a route and afterwards look for the times showed to be not as reliable as needed, yielding sometimes faster results but being unable to gain the needed precision.

The advantage of the Dijkstra algorithm is, that he provides always results which are proved to be the best possible, the disadvantage is, that this may need a huge amount of calculation and processing time. You always have the choice between “quick and dirty” or “slower and precise”.

To reduce the amount of processing work, some modelling assumptions can be made, since we deal with public transport. We can divide the network into an “access network” and an “interchange network”. The following figure shows the situation.

Stop Area 1

Stop Area 2



Fig. 4-5 Access Network

Fig. 4-6 Interchange Network

If a bus is calling on several stops where no interchange is possible, these stops are not relevant for interchange. The network may be reduced. These intermediate stops are only needed if they are used for origin or destination of a journey. In general, half of the points are intermediate points. If the EFA algorithm has to start from an intermediate point, the algorithm will at first go to the next interchange points, continue his search on the interchange network and finish on the access network if needed.

These interchange points are identified automatically. This is done by searching the predecessor stops and the successor stops. Each stop has previous and next stops, depending on the routes serving this stop. An interchange stop should have at least 2 previous or at least 2 next stops. If a stop has only one previous and one next stop, no interchange is possible. This stop will not be used in the reduced network.

The algorithm at work will span a tree, to describe the status. The nodes of the tree are objects which are linked by referencing the predecessor. The most important attributes of the node are

• Node-ID (DIVA stop or area or “root-node”)

• Predecessor node

• Route-ID of the route (line) with which this node was reached

• Trip-ID to identify a trip belonging to a given route

• Needed travel time from until now

• Number of interchanges until now

• Weighted in vehicle time (time in vehicles factor 1.0 time on footpaths factor 3.0 (example))

I I

I I



It the algorithm has reached a node, which is marked as destination a journey is found. The journey can be displayed by back tracking the tree, going to the predecessor until the root node is reached.

Having this structure, the algorithm can be implemented in a way to forbid loops, which means to reach the same point more than once. However, care is need, because it is not unusual that a bus will leave his main route to call at a school and come back to the same point and continue his route. Therefore it is allowed to touch the same point twice if route-ID and trip-ID are identical.

Every point may have an attribute “pick up only” or “set down only” for a certain trip which will be taken into account.

Since we deal with public transport, further restrictions can be used to limit the size of the tree.

• Latest time to reach the destination

• Maximum number of interchanges

However, the number of interchanges depends on the total journey time. You would probably accept to interchange 10 times if you travel across the UK from one end to the other but you will not accept it for a journey within a city.

The maximum overall number of changes can be limited by the parameter.

MaxNrChanges 9 (default value)

A very important feature is the “lead-restriction”. If the algorithm has reach a certain point at a certain time, in most cases there is no need to continue the search with branches, which will reach this point later. The following figure will explain this situation.



Fig. 4-7 If the lead time is large enough, the tree branch may be broken

If a route has a regular sequence of trips and all trips go to the same destination, there is no need to consider more then one trip of this route in the search tree.

However there may be situations, where you should not cut the branch. This is shown in the following figure.

07:00

07:15

07:30

07:45

08:00

Lead 15 min. later



Fig. 4-8 Some times, a trip, which arrives later, is needed

• The former versions of EFA have had a fix “lead time” to be set by the parameter “LeadMinutes”.

The newest version of the EFA (9.11) uses automatic lead computation. This can be activated by setting the parameter DynamicLeadCheck in the definition file. Automatic lead computation results in faster computation of journeys. In some cases a computation acceleration of up to 75% was realised.

Further restrictions can be imposed, knowing the geography. If a journey should be found from South-end on Sea to London, it should not go via Oxford. This means, that for certain relations of origin and destination, the access to certain regions may be forbidden. This will be covered in point …

If the algorithm has reached the destination, this result is kept. Now a certain time window is opened to compute further results. This window is called over run time. If within this time a journey will reach the destination with a smaller number of interchanges than the fastest, this journey may be offered too, as the more comfortable one.

A result of the computation may be that no journey exists. If the algorithm will not find the destination, this may happen due to some reasons

• The tree is finished, if there are no more links to prolongate the tree. This may happen early, if the number of interchanges is limited (for example to 3) and from none of the already reached points, another point can be reached without a further interchange. If may also happen early in small networks or if the networks fall into unlinked parts probably on weekends. In large networks other reasons do have a bigger likelihood.

10:00

10:02

10:05

10:10 10:12

10:08 10:12 10:14



• A maximum time is reached. Currently the maximum journey time is set to 24 hours. A result may be “no journey within the next 24 hours”. The algorithm searches always continuously around the clock, no matter whether timetables will change in the middle of the night. If a journey is searched on Friday evening, and the next possible trip will start on Saturday morning, this journey will be offered, if the next possible trip will start on Monday morning, it will be not offered. This value “maximum journey time” is a result from lengthy discussions on user groups.

• The maximum tree size is reached. The tree was already described. The maximum tree size is set with the parameter SizeTree x (Default value 300.000) Typical values to reach a destination within an hour are 30.000. For the South East network it is set to 400.000 to allow a search all over UK. Since the system is a multi thread system, the tree memory for each running thread. The number of parallel threads can be set with the parameter [Threads] PT-Router (Default value 2, South East 6). To estimate the needed memory, each tree branch must be multiplied by xxx Bytes. The advantage of large trees is, to be relatively sure to find exotic journeys. However if no journey exists, it will take considerable time (some seconds) for the algorithm to work through the whole tree. The maximum possible time is needed to search a trip from the middle of London to the north of the UK if no journey exists. To limit the tree size will also limit the maximum search time.

The optimisation algorithm can be applied forwards, to reach a destination as soon as possible after a given earliest possible departure time, or backwards, to leave the origin as late as possible to reach the destination at a given latest arrival time. The system will always compute a bundle of journeys where possible, for example, for given departure time, one journey which starts before the departure time and three which depart afterwards.

If the optimisation for the fastest journey was selected, what is usually the case, after the computation of the fastest journey the algorithm will try to find journeys with less interchanges. These alternative journeys may have a slightly longer duration than the fastest. The following figure

Fig. 4-9) will give an example; the request was to compute trips after 10:00.



Fig. 4-9 Alternatives to the fastest journey

Sometimes an alternative trip may exist which starts before the fastest and ends after the fastest, having a less number of interchanges than the fastest. This is called an encompassing alternative. To find these alternative trips an extra step is needed. This can be activated with the parameter

CalcAlternativeEx 1

However these alternatives are very rare and the computation needs extra time, independent of the case whether a result is found.

Each computation of a journey is a sequence of forward and backward search steps.

Given a departure time, the algorithm will find the earliest arrival in a first step.

However, if for example a bus with high frequency in the first leg is followed be a low frequency leg. The journey found in the first step may start too early. The latest possible departure is found by a subsequent backward search. The following figure shows an example.

10:00 10:10 10:5010:4010:30 10:20 11:2011:1011:00 11:30 11:40 11:50

Alternative 1 – 1 interchange

Fastest: 2 interchanges



Fastest jounrey: 10:10 – 11.10 2 interchanges

Alternatives: 10:10 – 11:15 1 interchange 10:05 – 11:10 1 interchange 10:05 – 11:15 1 interchange



Fig. 4-10 Forward and backward search

To find alternative journeys with less interchanges, the algorithm will continue to search after it reached the destination the first time. If a solution was found with a smaller number of interchanges within a given time limit called the OverrunMinutes.

The OverrunMinutes has got a default value of 9 minutes for trip times smaller than 3 hours.

If the trip time is greater than 3 hours (but smaller than 6 hours) the OverrunMinutes default value is multiplied by 5 and has got therefore the value 45 minutes (= 9 min * 5).

If the trip time is greater than 6 hours the OverrunMinutes default value is multiplied by 10 and has got therefore the value 90 minutes (= 9 min * 10).

OverrunMinutes 9 (default value) for trip times < 3 h

OverrunMinutes 45 for trip times >3 h and < 6h

OverrunMinutes 90 for trip times > 6h

Forward search

Backward search

08:00

08:15

08:30

08:45



Fig. 4-11 Example overrun time

fastest route

Route with less interchanges

08:00

08:15

08:30

08:45

Less than 9 min: OK



Special search must be performed with follow-up routes if the timetable includes changes between short/ long trips.

Fig. 4-12 Example route with short and long trips

The algorithm will stay a long as possible on a trip. The forward search will result in two interchanges, the backward search too. However, there is a result with one interchange.

Summary of Parameters

MaxNrChanges 9 (default value) Maximum number of interchanges

DynamicLeadCheck 1 (default value) Dynamic lead check

SizeTree 300.000 (default value) Maximum size of the tree

08:00

08:15

08:30

08:45

Ideal route

Forward search t

Backward search route



OverrunMinutes 9 (default value) Overrun minutes for alternate trips with less interchanges

ChangeTimeFactor 1.0 (default value) The general interchange time can be modified. This is only needed for special tasks.

WalkFactor 3.0 (default value) If two trips need the same arrival time but have different legs, it should be assured, that the trip with the less walking time should prevail

StopPreselection 1 Stop preselection activated (see ….)

The following parameters will control the number of computed trips

CalculateNumberOfTrips 4 (default value) 4 trips will be calculated per request. If less trips are found, the number will be smaller. Alternate trips and monomodal footpaths may increase the number

CalculateMaxNumberOfTrips 100 (default value) This value is needed to protect the layout. If the value is set to 100, the client must be able to show 100 trips.

PrevNextTripCount 4 (default value) Number of trips to be calculated after pressing the “next” or “previous” button

FirstLastTripCount (default value is CalculateNumberOfTrips) Number of trips to be calculated after pressing the “first” or “last” button.



4.2 Frequency calculation

Frequency calculation enables the EFA system to give additional information on specific journey legs. On the one hand optional services are offered for a single leg and on the other hand a so called frequency buffer is taken into account in the journey plan.

Frequency calculation can be turned on for specific sub-networks and for specific means of transport. In general a time window around the original leg time will be inspected to find additional trips for the same leg. The time window can be defined and is per default 10 minutes in the past and 20 minutes in the future.

4.2.1 Frequency Leg

A frequency leg is a leg where alternative services are presented e.g. on trunk routes. The user can now choose between different services for the leg independent of the arrival time and possible disruptions.

4.2.2 Penalty Frequency Leg

A TfL bus leg is a penalty frequency leg if the frequency interval is lower than 12 minutes. The penalty frequency leg has a specific time out of the sum of the maximum waiting time and the maximum travel time. If there is a frequency interval of 2 – 4 minutes and a maximum travel duration from 12 minutes the complete leg time will have 16 minutes.



4.2.3 Display Rules

A penalty frequency leg has no times. Exception is the start time if the leg is the first leg in this journey, or the end time if the leg is the last leg in this journey.

All service alternatives are displayed within this leg.

In the “Information” column the additional info “Buses every: 2 - 4 mins” and “Max journey time: 16 mins” is given. The frequency time interval consists of the average waiting time and the max waiting time.

4.2.4 Penalty Frequency Buffer

The following values are calculated during a penalty frequency calculation:

• avTimeGap – average waiting time between trips in the frequency window

• maxTimeGap – maximum waiting time between trips in the frequency window

• avTripTime – average time in vehicle for trips in the frequency window



• maxTripTime – maximum time in vehicle for trips in the frequency window

• PenaltyFrequencyBuffer – SUM(maxTimeGap, maxTripTime)

4.2.5 Frequency Calculation

The following diagram shows the principal of the frequency calculation on the example journey from Alexander Road Prince of Wales Gate. Both bus legs are penalty frequency legs. The Tube leg is a frequency leg.

The following steps will be performed for each leg:

• calculate additional trips if:

o the leg is a frequency leg

o the leg is a penalty frequency leg

o the leg must be shifted because at least one predecessor leg was a penalty frequency leg

• if the leg fulfils the requirements for a penalty frequency leg add the penalty frequency buffer to the arrival time



Alexander Road

Caledonian Road

Hyde Park Corner

Prince of Wales Gate

Original Journey

Frequency Trips Frequency Penalty

Resulting Journey



4.3 Assigned stops In simple cases only one start and destination point is defined. The highlighted route is the fastest route and will be shown.

Fig. 4-12 Single start and destination points

However, a DIVA-stop may be a collection of stop points and areas. Several means of transport may depart parallel from a stop. This means, a stop-to-stop request may already deliver very different trips.

10:10 11:10



Fig. 4-13 Route between DIVA Stops

Stop A

Stop B

Bus Underground

Underground Bus



Stops may also be assigned to each other. If a rail station is one stop and there is a bus stop in front of the station these stops are normally assigned one to the other. Assignment means, the journey planner may use either of them. In this case the journey planner will compute routes from and to all assigned stops. This is called a m:n search. In the case of assignment, it is assumed, that the passenger may start at the given time at each of the different points. In Fig. 4-14 the highlighted route is the fastest route. Stops a and b are assigned to each other, as well as stops c, d and e. Therefore routes between a, b and c,d,e are computed.

Fig. 4-14 Multiple start and destination points

a

d

b

c

e

10:10

10:10

11:00

11:10



4.4 Gain of processing speed by stop pre-selection Long journeys consist of a local transport in the origin and destination area and long distance transport between these areas. Local transport for example is transport by local buses and trams. Long distance transport is transport by train, underground, coaches and buses serving more than three districts.

For calculating longer routes, the journey planner should use all services in the vicinity areas of the stops. However, it should use only long distance transport outside the vicinity areas. This would lead to significant small trees for the search and speed processing.

Internally, vicinity areas are defined via districts and counties. Knowing districts and localities, stops in these localities can be identified. The location hierarchy is described in 2.3



Location hierarchy.

Vicinity areas

A vicinity area is the area around the district of the locality in which the origin or destination stop is located. These areas are defined manually in the mdv program for vicinity areas. The following figure shows the districts of Sevenoaks and Oxford with their vicinity areas in the southeast region. The red districts are the vicinity areas.

If the Journey Planner has to compute a route between Oxford and Sevenoaks, the JP is allowed to use local transport services for route computation within these areas (red + blue). Outside the two areas, the JP should use only long distance transport.

Fig. 4-15 Origin and Destination districts with vicinity areas



For routes from the Southeast region to a destination outside Southeast, the vicinity areas of the southeast are based on districts, the vicinity areas of the destination is based on counties. The following figure shows the district of Sevenoaks and the county Glasgow with its vicinity areas. The red districts and counties are the vicinity areas.

If the Journey Planner has to compute a route between Glasgow and Sevenoaks, the JP is allowed to use local transport services for route computation within these areas (red + blue). Outside the two areas, the JP should use long distance transport.

Fig. 4-16 Origin and destination counties with vicinity areas

Corridor

Within the London area, also corridors are used. Corridors are boroughs between the origin and destination vicinity areas that must be used for the computing of long



distance part of the route. This is used to save computing time. If corridors are not used, the JP will search for long distance connections throughout the whole country. Under circumstances, route from the city centre to the south of London via e.g. Plymouth will be computed, which does not make any sense. These corridors pre-define, through which districts the long distance transport may go.

The following figure shows the boroughs of Enfield and the Sutton with their vicinity areas. The red boroughs/districts are the vicinity areas. The green boroughs form the corridor.

If the Journey Planner has to compute a route between Enfield and Sutton, the JP is allowed to use local transport services for route computation within the vicinity areas (red + blue). Between the two areas, the JP should use long distance transport only in the corridor areas (green).

Fig. 4-17 Origin and destination districts and vicinity areas in London with corridor

Therefore it is important that all localities are assigned to the right county and district. If not, it is possible that interchange points are not offered, because they are not assigned to selected counties and the journey results may be incomplete.



Example

The following figure shows a journey from Blenheim Park (Southend-on-Sea) to Harrow-on-the-Hill (Harrow).

Fig. 4-18 Example route from Southend-on-Sea to London Harrow

Within the vicinity areas of Southend-on-Sea and Harrow (see Fig. 4-19), the JP should find interchange points to long distance transport.



Fig. 4-19 Example vicinity areas for route from Southend-on-Sea to London Harrow

During computation, if the JP algorithm arrives at the border of the vicinity areas and still did not find an interchange point to long distance transport, this search branch of the tree will not be prolonged. For more information about the JP algorithm, see 4.1 The Fundamental Algorithm.



The journey results, the JP offers a route with bus 21 and X1. The common data for route 21 show that this route is passing both the stops Westciffs High School stop A (Westciffs) and The Elms (Leigh-on-Sea). Also the flag “long distance traffic” has not been set. So, this route is a local bus route. Therefore this route may only be used within the vicinity areas.

Fig. 4-20 Common data server: route information Bus 21: Local bus



The common data for route X1 show that this route is passing both the stops The Elms (Leigh-on-Sea) and Aldgate. The flag “long distance traffic” has been set. So, this route is a long distance bus route. Therefore this route may also be used outside the vicinity areas.

Fig. 4-21 Common data server: route information Bus x1: Regional Bus



4.5 Showing Results The journey planer engine will create the results as an XML-structure. This structure will hold all existing information. The way, how the information is displayed is defined by the XSLT-Transformation.

4.5.1 The XML-Structure of the result

The XML-Structure of the EFA-Interface is described in the paper

EFA 9 XML Interface.

A new version is released with every version of the EFA. This interface describes the complete functionality of the JP system.

Journeys are provided as a result of a TRIP_REQUEST. A short overview is given in the following point. For in depth information, the complete interface description must be consulted.

4.5.2 Number of Trips, Collecting Journeys,

The number of journeys to be displayed on a request can be defined. Normally, if the search is based on a departure time, one best journey before the given time and the three best journeys after the given time are displayed. However, if the search is based on an arrival time, the three best journeys before the given time and one best journey after the given time are computed. This can be defined, see section 5.1.

The normal policy is to compute fastest journeys. In this case, it is also checked whether there is a journey that needs some more time but less interchanges. If this is possible, these results will be additionally given (see section 5.1).

If the distance between origin and destination is short, a direct footpath may be computed too.

This is ruled by the parameters

• CalculateNumberOfTrips 4 (default value)

• CalculateMaxNumberOfTrips 100 (default value)

Which are already explained in 4.1.

Using then buttons next or previous, more trips are computed. These trips are added to the already existing trips. Using these buttons repeating, a long list can be created. This maximum length should be restricted to a length, the layout can hold.



The trips are added to the personal memory space of the session (see 3.6 The Session Technique). This prevents the system to send session related information always backward and forward between server and client (usually the browser). The context is created with the first request of a session. This implies the allocation of a memory area. This happens on a server, which was selected by the load balancer. Subsequent requests must reach the same server. In most cases cookies are used to identify the server, where the session was started. Therefore a trip request is always case sensitive.

Because a new every new session needs memory to be allocated, the memory usage will grow after the start of the system. This can be observed with the task manager. However, since the available memory is limited, the session memory must be released after a given time, if it is not used. This time is set by the parameter DeleteSessionsAfter Seconds. If a request reaches the system after this time, the user will get the message “session expired” and he has to start his request again from the beginning.

The following pictures show a first request for four journeys. Since there are alternate journeys with less interchanges but longer durations, they are displayed too and the system will return seven journeys. Upon the “later” request eight additional journeys are displayed in a list of fifteen journeys.

Fig. 4-22 First request



Fig. 4-23 Following request

4.5.3 Earliest and Latest Journey

The following example was computed with a first request starting at 1200. A second request was send with the button “earliest” and a third request with the button “latest”.

The result is shown in the following figure.



Fig. 4-24 Earliest and latest

The computation is ruled by the following parameters

FirstTripTime 0300 Time from where the first trips of an operation day are computed.

LastTripTime 0259 Time until where the last trips of an operation day are computes.

FirstLastTripCount 4 Number of journeys to be computed

For the earliest trips, three trips are computed after 0300 and one before. Fore the latest trips, 3 before 0259 and one after. If only one trip is wanted, the parameter FirstLastTripCount should be set to one.



This function may show unexpected results if night services exist. In this case no real earliest and latest trip exists and the system will show journeys around the specified values FirstTripTime and LastTripTime.

4.5.4 Return Journey and Onward Journey

Having computed a trip the button “Onward Journey” or the button “Return Journey” will provide input forms. In the first case, the origin is already filled with the destination of the last journey, in the second case, origin and destination are exchanged.

Fig. 4-25 Buttons for onward and return journey



Fig. 4-26 Onward Journey



Fig. 4-27 Return Journey

In the session context, the journey sequence is stored. It is planned, for further extension of the system, to provide navigation within a chain of journeys.

4.5.5 Overview and Detail

Normally, the results are displayed in an overview display and a detail display.

The following figures show the technique, having an overview page, select journeys and show the details of the selected journeys.



Fig. 4-28 Result overview



Fig. 4-29 Result details

Another possibility is, to show overview and details together in a long page. This saves the user an extra request.



Fig. 4-30 Overview and details in one page

4.5.5.1 Overview The following figure shows another overview.



Fig. 4-31 Overview VVS

Together with the examples from the previous point the possible content may be described. The overview should be a summery of the request and a list of journeys.

For each journey, the following items are available

• Number of the journey

• Date and time of the start

• Date and time of the end

• Duration or total time



• Time spend in means of public transport

• Number of changes

• Fare

• Sequence of means of transport

• Link to an overview map

• Link to more detailed fare information

The following example shows an overview map.

Fig. 4-32 Overview map



The following figure shows tariff information for a given trip in more details.

Fig. 4-33 Detailed tariff information

It is up to the installation in which scope and which way the information is shown. It is always available over the interface and will be displayed after the wishes of the owner of the system.

4.5.5.2 Details, Legs of a Journey The following figure shows another example.



Fig. 4-34 Journey details

Two types of legs have to be displayed for journey details

• Riding legs on a vehicle of public transport

• Footpath legs

4.5.5.2.1 Riding legs The examples from above show, that the following information is available

• Departure time

• Arriving time

• Departure stop, the name is normally locality followed by the stop name. The stop name may depend on the operating branch or the mean. The stop name may be followed by a more detailed location, for example a bay, stand or stop identification

• Arrival stop as above

• A symbol for the mean of transport



• The mean of transport or the name of the transport operator like “London Underground”, “Tram”, “One Railway”

• The route name or number like “Bakerloo” or “6”

• The direction like “towards Southend Victoria Rail Station”

• A link to a map of the departure stop

• A link to a map of the arrival stop

• Additional maps of the stops

• A link to station information

• A link to operator information

• A link to a timetable

• Alternative routes with destination to reach the same arrival point

• Frequency

• Maximum journey time

• General hints

• Booking information for demand services

• Real time information

• A link to more real time information

It is up to the owner of the system to select from the variety of information.

Some examples are given:



Fig. 4-35 Map of the departure stop

The following example shows detailed information with hints. The first hint means, that the train may take bicycles along with, the second hint means

Bus on demand: Booking is needed latest 45 minutes before departure, phone number …., the vehicle will be a taxi



Fig. 4-36 Detailed information with hints

The information to be displayed must exist in the data. Each trip must be delivered with the information

• Mean of transport

• Symbol to be displayed

• Final destination

• Operator

• Line or route number

• Hints

The indication of the direction should be identical with the front sign of the arriving vehicle. However, this information is not always available. Some vehicles will change the front sign in the course of the trip. This may happen on circular trips or on trips crossing a city centre. In this case, the information must be provided for each section of the trip. The JP will be able to show this.

The following example shows a trip in the region of Frankfort. The first leg is shown as a special train type “RB”, which means regional train, followed by the train number.



Fig. 4-37 Detailed information with hints in Frankfort

4.5.5.2.2 Footpath legs

Footpath legs may appear as first or last leg or as interchange legs.

The information given is

• Time on the footpath

• A link to a map of the departure stop or point

• A link to a map of the arrival stop or point

• Sequence of path elements like stairs, escalators etc.



4.5.6 Hiding trips

The journey planner computes results, which will be always correct from a mathematical point of view. However not all results are advisable. A common example is a journey which starts in the evening, reaches an intermediate destination, let the traveller wait for several hours and end the journey with the earliest bus in the morning.

Such trips should not be shown. However, if they are deleted from the list of computed trips, they will be found again with the next request and the system will run into and endless loop.

Therefore, they are stored, but will be marked as hidden. The layout will not show them.

A maximum waiting time at a stop is defined in the system.

Rules: Total duration longest wait time at an interchange point < 3 hrs. > 1.0 hrs. < 6 hrs. > 1.5 hrs. < 12 hrs. > 2.0 hrs. < 24 hrs. > 3.0 hrs. >= 24 hrs. > 6.0 hrs.

These values are configurable in the definition file of the PTKernel in the section „HideTrips“. The following figure shows the names of the parameters and the default values.

Total duration longest wait time at an interchange point

Parameter name:TripDuration1 Default value: 180

Parameter name:MaxBreak1 Default value: 60



Paramete rname:TripDuration3 Default value: 720








Fig. 4-38 Parameters for longest wait time at an interchange point

Another reason to hide trips is that the time spent on footpaths legs is longer then the time needed to do the whole trip on foot. Details about footpaths are covered in 4.7 Footpaths.

4.5.7 Printing the result

In principle, each page shown on the screen may be printed. However a layout, which is designed for the screen is in most cases not optimal for printing. Printers use mostly A4 page size. The layout for the print should profit as much as possible from the size. Not all users do have colour printers. Colour printing is more expensive than black and white. Therefore pages, which are intended to be printed, should be readable without using a colour printer.

The following figure shows the way TfL has implemented the print function. Having clicked the printer button, a printer dialog will appear and the page is directly sent to the printer.

It is composed by a Header, the description of a request and the route itself.



Fig. 4-39 TfL implementation of print function

The MVV (Munich) has to different print options. There is a printer symbol on top of the page. This will create an overview of all computed trips.

Further printer symbols are located close to each trip. This will lead to detail prints.

Every print is created as a PDF-File which uses a layout, specially created for printing.



Fig. 4-40 MVV implementation of print function



Fig. 4-41 Print output MVV: overview of all trips



Fig. 4-42 Print output MVV: details about one trip



4.6 Filters Filter may be applied to restrict the result on certain conditions. Several types of filters exist

• Number of interchanges

• Line or route specific filters, only certain lines or routes may be used

• Area filters, only certain areas are allowed, mostly due to tariff conditions

• Trip specific filters, only certain vehicle types are allowed

• Interchange conditions, restriction for mobility impaired

• via

4.6.1 Number of interchanges

It is possible to define the maximum number of interchanges. The following screenshot shows an example of the interchange option in the Journey planner of Munich.

Fig. 4-43 Option selection: number of interchanges

This filter will change the search parameters for the current request (see 5.1 fundamental algorithm). However, to restrict the number of interchanges will cost extra computing time. Sometimes a fast trip with a larger number of interchanges is followed by a slow one, which normally will not be shown, if he is too slow. To get these trips, the search tree must hold more than one trip per line which makes him larger. Therefore the options are currently restricted to 0, 1 or 2 times. This may be changed on demand.

It is possible to set an option, with which only routes with the least amount of interchanges are shown. The following figure shows a screenshot of the London Journey Planner.



Fig. 4-44 Option selection: least interchanges

In this case, the system will do the following (exemplary explained for a ‘depart after’ journey):

1. Try to find a journey - with a maximum of 2 interchanges - leaving within the requested time + the value for LeastInterChangeTimeWindow (usually set to 3 hrs). This might result in a) or b):

a. If a journey is found, then try to find a journey with one less interchange than the result. Repeat this until no more journeys are found or number of interchanges is 0.

b. If no journey is found, then try to find a journey with one more interchange. Repeat this until a journey is found.

2. As soon as the first “least interchange” journey is found, further least interchange journeys are found by repeating step 1 but requesting a time one minute later than the departure time found in the first journey.

Example

Situation regardless of number of interchanges:

Journey # departure time arrival time number of interchanges

1 09:05 09:45 22 09:10 10:00 13 09:35 10:30 3

A request for “least interchange” departing at 09:00 will do the following:

1. Request a journey with max. 2 interchanges -> This will find journey 1.

2. Since a journey has been found, JP tries to find journeys with lesser interchanges, so it requests a journey with max. 1 interchange.



3. This will find journey 2. JP tries to find additional journeys with 0 interchanges.

4. No more journeys are found, so journey 2 starting at 09:10 is a valid result.

5. In order to find later journeys the JP repeats the process but requesting a journey with max. 2 interchanges leaving at 09:11 or later (09:10 + 1).

6. This will find no journeys. So, the JP will try again but allow one more interchange (3 interchanges).

7. This will find journey 3.

8. The overall result will provide Journeys 2+3.

4.6.2 Least Walking

The JP can also compute a request to minimize walking time. However, it is often not advisable to present the journey with the absolute minimal walking time, as this might be a journey that is leaving a lot later than the time requested.

Example: A request of a journey departing after 07:00 with least walking should not result in a journey leaving at 23:00 just because this late journey has the least walking time of all journeys throughout the day.

Therefore the computation of least walking time journeys needs to be a bit fuzzy with an emphasis on the walking time. This is achieved the following way:

1. In order to give the walking time a higher weight, the walking time is artificially increased by a factor of 3. This has the potential to make journeys with short walks faster than journeys with long walks.

2. With this artificially increased walking time a normal “fastest” journey is computed. The involved stops are saved.

3. Then the walking time is reset to normal values and a journey that is restricted to use the stops found in point 2 is computed. This is the final journey optimized for least walking.

4. As soon as the first journey is found, further journeys are calculated by starting over at point 1 with the requested time set to the start time found in point 3 + one minute. (This way the stops the journey is restricted to remain flexible throughout the day, allowing e.g. different routes when services get less frequent in the evening.)



4.6.3 Line restrictions

An internal line table exists. This table includes amongst others the following attributes:

• Route number

• Mode of transport

• Operator

• Authority y/n

• ICE/IC y/n

• Bicycle transport y/n

• Control of special services

These attributes can be used to exclude certain lines from the tree building.

By indicating the transport mode, particular routes will be excluded. Route search is done with a reduced network.

4.6.3.1 Modes of transport

By indicating the transport mode, particular routes will be excluded. Route search is done with a reduced network.

It is very common to exclude certain modes of transport. Fig. 4-45 shows this feature in the More Options dialogue.

Fig. 4-45 Options: selecting/deselecting means of transport

The following example shows one journey using the underground (Fig. 4-46). Fig. 4-47 shows the same connection with exclusion of the underground. The EFA offers journeys by bus.



Fig. 4-46 Journey using Tube

Fig. 4-47 Journey excluding tube

4.6.3.2 Operators



It should be possible to exclude certain operators. However, since the selection list will be very long, this was never done until now in UK. (See USA example end of this section).

Internally, this is done by deselection of routes. I route is normally operated by only one operator. If this is not the case, the route will be split into operator specific segments, before being used by the Journey Planner. The splitting will result in naming extensions in the DIVA administration system. If for example, a line 55 is operated by operator O1 and O2, the line will be split into 55A and 55B.

This route split allows operator specific links at the result. The following picture shows an example. Route 1 in Buckinghamshire is operated by the operators

• Carousel Buses and

• Walter Limousines

Fig. 4-48 Route 1 operated by Carousel Buses



Fig. 4-49 Route 1 operated by Walters Limousines

Fig. 4-50 Journey results Route 1 operated by Carousel Buses



Fig. 4-51 Journey results Route 1 operated by Walters Limousines

The following example from the transit.511.org system (San Francisco Bay Area) shows selection of operators.

Fig. 4-52 Selection of operators



In the bay area the list contains only about 30 operators. In the UK Traveline regions you would have hundreds of them.

There is a high risk that the user does not select all operators he needs. This would result in a “no journey” message. That is why the 511 system has “prefer to include” and “prefer to exclude” in addition. However, the result needs extra computing time.

4.6.3.3 Tariff conditions

Certain tariffs may restrict the usage of certain services. In Germany, using the ICE (Intercity Express Train) will be extra charged. This results in an exclusion of certain lines.

Fig. 4-53 Options: selecting/deselecting the ICE

The following example shows one journey using the ICE (Fig. 4-54) in Baden Wurttemberg (EFA-BW). Fig. 4-55 shows the same connection with exclusion of the ICE. The EFA offers journeys only by Intercity or regional trains.



Fig. 4-54 Journeys with ICE

Fig. 4-55 Journeys without ICE



4.6.3.4 Control of special services

If certain services may be reserved for a certain user group, for example pupils, this can be modelled as a line restriction.

Restricted school services may be offered by the public interface but not by the call centre interface. Since both interfaces access the same EFA engine, the layout must pass the restriction information to the Journey Planner.

Private Transport must be defined in the parameter file. The section name is

PrivateTransport

Services, which are handled by the journey planner specifically are defined in an extra file and flagged by an identification number. Fig 5-55 shows the record for service 12EB1_ of sub-network SET in the extra file:

Subnetwork Service number ID

SET 12EB1_ 1

Fig. 4-56 Data set entry in extra file

The information, whether flagged routes have to be considered for the request is passed to the journey planner engine by the layout. Fig 5-56 shows the parameter in the definition file:

Section PrivatTransport

Parameter Active 1

Filename Private_Transport.txt

Fig. 4-57 Parameters Privat Transport

4.6.3.5 Bicycle transport

Some systems allow computing trips, where you can take your bicycle along with you.

This will result in a multistage decision process. In most cases, only few lines have the capability to take bicycles. This is a first filter. This type of filter is fast. But bicycle transport may also be restricted to certain vehicle journeys, which is often the case for rail data. This means, that the attributes of every journey must be checked, this needs more time. Sometimes there is a time restriction too, if bicycle transport is not allowed in peak hours. This is an internal check, based on specific coded rules.



Fig. 4-25 Options: bicycle transport

In Munich it is for example allowed to bring your bike in the underground, except during the peak hours on weekdays (06:00-08:30 and 16:00-18:30).

The following example shows one journey without bicycle transport in Munich.

Fig. 4-58 shows a route without bike transport. Fig. 4-59 shows the same route with bicycle transport. The EFA offers journeys only by underground. Fig. 4-60 shows the same route with bicycle transport; however the request is made for a journey within peak hours.

Fig. 4-58 Journey without bike transport in Munich

The same request, however with bike transport, give only routes with the underground and commuter trains.

Fig. 4-59 Journey with bike transport in Munich

If the same request is made for a journey during peak times, the journey planner will give the first route option after the peak time.



Fig. 4-60 Journey request with bike transport within peak hours

4.6.4 Spatial filters

A table of all interchange stops exists. This table includes amongst others:

• Stop number

• Locality

• Tariff zone

4.6.4.1 Spatial tariff filters

If a user has bought a ticket for a certain area only, the journey planner can restrict the search to a certain region. This region may be defined by tariff zones. This option is typically used by service centres.



Fig. 4-26 Options: selecting/deselecting tariff zones

The following example shows a personal journey plan from Stuttgart Stadtmitte to Stuttgart Rudolph-Sophien-Stift.

The journey planner calculates journeys through either one or two zones.

Fig. 4-61 Personal schedule with routes through different zones



It is possible to select tariff zones. If a passenger has for example a travel card for only one particular zone, this can be taken into account. The following figures show the same request, however only the tariff zone 10 is selected.

Fig. 4-62 Selected Tariff zone

The journey planner now gives a personal plan, only including routes within zone 10. The other, more expensive routes, as in Fig. 4-61, are not shown.



Fig. 4-63 Personal schedule with tariff zone filter

4.6.4.2 Avoid London

Each stop has different attributes. One of these attributes is the tariff zone. Each stop can be allocated to a tariff zone. If a stop is located on a tariff border, the stop will be allocated to both tariff zones.

The following example shows the input of tariff zones for the stop Clapham in London with the program DIVA stop management. Clapham is allocated to three tariff zones:



• Underground tariff zone 0002

• Bus tariff 0102

• Bus tariff 0103

Fig. 4-64 Cut-out of DIVA Stop management

In order to avoid London in planned journeys, all stops in the tariff zones 0001 and 0101 are suppressed and the journey planner will calculate with a reduced network.

4.6.4.3 Via

The exact definition of “via” has been discussed in many user groups. “Via” is not an onward journey, where the passenger deboards the bus and boards again after an hour. “Via” is a route that passes a particular stop, but the passenger will not necessarily deboard here. In some cases, the via stop is also the interchange stop. The via-option does only work with transfer stops.

The following example shows a route in London from Wimbledon to Hyde Park Corner with the Via stop Waterloo.



Fig. 4-65 Via Option (1)





The time when the route will pass the via stop will be given, even if the passenger does not have to change at this route. This information is important if for example another passenger would like to join in at the via stop. The following figures show an example from the VVS in Stuttgart. The via stop Esslingen is requested. In the journey planner results the stopping time in Esslingen is given.



Fig. 4-68 Journey request with via stop in Esslingen

Fig. 4-69 Journey results with via stop in Esslingen

In former days, some journey planner systems needed via to find a journey. The EFA never needs any help by via. Via is sometimes used to avoid some means or to find a



cheaper route. It is always favourable to express the options direct, for example by selection of means or deselection of tariff zones.

Using “Via” has disadvantages. First of all it needs much more computing time. Nobody prevents a user to select a via point to go at first in one direction to find the via point and afterwards backwards. This will result in a journey, far away from the fastest route, and to find such a journey speeding techniques, like preselection of stops must be switched off. In most tariff systems, there is a rule, that you should reach your destination without detours. Assume that somebody wants to go in London from zone 1 to zone 2 via zone 6. This is normally not allowed at it is impossible to compute the fare. Fare computation must be switched off for via journeys.

Fig. 4-70 Via-Journeys, no fare computation possible



4.6.4.4 Via with dwell time

A new via-technique was developed for the transit.511.org (San Francisco Bay area).

The following example shows a via journey from San Francisco Airport to Oakland, via Golden Gate Bridge. The user wants to stay there for 30 minutes.

Fig. 4-71 Via-Journey with dwell time (Request)



Fig. 4-72 Via-Journey with dwell time (Result)

Internally the journey is computed as two journeys; however the presentation is one journey. This avoids the above mentioned disadvantages, especially the large increase of computing time. You should have a minimum dwell time. If not, there is a potential danger that the dwell time is shorter than the minimum interchange time at the via point and the two parts of the journey are joint without interchange time.



4.6.5 Via London

In the journey planner for Traveline South East, it is possible to select the option to travel via London centre.

The journey is calculated in two steps:

1. The algorithm search for connections to via stops (for London, a list with London terminals exist) if stops are found, a flag is set in the search tree.

2. From the found via stops, the JP will continue to calculate routes to the destination.

The following screenshots show an example for travelling via London centre.

Fig. 4-73 Journey request



Fig. 4-74 Journey results without Via London option

Fig. 4-75 Via London Option

Fig. 4-76 Journey results with Via London option

4.6.6 Mobility impaired

Public transport should be accessible for all customers, and people should be encouraged to use public transport as often as possible. This means that the information given to the customer should lower the barriers to do so. Especially for mobility impaired passengers, whether with a physical handicap (wheelchair, crutches, etc.) or with heavy luggage or prams, information on stairs, elevators, and escalators is most important. Without knowing this information, these potential customers will not use public transport in the first place or start their journey and have a good chance of getting stuck in large interchange buildings.

The Journey Planner gives transport authorities the possibility to directly take into account such handicaps within the journey planner and offer the customer the best possible path. This can result in advice to take a different route than the regular one or not use specific means of transport.

This information is administered in the DIVA program.



In the DIVA Stop management program, it is possible to define different footpath times between the station areas, depending on the connection between the different levels in the station. Footpath matrices for stairs, elevators, escalators and ramps can be filled in. (see Fig 2-5 .. 2-8 chapter2.2) Now, it is possible to calculate interchanges for mobility impaired, because the journey planner knows if there is a connection between the levels with for example an elevator.

Whether a vehicle is accessible for mobility impaired (low floor bus or bus with a ramp or lift) or not is administered in the tabular timetable. Accessibility is defined for each route.

In the following example, a journey from Tottenham Court Road to Limehouse is calculated. No options are set.

Fig. 4-77 Journey request without options



Fig. 4-78 Result overview without options

Fig. 4-79 Result details without options



At the interchanges the passenger has to use escalators and stairs to change platforms, but if the passenger is in a wheelchair, an elevator is necessary in order to change platforms.

By using the options of the journey planner, the journey can be planned directly with the option that stairs and escalator interchanges are excluded.

Fig. 4-80 Mobility impaired options

Using these options, the journey planner has found other journeys. There is no possibility for a wheelchair user to into or get out of the underground station Tottenham. Therefore, the journey planner suggests the passenger to take another route using a wheelchair accessible bus to the station Bank. At the station bank it is possible to use elevators to go to the platform. Also at the destination station Limehouse, elevators are available.



Fig. 4-81 Result overview with options

Fig. 4-82 Result details with options



Journeys for mobility impaired can only be calculated if the necessary data is available and administered in DIVA. Stops must have been modelled and footpath times must have been determined.

4.6.7 Footpath speed

Some people walk fast, others slow. If the journey planner would compute with a default footpath speed, it could happen that fast walkers have to wait long for their connection and could have taken a bus later. On the other hand, a grandmother with a walking stick walks very slowly and could miss her connection. In order to compute the best trips for all passengers, it is possible to vary the footpath speed. The following screenshots show an example of such a route. The walking speed can be defined in the options (fast, normal, slow). The first example shows a route from the Holiday Inn Hotel to Covent Garden. The footpath speed is set to fast.

Fig. 4-83 Input of journey request

Fig. 4-84 Walking Options: footpath speed fast



The journey planner calculates a journey with a 5 minutes footpath to the station Great Portland Street and the underground at 12:12, arriving at Covent Garden at 12:24.

Fig. 4-85 Details of the journey result with footpath speed fast

The following figures show the same route, however with a slow footpath speed.

Fig. 4-86 Walking Options: footpath speed slow



The journey planner calculates a route with a longer footpath (9 minutes) to the station Great Portland Street. The passenger has to leave the Holiday Inn 4 minutes earlier as the passenger walking very fast, in order to have the same underground. Additionally the journey planner has calculated one connection underground train later, compared with the calculated route for the passenger walking very fast. The arrival time is also later. The identical trip, however with a slow footpath speed, takes 7 minutes longer than the trip with a fast footpath speed.

Fig. 4-87 Details of the journey result with footpath speed slow

The parameters to control the change of footpath speed are

• ChangeSpeedNormal (100)

• ChangeSpeedSlow and (130)

• ChangeSpeedFast (70).

For example, if the footpath time for a particular interchange is set at 10 minutes, then the interchange time with the parameter ChangeSpeedNormal is calculated as 100% of the interchange time in the footpath matrix (10 minutes). Similarly, the interchange time with the parameters ChangeSpeedSlow and ChangeSpeedFast is calculated respectively as 130% (13 minutes) and 70% (7 minutes) of the interchange time in the footpath matrix.



4.7 Footpaths 4.7.1 General strategies for point to point journey planning

Ordinary Public Transport always starts and ends at stops. When the user specifies origin (or destination) of his request as a co-ordinate, the EMS has to find appropriate stops. This must be done for addresses, POIs, Postcodes and even stops (when the option optimise walking is set. See also 4.7.3 Optimised walking).

The EMS tries to find two different kinds of solutions:

1. Mono-modal solution: This solution is completely without Public Transport. The default case is a walk on the street network (GIS) within two times the maximum walk time. It is calculated by EFAITKernel.

2. Inter-modal solution: This solution uses the Individual Transport (default: walk) to reach the stops and combines it with Public Transport solutions between the stops. EFAITKernel calculates footpaths to stops near the origin point (or destination point). The result is a set of origin stops, each with a walk time from the origin point S. (The same for destination stops.) EFAPTKernel tries to connect the origin stops with the destination stops by the shortest possible connection.

A typical inter modal solution is a route between two addresses. Addresses are single house coordinates and can be displayed in the Geography. A special DIVA import program is available to import single house information from external sources. Typical sources are AdressPoint data in UK or Country specific address file in Vienna, Styria, Baden-Wuerttemberg or Northrhine Westfalia.

The following screenshot shows the program DIVA Geo with single houses in Vienna.



Fig. 4-88 DIVA Geo with single houses

The routing process could be divided in different steps:

1. Reference (link) address to the street network 2. Search for stops in the vicinity of the link point 3. Routing from origin stops to destination stops

The following figure show this process



Fig. 4-89 Door-to-Door journey planning

Step 1: Reference (link) address on the road network

The JP links the address on the nearest edge of the road network, by computing shortest distances.

Step 2: Search for stops in the vicinity of the link point

The JP searches for stops in the vicinity of the link point. The JP will search for stops that can be reached within a certain time. The specified maximum footpath time is taken into account. In the figure above, three stops for the origin and three stops for the destination address are found.

Step 3: Routing between these stops

Having found possible origin and departure stops, the JP will start computing the shortest path between these stops using the Dijkstra algorithm. The routing uses the computed departure times, which are different for the different departure stops. The footpath times to reach the final destination are added at the end of the route.

For test purposes a protocol exists, which logs stops found in the vicinity.

Street network Address Stop Footpath to stop (Step 1+2) public transport routes between stops (Step 3)

Stop B: 8,3 min

Stop C: 4,8 min

Stop F: 3,7 min

Stop D: 4,7 min

Stop E: 8,5 min

Stop A: 5,7 min

10 min.

11 min. 14 min. 12 min.

8 min.

10 min. 13 min.

11 min.

10 min.



Fig. 4-90 Protocol of the stop search in the vicinity of the address Grillparzerstr 18

The times at the end of each line show the computed footpath times from the starting point to the areas of the different stations. Footpath times are calculated in 1/10 minutes.

The example footpath times to two areas of the stop Grillparzerstraße (areas B 53 and B09) are found with 4,2 and 4,3 footpath minutes respectively. In addition the stops Haidenauplatz (area 000046), Leuchtenberg Unterführung (areas Bus89, Bus 44), Flurstraße (areas BusR, BusH) and the station Prinzregentenplatz (areas ZuPri, B53H, B53R, ZuPos, Lift, ZuThe and ZuGri) are found.

The journey planner shows route alternatives using different stops. Footpath times are always rounded up.

Fig. 4-91 Journey planner results

An escalation strategy defines, what will happen if no stops have been found within the default footpath time.



Rules:

- If no stops are found, the JP will increase the time gradually by doubling the default time until the universal MaxITTime or the MaxITTime for the mean of transport has been reached or until the maximum iteration number (how often the time is doubled) has been reached. These parameters are defined in the definition file.

- If the MaxITTime (universal or for mean of transport) has been reached and still no stops are found, the journey planner will switch to the search for routes by taxi, using the default taxi time in the options interface

- If no stops are found, the journey planner will increase the time by doubling it until the universal MaxITTime or the MaxITTime for taxi has been reached or until the maximum iteration number (how often the time is doubled) has been reached.

- If the MaxITTime (universal or for taxi) has been reached and still no stops are found, the journey planner will give a error message (no IT connection)

For each mean of transport, a MaxITTime can be defined:

• MaxITTime (universal, valid for all modes when the other parameters have not been set)

• MaxITTime100 (walk)

• MaxITTime101 (bike)

• MaxITTime102 (carry bike)

• MaxITTime103 (kiss&ride)

• MaxITTime104 (park&ride)

• MaxITTime105 (taxi)

The following figure show the entries of the MaxITTime values in the definition file.

Fig. 4-92 Parameter in the definition file



In the example above, the MaxITTime for walking is set to 40 minutes (MaxITTime100). This means that the journey planner will increase the searching time gradually by 10 minutes until the MaxITTime100 has been reached. If no stops are found, the journey planner will switch to the search for connections by taxi, using the default taxi time in the options interface. If no stops are found, the journey planner will increase the time gradually by 10 minutes steps until the MaxITTime105 (60 minutes) for taxi has been reached.

The MaxITTime100 and the other maximum times are reached at stopping pints on street or at entrances of stations. For stations extra time is needed to reach the departure platform. This extra time is needed for the footpath inside the building. Sometimes this time includes additional buffers. If in some layouts the outdoor footpath and the indoor footpath are shown as one leg, the time shown may exceed the maximum times by the indoor time.

Known problems

The following figure shows an example of linking address points to the nearest street.

Assuming houses 10, 12 and 14 belong to High Street, No 14 will link to X Street, because the distance is shorter. This may not be a problem, because nobody knows where the entrance to No 14 is located. However, in future it is planed to compare the name of the street from the network data with the name of the street from the address. Again this may lead to problems caused by different spelling of the street names because in most cases, the data source for the street network is different from the data source of the address data. However these should be very rare cases.

Special cases

In the case that origin and destination of an EMS enquiry are very close to each other special care needs to be taken.

High Street

No10 No12 No14

X Street



Fig. 4-93 Origin S, Destination D and the stops which are connected by walk

Special care is needed when the origin and destination stops overlap (stop M in Fig. 4-93) because in this case the algorithm can immediately terminate when reaching such a stop.

Examples

Walk only solution

S D

M

6

12 9

1

0

Start point Destination point Stop IT route



Fig. 4-94 Solution with walk only

Fig. 4-94 shows a solution where the fastest connection is equal to the previously calculated footpath. The destination stop D is part of the stop volume that has been found within the maximum walking time.

This has to be prohibited because walk only solutions are calculated by EFAITKernel (mono-modal solution).

Useless Public Transport Legs

EMS internally it is not allowed to change from one walk link to the next walk link. Therefore the algorithm tries to introduce PT legs before reaching the destination. Useless legs have to be identified.

S

D

6

12 9

Start point Stop IT route



Fig. 4-95 Useless PT legs

Inter-modal solutions

Fig. 4-96 shows a sensible inter-modal solution. The calculated intermodal route (8 min.) is faster than the IT route (SM + MD) (13 min.)

S D

M

6

12 9

1

0

Start point Destination point Stop IT route PT route

Bus 6 1 min

Bus 1 1 min



Fig. 4-96 Inter-modal solution with 6+1+1=8 mins journey duration

Fig. 4-97 shows a solution where the journey duration is longer than the sum of the IT route (SM + MD). This solution should be discarded.

Fig. 4-97 Inter-modal solution, passing M, but longer than walk sum

S D

M

6

12 9

1

0


Bus 6 7 min

S D

M

6

12 9

1

0


Bus 6 1 min



Rules

To overcome the situations shown above, following rules are applied:

Rule 1: If there is no Public Transport leg in the solution, discard the PT-Kernel solution (i.e. consider only the mono-modal result obtained by EFAITKernel).

Rule 2: If boarding and alighting take place at the same stop, discard the PT-Kernel solution.

Rule 3: If boarding or alighting takes place at one of the overlapping stops M, the PT-Kernel solution is discarded, if its journey duration is not less than the sum of the footpaths durations SM + MD.

When comparing the IT solution (if there is one) with the inter-modal solutions, the following rules apply:

Rule 4: Mono-modal minimum distance check 1: Before the journey calculation will be started a minimum distance check is accomplished. If the IT time (S-D) is lower than or equal to the sum of the minimum IT times to origin (S to stop) and destination (D to Stop), no journey request is sent to the PTKernel. The journey result only includes the mono-modal solution. In the example the IT time between S and D is 3 minutes. The minimum IT time from S to a stop is 1 minute and the minimum IT time from D to a stop is 2 minutes. This results that the minimum IT time to the stops is 3 minutes. In this case it is not necessary to send a journey request to the PTKernel, because it makes more sense for the passenger to walk directly from S to D needing 3 minutes.



Fig. 4-98 Mono-modal solution, walk to destination is faster than walk to stops

Rule 5: Mono-modal minimum distance check 2: If after the first check the journey planner calculates journeys a second check must be performed to be sure that the walking times to the stops is not longer than the direct walk from S to D. After a journey calculation the sum of all IT-Times to the stops will be compared against the IT time between S and D. If the IT time between S and D is lower than the sum of IT-times to the stops, the calculated journey will be flagged as inactive but is still part of the result. The layout has to make sure, whether the inactive results should be displayed or not.

In the example below the journey request passed check 1: IT time (S-D) is higher (7 minutes) than the sum of the minimum IT times to origin (S to stop) and destination (D to Stop) (2 minutes). Here the total IT time from S to stop (2 minutes) and D to stop (1 minute) is 3 minutes. This is lower that the It time directly between S and D. Therefore this journey is valid and will be displayed in the journey planner.

3 S D 1

2

3

2

Start point Destination point Stop IT route



Fig. 4-99 inter-modal solution, overall walking time of PT journey is smaller than direct walk

4.7.2 Addresses based on house number intervals

Some data sources do not provide single house data. Navteq data for example provides address intervals for edges. The following figure gives an example.

Assuming the edge 4711 belongs to High Street and house numbers 10 to 20 are located at the left side, whilst numbers 11 to 31 belong to the right side. Only the geometric information for the edge is provided and the two house number intervals. Knowing that 11 houses may belong to each side, it is possible to compute the position of an address by interpolation.

7 S D 1

2

4

1


3 2

High Street 10 30

11 31ID = 4711



4.7.3 Optimised walking for stop-to-stop journeys

With optimized walking the best possible solution is searched for. A stop to stop journey request will not only try to compute routes from the indicated stop, but will also use optimised walking. This means that the journey planner will take into account other stops:

- Stops that are allocated to the initial stop

- Stops that can be reached from the initial stop within the maximum IT time.

In both cases the initial stop will be connected with the origin stop with an IT path.

The following screenshot shows an example from the London journey planner. The fastest route in this case is to walk from the initial station Bank to the station Monument and travel with the underground to the final destination Victoria.

Fig. 4-100 Optimized walking at TfL

4.7.4 Point POIs

If a POI is assigned to a particular point, the POI has a coordinate. The routing to or from a Point-POI is equal to a door-to-door journey calculation.



4.7.5 Area POIs

The system supports both POIs (Point-POI) assigned to a point and POIs assigned to an area (Area-POI). If a POI is assigned to a particular point, the POI has a coordinate. The routing to or from a Point-POI is equal to a door-to-door journey calculation.

However, if a POI is assigned to a area, the POI does not necessarily have only one coordinate. The DIVA POI model allows to add access points to an area, in most cases entrances. An example is a cemetery or park with different entrances. The following figure shows the modelling of the Pragfriedhof, which is a cemetery in Stuttgart.

Fig. 4-101 Modelling of POI area

Three entrances are defined. All three entrances should be taken into account.

The following figures show two different arriving routes to the same POI (Pragfriedhof in Stuttgart), using different entrances.



Fig. 4-102 Result of POI area modelling in the journey planner

Fig. 4-103 Alternative result of POI area modelling in the journey planner

The routing process now takes the following steps:

1. Reference (link) entrances on the route network 2. Search for stops in the vicinity of the link points (one for each entry) 3. Routing between these stops



The following figure shows this process of a route from a Point-POI and an Area-POI

Fig. 4-104 Journey planning with POIs

If an area POI has no access points the centre point will be taken as origin or destination.

4.7.6 Post codes

Postcodes cover an area of a locality. For routing from or to a postcode, the coordinate, delivered with the postcode area is taken. Depending on the size of the postcode areas, this could be very imprecise, because the postcode will only be linked to one edge of the road network. From this edge the JP will look for stops in the vicinity and will use these stops for routing as described in 4.7.1 Door to Door journey planning.

The following figure shows the reference of a postcode area and the surrounding stops that have been found for this point.

Road network POI Stop Entrance Footpath to stop (Step 1+2) m:n routes between stops (Step 3)

Stop B: 8,3 min

Stop C: 4,8 min

Stop D: 4,7 min

Stop A: 5,7 min

10 min. 11 min. 14 min. 12 min.

8 min.

10 min.

13 min.

11 min.

10 min.

Stop E: 4,5 min

Stop F: 4 min

Stop G: 2 min

Stop H: 3 min

9 min.

8 min. 12 min.

9 min.

10 min. 14 min.



Fig. 4-105 Journey planning with postcodes

4.7.7 Journey planning with centre of locality

The user can also choose a centre of the locality as his origin or destination point. The coordinates of the locality centres must be available in the system data. The routing process is equal to door-to-door journey planning. The only difference is that the footpaths from the locality centre to the stops are not shown to the user because the coordinate of the locality centre is an arbitrary position. Only the walk times of these footpaths are taken into account whilst computing the optimal solution. The following figure shows this process.

Road network

Postcode area

Postcode coordinate

Stop

Stop A: 15 min

Stop B: 13 min

Stop C: 5 min

Stop D: 4 min

Stop E: 11 min

Stop F: 17 min Stop H: 12 min

Stop G: 11 min



Fig. 4-106 Journey planning with centre of locality

Step 1: Reference (link) centre of locality coordinate on the road network

The JP will link the centre of locality coordinate on the nearest edge of the road network.

Step 2: Search for stops in the vicinity of the link point

The JP will now search for stops in the vicinity of link point. The JP will search for stops that can be reached within a certain time. Default of 20 min footpath time is set. However, the user has the possibility to set the footpath time filter and change the max. footpath time. In the figure above, three stops for the origin and three stops for the destination centre of locality are found.

Step 3: Routing between these stops

After the JP has found all possible origin and departure stops, the JP will compute the shortest path between these stops using the Dijkstra algorithm taking into account the walk times from the coordinate to each stop.

Step 4: Display computed routes

The route from B to E is the best solution and will therefore be shown in the journey planner results. On the results screen the footpaths from the coordinate to the stop are hidden. This may lead to confusion because what the user sees is only part of the

Road network Centre of locality Stop

Footpath to stop (Step 1+2) m:n routes between stops (Step 3)

Stop B: 8,3 min

Stop C: 4,8 min

Stop F: 3,7 min

Stop D: 4,7 min

Stop E: 8,5 min

Stop A: 5,7 min

30 min.

31 min. 34 min. 32 min.

28 min.

30 min. 33 min.

31 min.

30 min.



search result. In particular, the departure and arrival times are shifted due to the hidden footpaths.

If in Step 2 no stops can be found in the neighbourhood (f.e. when the locality lies outside the area covered by the GIS data), pre-defined stops are used for the journey calculation. If available those stops are used which are marked as “centre of locality stops”. In localities where no stops are marked as centre stops, the stops with the most frequent service are chosen.

Of course, there are no footpaths from locality centre to stops when using pre-defined stops.

4.7.8 Input on map

In this example, origin and destination are selected through interactive maps. The links in the input interface enable to open the maps. By clicking the network plan, a stop on the network plan can be opened (Fig. 4-107).

Fig. 4-107 Link to network plan

Clicking a particular area on the network plan enables to zoom into this area and to select a station/stop. In this particular network plan (Fig. 4-108), only commuter trains and underground stations are shown. Of course, also a bus network plan can be used.



Fig. 4-108 Network plan

By clicking the desired station, the journey planner selects this station as origin point.

Fig. 4-109 Selection of origin on the network plan

The selected station is shown in the input interface (Fig. 4-110). By clicking the map icon, the map opens.



Fig. 4-110 Link to interactive map

The map shows the complete transport area. By clicking on the map, the map will zoom into the selected area.



Fig. 4-111 Overview map

The map module contains tools (zoom, navigation, overview map) to navigate through the map.

Stops and POIs can be selected on the map.

Also, by clicking on the map, the map will centre on this point. In this example the map is centred on the Abingdon Street (Fig. 4-112). By selection “Submit Map Center”, the journey planner will select this point as destination point.



Fig. 4-112 Selection of a particular point on the map

Both origin and destination are selected and the request for journeys can be submitted by clicking “Submit” (Fig. 4-113).

Fig. 4-113 Submission of journey request



The journey planner gives an overview of the calculated journeys.

Fig. 4-114 Overview of journey results

The detailed tabular view gives information about means of transport and maps.



Fig. 4-115 Details of journey results

The map from the Westminster Parliament St to the point in the Abingdon Street shows the footpath.



Fig. 4-116 Area map with footpath to the selected point



4.8 Bicycle access

4.8.1 Bicycle routes

The journey planner also gives the possibility to compute complete bicycle routes. The following example shows a route from an address to a Point of Interest.

Fig. 4-117 Input of a journey request

Fig. 4-118 Biclycle options in the request



Fig. 4-119 Bicycle route result details

The details contain information about the journey time and a link to the route map. The route map gives also a written description of the bicycle route.



Fig. 4-120 Bicycle route map



Fig. 4-121 Bicycle route description

4.8.2 Bike and Ride

With the option Bike and Ride, the journey planner computes journeys that include a path to the station or stop by bike. Only stations and stops that have B+R facilities will be taken into account. The following screenshots show such journey.

Fig. 4-122 Input of the journey request

The option B+R must be activated. A maximum cycling time can be defined.



Fig. 4-123 B+R Option in the journey request

Fig. 4-124 Overview of journey results

The journey planner computes the next journeys. The overview shows also the means of transport. In this case, also a bicycle symbol is given.



Fig. 4-125 Details of journey results

The details give more information about the route. The journey times for each leg are given. A link to the map is available. The map shows the bicycle path from the address to the station. A route description is also available.



Fig. 4-126 Bicycle map to the station

Fig. 4-127 Bicycle route description



4.9 Park & Ride, Kiss & Ride, Taxi & Ride The journey planner is able also to route car travel and show details on a map. The Park and Ride option must be activated in the options dialog. The following two screenshots show a door to door journey with a car travel to the station. Only stations and stops that have P+R facilities will be taken into account.

Fig. 4-128 Door to Station journey with taxi – result details



Fig. 4-129 Door to Station journey with taxi – taxi route map



Fig. 4-130 Door to Station journey with taxi – taxi route description

4.10 Demand responsive services This chapter has not been written yet.

4.11 Real-Time This chapter has not been written yet.



5 Specification of Origin and Destination

5.1 General Technique This chapter has not been written yet.

5.2 Localities This chapter has not been written yet.

5.3 Stops This chapter has not been written yet.

5.4 Addresses This chapter has not been written yet.

5.5 POIs This chapter has not been written yet.

5.6 Input on Maps This chapter has not been written yet.

Documents

Intermodal Journey Planner Business Rules · Journey Planner Business Rules JP Business Rules Page 2 of 168 2005-2010 Mentz Datenverarbeitung GmbH. All Rights Reserved. 2010-01-11