streetlife-d3.1-conceptual models and specifications for ... · fp7 - 608991 - streetlife d3.1 –...
TRANSCRIPT
FP7-SMARTCITIES-2013
STREETLIFE
Steering towards Green and Perceptive Mobility of the Future
WP3 – Mobility data integration
D3.1 – Conceptual models and
specifications for mobility data integration
Due date: 31.01.2014 Delivery Date: 07.02.2014
Editor: Sandro Castronovo (DFKI),
Monika Mitrevska (DFKI)
Contributors: Peppo Valetto (FBK), Mika Vuorio
(CGI), Antti Nurminen (AALTO)
Contributing partners: DFKI, FBK, CGI, AALTO, DLR, Siemens AG
Dissemination level: Public
Nature of Deliverable: Report
Internal Reviewers: Michael Bahr (Siemens AG), René Kelpin (DLR)
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 2 of 32
Executive Summary: The objective of this deliverable is to describe the required data for the
STREETLIFE system and scenarios. The document gives an overview of the STREETLIFE
Data Model (SDM) on a conceptual level that will serve as a specification for the
STREETLIFE mobility platform, which will be implemented later in the project. The data
sources that contribute to the SDM were identified in a twofold process: First, a survey of the
available data sources on the pilot sites was conducted. The results reflect a common view of
the consortium on exploitable data sources. Second, the STREETLIFE pilot sites scenarios
were discussed with the partners. The resulting scenarios generated requirements to data
sources that in turn influenced the SDM. Both sources provided valuable information about
the requirements and expectations of the system and contributed in creating a global view of
the required data.
We describe a high-level data model that is generic enough to be used as blueprint for the
pilot sites. We do not provide any detailed level of database design. The purpose of this model
is to provide an overview and common understanding of the required data, entities that need
to be represented, their main attributes and the main relations among them.
Three main parts of the model describing these requirements are the Communities, Services
and user model and are detailed in this document. In the process of creating the SDM, already
existing data models and ontologies were considered and influenced the mode, e.g. the user
model was based on the already existing general user model ontology and extended by
STREETLIFE specific data.
Already available data sources at the pilot sites were mainly describing the transportation and
infrastructure. Analysing their formats and standards contributed in creating the Context
model and the Transportation model of the SDM.
Disclaimer: The information and views set out in this publication are those of the author(s)
and do not necessarily reflect the official opinion of the European Communities. Neither the
European Union institutions and bodies nor any person acting on their behalf may be held
responsible for the use which may be made of the information contained therein.
© Copyright in this document remains vested with the STREETLIFE Partners
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 3 of 32
D3.1 – Conceptual models and
specifications for mobility data integration
Table of Contents
ABBREVIATIONS ............................................................................................................................................... 4
PARTNER NAME CORRESONDING TO ABBREVIATION IN STREETLIFE DOW ............................. 5
LIST OF FIGURES .............................................................................................................................................. 5
LIST OF TABLES ................................................................................................................................................ 6
1. INTRODUCTION ............................................................................................................................................. 7
1.1. WP3 OVERVIEW ........................................................................................................................................... 7 1.2. CONCEPT AND DELIVERABLE OBJECTIVE(S) ................................................................................................. 7
2. PILOT SITES: ESTABLISHED DATA REPRESENTATION FORMATS AND STANDARDS ............ 9
2.1. CURRENT STATE ON PILOT SITES .................................................................................................................. 9 2.2. DATA TYPES ............................................................................................................................................... 10
3. STREETLIFE DATA MODEL DESIGN ..................................................................................................... 11
3.1. DESIGN FOUNDATIONS ............................................................................................................................... 11 3.2. STREETLIFE DATA MODEL (SDM) ......................................................................................................... 12
3.2.1. User Model ........................................................................................................................................ 14 3.2.2. Context Model ................................................................................................................................... 19 3.2.3. Transportation Model ........................................................................................................................ 24 3.2.4. Services Model ................................................................................................................................... 26 3.2.5. Communities Model ........................................................................................................................... 26
4. CONCLUSION................................................................................................................................................ 27
5. LITERATURE ................................................................................................................................................ 28
APPENDIX A: DATA OVERVIEW TABLE................................................................................................... 29
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 4 of 32
ABBREVIATIONS
BER City of Berlin
CO Confidential, only for members of the Consortium (including the Commission
Services)
D Deliverable
DoW Description of Work
FP7 Seventh Framework Programme
FLOSS Free/Libre Open Source Software
GUI Graphical user Interface
IPR Intellectual Property Rights
MGT Management
MS Milestone
OS Open Source
OSS Open Source Software
O Other
P Prototype
POI Point of Interest
PU Public
PM Person Month
R Report
ROV Commune di Rovereto
RTD Research and Development
SDM STREETLIFE Data Model
TAM City of Tampere
WP Work Package
Y1 Year 1
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 5 of 32
PARTNER NAME CORRESONDING TO ABBREVIATION IN STREETLIFE DOW
Fraunhofer Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V.
FBK Fondazione Bruno Kessler
SIEMENS Siemens AG
DFKI Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
AALTO Aalto University
DLR Deutsches Zentrum für Luft- und Raumfahrt
CAIRE Cooperativa Architetti e Ingeneri - Urbanistica
Rovereto Comune di Rovereto
TSB Berlin Partner for Business and Technology
Tampere City of Tampere
Logica CGI Suomi Oy
LIST OF FIGURES
Figure 1: SDM - Overview ....................................................................................................... 13
Figure 2: STREETLIFE User Model - Main concepts ............................................................ 14
Figure 3: Concept - BasicInfo .................................................................................................. 15
Figure 4: Concept - Accounts ................................................................................................... 16
Figure 5: Concept - Devices ..................................................................................................... 16
Figure 6: Concept - Relationships ............................................................................................ 17
Figure 7: Concept - STREETLIFEProfile ................................................................................ 18
Figure 8: Concept - ContextData ............................................................................................. 18
Figure 9: Concept - EnvironmentalData .................................................................................. 19
Figure 10: Concept - Events ..................................................................................................... 20
Figure 11: Concept - PointOfInterest ....................................................................................... 22
Figure 12: Concept – Infrastructure ......................................................................................... 23
Figure 13: Concept - Transportation ........................................................................................ 25
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 6 of 32
Figure 14: Concept - Services .................................................................................................. 26
Figure 15: Concept - Communities .......................................................................................... 26
LIST OF TABLES
Table 1: Properties - BasicInfo ................................................................................................. 15
Table 2: Properties - EnvironmentalData ................................................................................. 20
Table 3: Properties - Events ..................................................................................................... 21
Table 4: Properties - ExternalParties ........................................................................................ 21
Table 5: Properties - PointOfInterest ....................................................................................... 23
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 7 of 32
1. INTRODUCTION
1.1. WP3 overview
The objective of WP3 is to integrate different data resources and establish a unique interface that can
be accessed and queried by the mobility services developed in the scope of the Urban Mobility
System. Taking into account national and European data protection regulations, data will be stored in
the mobility cloud and is therefore available to the entire STREETLIFE system.
WP3 scope of work involves building a STREETLIFE data model (SDM), analysing and integrating
different data sources into the model, data correlation and analysis, real-time data solutions, crowd
sourcing and intermodal mobility data representation.
In the first meetings with representatives of the consortium, the following collaborations with other
WPs could be identified:
WP2 integrates the SDM into the overall system architecture. Together with WP2, APIs for
generic access of mobility data will be developed.
WP3 provides interfaces for mobility data visualisation in WP4. More precisely, the
output of Task 3.1 will serve as input for Task 4.1.
WP5 relies on the open accessibly APIs that result from Task 3.4. Furthermore, WP3
delivers data for personalized travel assistance and routing for WP5.
WP6 delivers detailed information of available data sources to WP3. This information
serves as a basis for the SDM.
Partners contributing to WP3 are AALTO, DFKI, FBK, and CGI.
1.2. Concept and deliverable objective(s)
The objective of this deliverable is to describe the required data for the STREETLIFE system
and scenarios. The deliverable will give an overview of the STREETLIFE Data Model (SDM)
on a conceptual level that will serve as a specification for the STREETLIFE mobility
platform, which will be implemented later in the project. The data sources that contribute to
the SDM were identified in a twofold process: First, a survey of the available data sources on
the pilot sites was conducted. The results reflect a common view of the consortium on
exploitable data sources. Second, the STREETLIFE pilot sites scenarios were discussed with
the partners. The resulting scenarios generated requirements to data sources that in turn
influenced the SDM.
This document details on the information that has been gathered during the first four months
of the project. Rovereto and Tampere already have smart mobility systems in place that are
available to STREETLIFE. The situation in Berlin was settled during the first months of the
project. The data in Berlin is mainly available through VMZ Berlin Betreibergesellschaft
mbH, a 100% subsidiary of Siemens AG, that is operating the Berlin traffic information
system on behalf of the Senate of Berlin. VMZ will participate in project, actually starting in
Q1/2014 and will provide the data that is described in Appendix A. The SDM presented in
this deliverable originated in a condensed view of the Rovereto and Tampere data sets.
Additional information from Berlin were added later to the SDM.
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 8 of 32
The SDM described in this deliverable is conceptual, e.g. no options for technical realizations
are analysed at this early stage of the project.
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 9 of 32
2. PILOT SITES: ESTABLISHED DATA REPRESENTATION FORMATS AND STANDARDS
STREETLIFE’s goal is to reduce carbon emission and to promote users’ green behaviour
through advanced, personalized route planning and travel assistance. To be able to do that, the
system needs to consider and bring together several heterogeneous mobility-related data-
sources and services. The great amount of data sources and the broad variety of already
existing services in the transportation domain makes this task complex. Additional complexity
adds the fact that the project covers three different cities of different size in three countries
with different language, culture of mobility and transport usage, regulations, and existing
solutions.
The goal of deliverable D3.1 is to create a common understanding and to provide a basis for a
common representation of the required STREETLIFE data.
2.1. Current state on pilot sites
A starting point in the process of creating the SDM is the analysis of the current state at the
pilot sites. This section gives an overview of the data source formats and technologies that
could be identified at the pilot sites. Further analysis of these formats will help us to define a
unique data model that will be used by all logical components of STREETLIFE.
The survey among the responsible partners of the pilot sites resulted in a consolidated list of
35 data sources. These have been classified into eight categories:
Maps and cartography
Public transport information
Points of Interest (POIs)
State tracking
External events
User info
Environmental info
City statistics
Maps and cartography contains all kinds of available road networks on the pilot sites.
Besides the road network itself, street names, bike lanes, hiking routes as well as rural roads
comprise the data sources of this category. We expect the road network to be available on
every pilot site in either OSM (ROV, BER) or ESRI Shapefile format (TAM).
Public transport information in STREETLIFE includes bus and train routes, stops and
timetables. These are available as General Transit Feed Specification (GTFS) on every pilot
site. Additionally, we intend to include real time information about delays and timetable
changes. ROV and TAM signalled availability but the formats differ significantly. While
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 10 of 32
ROV represents real time data in a proprietary JSON format, TAM uses GTFS/SIRI and RSS
feeds.
Points of Interest (POIs) denote added value services for users that are bound to geo-
graphical locations. Here, street level parking, parking garages, and car sharing pick-up points
as well as bicycle-sharing pick-up points have been identified as data sources in the context of
STREETLIFE. However, access to this kind of information is available only in ROV and only
via a proprietary JSON format. Furthermore, road-side infrastructure will be included. It
consists of traffic lights and streetlights as well as WiFi hotspots. However, the pilot sites
rarely support this kind of information. At this point, TAM indicates availability of traffic
light and street light information.
State tracking refers to events that can be pinpointed to a geographical location or area. As a
result of our initial survey of available data sources, the pilot sites reported historic
information on accidents, road works, cultural and commercial events, weather and crowd
sourcing in this category. The latter refers to user inputs about bus delays or accidents. ROV
and TAM both support this data source but in different formats.
User info data sources serve as input for the user profile. This kind of information is highly
relevant for the multimodal personalized route-planning component in STREETLIFE and will
therefore be represented in the SDM. We identified three data sources in this context: i.) static
personal information like gender, age, etc., ii.) dynamic data that is captured while interacting
with the system and iii.) information that is available from social networks.
Environmental info is, for example, relevant for calculating the carbon footprint of a
multimodal transportation route. Hence, the project will develop a formula that determines
this value. Of course, this has to be represented in the SDM. Additionally, we include
information about air pollution if available.
City statistics on population, tourism, and economics might be valuable for the end user and
are therefore also represented in the SDM.
2.2. Data types
The SDM distinguishes three different data types. Each data source is static, dynamic or real
time. The classification is done depending on the expected update interval.
Data type Update interval
static > 1day
dynamic 1sec < update interval < 1day
real time < 1sec
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 11 of 32
3. STREETLIFE DATA MODEL DESIGN
The data model created in this first phase of the project is a result of combined analysis of the
already existing data sources at the pilot sites and the initially created STREETLIFE
scenarios. Both sources provided valuable information about the requirements and
expectations of the system and contributed in creating a global view of the required data.
Within WP6: City pilot planning and evaluation, the initial scenarios for the three pilot sites
were defined. The scenarios elaborated on the potential services the system should provide,
their functionalities and requirements. We defined the STREETLIFE specific data
requirements by analysing the scenarios. Three main parts of the model describing these
requirements are the Communities, Services and User model.
Already existing and used data sources at the pilot sites were mainly describing the
transportation and infrastructure. Analysing their formats and standards contributed in
creating the Context model and the Transportation model of the SDM.
In the first phase of the project we create a high-level data model that is generic enough to be
used as blueprint for the pilot sites. We do not provide any detailed level of database design.
The purpose of this model is to provide an overview and common understanding of the
required data, entities that need to be represented, their main attributes and the main relations
among them.
3.1. Design Foundations
In the process of creating the SDM already existing data models and ontologies were
considered.
User modelling is an essential part of human-computer interaction, thus many different
models have been created to serve different applications and purposes. In [1] general user
model ontology (GUMO) is proposed. This ontology collects user dimensions that are
modelled within user adaptive systems. The ontology is divided in four main groups of
information: Basic, Context, Domain and Extended. Analysing GUMO through
STREETLIFE perspective we realized that the model does not fit completely to a traveller
profile. The ontology includes wide range of general user data that can be adopted from
applications in the transportation domain but the STREETLIFE model requires additional
traveling-related user information. Common behaviour on the roads, traveling habits and
preferences and time pressure are a few of the examples that need to be added in the
STREETLIFE model.
On the other hand, there is information in the model (e.g. psychological and emotional state,
mood and other detailed personality information) that are either not relevant or are not
possible to obtain so they will not be included in the SDM.
Knowledge, Adaptation and Personalization component – KAPcom is a project that as a core
component creates an automotive ontology [2]. The KAPcom ontology provides semantic
knowledge about the user, the vehicle and the current driving situation. With a goal to
simplify access to information and data exchange the automotive ontology avoids modelling
of high level details. The main elements of the ontology are: Concepts, Properties, is-a
relation, has-part relation, has-property relation and Meta-data.
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 12 of 32
The three top-level collection concepts are: User, Vehicle and Trip. The STREETLIFE User
model is created using GUMO but additional authentication data is added. The Vehicle model
and the Trip model belong to the context model. The Vehicle model describes the technical
details, current state, manoeuvres, connected devices and sensors. The trips model describes
the context of a trip (start, destination, purpose, navigation).
3.2. STREETLIFE Data Model (SDM)
The SDM is designed to capture the user and detailed urban travelling context around the
user.
The data is defined and organized using properties, concepts, and relations.
As defined in [2]:
Concepts: Concepts are the prototypes of a knowledge instance and their purpose can be
compared with the purpose entities have in ontologies.
Relations: Define the relations between concepts.
The SDM model furthermore defines the following basic relations:
Is-a: relation defining the inheritance between concepts
atTime: relation between a concept and a temporal concept Timestamp. It defines the point of
time when an event happened.
isValidFor: another temporal relation that defines the duration or validity of things. Used for
events, road works, time tables etc.
atPosition: is a relation between a concept and a spatial concept Point. Defines the location
(longitude and latitude) where an event occurred.
atLocation: similar to atPosition, the relation defines the place there an event occurred, but the
domain concept is an area instead of a point.
The rest of the relation are concept specific and will be mentioned when the concept is
explained.
Properties: Properties, often called attributes, slots or fields are pointers to plain values only
evaluated with respect to the concept to which they belong.
Sample properties for some of the concepts are provided in this deliverable. The list is not
fixed and can be extended and improved in the later stage of the project.
SDM has five main concepts: User, Services, Transportation, Context, and Communities.
Figure 1: SDM - Overview
3.2.1. User Model
The user is the central figure in the STREETLIFE system. To meet user’s needs and provide
best services, STREETLIFE needs a user model that is designed to capture the static
information and preferences but at the same time contains enough information to be able to
learn from user’s behaviour and introduce personalization into the services.
Building on the GUMO model, STREETLIFE user model captures users’ basic information,
information about users’ accounts and devices, relations with other users as well as a detail
STREETLIFE profile data. This information is organized into five main user concepts (Figure
2)
Figure 2: STREETLIFE User Model - Main concepts
BasicInfo. BasicUserDimensions is a large part of GUMO ontology and covers a wide range
of dimensions that describe a user. While most of these dimensions (as previously mentioned:
Mental state, Mood, etc.) do not fit into STREETLIFE model, contact information abilities,
demographics and physical condition are categories that cover the basic personal information
that can be also adopted by theSTREETLIFE User model. The concept BasicInfo has four sub
concepts: ContactInfo, Abilities, Demographics and Physical (Figure 3). Information about
the properties of these concepts can be found in Table 1.
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 15 of 32
Figure 3: Concept - BasicInfo
BasicInfo Properties Description
ContactInfo Basic contact information about the user
Name,address, phoneNumber, email, url
Demographics Basic demographic information about the user
Gender, age, ageGroup, birthday, birthplace, firstLanguage, secondLanguage
Abilities
canSee,canHear, canTouch, canSmell, canGrasp, canWalk, canUseStairs, canSwim, canCycle, canDrive, canTalk, canFeel
Physical
height, weight
Table 1: Properties - BasicInfo
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 16 of 32
Accounts. Given the large number of possible “identities” the user can have these days, such
as social networks, mobile applications, mobile messaging etc., and the advantages of
interconnectivity this concept connects the STREETLIFE system with any other type of
account that the user wants to share. The two sub-concepts Account and Authentication define
the 3rd
party systems and user credentials for those systems (Figure 4).
Figure 4: Concept - Accounts
Devices: Similar to Accounts, users very often have multiple devices that they use to access
the system. For each of these devices they can have different system preferences (interface,
privacy or presentation preferences). This concept holds information about the user’s devices
and the preferences they have using the system on their devices (Figure 5).
Figure 5: Concept - Devices
Relationships: This concept keeps track of the user’s relationship with other users. The type
of the relationship can vary (family, friend, colleague are initial examples)(Figure 6).
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 17 of 32
Figure 6: Concept - Relationships
STREETLIFEProfile. This concept defines STREETLIFE specific user data. It is divided
into seven sub concepts and it is designed to capture user’s travel relevant data (Figure 7).
Preferences and Routines are concepts that capture the travel habits of the users. In
Preferences the users can define the type of routes they prefer (fastest, shortest, less stressful
etc.) – RoutingPreferences. They can also specify their transportation preferences (no bike,
prefer bike, no car, prefer car etc.) – TravelModePreferences. This information will be used in
combination with other constraints: the abilities that are defined in the BasicInfo concept or
with the available services. In Routines users can enter their regular trips (for example, home
– work – home) as well as their calendars for more convenient services. To enhance its main
service – trip planning, STREETLIFE will offer additional independent services (carpooling,
bike sharing etc.). UserServices and UserVehicles are reference concepts that define the
services that the user is registered for and the vehicles that the user owns.
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 18 of 32
Figure 7: Concept - STREETLIFEProfile
ContextData is a concept that captures the current behaviour of the user. It is divided in two
sub concepts: TravelContext and InteractionContext (Figure 8).
Figure 8: Concept - ContextData
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 19 of 32
TravelContext tracks the current position of the user, the motion type (walking, driving,
riding) and current trips users are taking.
InteractionContext tracks the user interaction with the system, applications and games.
Details about the interaction types will be known when detailed specification of the
STREETLIFE applications is made.
In a broader sense traveling context includes also the physical environment, conditions on
roads, weather, schedules, etc. This information is captured by the concept Context presented
in 3.2.2.
To be able to provide personalized services to the users, STREETLIFE will record user’s
behaviour and choices into a concept called UserHistory. The amount of data that will be
saved and the period of time, STREETLIFE will keep this data, will be determined later in the
project after the privacy regulations in the three different countries are checked.
As the main goal of STREETLIFE is to promote “green” behaviour and to reduce the carbon
emission a GreenProfile on a user and trip level will help STREETLIFE to evaluate the
progress it makes and also to motivate users to take recommended “green” trips.
3.2.2. Context Model
The Context model includes all the aspects related to the trips that users take. In the following
paragraphs, the separate concepts that are part of the Context model (EnvironmentalData,
Events, ExternalParties, PointOfInterest, Infrastructure, and TemporalData) are elaborated.
EnvironmentalData (Figure 9 and Table 2): This concept describes the state of the
environment at a given point in time on a given area. Even though environmental data can
have many dimensions and detailed information, Pollution and Meteorology are of interest in
STREETLIFE. The pollution can be defined either by the emission of CO2 that different
travel modes (cars, buses, trains) have – CO2Emission or by the general pollution statistics
that a given area or city has – PollutionState. Weather is another sub concept of Meteorology.
PollutionState and Weather are connected through the relations atTime and atLocation with
the concepts Timestamp and Places (Figure 9).
Figure 9: Concept - EnvironmentalData
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 20 of 32
EnvironmentalData Properties Description
Weather Basic weather measurements
airPressure, moisture, rain, snow, temperature, wind
CO2Emission CO2 emission level of different vehicle types
CO2, vehicleType
PollutionState Different measurements defining the pollution state of a city or area
CO, CO2, NO2, O3, PM10, pollutionScale
Table 2: Properties - EnvironmentalData
Events (Figure 10 and Table 3): This concept defines the events that can influence the
movement of the user, the trip planning and routing. The events can belong either to City
Events or Road Events. City events include cultural events, sport events, concerts and all other
events that by its size or popularity can influence the traffic in the city. The road events can be
either StreetWorks or Incident. Using relations the place, time and duration of the events is
defined. Events in STREETLIFE can be reported by a user or by a service, so the SourceType
is another sub concept that defines the events (Figure 10).
Figure 10: Concept - Events
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 21 of 32
Events Properties Description
eventDescription
eventEffect update impact on the transport network (e.g., road blocked)
Table 3: Properties - Events
ExternalParties (Table 4) are companies that are in any way connected with the system.
They can be owners of the public transport, rental vehicles, rental bikes etc.
ExternalParties Properties Description
Agency External parties with connection to the system (vehicle owners, service providers etc.)
Id, name, address, phone, url
Table 4: Properties - ExternalParties
PointOfInterest (Figure 11 and Table 5): From a STREETLIFE perspective, point of interest
is any point that is part of the traffic information and can be beneficial for the routing
algorithm. Like that, points of interest include parking places, rental places, traffic lights etc.
The concept is divided into six sub concepts. SharingFacilities and ParkingFacilities define
spaces where one can park a vehicle or can share/rent one. The concepts include the capacity
of the facilities, the availability, the owners, the position, the location etc. Points of interest
also include ParkingMeters, TrafficLights, StreetLights and WiFiHotspots (Figure 11).
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 22 of 32
Figure 11: Concept - PointOfInterest
PointOfInterest Properties Description
ParkingFacilities Parking places
Id, name, roadSurface, monitored, parkingCapacity, parkingFee (metered), prePay/postPay
BIkeParking
rackCapacity, rackCount, rackType, lockingOptions
VehicleParking
free parking, freeCapacity
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 23 of 32
SharingFacilities Car or bicycle sharing or renting places
facilityName, facilityCapacity, facilityDescription, freeCapacity, carSharingCompany
Table 5: Properties - PointOfInterest
Infrastructure (Figure 12): This concept describes the environment. It follows the OSM data
format. The BasicElements (way and point) correspond to the OSM data primitives Node and
Way. The rest of the Infrastructure sub concepts (Amenity, Places, Buildings and Highways)
are defined by the basic elements and correspond to the OSM map features (Figure 12).
Figure 12: Concept – Infrastructure
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 24 of 32
TemporalData: TemporalData is a concept that will add information and temporal context to
the rest of the data. With its two sub concepts Timestamp and Duration, STREETLIFE will
have a tool to mark the point in time when an event occurs and, if applicable, the period this
event is valid for.
3.2.3. Transportation Model
The concept Transportation describes the possible modes of transportation that users can take
and their schedules. The concept is divided in three sub concepts: TransportationMode,
Network and TimeTables. TransportationMode divides the transportation means in two main
groups: vehicles and public transport. The Vehicles concept describes the vehicles, their type,
location, ownership, and function. PublicTransport contains information about buses and
trains. Network describes predefined trips, routes, and stops for some of the vehicles (public
transport or shared vehicles). TimeTables describes the schedule of the transportation (Figure
13).
Figure 13: Concept - Transportation
3.2.4. Services Model
STREETLIFE functionality will be structured into several services that can collaborate and/or
work independently. TripPlanner, CarPooling, BikeSharing and ParkAndRide are the initial
services defined in the scenarios (Figure 14). The complete set of services and necessary data
will be defined later in the project.
Figure 14: Concept - Services
3.2.5. Communities Model
Even if users do not have a direct relation to each other they can directly or indirectly form
communities (Figure 15). Communities can be of any kind: work in the same company, live
in the same neighbourhood, have common commuting routes, etc. The communities help the
system to connect users in order to improve the services (e.g. car sharing).
Figure 15: Concept - Communities
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 27 of 32
4. CONCLUSION
In the deliverable D3.1: Conceptual models and specifications for mobility data integration,
the conceptual data model for STREETLIFE is presented. Data available at pilot sites was
taken into account when creating the model. The scenarios defined for the three pilot sites
were also used to determine the data requirements and to design the model. The model itself
is divided in five main concepts: User, Context, Transportation, Services, and Communities.
Definition of these concepts, their sub concepts, properties and the relation between the
concepts are elaborated.
We want to emphasize that the presented model is not the final STREETLIFE data model.
Once the scenarios are defined and elaborated in more detail and the implementation phase
begins, refinement of the model will be necessary.
As a next step, WP3 will define the database schema in collaboration with WP2 and WP6.
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for
mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 28 of 32
5. LITERATURE
[1] D. Heckmann, T. Schwartz, B. Brandherm, M. Schmitz and M. von Wilamowitz-
Moellendorff, "Gumo–the general user model ontology," in User modeling, Springer
Berlin Heidelberg, 2005.
[2] M. Feld and C. Müller, "The automotive ontology: managing knowledge inside the vehicle
and sharing it between cars.," in 3rd International Conference on Automotive User
Interfaces and Interactive Vehicular Applications, 2011.
APPENDIX A: DATA OVERVIEW TABLE
Explanation:
Data source category Color
DS1-DS5 Maps and cartography
DS6-DS9 Public transport information
DS10-DS16 POIs
DS17-DS24 State Tracking (incl. traffic)
DS25-29 external events
DS30-32 user info
DS33-34 environmental info
DS35-… city statistics
Availability Meaning
In use The pilot site already uses this data
In use (OD) The pilot site already uses this data (provided as open data)
Is use (OS) The pilot site already uses this data (provided as open service)
Available The data is available but not used yet
Availability TBD Data for which it is not clear whether the pilot is going to be able to get access to
Not available Currently, data is not available at the pilot site
ID Type Name Definition ROV
format ROV
availability TAM format
TAM availailbility
BER format BER
availability
DS1 s City road network road network OSM In use (OD) SHP,Mapinfo,Raster In use (OD)
Detail Network Berlin (Berliner
Detailnetz), shapefiles, Mapinfo In use
DS2 s City street network street names, numbers SHP In use (OD) SHP,Mapinfo,Raster In use (OS)
Detail Network Berlin (Berliner
Detailnetz), shapefiles, Mapinfo In use
DS2-b s City street guide city street info (queries) WMS, WFS
In use (OS) unknown Availability
TBD Not available
DS3 s City bicycle roads bike lane network OSM Available JSON, GML2,
GML32, SHP-ZIP, CVS
In use (OD)
Detail Network Berlin (Berliner
Detailnetz), shapefiles, Mapinfo In use
DS4 s promenading and hiking routes
route coordinates - Not available - Not available
Detail Network Berlin (Berliner
Detailnetz), shapefiles, Mapinfo In use
DS5 s Rural roads map of walk and bike paths (from GPS)
GPX In use (OD) ESRI, XML In use
Detail Network Berlin (Berliner
Detailnetz), shapefiles, Mapinfo In use
DS6 s Bus (public transport) routes
bus timetables, stops, routes and shapes
GTFS In use (OD) GTFS/SIRI In use (OS) GTFS Available
DS7 s Trains routes train timetables, stops, routes and shapes
GTFS In use (OD) GTFS/SIRI In use (OS) GTFS Available
DS8 r Real time bus (public transport) information
delays, timetable changes JSON Availability TBD GTFS/SIRI In use (OS)
Not available
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 31 of 32
DS9 r Real time train information
delays, timetable changes JSON In use (OS) XML/RSS feed Available Not available
DS10 s Street level parking location of street-level parking facilities and parking meters
JSON Availability TBD MID, MIF Not available CSV Available
DS11 s Car parking garages location and capacity of parking garages
JSON Available unknown In use CSV Available
DS12 s Car sharing pick-up points
location of pick-up points JSON Available - Not available SOAP/Proprietary In use
DS13 s Bicycle sharing pick-up points
location of pick-up points JSON Available - Not available SOAP/Proprietary In use
DS14 d Traffic lights information about traffic light signals and devices
- Not available JSON, GML2,
GML32, SHP-ZIP, CVS
In use (OD) Not available
DS15 s Street lights Street lighting data - Not available CSV Available Not available
DS16 s WLAN hotSpot public WLAN hotspots - Not available - Not available Not available
DS17 d Parking garages availability
free available places in parking garages
JSON In use (OS) unknown Available SOAP/Proprietary Available
DS18 d Bike parking availability
free available places in parkings for bicycles
- Not available JSON, GML2,
GML32, SHAPE-ZIP, CSV
Available Not available
DS19 d Car sharing state current position of available vehicles
unknown Availability TBD - Not available SOAP/Proprietary In use
DS20 d Bicycle sharing state current position of available bicycles
Web api Availability TBD - Not available SOAP/Proprietary In use
DS21 d Car flows past and real time information about road traffic
DBF Availability TBD Datex II,
XML/WSDL, PDF, XLS, shapefile
In use WMS In use
DS21-b
d Car flows ESTIMATED car flow DBF, SHP Availability TBD - Availability
TBD Not available
DS22 d Floating car data data captured by taxi fleet - Not available - Not available Not available
DS23 r Bike flows past and real time information about traffic on bike lanes
unknown Availability TBD - Not available Not available
DS24 d Bike floating data Data captured by bike fleet unknown Availability TBD - Not available Not available
FP7 - 608991 - STREETLIFE D3.1 – Conceptual models and specifications for mobility data integration
WP3 – Mobility Data Integration STREETLIFE Consortium Page 32 of 32
DS25 s Accidents historic Information on accidents Web api Available - Not available SOAP/Proprietary Available
DS26 d Road works crowdsourced information on road works
- Not available GML In use (OS) SOAP/Proprietary Available
DS27 d Cultural and commercial events
Information about current events and their location
- Not available - Not available SOAP/Proprietary Available
DS28 d Weather weather condition and forecast Web api Available XML(WMS, WFS) In use (OS) Not available
DS29 d Crowd sourcing users input information about bus delays, accidents, etc.
JSON Available Datex II Available Not available
DS30 s User profile static personal information unknown Availability TBD unknown In use Not available
DS31 d User preferences captured using the interaction with the system
unknown Availability TBD unknown In use SOAP/Proprietary Available
DS32 d Social networks unknown Availability TBD - Not available Not available
DS33 d Air pollution air pollution on a city level Web api Available - Not available FTP/Proprietary In use
DS34 s CO2 emission formula to determine carbon footprint
unknown Availability TBD html In use Not available
DS35 s Statistical information
population, tourism, economics Web api Available - Not available
Availability TBD