Executive summary

This document includes information about the data sources that the VaVeL
consortium will work and conduct research on. More specifically for each data
source the partners have defined a data management plan. The plan consists of
information about legal issues, privacy, infrastructure changes, archiving,
maintenance, standards and accessibility. The document will be regularly
updated as more information becomes available and data issues are resolved.
Please check the website of the project (  www.vavel-project.eu)  under the
deliverables section for updates. Early on, the consortium has agreed to make
every effort to provide open access to as many datasets as possible. This
document reflects this continuous effort.

Document Information  
  
<table>  
<tr>  
<th>

Contract Number

</th>  
<th>

H2020-688380

</th>  
<th>

Acronym

</th>  
<th>

VaVeL

</th> </tr>  
<tr>  
<td>

Name

</td>  
<td>

Variety, Veracity, VaLue: Handling the Multiplicity of Urban Sensors

</td> </tr>  
<tr>  
<td>

Project URL

</td>  
<td>

http://www.vavel-project.eu/

</td> </tr>  
<tr>  
<td>

EU Project Officer

</td>  
<td>

First Name - Last Name

</td> </tr>  
<tr>  
<td>

Deliverable

</td>  
<td>

D1.3

</td>  
<td>

Data Management Plan

</td> </tr>  
<tr>  
<td>

Work Package

</td>  
<td>

Number

</td>  
<td>

WP1

</td> </tr>  
<tr>  
<td>

Date of Delivery

</td>  
<td>

31/05/2016

</td>  
<td>

Actual

</td>  
<td>

31/05/2016

</td> </tr>  
<tr>  
<td>

Status

</td>  
<td>

Final

</td> </tr>  
<tr>  
<td>

Nature

</td>  
<td>

Report

</td> </tr>  
<tr>  
<td>

Distribution Type

</td>  
<td>

Public

</td> </tr>  
<tr>  
<td>

Authoring Partner

</td>  
<td>

National and Kapodistrian University of Athens

</td> </tr>  
<tr>  
<td>

QA Partner

</td>  
<td>

IBM

</td> </tr>  
<tr>  
<td>

Contact Person

</td>  
<td>

Ioannis Katakis

</td>  
<td>

katak@di.uoa.gr

</td> </tr>  
<tr>  
<td>

</td>  
<td>

Dimitrios Gunopulos

</td>  
<td>

dg@di.uoa.gr

</td> </tr>  
<tr>  
<td>

</td>  
<td>

Phone

</td>  
<td>

</td>  
<td>

Fax

</td>  
<td>

</td> </tr> </table>

List of Contributors: Ioannis Katakis (UoA), Dimitrios Gunopulos (UoA),
Jaroslaw Legierski

(OPL), Izabella Krzeminska (OPL), Robert Kunicki (CoW), Jakub Marecek (IBM),
Maggie O’Donnell (DCC), Aaron O’Connor (DCC).

Project Information

This document is part of a research project funded by Horizon H2020 programme
of the Commission of the European Communities as project number 688380. The
Beneficiaries in this project are:  
  
<table>  
<tr>  
<th>

No.

</th>  
<th>

Name

</th>  
<th>

Short Name

</th>  
<th>

Country

</th> </tr>  
<tr>  
<td>

1

</td>  
<td>

National and Kapodistrian University of

Athens

</td>  
<td>

UoA

</td>  
<td>

Greece

</td> </tr>  
<tr>  
<td>

2

</td>  
<td>

Technische Universit¨at Dortmund

</td>  
<td>

TUD

</td>  
<td>

Germany

</td> </tr>  
<tr>  
<td>

3

</td>  
<td>

Technion - Israel Institute of Technology

</td>  
<td>

Technion

</td>  
<td>

Israel

</td> </tr>  
<tr>  
<td>

4

</td>  
<td>

Fraunhofer-Gesellschaft Zur F¨orderung Der Angewandten Forschung E.V.

</td>  
<td>

Fraunhofer

</td>  
<td>

Germany

</td> </tr>  
<tr>  
<td>

5

</td>  
<td>

IBM Ireland Limited

</td>  
<td>

IBM

</td>  
<td>

Ireland

</td> </tr>  
<tr>  
<td>

6

</td>  
<td>

AGT International

</td>  
<td>

AGT GROUP (R&D) GMBH

</td>  
<td>

Germany

</td> </tr>  
<tr>  
<td>

7

</td>  
<td>

Orange Polska S.A.

</td>  
<td>

OPL

</td>  
<td>

Poland

</td> </tr>  
<tr>  
<td>

8

</td>  
<td>

Dublin City Council

</td>  
<td>

DCC

</td>  
<td>

Ireland

</td> </tr>  
<tr>  
<td>

9

</td>  
<td>

City of Warsaw

</td>  
<td>

CoW

</td>  
<td>

Poland

</td> </tr>  
<tr>  
<td>

10

</td>  
<td>

Warsaw University of Technology

</td>  
<td>

WUT

</td>  
<td>

Poland

</td> </tr> </table>
#  Introduction

In this document the VaVeL consortium presents information about the data that
will be exploited in the context of the project. It is by design that the
major data providers are also member of the consortium. These are:

The Dublin City Council, that will provide traffic, public transport, weather
and video data.

The City of Warsaw, that will provide public transport data, data on emergency
calls and citizen reporting.

Orange Polska, that will provide subscriber’s location data.

Figure 2: Real-Time Data from City of

Figure 1: Real-Time Data from City of Warsaw

Dublin

It is important to note that most of the above data sources will be provided
in _real-time_ . This document serves as a management plan for the above data
sources. More specifically it addresses the following issues and questions.

_Meta-data_ : Details about the meta-information that accompany our data (if
available).

_Standards_ : We mention any standards that are followed by the data or by the
way the consortium or the data providers provide access to the data.

_Infrastructure Improvements:_ The infrastructure providing the data is as
important as the data themselves. Hence, we present information on necessary
infrastructure changes that were required in order to improve any data-related
aspects (accessibility, information richness, volume, etc).

_Quality:_ Data veracity is one of the main objectives of VaVeL. We provide
brief information about the consortium’s efforts to address data quality
issues if necessary. Depending on the case, ‘quality’ might imply cleaning,
pre-processing, adding meta-data, transforming to a more convenient format or
providing easier access.

_Accessibility:_ We explicitly describe the access level provided for each
data source for various user groups (consortium, public, etc). On top of that
we outline the technical means that are necessary to access the data. We also
report on our efforts to make the data more easier to discover.

_Assessable and Intelligible:_ We describe the means that we provide in order
to make the data more easy to use and understand its content and value.

_Legal Issues & Privacy: _ The consortium provides details about legal issues
related to each dataset as well as the path of resolving them.

_Maintenance Plan:_ In this section we will describe the maintenance plan for
each dataset. More specifically, we will discuss archiving of historical data
and how the potential of maintaining/utilizing the data after the end of the
project.

Some of the above items were inspired by the document “Guidelines on Data
Management in Horizon 2020”, published by the European Commission,
Directorate-General for Research & Innovation (Version 1.0, 15 February 2016).

VaVeL’s Open Data Strategy and History. The consortium is willing to publicly
share and make easily accessible and discoverable as many datasets as
possible. Many data sets are already available online (see following sections)
and every effort will be made to make even more data sources accessible. On
top of that, the consortium intends to make available tools that analyze urban
data. More importantly the consortium has a history in publishing open data.
Dublinked (see Figure 3a) is a web platform hosting multiple data resources
originating from Dublin. On the other hand, the City of Warsaw along with its
technical partners (Orange) has a history in making APIs for processing and
accessing data open (api.um.warszawa.pl see Figure 3b).

(

a) The Dublinked website in Dublin

(

b) Open APIs in Warsaw

Figure 3: VaVeL’s history in publishing data

Open Data Portals On top of the above, the VaVeL consortium is currently
investigating the exploitation of additional portals and ways to disseminate,
archive, register and index its datasets and APIs in order to make the
resources more discoverable. Such are the following:

