door to door information for air passengers · dora deliverable d3.1 door to door information for...

DORA Deliverable D3.1

Door to Door Information for Air Passengers

D 3.1 Initial Specification of the DORA Architecture

Editor: Jan-Niklas Willing & Tom Schilling, VMZ Berlin

Deliverable nature: Report (R)

Dissemination level: Public (PU)

Date: planned | actual 30 November 2015 18 December 2015

Version | no. of pages Version 1.0 85

Keywords: System Architecture, Available Data and Services, Interfaces


2 / 85

Disclaimer

This document contains material, which is the copyright of certain DORA consortium parties,

and may not be reproduced or copied without permission.

All DORA consortium parties have agreed to full publication of this document.

Impressum

Project acronym/name DORA Door to Door Information for Air Passengers

Project number/type 643973 Research and Innovation Action

WP number/leader 3 Claudia Baumgartner, VMZ Berlin

Task(s) no.(s)/leader(s) 1 Claudia Baumgartner, VMZ Berlin

Copyright notice

2015 VMZ Berlin and members of the DORA consortium


3 / 85

Executive Summary

D3.1 Initial Specification of the DORA Architecture sets the starting point for the further

specification of the DORA system. The document describes the methodological approach for

the development of the DORA technologies and applications and provides a draft version of

the overall architecture of the DORA system. The presented concept will be revised based on

the finally defined use cases (D2.4), further elaborated and documented in D3.2.

The document summarizes the preceding technical discussions between the DORA partners.

It outlines their joint view on the DORA system architecture and a methodological approach

on how to realize the DORA system in its full complexity.

The DORA system will integrate services already existing in the test sites as well as new

services that are going to be developed within the project. This is a particular challenge for

the technical coordination of the project, as different development methods are required

and have to be harmonized in an overall time plan. The results of the methodological

discussions between the technical partners and the corresponding time line for the further

specification and development activities are summarized in Chap. 2 of the document.

Due to the DORA scope to integrate the information services already available at the test

sites a detailed status analysis of data, services and interfaces has been conducted for the

Berlin cluster and the Palma de Mallorca cluster. The results and recommendations on what

system components should be integrated in the cross-border DORA system is documented in

Chap. 3.

Based on this a first draft of the DORA system architecture is depicted in Chap. 4. The overall

system is described and the underlying services are initially described and the planned

frontends of DORA system are outlined.

.


4 / 85

List of Authors

Organisation Authors Main organisations’ contributions

VMZ

Dr. Jan Kätker

Claudia Baumgartner

Jan-Niklas Willing

Tom Schilling

ToC, Executive Summary, 1.1, 1.2, 1.3,

2.1, 2.2, 2.3, 2.4, 2.5, 3.1.3, 3.2.1, 3.3, 4.1,

4.3.5, 4.3.6, 4.3.8, 4.4.1, 5, Annex

CSE Konstantinos Koutsopoulos 3.1.2, 3.2.2, 4.3.2

UPVLC

Benjamin Molina

Eneko Olivares

Carlos E. Palau

2.3, 3.1.2, 3.2.2, 4.3.2, 4.3.3, 4.3.4,

Internal Review

FBB Samir Djulancic 3.2.2, 3.2.3

EUREVA Philippe Martineau 4.3.1

ETRA

German Martínez

Santiago Martínez

Patricia Bellver

3.1.1, 4.2, 4.3.7, 4.3.9, 4.4.2, 4.4.3


5 / 85

Table of contents

1 INTRODUCTION ............................................................................................... 10

1.1 Purpose of the Document ................................................................................ 10

1.2 Structure of the Document............................................................................... 11

1.3 Organization of work ....................................................................................... 11

2 DEVELOPMENT METHODOLOGY ...................................................................... 13

2.1 Introduction .................................................................................................... 13

2.2 Software Development Methodology .............................................................. 15

2.2.1 Waterfall Model ................................................................................................... 15

2.2.2 Agile Development............................................................................................... 17

2.2.3 Prototyping .......................................................................................................... 19

2.3 DORA Tribrid Approach.................................................................................... 20

2.3.1 Time schedule for Development Activities ........................................................... 21

2.4 Architectural Goals and Constraints ................................................................. 22

3 STATUS ANALYSIS OF EXISTING DATA, SERVICES AND INTERFACES ................... 24

3.1 Palma de Mallorca cluster specific components................................................ 24

3.1.1 Journey to and from the Airport: Landside Transport Data and Systems .............. 24

3.1.2 Airport: Indoor related Data and Systems ............................................................ 28

3.1.3 Flights: Flight related Data and Services ............................................................... 28

3.2 Berlin cluster specific components ................................................................... 28

3.2.1 Journey to and from the Airport: Landside Transport Data and Systems .............. 28

3.2.2 Airport: Indoor related Data and Systems ............................................................ 39

3.2.3 Flights: Flight related Data and Services ............................................................... 39

3.3 Impact on the DORA Initial Architecture........................................................... 41

4 DORA ARCHITECTURE (DRAFT) ......................................................................... 43

4.1 Basis requirements on DORA architecture ........................................................ 43

4.2 Draft Overall Architecture ................................................................................ 43

4.2.1 DORA – City Nodes............................................................................................... 47


6 / 85

4.2.2 DORA – Service Platform...................................................................................... 48

4.3 DORA Open Service Protocol............................................................................ 50

4.4 DORA Open Application Protocol ..................................................................... 51

4.5 External Interfaces ........................................................................................... 52

4.6 DORA Services and Technologies...................................................................... 52

4.6.1 Waiting Time Detection ....................................................................................... 52

4.6.2 Indoor Location.................................................................................................... 54

4.6.3 Indoor Maps......................................................................................................... 57

4.6.4 Indoor Router ...................................................................................................... 61

4.6.5 Intermodal Landside Router (ILR) ......................................................................... 67

4.6.6 Flight Information Service (FIS) ............................................................................ 69

4.6.7 Trip Monitoring Service (TMS).............................................................................. 70

4.6.8 Door-to-Door Journey Planner ............................................................................. 71

4.6.9 Strategic Routing Service...................................................................................... 72

4.7 Frontends ........................................................................................................ 73

4.7.1 DORA Mobile Application..................................................................................... 73

4.7.2 DORA Web-based Application .............................................................................. 73

4.7.3 Operation Centre Application............................................................................... 74

5 CONCLUSION ................................................................................................... 77

ANNEX A STATUS ANALYSIS PALMA CLUSTER ...................................................... 79

ANNEX B STATUS ANALYSIS BERLIN CLUSTER....................................................... 81


7 / 85

List of Figures

Figure 1: DORA Research & Development domains ..............................................................13

Figure 2: Waterfall Development approach [13] ...................................................................16

Figure 3: DORA Tribrid Development Approach ....................................................................20

Figure 4: Time Schedule of DORA development process and methodologies applied ...........22

Figure 5: MobiPalma App .....................................................................................................27

Figure 6: Background map tiles.............................................................................................29

Figure 7: Colour coded traffic situation (Level of Service) .....................................................31

Figure 8: Traffic messages (here a road closure with detailed information) ..........................32

Figure 9: Available parking data for Berlin ............................................................................34

Figure 10: VBB webpage with Fahrinfo PT routing service ....................................................35

Figure 11: VIZ (Verkehrsinformationszentrale - Traffic Information Centre) webpage with

modal car routing .................................................................................................................36

Figure 12: VIZ webpage with modal walk routing .................................................................37

Figure 13: VIZ webpage with modal cycling routing ..............................................................38

Figure 14: Data services provided by the FBB .......................................................................40

Figure 15: Initial version of DORA system as described in DOA .............................................44

Figure 16: DORA system from a travel chain point of view....................................................46

Figure 17: DORA local City Node ...........................................................................................47

Figure 18: Service View: Interaction between DORA City Nodes and Service platform..........49

Figure 19: Application view: Data and Services provision via Open Application API ..............50

Figure 20: DIPS Approach .....................................................................................................55

Figure 21: Indoor Maps architecture ....................................................................................57

Figure 22: Georeferencing map through scaling and rotating ...............................................58

Figure 23: Map provided via OGC WMS ................................................................................59

Figure 24: POI Manager overview.........................................................................................60


8 / 85

Figure 25: Graph Manager overview.....................................................................................61

Figure 26: REST API overview................................................................................................61

Figure 27: Typical indoor routing scenario ............................................................................62

Figure 28: Indoor Router architecture ..................................................................................63

Figure 29: Basic navigation graph and edge cost assignment ................................................65

Figure 30: Transport Mode Combinations of the ILR – Examples ..........................................68

Figure 31: Door-to-Door-Journey Planner .............................................................................72

Figure 32: Door-to-Door-Journey Planner.............................................................................75

List of Tables

Table 1: Flight information for Berlin ....................................................................................39

Table 2: POI information at the airport for Berlin .................................................................39


9 / 85

Abbreviations

Abbreviation Explanation

BER Berlin Brandenburg Airport Willy Brandt

BLE Bluetooth Low Energy

CPM City Council of Palma de Mallorca

CSV Comma-Separated Values

D#.# Deliverable number #.# (D7.1 deliverable 1 of work package 7)

DoA Description of Action of the project

DORA Door to Door Information for Airports and Airlines

EC European Commission

EU European Union

FCD Fluid Car Data

FIS Flight Information Service

GTFS General Transit Feed Specification

H2020 Horizon 2020 Programme for Research and Innovation

ILR Intermodal Landside Router

ITS Intelligent Transport Systems

LBS Location Based Services

LUT Lappeenranta University of Technology

M# #th month of the project (M1=June 2015)

OAS Operation Assistance System

OCIT-C Open Communication Interface for Road Traffic Control Systems

PMI Palma de Mallorca airport

RSSI Received Signal Strength Indicator

TIC Traffic Information Centre

TMS Trip Monitoring Service

TXL Berlin-Tegel Airport

VIZ Verkehrsinformationszentrale / Traffic Information Centre

WMS Web Map Service

WP Work Package


10 / 85

1 INTRODUCTION

1.1 Purpose of the Document

The purpose of this document is to analyse the mobility data services existing at the test

sites and to give a description of the DORA architecture at an early stage of the project. This

document aims at presenting the initial DORA architecture as it has been discussed by the

project partners, thus it shows a draft DORA overview that outlines a commonly shared

understanding of the architecture, interfaces and components. It is important to mention

that this document has been written before the use cases and technical requirements for

the project have been finally specified. After the final specification of requirements and use

cases in D2.3 the ultimate DORA architecture will be specified (D3.2), followed by the final

specification of services (D3.3) and applications (D3.4). However, it is important to provide a

first draft of the DORA architecture in order to identify the main components of the DORA

system and their main relations. In this sense this document represents the starting point in

order to approach the DORA architecture. It is supposed to outline the DORA overall system

so that the framework and the direction for the development of platform and components

are defined more closely in the upcoming specification process.

To be more specific this deliverable is supposed to achieve three objectives:

Describe the overall development methodology for DORA software and technologies,

Summarize the existing data and systems that already exist in each test site and

which can be built upon and, finally,

Provide a first description of how the different components and systems will be

implemented.

The description of the DORA components is especially important in order to define the basic

interactions that are needed between internal DORA components and with external

components, since DORA is not an isolated system but has links to existing non -DORA

components.

More specific system components descriptions such as the specification of interfaces, or

component diagrams of services and applications will be provided in the upcoming

documents (D3.2-D3.4).


11 / 85

1.2 Structure of the Document

This document consists of five main chapters with different subchapters of which the first

chapter is the introduction to this deliverable.

Chapter 2 describes the development methodology in the project. The different

development approaches that are applied within the project, namely the waterfall model,

agile development and prototyping, are explained and assigned to the different DORA

development domains.

Chapter 3 provides an overview on the systems and data that already exist in the two test

sites (PMI and BER) and that can be built upon during the project. In chapter 3.1 the existing

services in Palma de Mallorca test site are described divided into landside transport,

terminal-related and flight-related data and systems. In chapter 3.2 the same analysis is

applied to the existing systems in Berlin test site.

In chapter 4 a first description of the initial architecture is given as a basis for the following

discussions about the specification of the final architecture. The main DORA components are

briefly presented divided into the DORA services and technologies in chapter 4.3 and the

DORA front-ends in chapter 4.4.

The conclusion in chapter 5 summarizes the findings of this document and points out which

next steps will have to follow in order to achieve a detailed specification of the fi nal

architecture.

1.3 Organization of work

The work package 3 (WP3) is led by VMZ Berlin as the technical coordinator of the project

and runs during M4 (September 2015) and M18 (November 2016); in total 14 months of the

overall project lifetime.

The present deliverable D 3.1 “Initial Specification of the DORA architecture” is led by VMZ,

