streetlife-d3.1-conceptual models and specifications for ... · fp7 - 608991 - streetlife d3.1 –...

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 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




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




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




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




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




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.




The SDM described in this deliverable is conceptual, e.g. no options for technical realizations

are analysed at this early stage of the project.




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




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




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.




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.




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




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).




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.




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




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




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




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).




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




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




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




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.




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)



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)



DS4 s promenading and hiking routes

route coordinates - Not available - Not available



DS5 s Rural roads map of walk and bike paths (from GPS)

GPX In use (OD) ESRI, XML 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


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


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

streetlife-d3.1-conceptual models and specifications for ... · fp7 - 608991 - streetlife d3.1 –...

Documents