European Union Open Data Portal (  http://data.europa.eu/euodp/en/data)  where
a lot of European Organizations archive open data sets.

The programmable Web (  http://www.programmableweb.com/apis)  \- where more
than 15.000 APIs are indexed. This repository is especially suitable for the
APIs available from the City of Warsaw.

#  Dublin City Council Data

##  Data from a Traffic Management System (SCATS)

The Sydney Co-ordinated Adaptive Traffic System provides information on
vehicular traffic at fixed sensor locations as spatio-temporal time series.
The SCATS data are produced by aggregating the primary source data that are
collected by the Dublin SCATS traffic sensor monitoring system.

The primary data are given in the _Strategic Monitoring (SM)_ format Each
sensor sends messages with varying frequency (depending on the location,
conditions and other factors). The SM format specifies the message parameters.
In practice, data are imported from two sources. For a period of time in 2012,
the data have been recorded  1  as a sequence of following tuples:

_streetSegId_ : a unique identifier for a street segment ID, _armNumber_ : an
identifier for the arm on a street segment, _armAngle_ : bearing of the arm,
_gpsArm_ : GPS position 20 meters into the arm, _gpsCentroid_ : GPS position
of the centroid of the intersection. _aggerateCount_ : aggregated vehicles
volume count on the arm, _flow_ : flow ratio calculated as the volume divided
by the highest volume that has been measured in a sliding window of a week.

These samples are captured at 6-minute intervals. The more recent data from
01/01/2013 onwards are sampled every minute and are provided by DCC and IBM as
a sequence of following items

_year_ , _month_ , _day_ , _hour_ , _minute_ : denoting the timestamp _site_ :
measurement location _strategicApproachLink isLink detector index_ : index of
the detector _degreeOfSaturation_ : _flow/capacity flow_ : current flow value

These samples are used in conjunction with a file, which contains the
coordinates. The _detector index_ from the sequence refers to the _lane
number_ in the detectors.csv file.

These messages, in addition to the information that is maintained after the
aggregation to the SCATS format, includes additional system information that
is not used in our analysis. This dataset is a sequence of tuples ( _z,m,t_ ),
where _z_ is a geographic location of the observation (the sensor position),
_m_ is a metric and _t_ is an integer. The location is either _detector index_
, or a vector consisting of a number of elements, including the GPS
coordinates of the detector. The metric _m_ contains:

_aggerateCount_ : aggregated vehicles volume count on the arm, _flow_ : flow
ratio calculated as the volume divided by the highest volume that has been
measured in a sliding window of a week.

Integer _t_ element is the timestamp of the 5 minute interval in POSIX time,
i.e. the number of microseconds that have elapsed since 00:00:00 Coordinated
Universal Time (UTC), 1 January 1970.

Data Collection SCATS Region has automated collection of operational and
performance data. Traffic counts are collected on a lane-by-lane basis
wherever detectors are installed. Collected data can be sent to the SCATS
Central Manager for backup. If there is a failure in the communications with
SCATS Central Manager, SCATS Region maintains a queue of data until the
communications are restored. This ensures that there is no loss of data on the
SCATS Central Manager.

SCATS Central Manager manages the connection of up to 64 SCATS Regions (8
regions connected on the DCC system) and provides a global view of the whole
system. SCATS Region is the software that is used to manage the traffic signal
sites in a region. SCATS primarily manage the dynamic timing of signal phases
at traffic intersections. The system uses sensors at each traffic intersection
to detect vehicle presence in each lane and pedestrian demands. The vehicle
sensors are inductive loops installed beneath the road surface.  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

XY coordinate data for SCATS intersections. Traffic volumes for intersections.
SCATS Picture is the application that is used to create or modify the site
location details and site graphics stored in the SCATS Central Manager
database. Meta data for the site is stored in the LX files

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

SCATS Access version 6.9.2 Copyright  2014 Roads and Maritime Services. SCATS
proprietary format is the property of RMS. The format of the data that has
been passed on to the consortium currently can be made available to 3rd
parties. SCATS data stream is provided in JSON format.

</td> </tr> </table>  
<table>  
<tr>  
<th>

Infrastructure

Improvements

</th>  
<th>

To add resilience the SCATS Management System has been changed from a physical
to virtual environment.

SCATS-CMS Virtualised Environment

</th> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The SCATS data that is collected is 100% accurate in relation to the data that
it receives from its sensors.

</td> </tr> </table>  
<table>  
<tr>  
<th>

Accessibility

</th>  
<th>

Information contained in SCATS Access version 6.9.2 documentation may be of a
commercially sensitive nature and must not be given to any individual or
organisation without prior written consent from Roads and Maritime Services.
The SM data from the Dublin system has been supplied to IBM for processing and
translating to an open format which can then be of use to the consortium.
Access to the SCATS data is via an AWS cloud based structure. For the VaveL
project the inclusion of other data sources from SCATS will be explored to
assess their validity for inclusion as a data stream to assist in automatic
incident detection. Using AWS brought the following advantages: Compute
services based on pay-as-you-use rates, 24x7 management of servers up to OS
layer included regular back-up schedule. All operating system licenses are
built into the price. High resilience as it is running over 2 Availability
Zones (AZ) and a storage area in AWS S3 (Storage Bucket), SCATS data stream
provided in JSON.

Cloud Services Architecture

</th> </tr>  
<tr>  
<td>

Assessable and

Intelligible

</td>  
<td>

Associated software produced and/or used in the project maybe assessable for
and Intelligible to third parties in contexts such as scientific scrutiny and
peer review (e.g. are the minimal datasets handled together with scientific
papers for the purpose of peer review, are data is provided in a way that
judgments can be made about their reliability and the competence of those who
created them)

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Dublin City Council Law Department has advised that they have no issue with
the release of the data. Data is stored in the SCATS application logs which
relates to system changes. No personal/confidential data is stored.

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

The SCATS system is under an annual maintenance contract based on the software
licences used by DCC. This is to ensure that the system as adequate support to
maintain the level of service required. SCATS data backup files for
configuration backups have two sub directories LX files containing daily
backup of SCATS data which are created daily and RAM data backups which are
also crested daily. SCATS Region collects data and stores in daily files. Each
file includes the date and time at which the data was collected and the data
itself. The collection of data occurs automatically. The data is retained for
the period specified when configuring SCATS Region. The default is 365 days. A
backup and archival system is in place to ensure that old data is still
accessible outside the SCATS Regions specified data retention period. Meta
data for the site is stored in the LX files

</td> </tr> </table>

Table 1: SCATS DATA - Management Plan

##  Public Transport Data

The street map is represented as a graph, where vertices represent important
locations in space for a given means of transport (e.g. road intersections for
cars). Each edge represents a means of traversing between the vertices, which
can involve actual movement (e.g. between two intersections) or waiting (e.g.
at a bus-stop). The graph is illustrated in Figure 4.

Figure 4: The vertex-based transit graph. Cited in verbatim from
https://github.com/ openplans/OpenTripPlanner/wiki/GraphStructure.

Figure 5: An illustration of a delay function, which gives the travel-time
along a segment of a road as a func-

0

0

_._

2

0

_._

4

0

_._

6

0

_._

8

1

0

_._

6

0

_._

8

1

Utilisation

Traveltime,scaled

Piecewise-linear

Piecewise-convex

tion of its utilisation, i.e. the ratio of the number of concurrent users to
the maximum thereof.

In principle, the GPS data are a sequence of vectors _y z,t  _ , where _z_ is
a traffic object, e.g. a bus with an on-board GPS receiver, and _t_ is an
integer, e.g. the POSIX time of the acquisition. The overall data model is
rather complex, but closely parallels those used by OpenStreetMap,
OpenTripPlanner, and the General Transit Feed Specification; we hence direct
the reader to the reference documentation for those.

Our custom extensions to the standard format consist of:

the travel-time estimates, which correspond to the weights of the edges in the
graph the altitude data, which correspond to weights of the vertices in the
graph

The travel-time estimates are stored as delay functions and vehicle count
data. A delay function gives the travel-time along a segment of a road as a
function of its utilisation, i.e. the ratio of the number of concurrent users
to the maximum thereof. See Figure ?? for an example. The delay functions are
computed from the vehicle-count data (SCATS) and traces of vehicle movement
(Bus GPS) described above.

The vehicle GPS traces are imported from three very different data sources,
even in the case of Dublin. Instead of plain coordinates, there is a more
complex data model based on the General Transit Feed Specification. There, a
vehicle Journey (or “route” in GTFS) is a particular instance of a
journeyPattern starting at a given time. A journey Pattern is a sequence of
two or more stops. In between each two stops, there are one or more blocks
within a trip (or “segments” in GTFS and elsewhere)  2  . Notice that the
production time table starts at 6am and ends at 3am in Dublin.

The first source of GPS traces captures the movement of buses in Dublin in the
period from 01/02/2012 till 30/04/2012 (except the days 10th till 12th
February 2012) and contains the following values:

_timestamp_ : timestamp microseconds since 01/01/1970 00:00:00 GMT, _lineId_ :
bus line identifier, _direction_ : a string identifying the direction,
_journeyPatternId_

_timeFrame_ : the start date of the production time table (in Dublin the
production time table starts at 6am and ends at 3am), _vehicleJourneyId_ : a
given run on the journey pattern, _operator_ : bus operator, not the driver,
_congestion_ : boolean value [0=no,1=yes], _gpsPos_ : GPS position of the
vehicle, _delay_ : seconds, negative if bus is ahead of schedule, _blockId_ :
section identifier of the journey pattern, _vehicleId_ : vehicle identifier,
_stopId_ : stop identifier, _atStop_ : boolean value [0=no,1=yes].

The second source of GPS traces captures the movement of buses in Dublin
during a part of November 2012 (06/11/2012 till 30/11/2012) and contains
tuples of the following elements:

_timestamp_ : timestamp microseconds since 01/01/1970 00:00:00 GMT, _lineId_ :
bus line identifier, _direction_ : a string identifying the direction,
_journeyPatternId timeFrame_ : the start date of the production time table (in
Dublin the production time table starts at 6am and ends at 3am),
_vehicleJourneyId_ : a given run on the journey pattern, _operator_ : bus
operator, not the driver, _congestion_ : boolean value [0=no,1=yes], _gpsPos_
: GPS position of the vehicle, _delay_ : seconds, negative if bus is ahead of
schedule, _blockId_ : section identifier of the journey pattern, _vehicleId_ :
vehicle identifier, _stopId_ : stop identifier, _atStop_ : boolean value
[0=no,1=yes].

The third source of GPS traces captures the movement of buses in Dublin during
January 2013 (01/01/2013 till 31/01/2013) and contains tuples of the following
elements:

_timestamp_ : timestamp microseconds since 01/01/1970 00:00:00 GMT, _lineId_ :
bus line identifier, _direction_ : a string identifying the direction,
_journeyPatternId timeFrame_ : the start date of the production time table (in
Dublin the production time table starts at 6am and ends at 3am),
_vehicleJourneyId_ : a given run on the journey pattern, _operator_ : bus
operator, not the driver, _congestion_ : boolean value [0=no,1=yes], _gpsPos_
: GPS position of the vehicle, _delay_ : seconds, negative if bus is ahead of
schedule, _blockId_ : section identifier of the journey pattern, _vehicleId_ :
vehicle identifier,

_stopId_ : stop identifier, _atStop_ : boolean value [0=no,1=yes].

Data Collection The standardised SIRI Vehicle Monitoring Service reports
current positions of vehicles that are located and monitored in an ITCS. The
data receiving client system may use this data for visualisation of the
vehicles in a map, in tables, lists or diagrams or for any other purpose  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

XY coordinates of the Dublin Bus stops. Distance and route patterns.

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

The system uses SIRI (Service Interface for Real-time Information) protocol.
The Service Interface for Real Time Information (SIRI) specifies a European
interface standard for exchanging information about the planned, current or
projected performance of real-time public transport operations between
different computer systems.

</td> </tr>  
<tr>  
<td>

Infrastructure

Improvements

</td>  
<td>

The standardised SIRI services work based on bidirectional communication. For
security reasons a virtual private network (VPN) is established.

The exchange of visualisation data starts with the subscription request of the
data receiving system (MORTPI). Once the request is done, trip information is
transmitted by the data producer (AVLC) to the data receiving system
throughout its entire validity period. The method and frequency of repetition
is a matter for the data producer, but can be specified by the displaying
system in the scope of the subscription.

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The Service Interface for Real Time Information (SIRI) specifies a European
interface standard for exchanging information about the planned, current or
projected performance of real-time public transport operations between
different computer systems.

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

Access to this information has been agreed as per the INSIGHT project and the
same platform and access rights will apply for the VaVeL project.

</td> </tr>  
<tr>  
<td>

Assessable and In-

telligible

</td>  
<td>

Associated software produced and/or used in the project maybe assessable for
and Intelligible to third parties in contexts such as scientific scrutiny and
peer review (e.g. are the minimal datasets handled together with scientific
papers for the purpose of peer review, are data is provided in a way that
judgments can be made about their reliability and the competence of those who
created them)

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Dublin City Council has advised that they have no issue with the use of the
bus data and the accumulation and storage of this data by a third party for
data distributed.

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

The Public Transport Data and the system which provide the data are covered
under a maintenance contract. Any changes/ additional requirements to the
system or to provide access to data will be carried out under the supervision
of the maintenance contractor and in accordance with the terms and conditions
of the contract to ensure that the integrity of the system and/or the data
provided by the system is not compromised.

_Archiving and Preservation:_ The Public Transport Data systems are an
integral part of the DCC traffic systems and it is our aim to ensure the
integrity of the system and access to the system by third parties as agreed
now and into the future is maintained. Any access agreements made for data
during the life time of this project will be done so under the current and
subsequent maintenance contracts. These will be reviewed as part of any new
maintenance contract and every effort will be made to facilitate the access to
data now and into the future. Any changes to the system to allow for expansion
or upgrade will be done so in a manner that all stake holders will be
consulted and informed of subsequent changes.

</td> </tr> </table>

Table 2: Public Transport Data - Management Plan

##  Closed-Circuit Television Data

Closed Circuit Television (CCTV) has been in use by Dublin City Council
Environment and

Transportation department for over 20 years with 280 camera installations at
present. The use of traffic cameras is an essential tool for traffic
management in the city in conjunction with an adaptive traffic control system,
SCATS. Currently the Traffic Control Centre operators use the CCTV cameras to
manually scan the traffic network to detect, verify and manage incidents.

Selections of cameras are displayed on the Audio Visual wall and there is
rotation of the entire CCTV camera list on one IP input. Each operator has
access to Indigo Vision on their desk top which can be customized to display
CCTV combinations as required. Traffic surveillance is an integral part of the
traffic management system and the closer the time of the detection of the
incident to the time of its occurrence the greater the impact the traffic
control centre operator can have in effectively managing it. It would also be
in the scope of the research to assess how this CCTV data could be combined
with other sensory data from SCATS, weather data, public transport data in
detecting incidents on the traffic network.

The Traffic CCTV system consists of 2 backend systems running side by side,
Meyertech Analogue CCTV & Indigo Vision IP CCTV. Every Camera in the system is
available in both

Analogue and IP format. This redundancy is to ensure that one system is always
available to the Control Centre. The analogue cameras are available in IP by
encoding the stream using Indigo Vision 10 and the same also applies for IP
streams which are decoded using Indigo

Vision hardware and software to make them available to the Meyertech system.
All analogue cameras are compressed to IP via an Indigovision 9000 encoder to
H264 format. The codec facilitates can operate at Cif / 2 Cif / 4 Cif at a
variable bandwidth. The current operation stream 1 is set to 2048kbs and the
“Mobile Centre” for remote access is set to 1024 kbs stream 2. Transmission of
images from site is normally by high quality fibre optic cable and using
uncompressed digital transmission equipment, ensuring no errors are introduced
to the image prior to reaching the station equipment in DCC. Where a site has
no fibre transmission available, the analogue camera is compressed on site by
an Indigo Vision 9000 codec and transmitted to a fibre point via an NGW
Express IP VPN Tunnel. The IP from site is transported to the CCTV stack via
fibre and the stream is then pointed to an Indigovision decoder which allows
the video to be viewed on the Meyertech system. Web images from a selection of
cameras are made available on the Dublin City Council web site using Fusion
Capture software. The Fusion capture application provides images to the web
site only if the camera is in the “home position”, which is when the camera is
zoomed out. These images are updated every 10 minutes which is dependent on
the number of cameras in the cycle when in the home position and are not
updated if the camera is in use by an operator.  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

Data on the XY coordinates for the CCTV camera locations has been supplied to
IBM and the consortium.

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

Standards operated by DCC are currently ONVIF compliant. An advisory note from
the CCTV contrac on ONVIF there are several different layers and it does not
always work seamlessly. ONVIF standards apply to IP only.

</td> </tr>  
<tr>  
<td>

Infrastructure

Improvements

</td>  
<td>

It should be noted that the Fusion Capture technology was designed 12 years
ago. The system design is struggling to meet the availability of compatible
computer components available today. The system currently runs on Windows XP
and has some driver issues with the capture card.

No updates or patches are available.

For fusion capture images it should be noted that several operators have the
capability to set a preset, this can be set anywhere, zoomed in or out. The
Fusion Capture has no capability to know what the camera is looking at or even
if the camera has responded to the request to “Goto” Preset 1.

As part of the VaVeL project work with the consortium to explore the
possibilities of using the CCTV cameras as a sensor with the aim of enhancing
the functionality to use the camera as a senor where by the cameras can be
trained to detect incidents and automatically alert the traffic control
operators that there is an incident on the traffic network. This could result
in a faster more efficient response to incidents which in turn could reduce
traffic congestion. To develop this research, video data that captures the
scene for different incident types will be used to train algorithms to provide
incident detection capability.

Discussions are currently underway with the CCTV maintenance contractor to
formalise how the requirements of this project will be included under the
current maintenance framework agreement and how these will be included and
documented to provide data for future use.

</td> </tr> </table>  
<table>  
<tr>  
<th>

Quality

</th>  
<th>

The Meyertech system provides analogue 1Vpp Video images. Indigo takes a 1Vpp
image and compresses it to IP compression Cif / 2 Cif / 4 Cif variable
bandwidth. The Fusion Capture compression is done by the card in the XP
machine compression would be low but details unknown.

</th> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

There is an API available as part of the SDK from Indigo vision and this is
only released under an NDA. The SDK contains commercially sensitive
information and will not be released or distributed for general use. This
issue is currently under discussion with DCC and the maintenance contractor
and currently investigating the option to provide an “isolated” sample of some
cameras to the 3rd party until the development is complete.

</td> </tr>  
<tr>  
<td>

Assessable and

Intelligible

</td>  
<td>

The data produced and/or used in the project is usable by third parties even
long time after the collection of the data. CCTV images which are currently
available on the DCC website and the accumulation and storage of these images
by a third party from the DCC website.

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Dublin City Council Law Department has advised that they have no issue with
the use of the CCTV images which are currently available on the DCC website
and the accumulation and storage of these images by a third party from the DCC
website. A select number of cameras are made available to the public on the
Dublin City Councils traffic home page. Other agencies with access to the
cameras include the other three local authorities in the Dublin Region,
Railway Procurement Agency, Dublin Port Tunnel, Dublin Bus and An Garda
Siochana.

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

CCTV is an integral part of the DCC traffic management infrastructure and it
is DCCs policy to maintain and enhance its CCTV system as it has done since
1989.

The CCTV system is covered under a maintenance contract which includes - CCTV
out-station equipment, maintenance of Indigo Vision equipment and Meyertech
equipment located at all remote operator user sites, maintenance of Wireless
and Radio Link communication equipment, maintenance of all In-station Traffic
Control Centre CCTV equipment including recording equipment, hard drives,
fans, filters, and monitors, maintenance / cleaning of CCTV equipment, poles,
connections, wiring, and housing sealing, supply, installation, testing, and
commissioning of CCTV cameras, encoders, CCTV monitors and work stations,
video recording facilities, CCTV masts and poles, mini pillars, cabinets,
including all traffic management and safety requirements associated with the
works, supply and installation of CCTV camera poles in Dublin City and
environs, supply and installation of all communications equipment associated
with CCTV, supply, installation, testing and commissioning of all equipment
and software supplied as part of the contract.

Any changes/ additional requirements to the system or to provide access to
data will be carried out under the supervision of the maintenance contractor
and in accordance with the terms and conditions of the contract to ensure that
the integrity of the system and/or the data provided by the system is not
compromised.

_Archiving and Preservation._ The CCTV system is an integral part of the
traffic management system and this is envisaged into the future and it is our
aim to ensure the integrity of the system and access to the system by third
parties as agreed now and into the future is maintained. Any access agreements
made for data during the life time of this project will be done so under the
current and subsequent maintenance contracts. These will be reviewed as part
of any new maintenance contract and every effort will be made to facilitate
the access to data now and into the future. Any changes to the system to allow
for expansion or upgrade will be done so in a manner that all stake holders
will be consulted and informed of subsequent changes.

</td> </tr> </table>

Table 3: Closed-Cicruit Television Data - Management Plan

##  Measurements of Weather and Pollution

Ireland’s National Roads Authority (NRA) maintains a network of sensor
stations around Dublin city, each of which samples a variety of environmental
factors at ten-minute intervals. As part of the initial data-collection
effort, we have created a tool which pulls information from thirteen of these
stations into a central database. At present, our focus is on creating a
historical archive for future exploitation rather than providing the data in
real-time, and as such the data is harvested only once per day; this can, of
course, be changed at a later date to account for the project’s evolving
requirements. The database also contains meta-information about the various
data points, allowing human-readable reports to be generated with ease.

The database can be queried using standard SQL. It is currently only
accessible from within IBM, but it can be easily migrated to another location
as necessary.

The full list of stations from which these sensor data are drawn is provided
in Table 4, while some of the more interesting points captured by the database
are highlighted in Table 5. A visualisation of some of this data is shown in
Figure 6.

Table 4: NRA stations

Dublin Port Tunnel M1 Drogheda Bypass

M1 Dublin Airport M11 Bray Bypass

M4 Enfield M50 Blanchardstown Master

M50 Blanchardstown Slave M50 Dublin Airport

M50 Sandyford Bypass Tipping Bucket M50 Sandyford Master

M7 Newbridge Bypass M7 Portlaoise Bypass

N81 Tallaght

Table 5: Illustrative NRA datapoints  
  
<table>  
<tr>  
<th>

Code

</th>  
<th>

Description

</th>  
<th>

Unit

</th> </tr>  
<tr>  
<td>

CL

</td>  
<td>

Cloud State

</td>  
<td>

Status Code: Clear, Cloud, Cloud and Rain

</td> </tr>  
<tr>  
<td>

PW

</td>  
<td>

Present Weather

</td>  
<td>

Status Code: 0 (unobstructed) to 99 (tornado)

</td> </tr>  
<tr>  
<td>

WL

</td>  
<td>

Water Layer

</td>  
<td>

mm

</td> </tr>  
<tr>  
<td>

SL

</td>  
<td>

Snow Layer

</td>  
<td>

mm

</td> </tr>  
<tr>  
<td>

IL

</td>  
<td>

Ice Layer

</td>  
<td>

mm

</td> </tr>  
<tr>  
<td>

RH

</td>  
<td>

Relative Humidity

</td>  
<td>

%

</td> </tr>  
<tr>  
<td>

PR

</td>  
<td>

Precipitation Total

</td>  
<td>

mm

</td> </tr>  
<tr>  
<td>

RI

</td>  
<td>

Rain Intensity

</td>  
<td>

mm/h

</td> </tr>  
<tr>  
<td>

P

</td>  
<td>

Pressure

</td>  
<td>

hpa

</td> </tr>  
<tr>  
<td>

T

</td>  
<td>

Air Temperature

</td>  
<td>

◦C

</td> </tr>  
<tr>  
<td>

TS

</td>  
<td>

Surface Temperature

</td>  
<td>

◦C

</td> </tr>  
<tr>  
<td>

VI

</td>  
<td>

Visibility

</td>  
<td>

m

</td> </tr>  
<tr>  
<td>

WD

</td>  
<td>

Wind Direction

</td>  
<td>

◦

</td> </tr>  
<tr>  
<td>

WS

</td>  
<td>

Wind Speed

</td>  
<td>

m/s

</td> </tr> </table>

Alternatively, there are weather data available through The Weather Company.
In January 2016, IBM has acquired The Weather Company’s B2B, mobile and cloud-
based web-properties, weather.com, Weather Underground, The Weather Company
brand and WSI, its global businessto-business brand. Such data can be
accessed, e.g., via wunderground  3  . These can be queried

Figure 6: NRA data visualisation. Arrows indicate wind speed and direction;
heatmap blobs indicate cumulative rain intensity at each station, in mm/h

for weather information at a particular coordinate, e.g. Dublin, posing the
following request (the <key> has to be generated in advance by registering to
the wunderground website):
http://api.wunderground.com/api/<key>/hourly10day/q/Ireland/Dublin.json

As result, a json object is returned which contains the following fields:

_FCTTIME_ : the time of the weather forecast _temp_ : the temperature
_condition_ : the weather condition, e.g. “Rain” _icon_ : an icon to depict on
a map, e.g. “rain” _icon url_ : link to an icon for graphical user interfaces
_humidity_ : humidity in percent _feelslike_ : the perceived temperature and
many undocumented fields.

##  Social Media

Further input to the system is provided by Twitter Inc, a social network
operating a short messaging service. Twitter issues a stream of messages
(“tweets”) up to 140 characters long, optionally including one or more
“hashtags” - that is, arbitrary words preceded with a hash character, used to
denote topics to which the message relates (e.g., #dublin). Tweets may also
include links to websites and other auxiliary data; see Figure 7 for some
examples.  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

The metadata are described above and at  https://www.wunderground.

com/weather/api/

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

The standards are described at  https://www.wunderground.com/ weather/api/  
</td> </tr>  
<tr>  
<td>

Infrastructure Improvements

</td>  
<td>

None to be disclosed at the moment

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The data quality is discussed at  https://www.wunderground.com/ weather/api/  
</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

IBM has an unrestricted access to both the complete history of data, current
data, and weather forecasts. This access has not been shared with the other
partners.

</td> </tr>  
<tr>  
<td>

Assessable and In-

telligible

</td>  
<td>

The intelligibility issues are discussed at  https://www.wunderground.

com/weather/api/

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

IBM will make the data available for commercial licensing aiming for a long-
term availability into the future.

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

a) Archiving and Preservation: IBM aims for long-term preservation of the data
into the future. b) Usable beyond the original purpose for which it was
collected: No.

</td> </tr> </table>

Table 6: Weather Data - Management Plan

_“N3: Heavy delays from the M50 to J3 due to a collision on the R121 at
Blanchardstown SC. Traffic is down to one lane in both directions.”_

_“M50: Emergency services are at the scene before J5 Finglas. Middle and right
lanes now blocked. Traffic almost back to the M1/M50 roundabout”_

Figure 7: Sample Tweets from Live Drive.

The Twitter web application and its public API allow developers to retrieve a
substream of messages based on a given set of criteria; specifics hashtags,
for instance, or tweets produced by a certain user, etc. The stream is a
sequence of _tweets_ , which primarily consist of:

_tweetId_ : a unique tweet identifier _date_ : integer, POSIX time of the
tweet publication _twitterUserId_ : twitter user identifier _coordinate_ :
geo-localization of tweet _messageText_ : tweet text.

The stream is indexed by hashtag and clustered according to a given set of
criteria (e.g. GPS co-ordinates). The Twitter substream generated within a
geographical area of interest can be isolated by following relevant users
(e.g., @livedrive) and monitoring certain hashtags (e.g.,

#dublin).

Note that the input stream is not limited to users who are already known to
the system; all tweets by Twitter users who are publicly tweeting in the area
of interest are collected.

In more detail, we can access the following fields in the Twitter stream:

_tweetId_ : a unique Tweet ID, assigned by Twitter _twitterUserId_ : a
twitter-ID of Tweeting user. Unique per Twitter account.

_twitterUserScreenName_ : mnemonic user name (login name) _latitude_ :
geographic latitude of sending device _longitude_ : geographic longitude of
sending device _messageText_ : the actual tweet in raw textual form. It may
include non-ASCII characters. _messageDate_ : timestamp of message sending.
Format ’YYYY-MM-DD hh:mm:ss’ _location_ : tweet location place name, for
Gazetteer lookups _countryCode_ : ISO short country code (two characters)
_retweetStatusId_ : referred (tweetId) to embedded retweet (original tweet). 0
if not a retweet, -1 if not set or invalid value.

_isRetweeted_ : boolean flag (’y’—’n’) if tweet contained a retweet
_replyStatusId_ : referrer (tweetId) if tweet is-in-reply-to. -1 if not an
answer-to tweet. _replyUserId_ : referrer (twitterUserId) to author of
original tweet being answered. -1 if not an answer-to tweet.

_isFavorite_ : Boolean flag (’y’—’n’) if tweet was marked as favorite
_followersCount_ : Number of Twitter users currently following tweet author
_followingCount_ : Number of Twitter users the tweet author currently follows

Batch data samples are retrieved from the Twitter API using a spatial query.
Further for Dublin, The Live Drive Radio data set results from Twitter
messages sent by people driving in Dublin that report traffic hazards to the
local radio.  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

The metadata are described above and at  https://dev.twitter.com/ rest/public

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

The standards are described above and at  https://dev.twitter.com/ rest/public

</td> </tr>  
<tr>  
<td>

Infrastructure Improvements

</td>  
<td>

None to be disclosed at the moment

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

None to be disclosed at the moment

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

In November 2014, IBM Corporation entered into a licensing agreement with
Twitter Inc., which allows for unlimited access to the data by IBM. Limited
subset of the data is publicly available at  https://dev.twitter.

com/rest/public

</td> </tr>  
<tr>  
<td>

Assessable and In-

telligible

</td>  
<td>

See  https://dev.twitter.com/rest/public

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

IBM cannot share this access with the consortium.

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

a) Archiving and Preservation: Data may be archived by Twitter Inc. b) Usable
beyond the original purpose for which it was collected: Within IBM
Corporation.