too. It covers the first three months of the WP and especially the common understanding of

the upcoming subtasks in the definition of the detailed architecture and involved services.

To find a common technical approach within the entire project consortium three meetings

took place in the mentioned period during September till November. The work package was

launched at the 2nd Plenary Meeting in Palma de Mallorca, Spain (10-11th September) and

was in addition discussed during two separate full day technical workshops at 6th October

(Berlin, Germany) and 26th November (Frankfurt am Main, Germany). The two technical


12 / 85

workshops were used to extract the available data in both clusters (Palma de Mallorca and

Berlin) and to define the initial architecture and related responsibilities. In addition several

phone conferences and web-meetings were held to further discuss the general architecture

and to clarify specific issues bilaterally.


13 / 85

2 DEVELOPMENT METHODOLOGY

In this chapter the overall development methodology in the DORA project will be explained.

It gives an introduction on the overall approach pursued, the software development

methodology, the prototyping, their combination in the tribrid approach, as well as the

architectural goals and constraints.

2.1 Introduction

The developments made during the DORA project can be basically divided into three

research & development domains: applications, services, and technology. These domains are

not independent from each other but overlap in certain areas and influence each other. Data

collected from different technologies is processed by the DORA services and finally

presented to the DORA users in different end-user applications. In the opposite direction the

requirements of end-users and their applications affect the way the DORA services and the

DORA technology need to be designed. All three domains are based on a common set of

technical requirements but have different development process models.

Figure 1: DORA Research & Development domains


14 / 85

The application domain includes different DORA end-user applications, the operation centre

application as well as the possibility to provide DORA services or data to third-party end-user

applications over an open interface.

The DORA end-user applications are supposed to provide users with suitable route

suggestions according to their needs and with general travel information on the overall

door-to-door route. The DORA front-ends represent the user interfaces where all DORA end-

user functions are available and the routing parameters can be adjusted. In the DORA

project a mobile application for smartphones and tablets as well as a browser -based web

application will be developed. The development methodology for the end-user applications

have to take into account the special demands of possible end-users. So unlike the services

and technology developed in DORA the development of the DORA end-user applications has

to especially consider usability and layout aspects. The graphical user interfaces have to be

designed in a way that the handling of these applications is intuitive and simple. Feedback

from potential users and experiences from other projects as well as the findings regarding

user groups and mobility profiles (T2.2) have to be considered as early as possible in the

specification and development process.

The operation centre application is not focussed on passengers as end-users but will be

provided to the airport and traffic control centres in each test site. Layout and usability play

a subordinated role in comparison to the end-user applications. The development of the

operation centre application on the other hand has to strongly consider the technical and

strategic requirements in order to guarantee an added value for the organization and

coordination of airport-related traffic. As some of the project partners are important

stakeholders in the field of operation centres in each pilot, the requirements of the

operation centres towards the DORA operation centre application should be easily

identifiable.

The development of the open interface for third-party applications should take into account

two important aspects. First, the open interface should be designed in a way that third

parties can easily access the API, which means that standards and open protocols should be

used preferably. Second third parties should be enabled to not only connect to the entire

DORA system but also to single components that they need. The DORA architecture sho uld

be thus designed in a distributed and modular way.

The domain of the DORA services is characterized by developments made by different

project partners in parallel. All DORA services are going to be self-contained services but on

the other hand contribute to the overall DORA system and have strong interdependencies


15 / 85

among each other. In Task 2.4 the technical requirements for each service are being

collected including the requirements for the interaction with other services. The

development approach towards the DORA services will thus strongly rely on the predefined

requirements of the overall DORA platform and of the single services (also see chapter 2.2).

The development of the DORA technology again has special framework conditions. The

technology solutions developed in DORA, more precisely the waiting time detection and the

indoor localisation, consist of hardware and software components and therefore require a

different development methodology that the DORA applications and services. The

prototyping approach for the DORA technology is described in chapter2.2.3.

2.2 Software Development Methodology

For the software development methodology two different approaches will be pursued

depending on the special requirements of the different DORA domains: Waterfall and agile

development. In this chapter these two approaches are described shortly:

2.2.1 Waterfall Model

The waterfall model was published in 1970. It is the oldest software development

methodology and thus very well-established[11]. The waterfall development approach is

generally applied when there is a clear picture of what the final product should be and what

exact requirements and interdependencies with other systems have to be taken into

account for the development [10]. When the developed service is part of a wider project in

which interactions with other services or superordinate platforms are required and every

single service plays a certain role in this system, it is important to perform the development

process of the single components in a way that was agreed upon among all involved

development partners. This requires a detailed coordination process before the actual start

of developments.

This approach is called “waterfall model” as it describes a linear, non-iterative development

process. The waterfall model consists of five steps that are carried out one after the other

(Figure 2: Waterfall Development approach). Each step has to be fully completed before the

next can begin. The first step is a requirement analysis where the technical requirements of

the component itself towards other components but also from other components towards

the own component are collected. In this step it is defined which data is processed to and

from a component, which data format is needed and how possible interfaces need to be

designed in order to fulfil the requirements. In the second step the component is designed


16 / 85

based on these requirements. Before the development process starts it should be double -

checked with involved partners if the design fits into the overall system. In step 3 the actual

development process is carried out. Step 4 is the testing of the developed services and step

5 consists of the operation and maintenance of the components.

The waterfall model should be used if,

the requirements are very well known, clear and fixed

the technology is understood

the requirements are not ambiguous

the project duration is short.

Figure 2: Waterfall Development approach [13]

In the DORA project the main services are based on existing system components and have a

high TRL. These services are described in the DOA. Thus, the waterfall model is the

appropriate method for the development of all main service components. These include the

Door-to-Door Journey Planner, the Indoor Router, Intermodal Landside Router, the Flight

Information Service, the Trip Monitoring Service as well as the Strategic Routing Service. In

order to start the first step of the waterfall model the requirements of each compo nent are


17 / 85

being collected in Task 2.4. These requirements, together with the defined use cases in Task

2.3, will then be the basis for the specification and design of the DORA services.

However, as during the integration and testing process of the DORA syst em demand for

adjustments might occur, the system and its components will most likely have to be slightly

modified even after the specification of services in WP 3. This is why the DORA tribrid

approach is applied (see chapter 2.4) in order to allow different development methodologies

providing different levels of flexibility.

2.2.2 Agile Development

As a response to the strongly regulated waterfall-oriented software development methods

in the 1990s agile development methods were introduced [10]. In contrast to the waterfall

the agile software development methodology is characterized by its iterative and

evolutionary approach.

In general it is applied when there is not a clear picture of what the final product should look

like and when the scope of a project might change during the development process [10].

Agile development is especially of advantage when the product is targeted for a

technological environment which is rapidly changing and requires fast adjustments [12]. A

precondition nevertheless is that developers are able to think independently and react to

changing requirements. The development of the DORA applications such as the mobile

application, the browser-based web application, the open interface for third parties as well

as the operation centre application is set in such a fast changing environment. In order to

keep up with the technological progress and the changing user requirements in this field the

agile development approach is applied for the development of the DORA frontends.

The general proceeding of the agile development approach starts with a relatively open

“discovery” process in a first sprint in which the final result is not predefined. The

component will be designed, developed and assessed. Based on the outcomes of the first

sprint, the second development loop will be carried out. Taking into account the positive and

negative aspects of the first sprint, the component will thus be refined and improved. This

proceeding will be repeated in several development loops until the product is satis factory.

However, there probably won´t be a final static product as the user requirements and the

technological framework conditions are constantly changing. That means that also the DORA

end-user applications have to be constantly checked against the technological progress and

the changing user demands.


18 / 85

Agile methods should be used when:

not all requirements are fixed in the beginning of the project

features have to be added or removed, e.g. based on user feedback

the technologies or features are new and not completely understood.

The DORA project work plan provides an iterative development of the end user application

to included user´s feedback in the development process. This strongly indicates to apply the

agile development methods for the development of the end user application.


19 / 85

2.2.3 Prototyping

Beside software within DORA project also hardware will be developed. The systems for

waiting time detection and indoor location require parallel activities for hardware (cameras,

beacons) and software development. This means that the developers have to deal with

incomplete requirements and have to provide quickly cheap results to decide whether the

approach is being developed further or rejected. This leads to a prototyping methodology.

Software development approaches incorporating prototyping have gained respectability as

they have proved to be able to dynamically respond to changes in user requirements [3],

reduce the amount of rework required and help control the risk of incomplete requirements

[3]. Researchers have also noted that prototyping enables us to partition the development

process into smaller, easier to handle steps [4], is cost-effective [5,6,7], helps determining

technical feasibility [3], is a good risk management technique [8] and results in grea ter user

involvement and participation in the development process [9].

Prototyping is characterised as an iterative procedure following the four steps, :

1) Specification of preliminary requirements

2) Development of a working prototype

3) Implementation and testing of a working prototype

4) Revision and enhancement of the prototyping system.

This process goes through several iterations which means that step three and four are

repeated until the user accepts the system.

The main disadvantage of the prototyping process is the incomplete or inadequate problem

analysis, caused by the “implementing and repairing” way of building systems. This leads to

a potential increase of complexity, as the scope of the system may expand beyond the

original plans.

Prototyping should be used if

quick development of functions in needed

there is a risk of a complete redesign

there are dependencies to other developments (e.g. hardware9.


20 / 85

Due to the fact, that the waiting time detection and indoor location technologies are

strongly depending on the hardware components, prototyping is regarded to be the most

appropriate method and used to develop these technologies within DORA project.

2.3 DORA Tribrid Approach

In the previous chapter it was pointed out that with regard to the different core areas

services, applications and technology the optimal approach for the overall development

activities is combining the three different development methodologies: This leads to a

“tribrid” approach.

The DORA tribrid approach is the overall concept of the development methodology

combining the Waterfall Model, Agile Development and Prototyping. For each domain of

components to be developed an appropriate development approach is applied: Agile

Development for the DORA applications, the Waterfall Model for the DORA services and the

Prototyping approach for Waiting Time Detection and Indoor Localisation.

Figure 3: DORA Tribrid Development Approach

All three development activities need a common base as a starting point that needs to be

consistent, fixed and has to cover the requirements of all three methods.


21 / 85

In particular these are

Market Analysis (D2.1)

User Groups and Mobility Profile (D2.2)

a complete list of DORA use cases (D.2.3)

a status analysis of existing systems in the pilot (D3.1)

a complete list of technical and legal requirements (D2.4)

a final DORA architecture (D3.2)

Open DORA Service API (D3.2).

2.3.1 Time schedule for Development Activities

Figure 4 illustrates the time schedule for the different development activities.

It provides that the basis for the development process is established in M10 to start the

three development activities.

For the time being the functional requirements and the user requirements for the

application (D3.3) are not required in the final version. The three activities run

autonomously following their specific approach. The exchange of information between the

development activities is provided by the periodic project management meetings. In case

additional clarification is needed, extra technical workshops will be arranged.

The development phase lasts for 11 months (9 month software development and 2 month

module testing). After that, there will be a one-month integration test followed by a 2-

month pre-test of the overall system (M24). After that in M25 the pilot demonstration will

start.


22 / 85

Figure 4: Time Schedule of DORA development process and methodologies applied

2.4 Architectural Goals and Constraints

One of the top priorities in this project relates to the integration aspect of the entire

approach. DORA tries to include and combine as much as possible local and existing data,

services and components into a new platform approach. During the definition process of the

DORA architecture special attention is given to related architectural goals and constraints,

which will be described in the present section.

In principle the main DORA architectural goal foresees the development of an open and

interoperable platform which allows the adaption of new service providers on the backend

site and the provision of the DORA services to further frontends (web frontends or mobile

applications) via open interfaces. Following this, the platform will be transferable for the use


23 / 85

at other places and areas in addition to both clusters (Palma and Berlin) through the

integration of further existing data, services and route planners available at the pilots.

The platform and its integrated and related services should be flexible enough to act and

react to current system inquiries. For this reason, load balanced and scalable services are to

be developed and used.

The entire approach follows the use of Intelligent Transport System and EU wide as well as

de facto standards for the realization of the system architecture. Of course the to be defined

architecture follows official European data security and data privacy issues and takes as well

national and regional law into account.

Against mentioned goals several constraints exist. In particular, details regarding the use of

vendor or existing systems could restrict the (new) functionalities of the DORA platform and

related services. Especially, the indoor subsystem depends on the airport because it

interacts directly with the hardware inside it.

For security reasons and to avoid network problems the indoor system has to be instantiated

on each airport and should not offer any public services directly (restriction of the security

architecture). This applies to technical components like the web environment (server

configurations, firewall), server systems (operating systems) as a whole as well as the used

network topology. In addition, the use of third party software and related licensing models

has a restrictive character on the realization and software development process.


24 / 85

3 STATUS ANALYSIS OF EXISTING DATA, SERVICES AND

INTERFACES

This section will explain what kind of data and services are available in both clusters (Palma

and Berlin). It splits available services and data being important for a long term door-to-door

trip into the situations which requires that specific information:

Journey to / from the airport

Staying at the airport

The flight

3.1 Palma de Mallorca cluster specific components

3.1.1 Journey to and from the Airport: Landside Transport Data and Systems

In this subchapter all for the landside journey relevant existing services and data will be

described. In addition, the following part deals with not presently connected data and

services but with data which can be adapted and used in the project.

Looking at the table “Status Analysis of existing services and data” (Annex A) the data and

services can be split into four different groups:

Static infrastructure data

Real Time infrastructure data

Mobility services

Local modal routers

In the following for all groups the related entities and or connected attributes will be

described.


25 / 85

Static infrastructure data

Map tiles

The basis for the presentation of infrastructure data and information on a map in end user

services are map tiles – especially for the background map. The tiles are square bitmap

graphics which are displayed in a grid arrangement to show the map.

For the Palma de Mallorca cluster there is the availability of the following sources: OSM or

Google, which is suitable for outdoor but not for indoor maps. The so called web map service

(WMS) provides the map tiles for the DORA end user applications (Web GUI and App). The

service will be accessed via a pull request. If i.e. the user selects a different map section

because of a zoom in or zoom out in the map, a new loaded map tile will be presented. The

final decision regarding the source will be described in the document D3.2 DORA

Architecture.

Transport network

The detailed network for streets, footpaths and cycling routes is not available in Palma de

Mallorca, whereas the public transport network as well as the public transport stops is

available by means of GTFS (General Transit Feed Specification) files from EMT.


Road network

All the data regarding the Road Network (Traffic Situation, Accidents, Events, and

Construction Sites) is fully available but pending on authorisation, particularly the interurban

data (segment from the City of Palma de Mallorca to the airport) which belongs to the

regional government. The urban road network is owned and will be provided by the City of

Palma de Mallorca via ETRA’s Distributed Urban Traffic Control System (ETRA SDCTU).

Public Transport network

Public Transport Real Time Delays & Disruptions information is available as Web Service,

owned by EMT and will be provided by its ETRA Operation Assistance System (OAS).


26 / 85

Mobility services

Scheduled services

Public Transport timetables and price model is and will remain available for the project

lifetime. Both are provided as GTFS files by EMT and by its ETRA Operation Assistance

System (OAS).

Flexible services

From all the desired information within these categories: Station based vehicle sharing,

Station based bike sharing service, Station based other sharing service, Free -floating vehicle

sharing service, Free-floating bike sharing service, Free-floating other sharing service, Car-

pooling service and Taxi; only Station based bike sharing service and Taxi information is

available. The first one contains the geolocation of stations and available spaces for bi kes,

and are for public purpose (open data); besides it is owned by MobiPalma 1 and provided by

CPM (City of Palma de Mallorca) in the project framework. Taxi information availability is

related to the static geolocation of taxi stations, provided as a plai n text file by its owner:

CPM.

Vehicle parking

Regarding the vehicle parking information, only the Parking places (referred to both private

and public underground parking) and Real Time Capacity will be a vailable for the DORA

project. Unfortunately, car parks that refer to surface parking spaces won’t be available.

Available information on vehicle parking will be provided by CPM’s MobiPalma’s API using a

public-private key authentication.

1MobiPalma is a free app of the Palma de Mallorca city council and provides information on the public

transport service (including EMT and BiciPalma), car parks and real -time traffic info of Palma de Mallorca.


27 / 85

Figure 5: MobiPalma App

Local modal Routers

Public Transport Router

A single public transport router is available at the Palma cluster and will be integrated into

the local DORA systems. That information will be provided by CPM’s MobiPalma’s API using

a public-private key authentication.

Car Router

The car routing functionality will be provided by ETRA. Here the service owner is Google

Services who provides their API for that specific modal router. It indicates standard driving

directions using the available, regional road network.

Walking Router

Like the mentioned car router, a walking mode router will be included through a Google

Services license. The service is owned by Google and will be provided to the project by ETRA.

When this service is requested walking directions via pedestrian paths & si dewalks (where

available) will be calculated.


28 / 85

3.1.2 Airport: Indoor related Data and Systems

Palma de Mallorca airport is already covered by Google for Street View and Indoor Location

services (but not indoor navigation). Indoor Location has been based on existing WiFi

Infrastructure with 10m accuracy. It is not known whether the coverage is based on WiFi

signals that can be considered as infrastructure facilities (that are not expected to change,

e.g. airport WiFi services) or not (that may change in the future, e.g. a shop closes and a new

one with a different AP opens). This aspect probably has to be clarified during a testing

session with invocation of the Google API so that those APs that are considered as

ephemeral should not be taken into account for indoor positioning. Potentially part of the

location resolution logic can be performed by taking into account the fact that such a service

is already provided by Google. The DORA enhancement by the installation of additional WiFi

Beacons may achieve better accuracy in places considered important due to the increased

number of parameters that can be used (precise location, signal level adjustment).

Additionally, DORA Beacon positions can be also registered with Google Services for better

location estimation as retrieved from Google Services. The integration with Google Services

has to be evaluated and potentially included in future version of the architectural aspects.

3.1.3 Flights: Flight related Data and Services

An existing web service provides the current real time flight information for all arrivals and

departures at the airport of Palma de Mallorca. AENA is in charge of the service and provides

this component to the DORA project. It can be used through a pull method to request the

needed information. A restriction is representing due to the fact that the web service

provides the mentioned data for the current and for the next day. The data is not available

for a later time.

3.2 Berlin cluster specific components

3.2.1 Journey to and from the Airport: Landside Transport Data and Systems

In this subchapter all existing data and services relevant for the landside journey will be

described. In addition, the following part deals with not presently connected data and

services but with data which can be adapted and used in the project.

Looking at the table “Status Analysis of existing services and data” (Annex B) the data and

services can be split into four different groups:


29 / 85

Static infrastructure


Mobility services

Local modal routers

For all mentioned groups the related entities and or connected attributes will be described.

Static infrastructure

Map tiles

The basis for the presentation of infrastructure data and information on a map in end user

services are map tiles – especially for the background map. The tiles are square bitmap

graphics which are displayed in a grid arrangement to show the map.

For the Berlin cluster an internal at VMZ existing service provides them based on one of the

following sources: OSM or Google. The so called web map service (WMS) provides the map

tiles for the DORA end user applications (Web GUI and App). The service will be accessed via

a pull request. If i.e. the user selects a different map section because of a zoom in or zoom

out in the map, a new loaded map tile will be presented. The final decision regarding the

source will be described in the document “D3.2: Final Specification of the DORA

architecture.”

Figure 6: Background map tiles


30 / 85

Transport network

The available detailed network for streets, footpaths and cycling routes will be based on the

so called Berlin Detail Network. VMZ Berlin takes care of the official network of the city of

Berlin. It is a static network.

The Berlin and Brandenburg network for the public transportation network wil l be provided

by VBB and is an OSM based web service.


Road network

The VMZ Berlin is the provider of the Traffic Information Centre Berlin (TIC Berlin). The TIC

Berlin calculates the current traffic situation based on a data fusion process from at the road

installed detection systems and Fluid Car Data (FCD) from the operator TomTom. The

calculation results in a colour coded level of service Traffic Situation. It presents the real time

situation of the road infrastructure in red, yellow and green. This graph can be visualized

through the mentioned WMS service. The update interval of this information is every five

minutes.


31 / 85

Figure 7: Colour coded traffic situation (Level of Service)

In addition, current accidents, events, road closures and construction sites in the street

network will be provided in real time from the TIC Berlin through a realized Siemens Concert

interface which follows the Open Communication Interface for Road Traffic Control Systems

(OCIT-C) standard. For each event the position in geo coordinates (LAT/LONG), category and

a detailed description of the event is available.


32 / 85

Figure 8: Traffic messages (here a road closure with detailed information)

Public Transport network

Real time delays and disruptions in the public transport network of the Berlin cluster will be

provided by the local transport authority (VBB). Their own VBB Fahrinfo is a web service

which provides via pull and or push methods the related information for DORA.

Mobility services

Scheduled services

Regarding the scheduled time tables and the price model of the public transport system in

the Berlin cluster, DORA will be provided by the VBB with the mentioned VBB -Fahrinfo web

service. This existing component provides all planned and not real time data to the DORA

backend services, too.


33 / 85

Flexible services

DORA integrates in the Berlin cluster as many as possible new and innovative mobility

solutions. In particular car and bike sharing will be included. By now, the VMZ Berlin is

connected through proprietary provider interfaces to the following operators:

Car sharing (free floating and station based): DriveNow, car2go, Multicity, citeecar

and Flinkster

Bike sharing (station based): nextbike and Callabike

For all of the mentioned services the available vehicles and their related positions are

provided through the realized interfaces in real time to the local VMZ backend and will be

provided to the DORA services.

At the moment the VMZ proofs the adaption of a new electric scooter sharing system which

is called eMio. In this regard, a final decision of the adaption of this service to the DORA

components will be made in the coming months and will be announced in the second

deliverable of this work package (“D3.2: Final Specification of the DORA architecture.”).

Ride sharing functionalities, meaning to share a trip with passengers is currently available in

the Berlin cluster backend system at VMZ Berlin, too. The dynamic ride sharing service flinc

allows spontaneous carpooling for short distances. With the flinc system (www.flinc.de)

drivers and passengers offer and search for journeys. After finding a match they contact

each other to arrange any details for the journey(s). Costs, meeting points and other det ails

like space for luggage are agreed on. They then meet and carry out their shared car

journey(s) as planned.

Vehicle parking

Car parks and park and ride (P&R) facilities will be included in DORA as an important

information for car drivers too. The static information of 240 parking areas is available in

static CSV format at the TIC Berlin and therefore at the backend systems of the VMZ Berlin.


34 / 85

Figure 9: Available parking data for Berlin

In addition, real time capabilities could be included through an existing interface to the

operator ParkU, too. The real time data about available parking facilities will be provided by

this operator for just a small number of parking spots. The available real time data covers

the location in geo coordinates, the address and the real time capacity.

Local modal Router

The DORA architecture will use existing routers, calculating single itineraries for each mode

of transportation. For the Berlin Cluster local modal routers are available for relevant inner

urban transport modes: public transportation, private car, walking, cycling as well as shared

bike and shared cars.


35 / 85

Public Transportation Router

The specialized router for the calculation of public transportation parts is owned and in

parallel provided to the DORA consortium by the VBB. This single router is able to calculate

the exact route including turn advices for all Berlin and Brandenburg related public transport

modes (Bus, S-Bahn/suburban railway, U-Bahn/metro, tram and regional trains). This

dynamic component takes into account real time departures, delays as well as mode

changes between different public transport vehicles.

The following screenshot (Figure 10) shows the VBB own webpage as one frontend how the

service can be used by the VBB passengers. This component is currently available as a mobile

application too.

Figure 10: VBB webpage with Fahrinfo PT routing service

Car Router

The local modal router for the motorized individual transport, especially the car will be

provided by the VMZ Berlin. This component is owned by the operator TomTom and used

through a realized interface by the VMZ. A data delivery contract regulates the use of the

component in the DORA project. The router is able to calculate routes based on the


36 / 85

optimization criteria travel time and trip length. The car router is highly dynamic and takes

into account the real time traffic situation for route calculations. That means that the routing

component calculates alternative routes compared to normal ones in case of disruptions,

road closures or congestions. The single modal router is integrated into the TIC Berlin, like

the following screenshot (Figure 11) demonstrates.

Figure 11: VIZ (Verkehrsinformationszentrale - Traffic Information Centre) webpage with

modal car routing

Walking Router

Walking modes will be calculated by a single modal router from Google. The VMZ Berlin

operates the VIZ / TIC (Traffic Information Centre) and will contribute this component to

DORA project. As for the TomTom car router a data delivery contract regulates the use of

the component. The single modal router is integrated into the TIC Berlin as shown in Figure

12.


37 / 85

Figure 12: VIZ webpage with modal walk routing

Bike Router

Single Cycling modes will be calculated by a single modal router which was developed by

bbbike. This specialized bike planner covers the entire area of Berlin and Brandenburg. In

addition, it allows the setting of several options regarding the route optimization (see Figure

13) such as preferred street and surface types.

The VMZ Berlin operates the TIC Berlin and will provide this component to DORA project. As

for the TomTom car router a data delivery contract regulates the use of the component. The

single modal router is integrated into the TIC Berlin as well, like the following screenshot

shows (Figure 13).


38 / 85

Figure 13: VIZ webpage with modal cycling routing

Car- and Bike sharing Router

In addition to the single modal routers the VMZ Berlin has been developing own

components based on the routers and data from the mentioned providers to calculate

routes for new and innovative inner urban modes of transport. A special car sharing router

which uses the car route functionality from TomTom in combination with real time

availabilities of several car sharing operators is available, too. This routing component works

for free floating and station based car sharing providers. The included operators are: the Car

sharing operators: DriveNow, car2go, Multicity, citeecar and Flinkster

Also the bike sharing functionality has been implemented by VMZ. VMZ integrates data on

current availabilities of shared bikes in the above mentioned bbbike router to calculate trips

from sharing station to sharing station including the walking modes to and from the stations.

The included operators the bike sharing (station based) operators: nextbike and Callabike


39 / 85

3.2.2 Airport: Indoor related Data and Systems

Berlin Schönefeld Airport is covered by Google Maps including level information. Position

accuracy, however, is not adequate. This is a typical case for which the use of DIPS Beacons

can be beneficial to position resolution. As indicated also for the Palma Cluster, integration

of the DIPS functionality with the Google Services may worth considering due to the fact that

mapping info is already available. The fact that indoor location services are planned for a

future project has to be clarified so that DIPS integration can be beneficial for both DORA

platform and airport new services. The existing maps are currently available in Microstation

(with architectural notes) and PDF format.

3.2.3 Flights: Flight related Data and Services

The set of data and services have been summarized and is presented below:

Table 1: Flight information for Berlin

Static data: Flight information (FBB)

Description FBB provides information for a certain flight (arrival/departure), boarding

gate, check in nodes, weather, Airvis, flyamo web service (only for the push

notification) and Airline data (phone numbers)

Protocol The web service is based on REST-Style web services which are implemented

in PHP (ZEND Framework).

Comments The result of the output is always a JSON file.

Table 2: POI information at the airport for Berlin

Static data: POI information (FBB, UPVLC)

Description FBB provides information about several POI – shops, restaurants and services

Protocol The web service is based on REST-Style web services which are implemented

in PHP (ZEND Framework).

Comments The result of the output is always a JSON file.


40 / 85

Figure 14: Data services provided by the FBB


41 / 85

3.3 Impact on the DORA Initial Architecture

The above mentioned services and data give an overview of the current or during the project

life time available content, which will be theoretically used and integrated into the overall

DORA architecture.

It turns out that a lot of services are already in place in both clusters (Palma and Berlin).

However, the included granularities, details and functionalities are different in terms of local

peculiarities. This situation has to be considered as given and impacts the initial definition of

the overall DORA architecture. Especially in terms of the integration of each available data

and service source, the DORA architecture should be able to adapt to it, so that the

important data can be used within the project.

The DORA platform has to match local available data in an interoperable way to provide it in

a standardized form to all new DORA services and applications, which have to be developed

within the project.

The specific available data and services for the Palma cluster show that for the major modes

of transportation (car, walk, public transportation and flight related information) the needed

information is already in place and can be used.

The Berlin cluster goes a step ahead because of a wider set of available transport options to

and from the airport. Especially the installed transport systems like car and bike shar ing

which are provided by different operators allows the local cluster to proceed with a larger

set of mode alternatives for the land side transportation. The provided interfaces and

includable data to different operators will form the basis for that.

An important impact on the DORA architecture is the fact that most of the includable data is

already available in real time. This plays a significant role regarding the information

provisioning through the DORA services in cases of disruptions and disturbances . The DORA

system should take into account the real time updates and inform the end user accordingly.

Most of the data sources provided by DORA consortium partners are owned by other

operators or institutions who are not involved in the project. . This is an advantage for the

DORA platform because it ensures up-to-date and reliable data. On the other hand it

requires the capability to react to interface changes or updates of the data -providing

systems in quick and flexible manner. .

Flexibility is another important fact which has an impact on the architecture. Besides the

mentioned available sources, DORA should be open to adapt new data sources, which are


42 / 85

not mentioned in the status analysis and in the above written chapters. If a new service

operator is interested in adapting to the DORA system, the system should provide open

access.


43 / 85

4 DORA ARCHITECTURE (DRAFT)

4.1 Basis requirements on DORA architecture

In this chapter the initial idea of the DORA architecture is presented, as well an introduction

to the DORA services, interfaces and frontends.

The purpose of this document is to set a starting point for the upcoming detailed

specification of the new DORA technologies, applications, services and interfaces. It offers a

draft of the future DORA system that will be used to start the specification work.

The initial architecture is thus being described from a high-level point of view, showing the

direction and cornerstones of the final architecture yet to be described after the

specification of detailed use cases and single requirements for each component in D3.2

(DORA Architecture). However, the basic requirements of the DORA architecture can be

summarized already at this stage. The DORA system has to be

• Open: DORA provides open interfaces for applications and service providers

• Distributed: Integration of local data and local services

• Scalable: n cities with m airports each one can be connected to DORA

• Transferable: Easy to implement the whole DORA system or single DORA services to

other cities or airports

• Reliable: System’s functionality should not depend on one a single critical access

point

• Polymorphic: Nodes on DORA’s network should all offer the same interfaces so that

DORA applications can be developed by any technology and the DORA applications

are interoperable with all nodes.

4.2 Draft Overall Architecture

This chapter will focus on the context perspective of the architecture. That means that we

will describe the internal structure, the interactions between services and data flows. The

functional view on the architecture is outlined in section 4.6 describing the services and

technologies.


44 / 85

The very first concept of the DORA architecture was already included in the DOA of the

DORA project. It provides a three-layer system consisting of an application-layer, the DORA

platform and the distributed existing, new or modified services. The overall architecture is a

decentralized with a central platform and central applications.

Figure 15: Initial version of DORA system as described in DOA

Based on these first ideas the architectural concept has been further discussed during the

previous months and is outlined in a draft version in the following section.

The overall initial architecture is supposed to give an overview about how the external and

the internal DORA services are connected to each other in order to form the overall DORA

system. As a starting point it is helpful to frame the overall DORA system from a travel chain

point of view (see Figure 16) apart from the DORA architecture. This should give an


45 / 85

introductory idea about the actual objectives of the DORA architecture and the demands for

its performance.

The DORA travel chain can be divided into five major parts. The landside tra nsport part in

Berlin, the terminal part in Berlin, the actual flight part of the trip, the terminal part in Palma

as well as the landside transport part in Palma. For each part of the trip chain there are

dedicated routing services providing the respective partial routes. For the landside transport

part in Berlin the partial route is calculated by the Berlin instance of the Intermodal Landside

Router (ILR). Different connection points at the airports (e.g. parking facilities, public

transport stations, taxi stands) have to be determined where the routing is taken over by the

indoor routing instances of Berlin or Palma that integrate real-time waiting time information

and the data of the indoor location technology. The Flight Information Service provides the

route information for the middle part of each overall door-to-door-route. The partial routes

calculated by the different routing services are combined to an overall route by the Door-to-

Door Journey Planner. This information is provided to the DORA user v ia one of the DORA

end-user applications. It is important to mention that the figure below only shows the main

DORA routing services in their relationship to Door-to-Door-Mobility of the DORA user and

not all DORA services.


46 / 85

Figure 16: DORA system from a travel chain point of view

Based on this overall picture and the mentioned system requirements the DORA initial

architecture has been discussed in more detail among the project partners and has been

revised according to the existing mobility options and services.

The purpose of the initial architecture is to prepare the ground and roughly indicate the

direction for the following specification of the detailed DORA architecture in D3.2. It is

supposed to depict the communication between different DORA components, between

DORA services and external systems and the provision of information towards applications.

The added value of the DORA system for future mobility information services is to integrate

the locally existing services and to provide on the other side an open system that is easily

accessible by potential third parties and transferable to other cities and airports.


47 / 85

4.2.1 DORA – City Nodes

In Berlin and Palma de Mallorca data and services related to landside transport are alread y

integrated in existing City Platforms that provide real time data and modal routing services

for public transport, car traffic, bike as well as for car- and bike sharing.

These locally available system resources will be integrated in so -called City Nodes that

include all test site specific data, services and applications related to landside transport and

airports (Figure 17: DORA local City Node). Open DORA APIs provide access to these City

Nodes for DORA services as well as for third parties and new service providers.

Figure 17: DORA local City Node

The City Nodes are characterised by different features that should be summarized at this

point. Firstly, they are hosted and operated locally in the test site. Furthermore they

integrate and provide all test site specific data and services for landside mobility. If there is

an existing city platform which has already integrated the local transport information the

whole platform can be integrated in the City Node. If not, the different service and routing

providers will be integrated individually. Also, the services that will be implemented as a new

part of the airport infrastructure are located in the City Node. This especially refers to the

Waiting Time Detection service which, for security reasons, has to run on local servers inside


48 / 85

the airport. Finally, the City Node contains the local Incident and Information Management

Systems since they are usually operated by local Traffic Control Centres.

The City Node has two interfaces over which other components can connect to it and be

provided with data. Via the Open Application Interface the communication between City

Node and connected applications is handled such as the DORA frontends, third -party

applications and the Operation Centre Application. Via the Open Service API the City Nodes

are connected to the DORA service platform where the central DORA services are located.

Both interfaces are described more detailed in chapters 4.2 and 4.3.

4.2.2 DORA – Service Platform

The service platform contains all central, not test-site specific, DORA services, that

contribute to the route calculation, information and monitoring. Unlike the City Nodes the

DORA service platform can be located in a cloud environment since it is independent from

local infrastructure and hardware.

The global services located in the DORA service platform are:

Door-to-Door-Journey Planner

Intermodal Landside Router

Indoor Router

Flight Routing Service

Trip Monitoring Service

Strategic Routing Service

Figure 18 shows how the DORA service platform is connected to the DORA City Nodes. The

DORA service platform is connected to the City Nodes via the Open Service API. Over this

interface the central platform services receive the local data and services required for the

door-to-door route information from the City Nodes. The Indoor Router in the service

platform, for instance, gets the required Waiting Time Detection data and the Intermodal

Landside Router receives local mobility information via the Open Service API. This

architecture approach furthermore facilitates the addition of other City Nodes to the DORA

system in the future.


49 / 85

Figure 18: Service View: Interaction between DORA City Nodes and Service platform

Figure 19 illustrates how different applications are connected to the DORA System. These

shall include Web-GUIs, mobile applications (Smartphone, Tablet, Smartwatch (yet to be

discussed)) as well as Operation Centre Applications. All applications, both internal and

external, communicate with the DORA service platform and the DORA City Nodes over the

Open Application API. This interface is especially designed to meet the requirements that

applications have towards communication processes.


50 / 85

Figure 19: Application view: Data and Services provision via Open Application API

Over this API to the DORA service platform the applications request and receive the central

door-to-door information provided by the Door-to-Door Journey Planner and the associated

central services. From City Nodes the applications receive for example detail information on

specific POIs of a route, for example on relevant car-sharing vehicles.

The Open Application API will be based on standards so that third party applications can

access the DORA functionalities easily (see chapter 4.3).

4.3 DORA Open Service Protocol

The DORA Open Service Protocol will be developed during the DORA project and will provide

an open API for an easy integration of existing and local services into the DORA system. It

provides a state of the art open data and service exchange format for mobility services. The

specification of the protocol will be included in D 3.2 in M10.

The API needs to be self-evident, well documented and easy to understand and should use

standards if possible. No internal or external application will interconnect with this API.

Data and service exchange and interconnection to DORA applications and potential external

applications of third parties will be provided by the DORA Open Application Protocol (see

chapter 4.3).


51 / 85

To achieve high scalability and easy integration of additional services into the DORA system,

every service who interacts in some capacity to any DORA service has to impl ement the

DORA Open Service Protocol. To guarantee a high quality of the overall system, automatic

system tests for all API functions have to be developed and implemented. Only if all tests

pass, the service can register as a DORA service.

DORA Open Service Protocol will be published as an open protocol and should not only be

used within the DORA project but also for all intermodal seamless mobility platforms and

services. After testing and evaluating this protocol in DORA, it is envisaged to propose the

DORA Open Service Protocol to be evaluated by the European Committee for

Standardization (CEN).

4.4 DORA Open Application Protocol

The DORA Open Application Protocol will be developed during the DORA project and will

provide an open API for an easy integration of DORA services in all DORA applications by

different partners and 3rd party applications. It provides a state of the art open data

exchange format for seamless mobility applications. The specification of the protocol will be

included in D 3.2 in M10.

The API needs to be self-evident, well documented and easy to understand and should use

standards itself if possible.

To ensure high scalability and easy integration of additional services into the DORA system,

the DORA Open Application Protocol is published by the DORA services and the city nodes.

That implies that if a service or a services provider wants to take part in the DORA system

implementation of the DORA Service Protocol and the DORA Application Protocol is

required. To guarantee a high quality of the overall system, automatic system tests for the

all API functions have to be developed and implemented. Only if all tests pass, the service

can register as a DORA service.

It will be published as an open protocol and should not only be used within the DORA project

but also for all intermodal seamless mobility information platforms. After testing and

evaluating this protocol in DORA, it is envisaged to propose the DORA Open Application

Protocol to be evaluated by the European Committee for Standardization (CEN).


52 / 85

4.5 External Interfaces

The provision of door-to-door information requires data exchange and integration of various

services.

The technical specification of the external interfaces to the different data providing entities

(e.g. transport operators, traffic management centres, airports, airlines etc.) and the internal

interfaces between the services will be performed. The specifications to be performed are

the analysis of data flows and definition of data models, based on a rules-and-permissions

concept. A main goal is the definition of open interfaces for end user applications, mobility

and incident management panel and the Journey Planner.

4.6 DORA Services and Technologies

In this chapter the DORA services and technologies will be introduced. In each subc hapter it

will be described how the components are planned to be implemented, how they are

connected to other internal and external systems and which ingoing and outgoing data will

be processed. After the specification of use cases and requirements these d escriptions will

be modified and updated in more detail in deliverable D3.3.

The first subchapters 4.3.1 and 4.3.2 describe the DORA technologies of waiting time

detection and indoor location whereas the remaining subchapters give an introduction of

the DORA services.

4.6.1 Waiting Time Detection

Waiting time detection will be developed by Eureva as a system that will use image analysis

and data from airport in order to provide precise information to the user. It is important to

note that this service will work live and not by statistics, so that the information is often

updated and always refers to the present situation, and that even if its purpose is to inform

the common user, any other service can have access to the information and use it for its

own operation (e.g. Indoor Routing).

On the waiting time theories, two elements are important: how long the process will take,

and how many people are in the queue. The first information, whether we consider a check -

in counter or a security counter, can be considered as constant. The only important

information for this aspect is to know how many counters are opened at any moment. This

data will have to be provided to our system in order to have a fluent working in our waiting

time detection.


53 / 85

For the second element, an approach could be the detection of any entering person in the

queue, using infrared technologies. Another approach could be the detection of the mobile

phone when people enter and leave the queue, using Bluetooth or Wi-Fi technologies. We

chose another approach. Eureva has worked on many projects on image analysis, and we

think that evaluating the number of persons in the queue is a better option than counting

the number of persons entering this waiting line. Indeed, the system will not have to be

initialised and can be rebooted at any moment without any consequences for the efficiency

of the service.

In order to know how many people are in a queue at a precise moment, the system will need

cameras that will take a picture of the whole place where people are supposed to wait.

These cameras must consider the largest space possible, as the queue can sometimes grow

bigger than expected, especially on rush hours. It is also important that the structure of this

queue stays the same, or that the changing of this structure is noticed to the waiting time

detection system.

The method that Eureva will be using will not imply counting all the people that are in the

queue. Indeed, counting people in a crowd is not always precise, and sometimes people that

are not part of the waiting line can be considered, and the evaluation will not be correct.

Instead of this technology, the system will determine where the waiting line starts, and

deduce the number of people in the line given the usual width of the queue. This operation

will be possible by comparing the picture taken by the camera to another picture that will

show the empty line.

This solution will need the installation of cameras at precise places and the update of the

counter number at any moment, but it will work at any moment, and will not necessitate the

user to give access to any of his data on his mobile, and can even be accessed from a

computer. Statistics of the evolution of waiting time can even be made with the help of this

system, and information of the usual waiting time can be provided to the user if this is

necessary for the project aspect.

In order to have a proper Waiting Time evaluation, the system will need the following data:

The common waiting time at a security counter (or a check-in counter)

The number of counters that are opened

The way the queue is organised on the waiting line (if this parameter is supposed to

change)

The images of the current waiting line (from all the cameras that are showing the

queue)


54 / 85

The way cameras are placed will be an important task that will require the work of both

Eureva and the Airport teams. Whether the security cameras can be used for this feature is

yet to be decided, but it seems that having dedicated cameras would be a better option.

The information given by the Waiting Time Detection system will only be associated with a

specific counter (security counter or check-in counter). The link between the user flight and

the counter he/she is supposed to use will not be a part of this system, and will have to be

done previously.

The technology used by Eureva for the Waiting Time Detection could also be completed by

other information. Currently used systems on the different airports can be used as a

complement in order to get a more precise result. Eureva’s system can also ta ke in

consideration information sent by other features, such as indoor location module or

feedbacks from users. Whether this information is used as a complement or as a validation is

yet to be discussed.

4.6.2 Indoor Location

Indoor location in the context of DORA (DIPS – DORA Indoor Positioning System) regards a part

of the platform that involves development both of software and hardware components. There

are several state of the art solutions in the field of indoor location for airports mainly involving

use of Bluetooth Low Energy Beacons (BLE) or measurement of existing WiFi Beacon Frames. In

DORA an attempt to produce a platform based on a combination of the two approaches will be

made for the provision of a novel product that is a Wi-Fi Beacon device. The device will be an

easy to install standalone battery powered device that emits a predefined unique SSID in Wi -Fi

Beacon Frames at a properly configured rate. The novelty, therefore, lies in the fact that the

device will be used in order to augment the Wi-Fi signals in a specific building allowing for the

development of an application concept similar to the one established with the use of BLE

Beacons for context and location aware approaches. The use of Wi -Fi instead of BLE is expected

to take advantage of mainly three aspects:

Better propagation of the Wi-Fi signals contrary to the BLE ones

Always on status of Wi-Fi modules in smartphones and relevant devices

Currently not all devices (smartphones) support BLE (BT v4.0)

However, if a mobile OS (i.e. iOS) is not providing full support for RSSI measurements a hybrid

device featuring both BLE and Wi-Fi will be considered.

The DIPS approach will take advantage of the capability of modern user equipment to take

measurements of the Wi-Fi signals in terms of Received Signal Strength Indicators (RSSI). The

approach presupposes that for a DIPS enabled place there has been a preparation phase during


55 / 85

which Wi-Fi signals are used to create a Fingerprinting Database that contains reference

measurements with respect to Wi-Fi signal propagation. Once a device has to get information

about its current position, the current vector containing SSIDs along with the related RSSIs has to

be sent to the DIPS system for retrieving back an evaluation of the current position.

Figure 20: DIPS Approach

Before the DIPS system is activated for a specific airport, a study has to be performed with

respect to existing Wi-Fi signals and the propagation of these signals across all public areas.

Apart from the technical details regarding coverage and signal availability issues, other

factors have to be considered such as the ownership of the existing Access Points (if they are

airport facilities or if they are administered by other stakeholders and their status and

availability is not guaranteed). After such study it is expected that a better view can be

produced with respect to the coverage needs of the specific airport. The extra coverage that

is required will be provided by the installation of DIPS Beacons as presented in Figure 20 A

number of iterations of measurements and installations will be the n performed so as to

ensure adequate coverage.


56 / 85

Once acceptable coverage has been achieved, the phase of populating the Fingerprinting

Database will follow. The fact that the conditions inside the airport (movement and number

of people, noise factors, interference, etc.) will have an impact on signal propagation and

also the fact that DIPS broadcasting will be depending on battery status guides to

maintaining a multidimensional array of reference measurements so that such factors can be

taken into account in the positioning algorithms. Additionally, attention should be paid on

the differences among end user equipment so that objective results can be deduced.

Depending on the battery replacement or recharging plan that will be used, calibration

sessions may be implemented in the overall infrastructure. These may be scheduled once (or

lightly more) per day focusing on re-evaluation of the transmitted signals. The concept is to

collect from each DIPS Beacon measurements with respect to the signals emitted by their

neighbour ones so as to allow for a more objective view of the ambient conditions (since

installation positions are known parameters and they can be correlated with received signals

to produce better propagation models). These calibrations can be automated by having the

DIPS Beacons emitting for a few frames related information that can be collected and fed

into the backend of the DIPS Subsystem. This functionality can be used also for automating

the deployment process.

The DIPS Subsystem consist both of the Beacon Infrastructure as presented above and the

backed service to be provided via a REST interface to the DORA Applications for lookup of

the collected RSSI vector. It is expected that the DIPS backend subsystem is not interacting

with the rest of the platform for the provision of the basic service of position resolution.

However, the following transactions may be worth evaluating:

Interaction with the Queue Detection Subsystem for provision of rough estimation of

number of devices receiving similar Beacon Frames and are close to points where

queues may appear.

In case a management interface is implemented for the Beacons (e.g. for calibration)

it can be also used by the Intermodal Router to propagate emergency information via

the emitted SSIDs. In this case the DORA application component responsible for the

indoor location measurements should translate appropriately the received

information and push it toward the UI.


57 / 85

4.6.3 Indoor Maps

The Indoor Map service is in charge of providing maps, basic graphs and POIs to DORA

applications (e.g. mobile app). These three components, including a REST API interface,

compound the main architecture of the Indoor Maps Service, as depicted in Figure 21. In

practical terms and for the DORA project, the mobile app will request a map or map tiles and

also specific layers on this map that correspond to specific POI categories (e.g. shop, toilet, c ar

rental, etc.). This means that the three components of the Indoor Maps service are typically

managed by an administrator, as will be described below.

Figure 21: Indoor Maps architecture

The Maps Manager is the core component of the whole Indoor Map service and manages

the maps to be used by applications. A map represents typically a building composed by

several layers (floors). For the DORA project, the map corresponds to the PMI or the BER

airport, floor by floor, and probably including neighbourhood areas, such as parking areas

and nearby public transport stations. Unfortunately, there is no standard method to deal

with maps and typically commercial applications employ their own way. However , we can

distinguish two types according to the way maps are accessed:

Application Server

Database (POSTGIS)

Maps

REST API

Maps Manager

Graph Manager

Mobile app

POI Manager

getMap()


58 / 85

Non-standard way: maps are processed somehow through scaling and

transformation functions, which are included in an open library that the user

application can utilize. For example, one approach employed by some companie s

(and even Google) is importing a standard web image extension (e.g. PNG) and

georeference the map on top of Google maps, as depicted in Figure 22. Basically, we

just need to move the map, to resize the map and to rotate the map. There are

JavaScript libraries able to place the map in its correct position with the previous

parameters.

Figure 22: Georeferencing map through scaling and rotating

Standard way: here OGC WMS (Web Map Service) is the common way in which the

map is served, including tiles. This facilitates the integration with third party

applications. The functionality of serving tiles is also very interesting in terms of

efficiency in the response time, otherwise the whole map should be loade d and for

large areas (e.g. airports) and good quality maps the required bandwidth may have

an impact in the user experience. There are various open environments (servers) to

provide maps via OCG WMS. Probably the most common one is GeoServer

[www.geoserver.og]. It can import a map either as a raster image or as a vectorial

image (Shapefile). In both cases, the images should be georeferenced, which can be

performed via specific applications, such a QGIS [www.qgis.org]. For quality reasons,

it is desirable that the airport maps are provided by PMI and BER representatives in

vectorial format, as the image quality does not decrease when zoom in is performed.


59 / 85

Figure 23: Map provided via OGC WMS

On top of the map we can build and add layers containing the POIs. This is mainly managed

by the POI Manager in the Indoor Map service. It is important to highlight that

georeferenced POIs are the starting point for creating a useful navigation service, as the user

will typically go from one POI to another, or at least have a certain POI as destination. Thus

the airport representatives should provide a list of georeferenced POIs to be imported in the

POI Manager. It manages POIs in different nodes categories:

Simple nodes: transitional nodes towards other nodes. They are manually created by

the administrator when he/she creates a graph.

Connector nodes: door, elevator, escalator, stairs, gate. They are manually created by

the administrator with the help of PMI and BER representatives (or maybe it is

already clear through the map).


60 / 85

Relevant POIs: toilets, restaurants, shopping areas. They are imported from the list of

georeferenced POIs provided by PMI and BER representatives

In summary, each airport should specify the interesting nodes for each floor of a map and

their location. This should be given to the administrator who will configure accordingly the

POI Manager, building the different categories, as depicted in Figure 24.

Figure 24: POI Manager overview

The Graph Manager is in charge of building a navigation graph on a certain floor. It is only

useful for the navigation on this floor. For the whole building, the floor graphs have to be

connected. Currently some configuration is performed in the Maps service and other in the

Navigation (Indoor Router) service, but it may change in the final architecture.

In the floor graph, nodes are placed on the map and connected through links. Each link has a

specific cost and can be unidirectional (security check) or bidirectional (e.g. single nodes)

Whereas relevant POI nodes are fixed, simple nodes should be placed between them to

generate way paths.


61 / 85

Figure 25: Graph Manager overview

The REST API in Figure 26 provides all required functionality to mobile applications regarding

maps. It refers not only to maps obtained via GeoServer but as well other relevant

information regarding to the map data model. We propose to use (whenever possible)

Swagger [http://swagger.io/] to define the interfaces, as depicted in Figure 26. It allows for

developers and integrators to easily (and visually) see inputs and outputs, as well as

examples.

Figure 26: REST API overview

4.6.4 Indoor Router

The Indoor Router component is responsible for providing indoor navigation services.

Navigation is the process of providing a path from an origin node (typically the current

position of a user) to a destination node according to certain settings or preferences. All


62 / 85

implied nodes (origin, destination and transitional ones) are georeferenced, and can be

displayed in an indoor map.

In the case of the DORA project, the Indoor Router offers the user (traveller) the

functionality of navigating in the airport and finding different indoor destinations (check in,

kiosk, security check, boarding gate, etc.) optimizing the travel time. The navigation process

considers user preferences (e.g. impaired people will avoid stairs) and real time status (e.g. if

a lift is out of order it will be discarded as a path node in the navigation).

Figure 27: Typical indoor routing scenario

The general architecture for the Indoor Router is depicted in Figure 28. We can differentiate

the mobile app and the backend service:

The mobile app is in charge of issuing a request to the backend service and obtaining

a navigation route as response. This is simplified in Figure 28 as the getRoute()

operation. The request includes a set of user preferences to be considered while

processing the path in the backend service. Once the response is obtained (e.g. as a

set of georeferenced nodes) the mobile app can display the path on a map providing

a user friendly GUI. The response may include additional information, such as

distance to destination and average times.

The navigation service runs on an application server and includes 3 main

components, as depicted in Figure 28:

o REST API interface: it is in charge of providing navigation functionalities to

external applications (e.g. mobile app)

o Algorithm: it determines the best route from one node to another.


63 / 85

o Context Manager: it updates status and costs of certain graph nodes in r eal

time, if they are available (e.g. queue times, escalators, lifts, etc.). It may also

get other information from the context (e.g. baggage belt information)

Some navigation nodes correspond to certain Points of Interest (POIs) that can be either

stored in the navigation service (e.g. as a POSTGIS database) or be provided by another

DORA service (e.g. Maps).

Figure 28: Indoor Router architecture

The navigation algorithm is probably the most critical component in the navigati on service as it

has to be rather efficient considering the graph size. In the case of DORA, the graph (list and

relationship among all possible nodes) of a large airport such as PMI and BER can be huge, thus it

is important at design phase to consider only relevant areas. Those airport areas that will not be

used by a traveller do not require any graph node. Furthermore, if extended accuracy is

required, due to a limited amount of positioning beacons, some areas of the airport will be

priorized among others in order to fully fulfil the different use cases defined for DORA and

available in deliverable D2.3.

Application Server

Database (POSTGIS)

Navigation

REST API

Algorithm

Mobile app

getRoute()

Context Manager

Admin interface

Real time information:Queue Time, POIs

status, Flight information


64 / 85

In the end the Navigation Algorithm requires a complete multi layered connected graph (each

floor has its own graph) of nodes. Each node corresponds to a possible navigation position of the

user. Nodes are connected by means of edges, which have a particular cost and are bidirectional.

The cost is a way of setting weights to the transition from one node to another, so if there are

various navigation paths from one node to another, the preferred path will be the one that

provides a lower cost. As the cost is simply a weight, it can be associated to a certain measurable

unit; in the case of DORA, the cost refers to time and therefore a path with the lowest co st

indicates that this path is the fastest one. Note that edge costs are bidirectional: it is not

necessarily true that the cost from node A to node B is the same as the cost from node B to node

A (e.g. security checkpoints in airports are one-way).

Edge cost is determined by several parameters:

Base graph: this refers to a base node graph for a default user and no changing

conditions. In this case, the cost from one node to another could be set, for example, as

the distance (in meters) between nodes. Bidirectional cost will also be considered for

special nodes (security check) in this base graph.

User preferences: the user may provide a profile that can affect the edge costs. For

example, if stairs should be avoided, this corresponds to setting a very high level cost to

the edges between ‘stair nodes’

Real time status: some nodes may be out of order by the time the Navigation Algorithm

has to perform the navigation process. For example, if a lift is out of order, the cost to

the edges between ‘lift nodes’ should be changed to a very high value. The average

queue time is also included here. The management of all this information is performed

by the Context Manager, as depicted in Figure 28.

The Navigation Algorithm is mainly managed through an admin interface. It is an administrator

who builds the base graph on a map (e.g. floor by floor) and assigns initial costs between nodes.

This is depicted in Figure 29. The basic process is as follows:

Step 1: the starting point is the map of the airport and a georeferenced list of POIs. The

airport (PMI, BER) are responsible in the DORA project to provide this information. The

POIs constitute the initial required elements for the navigation.

Step 2: once the POIs are placed as nodes in the graph, it is time to add additional

transitional nodes that connect POIs. POIs can be considered as ‘houses’, whereas

transitional nodes play the role of ‘streets’ connecting houses. This process depends on

the distribution of POIs in the airport and is typically done manually by the administrator.


65 / 85

There are special transitional nodes, such as lift and stairs that allow connecting different

floors inside an airport.

Step 3: the navigation path is the basis for the Fingerprinting (FP) map, this means, the

FP graph extends the navigation graph to better (accurately) position a user. Note that

positioning is an initial requirement for indoor navigation, otherwise it may be difficult to

track the user and notice whether he/she is following the navigation path or getting lost.

Figure 29: Basic navigation graph and edge cost assignment

Another aspect to configure as administrator is how to calculate the best route. There are

several algorithms to be employed, such as A*, IDA*, Dijkstra, etc. It is difficult to decide

beforehand which one will perform better in practice, thus we will provide this feedback at

evaluation phase.


66 / 85

The mobile app is responsible for interacting with the REST API of the backend service and

presenting this information to the user on a map. Currently there are two possible

operations identified after analysing the DORA use cases:

getOfflineRoute(): this is just a drafted route when the user is preparing its journey

and is not physically at the airport.

o Input parameters:

Node entrance_node (optional): where the user is supposed to arrive

as the airport may have several entrances (if not provided, a default

entrance will be used).

Boolean checkin (optional): determines if the user needs to check in. If

yes, the check in node should also be provided; otherwise, a default

node will be used.

Node boarding_gate (optional): where the user is expected to take the

plane (if not provided, a default node will be used).

Global average queue time: a global mean value for the queue time

when passing the security control. This parameter does not need to be

provided by the user, but should be provided by the Waiting Time

Detection service.

Properties user_profile (optional): settings of the user. Depending on

the profile, the navigation path will be one or another. The profile

needs to be further defined in the next months. Currently there is only

one identified property for indoor navigation: to avoid or not stairs. If

not provided, a default setting will be used.

o Return parameters

ArrayList<nodes>: an ordered list of georeferenced nodes that allow

navigating from the entrance to the boarding gate.

Double distance: estimated distance (in m) of the navigation path.

Average queue time: the value obtained by the Waiting Time

Detection Service.

getOnlineRoute(): provides a navigation path to the user when it is physically at the

airport. The operation is similar to the previous one but this time the origin node and

the destination node may differ, as now the user (traveller) might go from a certain

POI to another.

o Inputs

Node origin_node


67 / 85

Node destination_node

Average queue time: here the Waiting Time Detection service provides

the real time average queue time (e.g. last 5 minutes)

Properties user_profile

o Return parameters

ArrayList<nodes>: an ordered list of georeferenced nodes that allow

navigating from the origin node to the destination

Double distance: estimated distance (in m) of the path

Average queue time: the value obtained by the Waiting Time

Detection Service

For scalability purposes, the mobile user may periodically track the user position (e.g. via the

Indoor Location service) to detect whether the user is following the navigation part and thus

approaching the destination node or per contrary is getting lost. In that case, the mobile app

may alert the user and request another navigation path (to the Indoor Router) from its

current position.

4.6.5 Intermodal Landside Router (ILR)

The intermodal router is one of the main components of the overall DORA system providing

the D2D Journey Planner with the routes for the landside part of the overall trip chain for

both test sites. The landside parts of the trip include the journey from the starting point to a

connection point in the area of the terminal where the indoor routing system takes over as

well as the final part of the trip after having left the range of the indoor routing system to

the final destination of the overall trip.

The route calculation of the Intermodal Landside Router relies on real -time traffic

information provided by the public transport operators, mobility service providers and the

traffic information and control centres. The Intermodal landside router allows the

calculation of routes from A to B for routes with just one single transport mode but also ,

based on the different modal routers and integrated mobility service providers, the

combination of different modes within one trip chain. The Intermodal Landside Router is

based on an intermodal routing platform, which is designed as a modular and easily

expandable system that can be updated when new modal routers or mobility services are

supposed to be integrated. The intermodal routing platform firstly consists of a modal

routing platform that connects different specialized modal routers, more precisely a dynamic

car router, a dynamic public transport router and a walking/biking router . Secondly an


68 / 85

integrated mobility service provider platform comprises all different kinds of available

mobility options that might be interesting for the journey to and fro m the airport. The

different mobility services such as car sharing, bike sharing, EV charging stations or parking

facilities are provided to the intermodal routing platform as Location Based Services (LBS).

The design of the mobility service provider platform as a modular and expandable system

allows the integration of different mobility services per each test site. The figure below

(Figure 29) illustrates examples of possible intermodal routes being calculated by the

Intermodal Landside Router.

Figure 30: Transport Mode Combinations of the ILR – Examples

The route calculation is based on different modifiable request parameters. These are most

importantly the coordinates of the start and destination locations as well as the departure

and arrival time. The route calculation also considers the different route optimization criteria

that can be modified by the DORA user. These are duration, costs and CO 2-emissions of the

landside parts of the trip. Furthermore, the user can select his or her mobility preferences,

options and restrictions in the DORA end-user applications. These adjustable mobility


69 / 85

options consist for example of preferred or undesired transport modes, buffer time at the

airport, availability of private car or public transport season tickets, car sharing memberships

etc. In addition, settings can be adjusted that deal with personal mobility restrictions such as

inability to take stairs or maximum distance of walking.

The intermodal Landside Router starts the route calculation after the D2D Journey Planner

has sent a routing request for the landside parts of the overall trip chain. The route

calculation of the Intermodal Landside Router relies on data of different external and

internal services. The ILR is firstly connected to a modal routing platform in which the modal

routes are calculated and secondly to the mobility service provider platform. Both these

platforms are connected to the ILR via proprietary interfaces. Furthermore, the ILR receives

data from two internal services within the DORA platform. First the Strategic Routing Service

provides the intermodal routing system with dynamic and static strategies to influence the

computed route recommendations. In case of incidents such as congestion, road closures,

train failure or disruptions the user will be routed to and from the airport taking into account

these events.

After the ILR has calculated the routes based on the different request parameters it provides

the results to the D2D-Journey-Planner for the calculation of the overall route. In case the

Trip Monitoring Service detects deviations from the actual suggested route, e.g. a traffic

disruption, delay of flight, gate change etc., the D2D Journey Planner might suggest an

alternative route which can also result in a new routing request towards the ILR for the

landside parts of the trip chain.

4.6.6 Flight Information Service (FIS)

The Flight Information Service is aimed at providing the Door-to-Door Journey Planner with

suitable flights between the two pilot sites for the overall door-to-door route. This service

has different interfaces to DORA services and applications as well as to external systems.

The Flight Information Service is requested for data by two other DORA components. First of

all, the DORA end-user applications directly request the Flight Information Service for real-

time flight information. This request is made in order to show in the DORA frontends all

departing flights from the departure to the destination airport in a list view. The displayed

flights can be selected by the DORA user as a basis for his door-to-door routing request.

Secondly the Flight Information Service is requested by the Door-to-Door Journey Planner

for a suitable flight connection for an overall door-to-door route. Based on the routing

parameters sent in the request, the Flight Information Service sends a suitable flight


70 / 85

connection or multiple alternatives in a response to the Door-to-Door Journey Planner

where the information on the flight including start and arrival time as well as gate

information is processed for the door-to-door route calculation.

The Flight Information in turn imports real-time flight information from two external, already

existing services. To get the flight information for Palma de Mallorca airport, the Fligh t

Information Service has access to a web service from AENA. In this web service the real -time

flight information for all arrivals and departures at PMI airport is available. The web service

can be accessed by the FIS via pull/get method. A constraint here is that the real-time flight

information is only available for the current and the next day. The web service provides data

for estimated start and arrival time, luggage belt information, gates, check-in counters and

terminal.

For the test site of Berlin, the FIS imports data from an existing web service of FBB. The web

service provides real time flight information via push method. The flight information includes

estimated start and arrival time, check-in counters, gates, and terminal as well as weather-

at-destination information. Luggage belt information is not available via the web service. The

real-time flight information is provided for four days in advance.

4.6.7 Trip Monitoring Service (TMS)

The purpose of the Trip Monitoring Service is to supervise the selected route of a passenger

based on the calculation of the Door-to-Door Journey Planner. The Trip Monitoring Service is

based on real time data, e.g. changes in travel times in public transport or individual traffic,

delays of flights, gate changes or traffic disruptions. If the service detects a significant

change of travel time for the selected route, the DORA user will be informed about the

deviation via alert and a re-routing by the Door-to-Door-Journey Planner is forced. The re-

routing takes into account the incident that forced the alert and proposes alternative routes

bypassing the affected area. The routing system also considers the available modes of

transport for avoiding the disturbance on the route to the airport.

The Trip Monitoring Service supervises a specific route once it has been selected by the user

and the “Start monitoring the trip”-button has been actively clicked. This means that the

user can be informed in a DORA end-user application about any disruption even before the

actual journey begins. If the user does not change his route selection, the Trip Monitoring

Service assumes that the DORA user attends to do his trip as planned. For both cases the

Trip Monitoring Service regularly checks the different DORA services providing traffic

disruption and delay information for possible deviations for the selected route.


71 / 85

There are different ways of how the Trip Monitoring Service imports data from other DORA

services. First of all, the TMS receives the information from the DORA frontend which route

was selected by the user in case he/she has activated the trip monitoring in the app. The trip

monitoring saves the route information for further supervision. The Trip Monitoring S ervice

regularly checks if the monitored route is affected by any disruption. In order to do this the

TMS regularly verifies with routing requests towards the Door-to-Door Journey Planner if

there is a deviation from the planned route. The Door-to-Door Journey Planner in turn

receives incidents from the different routing services and the Operation Centre Application.

If a deviation is detected the TMS informs the respective DORA front -end about this

including information on the type and quality of the incident. The DORA front -end in turn

actively informs the user about the incident, e. g. via push-messages, and suggests, if

necessary, to start a re-routing.

4.6.8 Door-to-Door Journey Planner

The Door-to-Door-Journey Planner is the core service in the DORA system as it provides the

DORA user with the optimal door-to-door route to a given cost function. For the calculation

of the overall route the Door-to-Door Journey Planner integrates the three routers for the

intermodal landside part, the indoor part and the flight part of the trip.

The communication flow of the Door-to-Door Journey Planner is as follows. The DORA user

requests a route in a DORA end-user application. The routing request including the specific

routing parameters such as start and arrival time, origin and destination, personal mobility

settings, etc. is sent to the Door-to-Door Journey Planner. Based on the different routing

parameters the Door-to-Door Journey Planner either requests the partial route for the flight

part of the trip or, in case a specific flight has already been selected in the DORA app,

requests detailed route information from the Flight Information Service. Based on the

received flight and gate information the Door-to-Door Journey Planner then sends routing

requests to the Indoor Router and the Intermodal Landside Router for the landside and the

indoor parts of the trip. The Strategic Routing Service is not directly connected to the Door -

to-door Journey Planner but influences the route calculation in the ILR and the IR (this is

described in the next section). Based on the responses of the partial routing services the

Door-to-Door Journey Planner combines the provided routes to one or several overall door -

to-door connections. The routing results are then finally sent back to the DORA end -user

application where they are presented to the DORA user.


72 / 85

Figure 31: Door-to-Door-Journey Planner

If the Trip Monitoring Service detects a deviation on the monitored route, the DORA user,

after being informed about this, starts another routing request. The calculation of the door -

to-door route will then take into account the particular incident or delay.

4.6.9 Strategic Routing Service

The aim of the Strategic Routing Service is to provide the Routing Services with dynamic and

static strategies to influence the computed route recommendations. In m any cases the

shortest route is not the best alternative, especially in cases of incidents or emergency. Until

now the dynamic routing has been working with time delays, as it only comes into action

after disruptions occurred. The strategic version can inform the passenger in advance and

traffic or passenger flows can be controlled as required. Dynamic strategic routing strategies

are activated by the Information and Incident Management System.

The Strategic Routing Service will consider two types of strategies: static and dynamic

strategies. The static strategies deal e.g. with passenger guidance in the terminal for

different user groups or different set up scenarios. In case of incidents other, pre -defined

routing strategies for the terminal but also for the landside transport can be activated by the

mobility and incident management panel. The strategic routing service is linked to all

Routing Services of the DORA project.

The incident and information management panel provides public administration, traffic

control and operation centre with cooperative management mechanisms and tools to


73 / 85

support DORA´s Incident and Information Strategy service with routing policies and

strategies for urban street environments and airport terminals. In case of major disruption s,

based on pre-defined strategies the control centres of air transport, public transport and

road traffic, manage disruptions consistently. Through information services of these

different operators and the storage of dynamic strategies in the DORA platfor m, the

passenger will be informed consistently and promptly via the DORA end user information.

4.7 Frontends

4.7.1 DORA Mobile Application

The DORA Mobile Application is the main DORA frontend and serves as the main

communication point of the DORA user with the overall system. The goal of the mobile

application is to provide travellers with all trip planning and trip monitoring functionalities of

the DORA system.

The DORA app is connected to the DORA service platform as well as the city nodes via the

DORA open API, which will be developed as a JSON/REST API. For the map visualisation in

the app, a Web Map Service (WMS) will be used as interface.

Over the WMS of the DORA open API to the city nodes the app receives the city specific POI

content for the visualisation in maps, such as car- and bike sharing providers, parking

facilities, public transport stops etc. Over the open API to the service platform the DORA

mobile Application communicates with the Door-to-Door Journey Planner. The

communication goes in both directions. The DORA user requests a route in the DORA app

and thereby sets the parameters for the routing calculation such as start and arrival times,

departure, destination etc. This routing request is sent over the DORA open API to the

Doour-to-Door Journey Planner which in turns requests the partial routes from the

secondary routing services such as the ILR and IR. After the calculation of the overall door -to

door-route, the route recommendations are sent back to the DORA app over the mentioned

interface.

4.7.2 DORA Web-based Application

The DORA system will be an integrated solution through considering one single system for

door-to-door journey planning delivered to the end-user by means of a mobile App and a

Web-GUI. The advanced graphical interface will provide the user with a seamless

visualization of the landside trip and the terminal trip as well.


74 / 85

The required backend services will be implemented and an advanced frontend GUI for

visualizing the services and information will be developed.

4.7.3 Operation Centre Application

To make sure that the seamless mobility information of the DORA system is consistent with

the local existing information services of the operation centres like public transport

operators or airports, the technical systems of these stakeholders are cross-linked and

integrated within the DORA platform. Even in case of incidents or disruptions, real time

information services are very important and can achieve a very high benefit, if incident

information strategies exist and if these strategies are linked to the end user information

systems.

The DORA Platform provides the main services and functionalities of this project and has

open interfaces for providing the services to the end user, as well as to the operation centre

applications. There are two types of distributed services: those providing real time data for

the journey Planner and those services in operation centres of the information and incident

management system.

Except of the operation centre services all distributed services are existing servic es. The

distributed services are either connected via their proprietary interfaces or via open

interfaces to the DORA platform.

By realizing an operation centre application for cooperative incident and information

management, DORA introduces a novel instrument for comprehensive traffic information.

With the DORA operation centre application, the operation centres of landside transport and

airports will jointly respond to delays and extraordinary conditions (e.g. technical break

down, strikes, bad weather) and employ decision and information management mechanism

that will be considered for traveller alerting and trip redesign.

The DORA Operation centre application implements a cooperative Incident and Information

Management. For the pilot site Berlin a cooperative incident and information management has

already been prepared. Partners involved and connected information devices are depicted in Figure

32.


75 / 85

Figure 32: Door-to-Door-Journey Planner

The system is focussed on safeguarding the basic service of landside and air traffic in case of

unpredicted disturbances in the traffic network and the terminal. With this the DORA

component critical situations in the landside and air traffic are anticipated and substitution

processes to deal with the problems are planned and implemented.

The DORA application provides predefined management and information strategies to

operation centres involved and ensures that the passengers are adequately informed using

the DORA end user application and the information devices available at the airport, in

station and vehicles.

In case of incidents is has to be made sure that operation centres of all transport modes

involved cooperate and act in a consistent way. A functional, technic al and operational

concept for cooperative management and information of air passengers in landside and air

traffic for the pilot in Berlin and PMI will be developed. This includes the definition of

potential disruptions in the landside and air transport system, the elaboration of pre-defined

management and information strategies and the implementation of management and

information processes. Subsequently the soft- and hardware components required will be

specified and developed. Afterwards, the Operation centre applications will be implemented

for the pilots PMI and BER. Based on the concept elaborated previously, the software to

execute common management and information strategies shared by all operation centres

will be developed and installed in the operation centres. A cooperation handbook describing


76 / 85

the processes on how to cooperate in case of incidents and disruptions will be worked out

and the teams in the operation centres will be trained accordingly. To sum up, DORA

Operation Centre Application provides predefined substitution processes for managing air

and landside traffic and consistent passenger information in stations, streets and terminals.


77 / 85

5 CONCLUSION

The presented document D3.1 provides a commonly shared methodological approach for

the different development activities to be performed in the DORA project. It includes an

update of the time line for the system development tasks that confirms the overall project

time schedule.

The status analysis of existing mobility information services shows that the basic services for

a land side multimodal routing service are available in the test sites . They can be integrated

to a cross-border door-to-door landside information service and can be combined with flight

information provided by the airport operators. Thus, the prerequisites for the overall door-

to-door information including air and landside transport are at hand and will be provided for

the DORA system. The technologies newly to be developed within the project such as

waiting time detection and indoor location and navigation are described in their basic

functionalities and will be further specified.

The draft DORA architecture is based on the analysis of the systems and services existing at

the two test sites and the corresponding airports. It is a view of the overall technical system

that is shared by all the partners. It is based on test site specific system and service

availabilities and targets at a distributed, open and transferable system providing open

interfaces for application and service providers.

The draft DORA architecture can be briefly described as a three-layer concept: So-called City

Nodes integrate all test site specific data and services in the landside mobility system and

the airport. The DORA services platform contains all central, not test-site specific, DORA

services, that contribute to the route calculation, information and monitoring and the end

user application. Open API provide access to service platform and city node to ensure

flexibility, transferability and scalability of the system.

The system architecture outlined in this document will be used for further specification and

elaboration of the final system architecture which will be documented in D3.2.


78 / 85

References

[1] Basili, V.R. and Turner, A.J. (1975) Iterative Enhancement: A Practical Technique for

Software Development, IEEE Transactions on Software Engineering 1, 4, 390-396.

[2] Gomaa, H. (1983) The Impact of Rapid Prototyping on Specifying User Requirements,

ACM SIGSOFT Software Engineering Notes 8, 2, 17-28.

[3] Floyd, C. (1984) A Systematic Look at Prototyping, in: Budde, R., Kuhlenkamp, K.,

Mathiassen, L. and Zullighoven, H. (Eds.) Approaches to Prototyping, Springer -Verlag:

Heidelberg, 1-17.

[4] Kaushaar, J.M. and Shirland, L.E. (1985) A Prototyping Method for App lications

Development End Users and Information Systems Specialists, MIS Quarterly, 9, 4, 189 -197.

[5] Boehm, B.W., Gray, T.E. and Seewaldt, T. (1984) Prototyping Versus Specifying: A

Multiproject Experiment, IEEE Transactions on Software Engineering, SE-10, 4, 290 -402.

[6] Gordon, V.S. and Bieman, J.M. (1994) Rapid Prototyping: Lessons Learned, IEEE Software,

12, 1, 85-95.

[7] Palvia, P. and Nosek, J.T. (1990) An Empirical Evaluation of System Development

Methodologies, Information Resources Management Journal, 3, 23-32.

[8] Verner, J., Tate, G. and Cerpa, N. (1995) Prototyping: Some New Results, Information and

Software Technology, 38, 12, 743-755.

[9] Nauman, J.D. and Jenkins, M. (1982) Prototyping: The New Paradigm for Systems

Development, MIS Quarterly, 6, 3, 29-44.[10] Tsui, F., Karam, O., Bernal, B. and Marietta, G.

(2014) Essentials of Software Engineering, Third Edition, Jones and Bartlett Publishers:

Burlington.

[11] Royce, W. (1970) Managing the Development of Large Software Systems,

Proceedings of IEE WESCON, 26, 1-9

[12] Shore, J., Warden, S. (2008) The Art of Agile Development, O´Reilly: Sebastopol

[13] http://xbsoftware.com/blog/software-development-life-cycle-waterfall-model/


ANNEX A STATUS ANALYSIS PALMA CLUSTER

Situation requires Data / Service

Group of Data / Service

Entity Sub-AttributePilot

regionAvailable already

Available during the

project period

Description

Protocol

Type Data-Types Data ownerData

provider in DORA

Personal Data

Data delivery contract

(system actor or natural persons)

Journey to /from the Airport

Static infra-structure data

Map tiles

PMI yes yes GOOGLE/ OSM Web Service Pull Image GOOGLE/ Open Data Commons Open Database License (ODbL)

ETRA NO

Transport network

Road network PMI no no

Bike network PMI no no

Footpath network PMI no no

PT network PMI yes yes GTFS file (EMT)/ ETRA OAS (EMT) Web Service Pull Scheme EMT EMT NO YES

PT stops PMI yes yes GTFS file (EMT)/ ETRA OAS (EMT) Web Service Pull Scheme EMT EMT NO YES

Real Time infra-structure data

Road network

Traffic Situation (Level of Service) PMI yes (*) yes (**) ETRA SDCTU CPM CPM

Accidents PMI yes (*) yes (**) ETRA SDCTU CPM CPM

Events PMI yes (*) yes (**) ETRA SDCTU CPM CPM

Construction Sites PMI yes (*) yes (**) ETRA SDCTU CPM CPM

PT network PT Real Time Delays & disruptions PMI yes yes ETRA OAS (EMT) Web Service Pull Scheme EMT ETRA NO YES

Mobility Services

Scheduled services

PT timetables PMI yes yes GTFS file (EMT)/ ETRA OAS (EMT) EMT EMT

PT price model PMI yes (*) yes GTFS file (EMT) EMT EMT

Flexbile services

Station Based vehicle sharing PMI no no

Stationbased bike sharing servicePMI yes yes Geolacation of stations and available

spaces for bikesopen data Pull MOBIPALMA CPM NO NO

Stationbased other sharing servcie PMI no no

Freefloating vehicle sharing service PMI no no

Freefloating bike sharing service PMI no no

Freefloating other sharing servcie PMI no no

Car pooling service PMI no no

Taxi PMI yes yes Static geolacation of stations text file CPM CPM NO

Vehicle parking

Parking placesPMI yes yes MOBIPALMA API

MOBIPALMAOAUTH2/CLAVE PUBLICA PRIVADA

Scheme MOBIPALMA CPM NO

Car parks PMI no no CPM

Real Time CapacityPMI yes yes MOBIPALMA API



Modal local Router

PT RouterPMI yes yes MOBIPALMA API



Car Router PMI yes yes GOOGLE Web Service GOOGLE ETRA

Walking Router PMI yes yes GOOGLE Web Service GOOGLE ETRA

Bike Router PMI no no

Car-sharing Router PMI no no

Bike-sharing Router PMI no no

At the Airport

Static dataAirport location plan (network) PMI yes yes Maps avalaible in airport web

Scheduled Flight plan PMI no no

Real Time data

Indoor conditions

Real Time Elevator condition PMI yes yes Text file pull Airport AENA no no

Real Time Escalator condition PMI yes yes Text file pull Airport AENA no no

Queues recognition PMIyes yes Estimated time of queue at security

control point every 1 min.pull Airport AENA no no

Real Time Luggage / Baggage Information PMIyes yes Baggage belt for arrivals flights

provided in real time flight information

see Real Time flight plan

AENA


80 / 85

Indoor localisation PMI no no Locates traveller in the airport

Flights Real Time flight plan PMI

yes yesFull information of each flight operated during the day

Web Service pull

It will be sent the scheme data flight

Aena HQ AENA no no

Indoor routing service

Door-to-Gate

Company Kiosk/Desk PMI No Guides traveller to check in point

Control entry points PMIno no Guides traveller to nearest control

point considering queue times

Gate-to-Gate

Shuttle info PMIno no Helps traveller changing from

terminal to terminal (if required)

Gate-to-Door

Baggage Belt PMIno no Guides the traveller to the baggage

belt

Control exit points PMI no no Guides traveller to the exit

Train/Underground info (if any) PMIno no Guides traveller to the proper door to

take the train/underground

Bus info (if any) PMIno no Guides traveller to the proper door to

take the bus

Taxi info PMIno no Guides traveller to the proper door to

take a taxi

General navigation (POIs)

Shopping PMI no no Shows available shopping spaces

Panel points PMI no no Shows info panels

Toilets PMI no no Shows available toilets

Food/Restaurants PMI no no Shows available food spaces

Car rental (if any) PMI no no Shows available car rental spaces

Currency Exchange (if any) PMI no no Shows available exchange spaces

Smoking Loungue (if any) PMI no no Shows available smoking areas

VIP Longue (if any) PMI no no Shows available VIP longues

Tourist info (if any) PMIno no Guides the traveller to the tourist info

space

Information point PMI no no Guides the traveller to the Info desk

Parking area PMI no no Shows parking areas

Lost luggage point PMIno no Guides the traveller to the lost bagge

claim space


81 / 85

ANNEX B STATUS ANALYSIS BERLIN CLUSTER

Situation requires Data / Service

Group of Data / Service

Entity Sub-AttributePilot

regionAvailable already

Available during

the project period

Description

Protocol

Type Data-Types Data ownerData

provider in DORA

Personal Data

Data delivery contract

Currentness of Data

(system actor or natural persons)

Journey to /from the Airport

Static infra-structure data

Map tiles

BER yes yes An internal VMZ service provides background map tiles for different map sources: Google, OSM, and other

WMS-Service, EU Standard: no, National standard: no

Pull WMS Google, OSM, ect.

VMZ no yes Dynamic, every 5 min

Transport network

Road network

BER yes yes The static road network of the area Berlin-Brandenburg

Berlin Detail Network, EU Standard: no, National standard: no

Static file, Data import TAB file with street category, link and node Ids,attributes about surface, ect.

SenStadtUm VMZ no yes Static

Bike network

BER yes yes The static bike network of the area Berlin-Brandenburg




Footpath network

BER yes yes The static walking network of the area Berlin-Brandenburg




PT network BER yes yes OpenStreetMap Webservices Pull OSM VBB no twice a year

PT stops BER yes yes OpenStreetMap Webservices Pull OSM VBB no twice a year

Real Time infra-structure data

Road network

Traffic Situation (Level of Service)

BER yes yes Real time situation of the road infrastructure, color codes in red, yellow and green

TSE-Service, EU Standard: no, National standard: no

Push WMS TIC Berlin VMZ no yes Dynamic, every 5 min

AccidentsBER yes yes Real time

information about Siemens Concert OCIT-

Push ID, Category,

TIC Berlin VMZ no yes Dynamic, every 5 min


82 / 85

road accidents C/Propieraty, EU Standard: no, National standard: no

Latlong, Time, ect.; WMS

Events

BER yes yes (Real time) information about events like planned road closures

Siemens Concert OCIT-C/Propieraty, EU Standard: no, National standard: no

Push ID, Category, Latlong, Time, ect.; WMS


Construction Sites

BER yes yes (Real time) information about planned construction sites

Siemens Concert OCIT-C/Propieraty, EU Standard: no, National standard: no

Push ID, Category, Latlong, Time, ect.; WMS


PT network PT Real Time Delays & disruptions BER yes yes VBB-Fahrinfo Webservices Pull /VBB-App = Pull + Push VBB VBB no in case of action

Mobility

Services

Scheduled services

PT timetables BER yes yes VBB-Fahrinfo Webservices Pull VBB VBB no weekly

PT price model BER yes yes VBB-Fahrinfo Webservices Pull VBB VBB no once a year

Flexbile services

Station Based vehicle sharing

BER yes yes Real time information about available vehicles at stations

SOAP/Propieraty, EU Standard: no, National standard: no

Pull ID, number plate, name, LatLong, price, seats, fuel type, reach, condition

citeecar VMZ no yes Dynamic, every 5 min

Stationbased bike sharing service

BER yes yes Real time information about available bikes at

stations

SOAP/Propieraty, EU Standard: no, National

standard: no

Pull ID, LatLong, price

nextbike, CallaBike


Stationbased other sharing servcie BER no no n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a.

Freefloating vehicle sharing service

BER yes yes Real time information about available freefloating car sharing vehicles


Pull ID, number plate, name, LatLong, price, seats, fuel type, reach, condition

DriveNow, car2go, Multicity


Freefloating bike sharing service BER no no n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a.

Freefloating other sharing servcie

BER no yes Real time information about available freefloating electric scooters

TBD TBD ID, number plate, name, LatLong, price,reach, condition

eMio VMZ TBD TBD TBD

Car pooling service

BER yes yes Real time information about available ride sharings / car pooling journeys offered by flinc


Pull ID, Driver, start time, price

flinc VMZ no yes Dynamic, every 5 min


83 / 85

Taxi

BER yes yes Real time information about available taxis


Pull ID, Driver, start time, price

Taxi Zentrale Berlin


Vehicle parking

Parking places

BER yes yes Static information about locations of parking places

csv, EU Standard: no, National standard: no

Static file, Data import ID, LatlLong, Adress, Static infos about capacity

TIC Berlin VMZ no yes Static

Car parks

BER yes yes Static information about locations of car parks at the airport

csv, EU Standard: no, National standard: no

Static file, Data import ID, LatlLong, Adress, Static infos about capacity

FBB FBB no not neccessary

Static

Real Time Capacity

BER yes yes Real time information about locations of car parks


Pull ID, LatlLong, Adress, real time capacity

ParkU VMZ no yes Dynamic, every 5 min

Modal local Router

PT Router

BER yes yes A specialized router for calculations of public transportation routes


Pull exact route, turn advices, departures, delays, mode changes

VBB VMZ no yes Dynamic, every 5 min

Car Router

BER yes yes A specialized router for calculations of public car routes


Pull Exact Route, turn advices

TomTom VMZ no yes Dynamic, every 5 min

Walking Router

BER yes yes A specialized router for calculations of walking routes



Google VMZ no yes Dynamic, every 5 min

Bike Router

BER yes yes A specialized router for calculations of biken routes



VMZ VMZ no not neccessary

Dynamic, every 5 min

Car-sharing Router

BER yes yes A specialized router for calculations of routes conatining of a car sharing vehicle





Bike-sharing Router

BER yes yes A specialized router for calculations of routes conatining of a bike sharing vehicle





At the Airport

Static data

Airport location plan (network) BER yes yes

Scheduled Flight plan BER yes yes webservice xml push list of types FBB FBB no yes 1 minute


84 / 85

is available (aviation( (online solutions)

Real Time data

Indoor conditions

Real Time Elevator condition BER no no

Real Time Escalator condition BER no no

Queues recognition BER no no

Real Time Luggage / Baggage Information BER no no

Indoor localisation BER nono Locates traveller in

the airport

Flights Real Time flight plan BERyes yes

webservice xml pushlist of types is available

FBB (aviation(

FBB (online solutions)

no yes 1 minute

Indoor routing service

Door-to-Gate

Company Kiosk/Desk BER nono Guides traveller to

check in point

Control entry points BER no

no Guides traveller to nearest control point considering queue times

Gate-to-Gate

Shuttle info BER no

no Helps traveller changing from terminal to terminal (if required)

Gate-to-Door

Baggage Belt BER nono Guides the

traveller to the baggage belt

Control exit points BER nono Guides traveller to

the exit

Train/Underground info (if any) BER no

no Guides traveller to the proper door to take the train/underground

Bus info (if any) BER nono Guides traveller to

the proper door totake the bus

Taxi info BER nono Guides traveller to

the proper door to take a taxi

General navigation (POIs)

Shopping BER nono Shows available

shopping spaces

Panel points BER no no Shows info panels

Toilets BER nono Shows available

toilets

Food/Restaurants BER nono Shows available

food spaces

Car rental (if any) BER nono Shows available car

rental spaces

Currency Exchange (if any) BER nono Shows available

exchange spaces

Smoking Loungue (if any) BER no no Shows available


85 / 85

smoking areas

VIP Longue (if any) BER nono Shows available

VIP longues

Tourist info (if any) BER nono Guides the

traveller to the tourist info space

Information point BER nono Guides the

traveller to the Info desk

Parking area BER nono Shows parking

areas

Lost luggage point BER no noGuides the traveller to the lost bagge claim space

door to door information for air passengers · dora deliverable d3.1 door to door information for...

Documents