</td> </tr> </table>

Table 7: Social Media Data - Management Plan

#  City of Warsaw Data

##  Real time trams location

Warsaw operates 25 tram lines. Total trams line length exceeds 360 km. Number
of trams in use is as follows:

Morning peak: 414

Mid-day: 313

Afternoon peak: 421

Real time Trams location web service exposes information about geographical
location of trams. Data set contains information about all vehicles active at
the moment. The data is updated every 15 seconds. This dataset has been
released by the Warsaw Trams.  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

(data category from CKAN): real time, trams, online data. Meta data describing
this dataset are used only in documentation as keywords: e.g. real time,
trams, online data. CKAN platform used as middleware for CoW open data
exposition supports meta-data in form of RDF but this functionality is
currently not used by CoW IT department.

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

RESTlike Web Services, pooling data refreshing every 15 seconds. CoW trams
location is exposed using RESTlike Web Services, in form of GET HTTP method.
Information about trams location is refreshing every 15 seconds and must be
retrieved by developers using request - response model

(pooling). The geographical coordinates are float numbers compliant with EPSG
4326 (WGS 84). Example: 20.992 for long, 51.242 for the latitude.

</td> </tr>  
<tr>  
<td>

Infrastructure

Improvements

</td>  
<td>

Caching of data period on MUNDO backend was changed from 30 to 15 seconds for
VaVeL project

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The quality of data is currently analyzed by consortium members. Some issues
have already been resolved.

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

Publicly available open data after registration and terms and condition
acceptance.

</td> </tr>  
<tr>  
<td>

Assessable and

Intelligible

</td>  
<td>

Documentation available

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Open data registration on api.um.warszawa.pl needed. Terms of use are
available at https://api.um.warszawa.pl website.

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

a) Archiving and Preservation: This data set will be implemented as source of
information for realization of use cases defined by CoW and stored in data
processing system installed in CoW. Online data available by API. Historical
data collected in csv files is available at CoW Cloud b) Usable beyond the
original purpose for which it was collected not possible

</td> </tr> </table>

Table 8: Real Time Tram Locations - Management Plan

Real time Trams location web service exposes information about geographical
location of trams. Data set contains information about all active at the
moment vehicles. Warsaw operates 25 tram lines. Average number of vehicles
varies from 414 during morning peak, 313 in mid-day, to 421 in the afternoon.
The data is updated every 15 seconds. This dataset has been released by the
Warsaw Trams CoW agency.

Where HTTP response parameters are listed below:

Time - datetime timestamp

Lat - float - latitude (GPS)

Lon - float longitude (GPS)

FirstLine - string - number of the first line realized by vehicle

Lines - string - the numbers of all lines (for multiline brigades will be more
than one line)

Brigade - string - the number of brigade

Status - string task status can assume values “RUNNING” or “FINISHED”.
LowFloor - bool - indicates if the tram is a low floor one 1 Yes, 0 No.

Trams Location historical Data Archival data available to the consortium. Data
from 21 march 2016 are collected in csv files and available at CoW Cloud.

Time - datetime timestamp

Lat - float - latitude (GPS)

Lon - float longitude (GPS)

FirstLine - string - number of the first line realized by vehicle

Lines - string - the numbers of all lines (for multiline brigades will be more
than one line)

Brigade - string - the number of brigade

FirstLine Brigade - concatenate 2 fields (tram ID for a day)

Status - string task status can assume values “RUNNING” or “FINISHED” LowFloor
- bool - indicates if the tram is a low floor one 1 Yes, 0 No.

##  Bus Data

285 bus lines

Total line length 4379,9 km

Number of buses in use: 1729 (1366 operated by MZA)

Morning peak: 1644

Mid-day: 1035

Afternoon peak: 1619

Historical Data Archive data from 21 April 2016 are available in CoW cloud.
Data format:

Side Number(vehicle Number), unix timestamp, latitude GPS, longitude GPS,
Line, Brigade Example: 1525,1461362407,21.170208,52.160407,146,4

##  19115 Non-emergency notification system

API enables reporting of various issues to the City by locals and visitors.
Issues such as failures, defects and non-critical threats concerning eg. the
state of roads, snow removal, damage, acts of vandalism, etc. API also allows
users to obtain information filtered by the keys. Information available:  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

CKAN: bus

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

Websocket interface exposed by MZA (Warsaw’s Buses Authority) accessible only
in internal CoW network

</td> </tr>  
<tr>  
<td>

Infrastructure

Improvements

</td>  
<td>

None

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The quality of data is currently analyzed by consortium members. Some issues
have already been resolved.

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

Public data with restricted access. Available only for VaVeL consortium
members

</td> </tr>  
<tr>  
<td>

Assessable and In-

telligible

</td>  
<td>

Documentation available

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Public data with restricted access Available only for VaVeL consortium members

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

a) Archiving and Preservation: This data set will be implemented as source of
information for realization of use cases defined by CoW and stored in data
processing system installed in CoW. b) Usable beyond the original purpose for
which it was collected not possible.

</td> </tr> </table>

Table 9: Bus Data - Management Plan  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

CKAN keywords: bus, historical data

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

Flat csv files with bus locations

</td> </tr>  
<tr>  
<td>

Infrastructure

Improvements

</td>  
<td>

Dedicated data collector was developed

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The quality of data is currently analyzed by consortium members. Some issues
resolved.

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

Public data with restricted access Available only for VaVeL consortium members

</td> </tr>  
<tr>  
<td>

Assessable and In-

telligible

</td>  
<td>

Documentation available

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Public data with restricted access. Available only for VaVeL consortium
members.

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

a) Archiving and Preservation: Archiving and Preservation: This data set will
be implemented as source of information for realization of use cases defined
by CoW and stored in data processing system installed in CoW. b) Usable beyond
the original purpose for which it was collected not possible.

</td> </tr> </table>

Table 10: Bus Historical Data - Management Plan siebelEventId: Event ID in the
city CRM system deviceType: type of device used to submit notification street:
notification street name - this field is only used in notifications registered
by CRM operators.It is validated with the city’s street names dictionary.

street2: notification street name field only used in notifications submitted
by citizens (ie. notifications generated outside of CRM). Not validated.

district: district of the notification city: city of the notification
houseNumber: building number of the notification aparmentNumber: apartament
number of the notification category: notifcication category subcategory:
notification subcategory(dictionary value, as when reporting) event: the
process of intervention (dictionary value, as when reporting) description:
notification description createDate: creation date notificationNumber:
notification number xCoordWGS84: Latitude notification in WGS84 standard
yCoordWGS84: Longitude notification in WGS84 standard xCoordOracle: Latitude
notification in Oracle Spartial standard yCoordOracle: Longitude notification
in Oracle Spartail standard

notificationType: (INCIDENT(”Awaria/ Interwencja”),
INFORMATIONAL(”Informacyjne”), COMPLAINT(”Reklamacja”), STATUS(”Status
sprawy/zgoszenia”) PUBLIC INFORMATION(”Wniosek o dostp do informacji
publicznej”), FREEFORM(”Wolne wnioski i uwagi”) statuses - List of
notification statuses (changeDate change date, status status, description
description,

Source notification source (API(”API”), CALL(”CALL”), CKM(”CKM”),
MAIL(”MAIL”), MOBILE(”MOBILE”), PHONE(”Phone”), PORTAL(”PORTAL”),

SMS(”SMS”), WEB(”Web”), WEBCHAT(”WEBCHAT”), EMPTY(”brak”)

##  Public transport timetables

Public transport timetables data set is managed by Warsaw’ Public Transport
Authority and stored in MySQL database. This information is exposed for
developers as an Open API by api.um.warszawa.pl portal in RESTlike Web
Services form. Exposed API allows to obtain information about timetables and
information about bus or trams lines for the selected stops.

API provides three methods. First of them (getBusstopId) is mandatory for the
use of the other and is used to obtain the ID stop identifier. The other two
(getTimetable and getLines) are used to obtain data about lines and timetables
related with the stop.

Historical data Public transport historical timetables data set is managed by
Warsaw’ Public

Transport Authority and stored in MySQL database. This information is exposed
for developers as an Open API by api.um.warszawa.pl portal in RESTlike Web
Services form. Exposed API  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

(data category from CKAN): not emergency issue, real time, online data

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

RESTlike Web Services, data from Siebel CRM database

</td> </tr>  
<tr>  
<td>

Infrastructure

Improvements

</td>  
<td>

Data exposed during MUNDO project, no additional improvements needed

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The quality of data is currently analyzed by consortium members

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

Publicly available open data after registration and terms and condition
acceptance

</td> </tr>  
<tr>  
<td>

Assessable and Intelligible

</td>  
<td>

Documentation available.

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Open data registration on api.um.warszawa.pl needed. Terms of use areavaliable
at https://api.um.warszawa.pl website.

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

a) Archiving and Preservation: This data set will be utilized as source of
information for realization of use cases defined by CoW and stored in data
processing system installed in CoW. Via an API there are available historical
data for approx. 2 month period. b) usable beyond the original purpose for
which it was collected not possible

</td> </tr> </table>

Table 11: 19115 Data - Management Plan  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

(data categories from CKAN): transport, timetables

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

RESTlike Web Services, data from ZTM MySQL SQL database exposed by

MUNDO platform

</td> </tr>  
<tr>  
<td>

Infrastructure

Improvements

</td>  
<td>

Data exposed during MUNDO project, no additional improvements needed

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The quality of data is currently analyzed by consortium members.

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

Publicly available open data after registration and terms and condition
acceptance.

</td> </tr>  
<tr>  
<td>

Assessable and Intelligible

</td>  
<td>

Documentation available.

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Open data registration on api.um.warszawa.pl needed. Terms of use are
available at  http://www.ztm.waw.pl/?c=628&l=1  website.

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

a) Archiving and Preservation: The actual timetable is available via the API.
This data set will be utilized as source of information for realization of use
cases defined by CoW and stored in data processing system installed in CoW. b)
usable beyond the original purpose for which it was collected not possible.

</td> </tr> </table>

Table 12: Public transport timetables - Management Plan  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

(data categories from CKAN): transport, timetables historical data

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

RESTlike Web Services, data from ZTM MySQL database exposed by MUNDO platform.

</td> </tr>  
<tr>  
<td>

Infrastructure Improvements

</td>  
<td>

New data set implemented for VaVeL project. Redevelopment CKAN extensions was
made and implemented on MUNDO Data server

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The quality of data is currently analyzed by consortium members

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

Public data with restricted access. Available only for VaVeL consortium
members after registration and terms and condition acceptance. Documentation
Avaliable.

</td> </tr>  
<tr>  
<td>

Assessable and Intelligible

</td>  
<td>

Documentation avaliable.

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Restricted access only for VaVeL consortium member

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

a) Archiving and Preservation: This data set will be implemented as source of
information for realization of use cases defined by CoW and stored in data
processing system installed in CoW. Via the API the timetable is available for
the past 4 months b) usable beyond the original purpose for which it was
collected not possible.

</td> </tr> </table>

Table 13: Public transport historical timetables - Management Plan

allows to obtain information about timetables and information about bus or
trams lines for the selected stops in selected time in the past.

##  Bus & trams stops locations

Bus & trams stops locations API offers developers the information about
current geographical location of bus and trams stops in Warsaw. This dataset
has been released by the Public Transport Authority (ZTM).

##  Park& Ride

Park & Ride Parking information data set contains information about P&R
parking stations in City of Warsaw for selected geographical areas.

##  Bike roads

Park & Ride Parking information data set contains information about bike roads
in City of Warsaw.

##  Bike stations location (Veturilo)

Bike stations location (Veturilo) data set contains information about rent-a-
bike Veturilo stations in City of Warsaw for selected geographical areas.  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

(data categories from CKAN): bus, tram, stops, geolocation

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

RESTlike Web Services

</td> </tr>  
<tr>  
<td>

Infrastructure

Improvements

</td>  
<td>

New data set implemented for VaVeL project. Redevelopment CKAN extensions was
made and implemented on MUNDO Data server

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The quality of data is currently analyzed by consortium members

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

Public data with restricted access. New data set implemented for VaVeL
project. Redevelopment CKAN extensions was made and implemented on

MUNDO Data server

</td> </tr>  
<tr>  
<td>

Assessable and In-

telligible

</td>  
<td>

Documentation avaliable

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Available only for VaVeL consortium members after registration and terms and
condition acceptance. Additional terms of use are available at  http:

//www.ztm.waw.pl/?c=628&l=1  website.

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

a) Archiving and Preservation: This data set will be implemented as source of
information for realization of use cases defined by CoW and stored in data
processing system installed in CoW. Via API accessible are the descriptions of
actual bus & trams stops parameters, b) usable beyond the original purpose for
which it was collected not possible.

</td> </tr> </table>

Table 14: Bus and Trams Stop Locations - Management Plan  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

(data categories from CKAN): park & ride, static data, geolocation

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

REST like Web Services, WFS

</td> </tr>  
<tr>  
<td>

Infrastructure

Improvements

</td>  
<td>

None

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The quality of the data will be analyzed by consortium members.

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

Public data with restricted access.

</td> </tr>  
<tr>  
<td>

Assessable and

Intelligible

</td>  
<td>

Documentation available.

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Public data with restricted access. Terms of use
http://mapa.um.warszawa.pl/warunki.html

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

a) Archiving and Preservation: This data set will be implemented as source of
information for realization of use cases defined by CoW and stored in data
processing system installed in CoW. b) usable beyond the original purpose for
which it was collected not possible.

</td> </tr> </table>

Table 15: Park & Ride - Management Plan  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

(data categories from CKAN): bike roads, static data, vector map, WFS

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

RESTlike Web Services, WFS

</td> </tr>  
<tr>  
<td>

Infrastructure

Improvements

</td>  
<td>

None

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The quality of the data will be analyzed by consortium members

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

Public data with restricted access.

</td> </tr>  
<tr>  
<td>

Assessable and Intelligible

</td>  
<td>

Documentation available.

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Public data with restricted access. Terms of use
http://mapa.um.warszawa.pl/warunki.html

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

a) Archiving and Preservation: This data set will be implemented as source of
information for realization of use cases defined by CoW and stored in data
processing system installed in CoW. b) usable beyond the original purpose for
which it was collected not possible.

</td> </tr> </table>

Table 16: Bike Roads - Management Plan  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

(data categories from CKAN): city bike, static data, Veturilo

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

RESTlike Web Services, WFS

</td> </tr>  
<tr>  
<td>

Infrastructure

Improvements

</td>  
<td>

None

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The quality of the data must be analyzed by consortium members

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

Public data with restricted access.

</td> </tr>  
<tr>  
<td>

Assessable and

Intelligible

</td>  
<td>

Documentation avaliable, WFS standard documentation is publicly available
http://www.opengeospatial.org/standards/wfs  
</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Public data with restricted access

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

a) Archiving and Preservation: This data set will be implemented as source of
information for realization of use cases defined by CoW and stored in data
processing system installed in CoW. b) usable beyond the original purpose for
which it was collected not possible.

</td> </tr> </table>

Table 17: City bike stations - Management Plan  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

(data categories from CKAN):metro entrances, static data

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

RESTlike Web Services, WFS

</td> </tr>  
<tr>  
<td>

Infrastructure

Improvements

</td>  
<td>

None

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The quality of the data will be analyzed by the consortium members.

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

Public data with restricted access.

</td> </tr>  
<tr>  
<td>

Assessable and

Intelligible

</td>  
<td>

Documentation avaliable. WFS standard documentation is publicly available
http://www.opengeospatial.org/standards/wfs  
</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Public data with restricted access. Terms of use
http://mapa.um.warszawa.pl/warunki.html

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

a) Archiving and Preservation: This data set will be implemented as source of
information for realization of use cases defined by CoW and stored in data
processing system installed in CoW. b) usable beyond the original purpose for
which it was collected not possible.

</td> </tr> </table>

Table 18: Metro entrances - Management Plan

##  Metro Entrances

Metro Entrances data set exposes information about metro entrances in Warsaw.
API allows to retrieve information for selected geographical area and filter
data based on defined keys.

Access to data is based on Web Feature Service (WFS) standard defined by Open
Geospatial Consortium dedicated for exposition geospatial information in
vector maps form.  http:

//www.opengeospatial.org/standards/wfs.

##  Address points

Address points data set offers information on addresses in City of Warsaw for
a selected geographical area. API allows to retrieve information for the
selected geographical area and filter data based on defined keys. Access to
data is based on Web Feature Service (WFS) standard defined by Open Geospatial
Consortium dedicated for the exposition geospatial information in vector maps
form. Dataset Address points is maintained by Office of Surveying and Cadastre
(BGiK) City of Warsaw and exposed using a URL (endpoint).

##  Streets

This data set exposes information about location of streets in the City of
Warsaw. An API allows to retrieve information for a selected geographical area
and filter data based on defined keys. Access to data is based on Web Feature
Service (WFS) standard defined by Open Geospatial Consortium dedicated for
exposition geospatial information in vector maps form. The dataset Streets is
maintained by Office of Surveying and Cadastre (BGiK) City of Warsaw end
exposed using a URL.  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

(data categories from CKAN):address points, static data, geolocation

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

RESTlike Web Services, WFS

</td> </tr>  
<tr>  
<td>

Infrastructure

Improvements

</td>  
<td>

None

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The quality of the data will be analyzed by consortium members.

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

Public data with restricted access.

</td> </tr>  
<tr>  
<td>

Assessable and Intelligible

</td>  
<td>

Documentation available. WFS standard documentation is publicly available.

http://www.opengeospatial.org/standards/wfs

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Public data with restricted access

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

a) Archiving and Preservation: This data set will be utilized as source of
information for realization of use cases defined by CoW and stored in data
processing system installed in CoW. b) usable beyond the original purpose for
which it was collected not possible.

</td> </tr> </table>

Table 19: Address points - Management Plan  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

(data categories from CKAN):streets, static data, geolocation

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

RESTlike Web Services, WFS

</td> </tr>  
<tr>  
<td>

Infrastructure Improvements

</td>  
<td>

None

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The quality of the data will be assessed by the consortium members

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

Public data with restricted access.

</td> </tr>  
<tr>  
<td>

Assessable and

Intelligible

</td>  
<td>

WFS standard documentation is publicly available  http://www.

opengeospatial.org/standards/wfs

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Public data with restricted access

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

a) Archiving and Preservation: This data set will be utilized as source of
information for realization of use cases defined by CoW and stored in a data
processing system installed in CoW. b) usable beyond the original purpose for
which it was collected not possible.

</td> </tr> </table>

Table 20: Streets - Management Plan

Figure 8: ZTM-Warsaw’s Twitter Account

##  City of Warsaw Twitter

ZTM Public Transport Authority publishes information about public transport on
Twitter  https://twitter.com/ztm_warszawa.  Primarily it is information about
the failures of public transport, the resolution of the failure and sudden
timetable changes resulting from unplanned events (demonstrations, accidents,
etc.).

Standards Data from Twitter is available using Twitter Open API. Details can
be found on page:  https://dev.twitter.com/overview/documentation.  Twitter
offers two Open API sets for developers:

REST API mostly dedicated for off-line access -  https://dev.twitter.com/rest/
public

Stream API dedicated for real time data access -  https://dev.twitter.com/
streaming/overview

Access to Twitter API requires a developer account (OAuth protocol credential
needed) and application in Twitter developers portal (
https://dev.twitter.com/apps)  .

##  RSS services

Public Transport Authority runs RSS (Rich Site Summary) service information
about public transport. RSS contains 5 main categories:

News

Press releases

Changes in public transport

Public procurement

Difficulties  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

(data categories from CKAN):hashtags

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

RESTlike Web Services, WFS

</td> </tr>  
<tr>  
<td>

Infrastructure

Improvements

</td>  
<td>

External data provider - N/A

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The quality of the data will be assessed by VaVeL’s consortium members.

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

Private data with open access. Data publicly available after registration

</td> </tr>  
<tr>  
<td>

Assessable and

Intelligible

</td>  
<td>

Public available open data delivered by Warsaw Public Transport Authority

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Twitter Term and Conditions acceptance needed:  https://dev.twitter.

com/overview/terms/agreement-and-policy

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

a) Archiving and Preservation: This data set will be implemented as source of
information for realization of use cases defined by CoW and stored in data
processing system installed in CoW.

</td> </tr> </table>

Table 21: Twitter Data - Management Plan  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

RSS (XML) meta-data

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

RSS, multiple feeds: News:  http://www.ztm.waw.pl/rss.php?l=

1&IDRss=1  Press releases:  http://www.ztm.waw.pl/rss.php?l=1& IDRss=2
Changes in public transport:  http://www.ztm.waw.pl/rss. php?l=1&IDRss=3
Public procurement:  http://www.ztm.waw.pl/rss. php?l=1&IDRss=4  Changes in
public transport:  http://www.ztm.waw.

pl/rss.php?l=1&IDRss=6

</td> </tr>  
<tr>  
<td>

Infrastructure

Improvements

</td>  
<td>

Data is delivered by Warsaw Public Transport Authority. Changes are not
possible.

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The quality of the data will be assessed by VaVeL’s consortium members.

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

Open Data exposed in Internet for everyone Publicly available open data
delivered by Warsaw Public Transport Authority.

</td> </tr>  
<tr>  
<td>

Assessable and In-

telligible

</td>  
<td>

RSS is well known information exposition standard, polish language is used in
RSS information.

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Open Data

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

a) Archiving and Preservation: This data set will be implemented as source of
information for realization of use cases defined by CoW and stored in a data
processing system installed in CoW.

</td> </tr> </table>

Table 22: RSS services - Management Plan  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

None.

</th> </tr>  
<tr>  
<td>

Standards

</td>  
<td>

XML data exposed using dedicated URL.

</td> </tr>  
<tr>  
<td>

Infrastructure

Improvements

</td>  
<td>

Data is delivered by Warsaw Public Bikes operator (external system). Changes
are not possible.

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

The quality of the data will be assessed by the VaVeL consortium.

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

Data exposed in Internet for everyone. Publicly available data delivered by
Warsaw Public Bikes operator.

</td> </tr>  
<tr>  
<td>

Assessable and

Intelligible

</td>  
<td>

XML file structure is clear. However there is no API documentation.

</td> </tr>  
<tr>  
<td>

Legal Issues and

Privacy

</td>  
<td>

Public data. Unfortunately API usage terms and conditions are currently not
accessible on the Nextbike web page.

</td> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

a) Archiving and Preservation: This data set will be utilized as a source of
information for realization of use cases defined by CoW and stored in data
processing system installed in CoW. b) usable beyond the original purpose for
which it was collected: depends on confirmation from Warsaw Public Bikes
operator Nextbike.

</td> </tr> </table>

Table 23: Veturilo stations - Management Plan

##  Veturilo stations (Warsaw City Bike system)

Warsaw’s City Bike system (Veturilo) exposes an API that contains information
about bikes accessibility in Veturilo stations. Warsaw Public Bikes near real
time information is provided by the portal  http://nextbike.net  (data
refreshing every 1 minute).

##  Orange subscribers location statistics

Dataset of mobile subscriber’s location statistics contains statistical
information on the amount of terminals communicated with given cells of the
Public Land Mobile Network (PLMN).

Subscriber activity is detected on the basis of network events (13 different
events are taken into account) that are triggered together with voice and xMS
communication. Inactive terminals are periodicaly updated accordingly to
network & terminal settings (usually 1-2 hrs). For the VaVeL project samples
will be delivered of data from urban area for selected cells located in
Warsaw, for a defined period of time. The raw stream of data from mobile cells
in Warsaw is between 300 and 400 events per second. Volume of raw data is
between 18 and 20 M events for time period 24 hours for Warsaw area (data from
about 6000 cells). Statistic information are collected in csv files. Average
file size with aggregate of events from 24 hours for Warsaw area is about 8-9
MB.  
  
<table>  
<tr>  
<th>

Metadata

</th>  
<th>

None

</th> </tr> </table>  
<table>  
<tr>  
<th>

Standards

</th>  
<th>

Mobile data statistics are calculated and collected by dedicated network
system based on the events from MSS (Mobile Switching Centre Server).
Statistics are provided in form of flat csv files. File names have the
following form: statistics hours YYYY-MM-DD.csv File is generated daily at
1:00 am and contains data from previous day. For example, a file named stats
hours 2016-05-04.csv is created on May 5 at 1:00 AM and includes statistics
from 4th May. Data structure in files contains the following columns: date &
hour,x,y,numer of events, where csv file columns are listed bellow:

number of events - numeric (1,10) - Unique amount of MSISDN detected in given
period x - float - latitude (GPS) center of cell y - float longitude (GPS)
center of cell radius - Int cell radius date & hour date and hour - (e.g. -
2016-05-05 01:00:00 means

2016-05-05 between 0:00 am and 1:00 am)

</th> </tr>  
<tr>  
<td>

Infrastructure

Improvements

</td>  
<td>

To expose the data described in this chapter a re-development of
eventscollecting system was performed. The changes include:

automation of statistics recording data compression

automation of historical data cleaning

The system is used for data collection is the pre-production instance and
contains numerous restrictions e.g. limited storage and limited performance.

</td> </tr>  
<tr>  
<td>

Quality

</td>  
<td>

Because of the aforementioned limitations there is a possibility that not all
events from all cells will be reported. The test instance due to a single node
architecture cannot provide high values of SLA (redundancy mechanism not
implemented). Since the events generation mechanism related to TDM events, not
all subscribers activities are reported (e.g. statistics might not contain
information about mobile data usage).

</td> </tr>  
<tr>  
<td>

Accessibility

</td>  
<td>

For data analysis this data set will be send via e-mail as an encrypted
attachment to consortium leader Password will be send separated communication
channel (e.g. SMS). Because of polish telecommunication law restriction and
internal Orange Polska regulation this data set can be used only by consortium
members for the project VaVeL. Open Access and any sharing this dataset with
3rd parties is prohibited.

</td> </tr> </table>  
<table>  
<tr>  
<th>

Assessable and

Intelligible

</th>  
<th>

Raw data sharing with other parties (not consortium members) is currently not
possible because of telecommunication law (Operators cannot process any
telecommunication data without the special and clear consent from end user of
terminal) and internal Orange regulations (privacy policy do not allow for
sharing any data which can deliver business information about network).

Statistics used for VaVeL project are prepared based on a validated mechanism.
Based on all available network events on MSS we calculate the amount of unique
MSISDNS appeared in defined cell in defined quantum of time (most often one
hour). Mechanism is simple without any other conditions so the data are not
performed and calibrated. But based on law regulation - this data aggregation
procedure is not reversible. Also if data is exposed close to real time there
are additional restrictions in which statistics lower than 10 for cell cannot
be displayed. But in case of VaVeL project this is not implemented because we
transfer historical location statistics. This data set is well documented in a
data manual provided to the consortium.

</th> </tr> </table>  
<table>  
<tr>  
<th>

Legal Issues and

Privacy

</th>  
<th>

Based on current regulations in Polish Telco Law and EU directives concerning
the topic of telco transmission data processing we include below some points
that require attention. Based on the above documents we outline some basic
rules related to operators using data:

  1. In particular, concerning personal data, always should be considered the highest protection required by the law principles (Telecommunication Law (TL), Law on the protection of personal data (LPPD), EU directives and in particular to 2002/58/EC directive on e-Privacy and 95/46/EC directive on personal data protection) 

  

  2. For processing of personal data, the consent of the data subject is required. 

  

  3. Anonymised data can be used without consent of the subject only if they are aggregated from the first step of processing and can not be associated to an individual. 

  

  4. Everything what can be legally conducted by OLP can be also performed by subcontractors (based on appropriate contracts). Using personal data by other companies should be specified in the provided consent provided by the subject for data usage. 

  

  

Law protecting the privacy of operators data do not make any extraordinary
exceptions concerning R&D area. So for VaVeL project rules are the same as in
case of creating any other operators data usage for other than delivery of
telco services ordered by end user or terminal owner. Based on that we
investigate and deploy some techniques allowing the calculation of statistics
allowed by Law in the closest network area MSS.

That’s why we will be able to share with other participants only those
aggregated statistics which are safe from a legal point of view. This
mechanism of statistics calculation was investigated with some proof of
concept projects and we evaluated their reliability for being used as a source
of location statistics. We prepare some extrapolation and compare operators
data with calculations made based on optic sigh (based on camera). On the
other hand we also believe that, even aggregated statistics, data taken from
all users have better quality and value, than data taken from those who only
give consent. Users that provide consent for using location data are actually
a sub-sample but the mechanism can not be treated as “random selection” and we
are not able to predict the bias of this factor in these data (especially in
case of small areas of observation).

</th> </tr>  
<tr>  
<td>

Maintenance Plan

</td>  
<td>

  1. Archiving and Preservation: Finally Orange Mobile Subscriber’s Locationstatistics will be implemented as source of information for realization of use cases defined by CoW and stored in data processing system installed in CoW. 

  

  2. usable beyond the original purpose for which it was collected not possible 

  

  

</td> </tr> </table>

Table 24: Orange subscribers location statistics - Management Plan