D3.5 TRENTO, BILBAO, FINNISH REGION AND NOVI SAD ... · D3.5 – Trento, Bilbao, Finnish Region and Novi Sad Environment v1 page 7 2. INTRODUCTION The 2010 edition of the EU eGovernment

A neW concept of pubLic administration based on

citizen co-created mobile urban services Grant Agreement: 645845

D3.5 – TRENTO, BILBAO, FINNISH REGION AND

NOVI SAD ENVIRONMENT V1

DOC. REFERENCE: WeLive-WP3-D35-REP-211206-v10

RESPONSIBLE: FBK

AUTHOR(S): ENG, TECNALIA, UDEUSTO, FBK, CNS, INF, DNET, TRENTO, LAUREA, EUROHELP

DATE OF ISSUE: 21/12/16

STATUS: FINAL

DISSEMINATION LEVEL: PUBLIC

VERSION DATE DESCRIPTION

v0.1 11/08/2016 Definition of the Table of Contents and distribution of tasks

v0.2 08/11/2016 Contributions from all partners

v0.3 29/11/2016 Final version ready to be externally reviewed by BILBAO and TRENTO

v1.0 21/12/2016 Reviewers´ comments processed and accepted version submission.

Ref. Ares(2016)7134000 - 22/12/2016

D3.5 – Trento, Bilbao, Finnish Region and Novi Sad Environment v1 page 2

INDEX

1. EXECUTIVE SUMMARY............................................................................................................................................. 6

2. INTRODUCTION ....................................................................................................................................................... 7

3. COMMON ENVIRONMENT FOR ALL WELIVE PILOTS ................................................................................................ 9

4. TRENTO ENVIRONMENT ........................................................................................................................................ 10

4.1. PROCESS FOLLOWED IN TRENTO FOR PLATFORM POPULATION ......................................................................... 10

4.1.1. Phase 1 - Stakeholders Consultation Process .............................................................................................. 10 4.1.1.1. Surveys ..................................................................................................................................................................... 11 4.1.1.2. Workshops ............................................................................................................................................................... 11 4.1.1.3. Design Games ........................................................................................................................................................... 11

4.1.2. Phase 2 - Expectations and insights extraction ........................................................................................... 12

4.2. INTEGRATION WITH LOCAL INFRASTRUCTURE .................................................................................................... 12

4.3. SERVICES, BUILDING BLOCKS, DATASETS ............................................................................................................. 14

4.3.1. Services ....................................................................................................................................................... 14 4.3.1.1. Trento Street Cleaning ............................................................................................................................................. 14 4.3.1.2. Trento Bike Sharing .................................................................................................................................................. 15 4.3.1.3. Trento Transport Timetables.................................................................................................................................... 16

4.3.2. Building blocks ............................................................................................................................................ 17

4.3.3. Datasets ...................................................................................................................................................... 18

5. BILBAO ENVIRONMENT ......................................................................................................................................... 20

5.1. PROCESS FOLLOWED IN BILBAO FOR PLATFORM POPULATION .......................................................................... 20

5.2. INTEGRATION WITH LOCAL INFRASTRUCTURES .................................................................................................. 21

5.3. SERVICES, BUILDING BLOCKS AND DATASETS ...................................................................................................... 22

5.3.1. Services ....................................................................................................................................................... 22 5.3.1.1. Bilbozkatu ................................................................................................................................................................. 22 5.3.1.2. Auzonet .................................................................................................................................................................... 24 5.3.1.3. BilbOn ....................................................................................................................................................................... 25

5.3.2. Building blocks ............................................................................................................................................ 26 5.3.2.1. BB Citizens voting (Bilbozkatu) ................................................................................................................................. 26 5.3.2.2. BB Users feedback .................................................................................................................................................... 26 5.3.2.3. BB Users Ranking ...................................................................................................................................................... 27 5.3.2.4. Nearest Point Finder ................................................................................................................................................ 27 5.3.2.5. Image uploader ........................................................................................................................................................ 27 5.3.2.6. In-app questionnaires .............................................................................................................................................. 27

5.3.3. Datasets ...................................................................................................................................................... 28

6. HELSINKI-UUSIMAA ENVIRONMENT ...................................................................................................................... 29

6.1. PROCESS FOLLOWED IN FINLAND FOR PLATFORM POPULATION ........................................................................ 29

6.2. DESIGN PRINCIPLES ............................................................................................................................................. 30

6.3. SERVICES .............................................................................................................................................................. 32

6.3.1. My Polls ....................................................................................................................................................... 32

6.3.2. My Opinion ................................................................................................................................................. 35

6.3.3. My Neighbourhood ..................................................................................................................................... 37

6.4. BUILDING BLOCKS ................................................................................................................................................ 41

6.4.1. GeoPoll Answers ......................................................................................................................................... 41

6.4.2. GeoPoll Statistics ........................................................................................................................................ 41

6.4.3. GeoPoll Locations ........................................................................................................................................ 42

6.4.4. GeoPoll Polls ............................................................................................................................................... 42

6.4.5. GeoPoll Perspectives ................................................................................................................................... 43


6.4.6. Geo Locations.............................................................................................................................................. 43

6.4.7. GeoPoll Tags ............................................................................................................................................... 43

6.4.8. GeoPoll Attributes ....................................................................................................................................... 44

6.4.9. GeoPoll Users .............................................................................................................................................. 44

6.4.10. GeoPoll My .................................................................................................................................................. 45

6.4.11. GeoHeatmap ............................................................................................................................................... 46

6.4.12. GeoDB Match Matrix .................................................................................................................................. 46

6.4.13. Geocoder ..................................................................................................................................................... 46

6.4.14. Personal Data ............................................................................................................................................. 47

6.4.15. GeoDB Match Heatmap .............................................................................................................................. 47

6.4.16. GeoPoll Heatmaps ...................................................................................................................................... 47

6.4.17. GeoPoll Density Heatmap ........................................................................................................................... 47

6.4.18. Geo Areas .................................................................................................................................................... 47

6.4.19. Area datasets .............................................................................................................................................. 48

6.4.20. Citizen Data Vault API ................................................................................................................................. 48

6.5. DATASETS ............................................................................................................................................................ 48

7. NOVI SAD ENVIRONMENT ..................................................................................................................................... 51

7.1. PROCESS FOLLOWED IN NOVI SAD FOR PLATFORM POPULATION ...................................................................... 51

7.2. INTEGRATION WITH LOCAL INFRASTRUCTURE .................................................................................................... 52

7.3. SERVICES, BUILDING BLOCKS, DATASETS ............................................................................................................. 53

7.3.1. Services ....................................................................................................................................................... 53 7.3.1.1. Relocation Advisor ................................................................................................................................................... 53 7.3.1.2. Safe City ................................................................................................................................................................... 57 7.3.1.3. Public Procurement Transparency ........................................................................................................................... 59

7.3.2. Building blocks ............................................................................................................................................ 61 7.3.2.1. Water and air quality ............................................................................................................................................... 61 7.3.2.2. Traffic analyzer ......................................................................................................................................................... 62 7.3.2.3. Citizen Data Vault API ............................................................................................................................................... 62

7.3.3. Datasets ...................................................................................................................................................... 62

8. CONCLUSIONS ....................................................................................................................................................... 63

9. ABBREVIATIONS .................................................................................................................................................... 64

10. REFERENCES ...................................................................................................................................................... 65

11. COMMENTS FROM EXTERNAL REVIEWERS ........................................................................................................ 66

11.1. TRENTO ................................................................................................................................................................ 66

11.2. BILBAO ................................................................................................................................................................. 67

12. ANNEX I – ETHICAL COMPLIANCE CHECK ........................................................................................................... 68

ILLUSTRATIONS

Figure 1 – Population Process in Trento .................................................................................................................................................... 10 Figure 2 – Trentino Open Data Portal ........................................................................................................................................................ 13 Figure 3 – Open Services Portal ................................................................................................................................................................. 13 Figure 4 – List of street cleaning occurrences ............................................................................................................................................ 15 Figure 5 – Map of street cleaning occurrences .......................................................................................................................................... 15 Figure 6 – Search for street cleaning occurrences ..................................................................................................................................... 15 Figure 7 – Schedule of cleaning for a street ............................................................................................................................................... 15 Figure 8 – Details of a street cleaning occurrence ..................................................................................................................................... 15 Figure 9 – Favorite streets ......................................................................................................................................................................... 15


Figure 10 – Bikes availability within a shared bike station ......................................................................................................................... 16 Figure 11 – List of shared bike station ....................................................................................................................................................... 16 Figure 12 – Shared bike station on the city map ........................................................................................................................................ 16 Figure 13 – Favorite shared bike stations management ............................................................................................................................ 16 Figure 14 – Bus line selector ...................................................................................................................................................................... 17 Figure 15 – Train line selector .................................................................................................................................................................... 17 Figure 16 – Sample bus line timetable ....................................................................................................................................................... 17 Figure 17 – Bus stops on the city map ....................................................................................................................................................... 17 Figure 18 – Next runs at a given bus stop .................................................................................................................................................. 17 Figure 19 – Favorite lines, stops and stations ............................................................................................................................................ 17 Figure 20 – Population Process in Bilbao ................................................................................................................................................... 20 Figure 21 – Bilbao´s Open Data portal. ...................................................................................................................................................... 21 Figure 22 – DCAT harvester. ....................................................................................................................................................................... 22 Figure 23 – Proposals filtering .................................................................................................................................................................... 23 Figure 24 – List of Proposals ...................................................................................................................................................................... 23 Figure 25 – Detail of a Proposal, with their ratings and votes ................................................................................................................... 23 Figure 26 – Map of proposals by neighborhood ........................................................................................................................................ 23 Figure 27 – Comments in a proposal .......................................................................................................................................................... 23 Figure 28 – Statistics of a proposal ............................................................................................................................................................ 23 Figure 29 – Rating and commenting a proposal......................................................................................................................................... 23 Figure 30 – Introducing a new request ...................................................................................................................................................... 23 Figure 31 – Main menu of the app ............................................................................................................................................................. 23 Figure 32 – List of Auzonet functionalities ................................................................................................................................................. 24 Figure 33 – Introduce needs or things to borrow ...................................................................................................................................... 24 Figure 34 – Auzonet search screen ............................................................................................................................................................ 24 Figure 35 – Filtering POIs created by citizens ............................................................................................................................................. 25 Figure 36 – POI search by category ............................................................................................................................................................ 25 Figure 37 – POI search by text ................................................................................................................................................................... 25 Figure 38 – POIs located on a map ............................................................................................................................................................. 25 Figure 39 – POIs located on a map ............................................................................................................................................................. 25 Figure 40 – Details of a POI ........................................................................................................................................................................ 25 Figure 41 – Searching by location .............................................................................................................................................................. 26 Figure 42 – Introducing a new POI ............................................................................................................................................................. 26 Figure 43 – Login ........................................................................................................................................................................................ 26 Figure 44 – Citizens´ and stakeholders’ interests in different public sectors in Helsinki-Uusimaa region ................................................. 29 Figure 45 – Example: result of the design game ........................................................................................................................................ 30 Figure 46 – Finnish pilot services ............................................................................................................................................................... 31 Figure 47 – Architecture overview for Finnish pilot services hosted in the CNS environment .................................................................. 32 Figure 48 – My Polls menu ......................................................................................................................................................................... 33 Figure 49 – My Polls: Create one or more location based polls to reveal the public opinion .................................................................... 33 Figure 50 – My Polls: Summary of poll answers can be viewed as pie charts ............................................................................................ 34 Figure 51 – My Polls: Poll heatmap shows averages of poll location answers with colors ........................................................................ 34 Figure 52 – My Opinion menu .................................................................................................................................................................... 35 Figure 53 – My Opinion: Poll map view allows search and adding poll locations ...................................................................................... 36 Figure 54 – My Opinion: Answer poll questions and view statistics on answers by others ....................................................................... 36 Figure 55 – My Opinion: Poll density heatmap helps finding areas with active polls ................................................................................ 37 Figure 56 – My Neighbourhood menu ....................................................................................................................................................... 38 Figure 57 – My Neighbourhood: Add one or more personal preferences to define what is important to you ......................................... 38 Figure 58 – My Neighbourhood: Add one or more interesting locations to be analysed .......................................................................... 39 Figure 59 – My Neighbourhood: Match matrix summarizes how well each location matches your preferences ..................................... 39 Figure 60 – My Neighbourhood: Match heatmap helps finding areas that match your personal preferences ......................................... 39 Figure 61 – My Neighbourhood: Finding a safe neighbourhood with city rental houses .......................................................................... 40 Figure 62 – My Neighbourhood: Sub-requests triggered by a simple match heatmap request ................................................................ 41 Figure 63 – Age structure of survey participants ....................................................................................................................................... 51 Figure 64 – Personal digital needs of examinees - the most common answers (in percentages) ............................................................. 51 Figure 65 – Examinees' needs for public service sectors - the most common answers (in percentages) ................................................. 51


Figure 66 – Data sources in Novi Sad ......................................................................................................................................................... 53 Figure 67 – The first window of Relocation Advisor application in both Web and Android service .......................................................... 56 Figure 68 – Information regarding one of schools in Novi Sad .................................................................................................................. 56 Figure 69 – Route from requested address to one of the schools in Novi Sad .......................................................................................... 56 Figure 70 – Bus stops on requested bus line .............................................................................................................................................. 56 Figure 71 – Parking places nearby requested address ............................................................................................................................... 56 Figure 72 –The first window of Safe City Trip application in both web and android service ..................................................................... 58 Figure 73 – The route which the user has requested ................................................................................................................................. 58 Figure 74 – Window showing the quality of water in Novi Sad ................................................................................................................. 58 Figure 75 – Microphones shown on the map presenting the noise levels in Novi Sad .............................................................................. 58 Figure 76 – Noise level in the city of Novi Sad ........................................................................................................................................... 58 Figure 77 – Traffic buttons showing the amount of traffic in the city ........................................................................................................ 58 Figure 78 – Information regarding traffic in specific area in the city of Novi Sad ...................................................................................... 58 Figure 79 – Public procurement transparency application logo and first page.......................................................................................... 61 Figure 80 – Options available in the application ........................................................................................................................................ 61 Figure 81 – Companies' public procurement options ................................................................................................................................ 61 Figure 82 – Information about the company, which the user chose to get information about ................................................................. 61 Figure 83 – Statistics .................................................................................................................................................................................. 61

TABLES

Table 1 – Most requested services in Trento by area ................................................................................................................................ 11 Table 2 – Quantitative outcome of population activities ........................................................................................................................... 63


1. EXECUTIVE SUMMARY

This document reports the outcomes of Tasks from 3.3 to 3.6, that is to say the setup and population of the

WeLive environment for the four project pilots, namely Trento, Bilbao, Novi Sad and the Finnish region of

Uusimaa-Helsinki.

By “Welive environment” we mean the union of the WeLive framework and of the artefacts (services, building

blocks, datasets, needs ideas, challenges and more) published onto it with which the stakeholders in the

different cities/regions interact during the pilot execution.

The WeLive framework was described for what concerns its components in the WP2 deliverables [4], [5], [6],

[7], [8], [9], [10], [11], and for what concerns its integration in the deliverable [3]. The guidelines followed for

the integration and population activities were set in the deliverable [12]. In this document, we focus on the

actual population activities carried out in the different pilot cities and on the actual artefacts used for preparing

the pilot environments.

This document will briefly recall the portion of the WeLive environment that is commonly shared by all pilots

and will provide the details of those aspects that differentiates the environments prepared in the four

cities/region involved in the experimentation. In particular, for each of these four environments, they will be

described:

the process by which the population of the environment was obtained;

any possible pre-existing infrastructure that have facilitated the setup and population of the

environment;

the actual artefacts with which the environment was populated.

As usual, the description will be enriched by a discussion of possible ethical issues involved in the activities

described, and we will provide some final considerations about the work that was executed.


2. INTRODUCTION

The 2010 edition of the EU eGovernment Benchmark Report states that currently public services are built

following an administration-centric approach, driving to a low usage, rather than according to the citizens´ need

(user-centric approach). Public administrations are facing key socioeconomic challenges such as demographic

change, employment, mobility, security, environment and many others. Besides, citizens expectations, in terms

of burden reduction, efficiency, and personalization, are growing and will make the take-up of traditional public

e-services steadily harder in the following years. Citizens want to transit from being mere consumers of public

services to providers of those services, i.e. prosumers of the open government ecosystem. Public-private

parnership and active contribution of citizens are two key instruments to transform the way currently cities and

territories are being governed. To turn cities and territories into hubs of welfare, innovation and economic

growth (i.e. to give place to Smarter Cities or Territories) not only they have to make a more efficient

management of resources but they also have to be aware and reactive to the socio-economic needs and wants

of their stakeholders, i.e. their citizens, local businesses and companies. ICT-enabled Open and Collaborative

Government is the recipe to deliver "more from less". Indeed, governments cannot be any longer the single

providers of public services. Enpowerment of stakeholders is necessary by incentivizing them to take a more

active role. Public-private partenerships have to be catalysed to give place to a more sustainable model of

government which also behaves as a economy promotion dynamizer.

The WeLive project was born as a means to address the above challenges. WeLive aims at transforming the

current e-government approach followed by most public administrations into we-government where all the

stakeholders of public administration, namely citizens, local businesses and companies, are treated as peers

(collaborators) and prosumers (providers) instead of the usual customer role associated to them. WeLive will

enable also the so-called “t-Government” (Transformational Government) by providing stakeholders with the

technology tools that enable them to create public value. In addition, WeLive is also thought to embrace l-

Government (Lean Government), which aims to do more with less by involving other players, leaving the

Government as an orchestrator around enabled platforms. Finally, WeLive fully adopts m-Government, i.e. an

extension or evolution of e-government through utilization of mobile technologies for public service delivery.

Consequently, WeLive proposes a new concept of e-Government, which provides the means, i.e. an

environment or platform, analogously to the Web, and leaves others, all the stakeholders in a city or territory,

to lead the innovation process and so turn public resource assets into artifacts to nurture economic growth and

job creation.

One of the goals of the WeLive project is to test its approach by running four pilots in four European cities,

namely Trento (Italy), Novi Sad (Serbia), Bilbao (Spain), and Helsinki-Uusimaa Region (Finland). These cities are

good examples of economic dynamism and social welfare in their respective countries; they are different with

respect to population size and each of them is endowed with distinguishing features, which overall make them

very suitable to measure the impact of the Open and Collaborative Government solution proposed by WeLive.

This deliverable describes the activities of Work Package 3 (WP3) “Integration, set-up and population of the

WeLive framework” [13] that are required for the setup of the WeLive framework in the four trial sites. The

deliverable strictly related to the deliverable [3] that describes the integration of the WeLive components into

a unique framework and the deliverable [12] that provides the guidelines for the integration and setup of the

framework required for launching the pilot activities. The document describes the environments in which the

experimentation phase will take place. By “environment”, we mean the assembly of the unique instance of the

WeLive framework that has been integrated and setup with other infrastructural elements adopted in the

different cities/region and with a set of artefacts (services, building blocks, datasets, challenges, needs, ideas

and more) published onto the platform whose role is to trigger the WeLive co-innovation and co-creation

processes.


It has to be noted that despite the presence of a unique and shared instance of the Welive framework that will

serve the four pilots, we can reasonably talk of four different environments. As a matter of fact, if from a

technical and physical point of view the running framework is just one, nevertheless, from a logical point of

view, the presence of other technical elements or tool and the different artefacts loaded onto the framework

give place to four separate environments, that will be separately used by the stakeholders of the different

cities/regions involved in the experimentation.

The ultimate goal of this deliverable is to describe these virtual environments and how they are characterized

by peculiar aspects and by different elements.

Each pilot city/region actually entered the project already having in its background its own smartcity approach

that the WeLive contributed to enhance and extend in the first year and a half of the project. In some cases,

such a local approach consists of pieces of infrastructure, services, datasets or other kinds of IT artefacts that

have been integrated more or less tightly into the WeLive framework. In some other cases, the background of

the local approach comprises tangible or intangible non-IT artefacts that are relevant for the execution of the

WeLive innovation process.

Besides, all the pilot cities share the existence of a number of WeLive artefacts that have been devised for

initially populating the framework in order to trigger and exemplify the intended co-innovation approach.

This deliverable explains how these platforms and artefact, whatever their form, have been integrated or have

been injected into the WeLive components or are part at any of the environment for the pilot execution.

We will also deal with the process by which these environments have been created and to describe the part

they share.

In particular:

In Section 3, we describe the part of the WeLive environment that is shared by all the pilots,

In Section 4, the Trento task force introduces the peculiarities of its pilot environment;

In Section 5, the Bilbao task force introduces the peculiarities of its pilot environment;

In Section 6, the Uusimaa-Helsinki task force introduces the peculiarities of its pilot environment;

In Section 7, the Novi Sad task force introduces the peculiarities of its pilot environment;

Finally, in Section 8, we draw some conclusions about the setup and the population of the WeLive

environments for the pilot execution.


3. COMMON ENVIRONMENT FOR ALL WELIVE PILOTS

The environment in which the users engaged in the first pilot iteration of the WeLive project are expected to

operate is ideally composed by three elements. The first one is the centralized common instance of the

integrated WeLive framework described in the deliverable [3]. The second one is any optional legacy

infrastructure offered locally by each city to complement in some aspect the WeLive technological stack. The

last one is the set of artefacts that each city publishes on the platform to enable the co-innovation and co-

creation processes fostered by the WeLive approach. The second and the third one, being a prerogative of each

pilot city, will be the subject matter of sections from 4 to 7. In the rest of this section, we describe the first one.

In the DoA of the project ([13]), when referring to the activities related to pilot execution, we repeatedly

mentioned the existence of four different environments, one per city/region, in which stakeholder (citizens,

businesses, public administrations) would be engaged to take part to the co-innovation and co-creation

processes. While this is actually what is going to happen in the first pilot iteration, at the same time, a portion

part of these four environments is actually shared amongst the four different trials. This part of the environment

is the unique instance of the WeLive framework that has been deployed. A thorough description of such

environment is contained in deliverable 3, while a complete description of the components integrated in such

environment can be found in the deliverable of Work Package 2, that is [4], [5], [6], [7], [8], [9], [10], and [11].

Substantially, it corresponds to the set of tools with which the users of the WeLive framework can interact to

perform their activities in terms of co-innovation and co-creation. Such tools correspond to the Open Innovation

Area, the Citizen Data Vault, the Open Data Stack, the Analytics Dashboard, the Marketplace and all the other

visible or invisible tools that support the execution of the former ones, e.g. in terms of authentication, logging,

Such an environment encompasses also the cloud hosting facilities represented by the CNS marketplace and

the Cloudfoundry PaaS.

The reasons for having just one deployed instance for these elements instead of replicating them for the four

trials, can be summarized as follows. First, the Consortium considered more effective to separate clearly the

integration task from its replication in different settings. The integration of the WeLive legacy components,

opportunely tailored to the requirements of the project, demonstrated to be a challenge difficult enough for

the first iteration of these project activities. Mixing such problems with a concurrent replication of the

deployment on different infrastructures would have delayed furtherly the completion of the activities

themselves. In fact, this choice has allowed the Consortium to gain more insight about the matters of

replication, configuration and adaptation of the WeLive framework to different situations. Besides, already

since the start of the first activities related to the tailoring of the components, to the integration of the

framework and to the planning of the pilot execution that have occurred in parallel, it has been clear that the

replication of this environment would have not granted any concrete advantage to the execution of the pilots

and to the project. About any possible language issue, the opportune management of localization within the

unique instance of the framework has prevented the raise of such kind of problems. Furthermore, the

centralization of the execution environment of the WeLive framework has guaranteed a neat advantage in

terms of management of the framework and of presentation of the results. Finally, yet importantly, the

arrangement of a unique deployment of the WeLive framework has carried along a containment of the global

costs sustained by the project for the hardware infrastructure and for the virtualization of the systems.

In the following sections, each task force will explain how this common environment has been integrated and

completed for each pilot city with all those elements needed to trigger and to support the co-innovation and

co-creation approaches.


4. TRENTO ENVIRONMENT

4.1. PROCESS FOLLOWED IN TRENTO FOR PLATFORM POPULATION

The population of the WeLive platform for Trento environment is the final stage of a process launched at the

beginning of the project and which involved the participation of several stakeholders in different online and

offline activities.

The process followed in Trento mainly comprised two stages as shown in Figure 1:

A first phase named “Stakeholders Consultation Process” aiming at collecting needs and ideas from

stakeholders in order to identify requirements.

A second phase named “Expectations and insights extraction” for transforming such requirements,

needs and ideas into a set of services, building blocks and datasets that address the stakeholders´

needs. This phase was accomplished involving WeLive consortium members.

Figure 1 – Population Process in Trento

4.1.1. Phase 1 - Stakeholders Consultation Process

As described in D1.3 “WeLive scenarios, services and building blocks” ([2]) the municipality of Trento decided

to organize the stakeholders’ consultation process in three steps:

Surveys

Workshop

Design games


4.1.1.1. Surveys

At the end of June a survey was disseminated to citizens, public administrations, companies and professionals.

The survey was made available both online and on paper for two weeks. A large communication campaign

allowed to reach most of citizens by using the Web site, where a main story was edited, by sending ad hoc

newsletters to opportune mailing lists, by spreading the news on social networks such as Facebook and Twitter.

Paper version was also distributed by the Public Relation Office and made available in all the information points

of the twelve city's districts.

The results confirmed positively the initial expectations. Despite the summer period, we could witness a high

participation: 555 people took the survey and 352 forms were completed. The average time to complete the

form was 11 minutes and 32 seconds.

The survey gave feedback about the areas where a stronger investment by the city was considered more

valuable, at least from the point of view of the stakeholders:

Online services

Sustainable Mobility

Environment

Energy efficiency and building

Contribution with ideas and suggestions for new services was very high, with 92 proposals. Some of them

delivered more ideas up to a total of 244. In Table 1, it is available a summary of the main proposals, grouped

according to their relevant area:

Area Most wanted services

Government / Online

services

Digital helpdesk where submit all kind of dossier. Booking on–line of public

facilities (sport, conference hall, etc.). Online payment related pending dossier

by the Administration.

Sustainable mobility Improving of sustainable mobility: bike sharing, car sharing/car pooling, info

about bike-lane. Strengthen information about public transport: parking,

fastest solution in order to reach the destination.

Environment; Waste

management / decorum

Service or app with more info about waste recycling. Reporting about

abandoned waste or deteriorated areas

Participation Participation to the management of public goods. Simplified reporting

methods

Wi-Fi Expanding area where Wi-fi is free

Table 1 – Most requested services in Trento by area

4.1.1.2. Workshops

According to the results of the survey and the relevant number of stakeholder available to be involved, three

workshops were organized, with the presentation of the above summarized results and discussion about new

proposals.

4.1.1.3. Design Games


After the survey and the workshops, the third step was to organize some design games focused on “government

and online services” and “sustainable mobility”, considering that the survey results highlighted both these

issues as the most promising.

4.1.2. Phase 2 - Expectations and insights extraction

The result of this process was to determine in detail the demands and needs of stakeholders of Trento.

Some of these requirements were already well known by the Municipality of Trento as well as priorities to

satisfy. For this reason the municipality had already initiated specific projects:

The introduction of a “one-stop shop” for all the interactive online services connected with another

specific European H2020 Project, named “Simpatico” (regarding "Government / online services" Area)

The introduction of “FuturaTrento” project and platform to permit the participation and the

management of public goods (regarding Participation area)

The development of a specific app “100% Riciclo” and the connected services (regarding "Environment"

Area and “Waste management/decorum” in particular)

For the remaining requirements, especially in “Sustainable Mobility”, Trento task force studied the viability of

the scenarios and the ideas presented by defining which building blocks, datasets and infrastructures were

necessary to transform each of these scenarios and ideas into real assets and prototypes that could be further

populated into the WeLive framework.

This phase involved the design and implementation of a set of assets by WeLive partner and required the

participation if stakeholders during the testing phase to identify potential deficiencies and problems to be

solved before the pilot phase II.

Finally the services carried out according to user requests have been objects of a specific hackathon for

improvement, as well as additional requests for improvement through specific challenges included in the “Open

innovation Area” of WeLive platform.

4.2. INTEGRATION WITH LOCAL INFRASTRUCTURE

In order to support the definition and publication of the open artefacts, the environment adopted in Trento

relies on two software systems, namely open data portal and open service portal.

The open datasets provided by the Municipality of Trento as well as by other local stakeholders are published

in the CKAN-based open data portal of the Trentino province [1]. The use of the de-facto standard technology

facilitates the integration of this tool with the WeLive framework. Indeed, currently the integration is achieved

through the continuous harvesting of the relevant datasets from this portal. The extracted metadata is then

automatically published to the WeLive platform, in particular, in the open data stack and in the marketplace.

Currently, the open data portal of the Trentino province hosts as much as 5,124 open datasets that belongs t

212 organizations within the Trentino province. The harvesting procedure for populating the ODS component

of the WeLive framework considers only those datasets (16) that belongs to the Municipality of Trento

organization. For more documentation about the ODS please check the WeLive online documentation ([14]).


Figure 2 – Trentino Open Data Portal

In order to publish and manage the building blocks, the Trento environment adopts the Open Service portal

that is being developed and maintained by FBK. This portal allows for publication of Web services and APIs,

allowing the users to explore their metadata (i.e., the formats and protocols, authors, licenses) and

documentation, as well as to perform tests and see the results of the service invocations.

Figure 3 – Open Services Portal


The Open Service portal is also integrated with the WeLive framework to guarantee that the building blocks

published within the portal appear on the WeLive marketplace. To accomplish this, the portal relies on the APIs

provided by the marketplace for the artefact creation. Specifically, when a new open service is published, the

corresponding WeLive-compatible specifications are generated, namely linked USDL and WADL / WSDL

documents. Together with other metadata, the references to these specifications are passed to the marketplace

API.

4.3. SERVICES, BUILDING BLOCKS, DATASETS

The users of the WeLive framework involved in the activities of the first iteration of the Trento pilot will interact

with an environment that has been populated with a set of WeLive-compliant artefacts. Such artifacts are

published in the WeLive marketplace and are of three kinds: services, building blocks and datasets. The

following sub-sections provide the details about them.

4.3.1. Services

The Trento task force has implemented three public service applications, namely:

Trento Street Cleaning

Trento Bike Sharing

Trento Transport Timetables

Such applications are presented to WeLive users through the WeLive Marketplace and through the WeLive

Player app. They are actually Android apps and, thus, are available for download from the Google Play app

store.

The services offered within the three applications have been identified with the help of citizen during the

engagement activities executed by the Trento task force during the first year of the project, which are described

in [2]. The following subsections provide a description of the envisaged applications.

4.3.1.1. Trento Street Cleaning

The app “Trento Street Cleaning” stems from the need, expressed by Trento citizens, to avoid being fined or,

even worst, to have their car removed due to the cleaning of the street cleaning that takes place during certain

periods of the year. The cleaning of the streets is communicated to Trento citizens using standard channels that

is to say, websites, bulletins, etc.) and temporary road signs that are exposed 48 hours before the cleaning itself.

Overall, for the citizens it is not always easy to get informed timely about such occurrences. For this reason, it

is useful for them to know in advance when streets, where they usually park their car, are going to be cleaned.

The app presents, on a day-by-day basis, the schedule of the street cleaning. Such information is displayed both

in the shape of a list of occurrences (Figure 4) and with markers located in the relevant streets within the city

map (Figure 5).

Users can also perform a text search for a street they are interested (Figure 6). Whatever they way in which a

street is selected, the user gets the complete schedule of upcoming cleanings planned (and also of the ones

that have been already carried out) for that street (Figure 7) and the details of a single cleaning occurrence

(Figure 8).

If a user is interested in receiving push notifications the day before the cleaning is performed for a given street

they can set such street as favorite. User can also manage such list of favorite streets (Figure 9).


Figure 4 – List of street cleaning

occurrences

Figure 5 – Map of street cleaning

occurrences

Figure 6 – Search for street cleaning

occurrences

Figure 7 – Schedule of cleaning for a

street

Figure 8 – Details of a street

cleaning occurrence

Figure 9 – Favorite streets

4.3.1.2. Trento Bike Sharing

The app “Trento Bike Sharing” is the result of Trento citizens’ interest towards the usage of bike sharing. In

Trento it has been active since some years a service of electric bike sharing. The stations hosting the bikes are

spread throughout the city and are endowed with sensors that provide the number of bikes and free slots

available in the station itself. The application allows the user to perform a real-time check over the number of

bicycles that are available and the number of empty slots for returning the bicycle (Figure 10).

The stations can either be viewed as a list (Figure 11) or browsed on a map (Figure 12). In this way the user can,

for example, see which are the nearest stations.

It is possible to set some stations as favorites to have them always at one’s fingertips (Figure 13).

The app is built over one of the building blocks available within the WeLive Marketplace. Namely, it is the “Bike

Sharing” building block which provides the real time availability of bikes within bike stations.


Figure 10 – Bikes availability within

a shared bike station

Figure 11 – List of shared bike

station

Figure 12 – Shared bike station on

the city map

Figure 13 – Favorite shared bike

stations management

4.3.1.3. Trento Transport Timetables

The interests expressed by Trento citizens during the engagement activities performed within the WeLive

project about sustainable mobility motivated the design and the implementation of the app “Trento Transport

Timetables”. The app displays in a simple and immediate manner the timetables of buses that circulate in Trento

and of trains passing by Trento (Figure 14, Figure 15, and Figure 16). The timetables in some cases also report

real-time information about delays. Users can save their favorite tables for having them at hand in the main

page.

The timetables can be selected by choosing them from a list or by browsing a map (Figure 17) and checking

what are the next runs for a particular bus stop or train station (Figure 18), as for instance the closest one.

Also for this app a personalization of the service is achieved allowing the users to store and manage a list of

favorite bus lines, bus stop or train stations (Figure 19).


Figure 14 – Bus line selector

Figure 15 – Train line selector

Figure 16 – Sample bus line

timetable

Figure 17 – Bus stops on the city

map

Figure 18 – Next runs at a given bus

stop

Figure 19 – Favorite lines, stops and

stations

4.3.2. Building blocks

The environment of the Trento pilot can count on a number of building blocks that are hosted on the Trento

open services platform, as explained in Section 4.2, and that are published as WeLive compliant artifact onto

the WeLive Marketplace.

Such building blocks provides basic functionalities of different kinds, which are related to different service

domains. Here below they are fully listed and catalogued:

Mobility domain:

“Public Transport”: a service that provides access to the local transport network information,

including the static and real-time information about the public transport schedules and their

deviations, information about parking structures and their real-time filling, information about

road works and blocks, etc.

“Route Planner”: a service that provides the functionality of multimodal route planner,

enabling planning for public transport and a car, bicycle routes, considering also the bike

sharing stations and parkings nearby, etc. Besides, the service allows the user to store the

planned routes and perform their monitoring, signaling possible problems (e.g., delays, strikes,

accidents, etc).


“Street Cleaning”: a service that provides information about the street cleaning schedules in

the city of Trento. Specifically, the service allows for accessing the information about which

streets are subject to cleaning on a specific day, to search for the street schedule by the street

name, etc.

“Bike Sharing”: a service that represents the real-time information about electric bike sharing

stations in Trentino. The information represents the availability of the bike and bike slots at real

time.

“Mobility Crowdsourcing”: a service allows the user to signal different problems and situations

regarding the mobility information. Typical scenarios include the information about bus or train

delays, accidents, bike sharing station problems, transport network strikes, etc.

Information and Tourism domain:

“Trento in Your Pocket”: a service that provides an access to the cultural and touristic

information about Trento and its suburbs. This includes events, places of interests, itineraries,

hotels, restaurants, etc.

Environment domain:

“Waste Disposal”: a service that provides information about the waste disposal in the city,

including the way the waste is separated, points of disposal, their opening times, etc.

General purpose services:

“City Report”: a service that exposes the functionality for the citizen to report a problem or a

recommendation to the public administration regarding the provided services and

infrastructure. The API exposes the methods for reading and publishing the problems across

different tenants (municipalities or departments) and different services (e.g., road

infrastructures, waste management, etc.).

“Geocoder”: a service permits to convert an address in its coordinates, and vice versa converts

coordinates in a readable address. The service uses Open Street Map data source to resolve

addresses.

“CDV Citizen Data Vault Trento”: the Citizen Data Vault (CDV) is the WeLive component that

allows the citizens to manage their own data in a vault. The CDV collects the citizens profile

data during the interaction with the Welive tools tools. Furthermore the CDV provides a set of

API to get the user profile data and to store and manage data generated using the third party

application (User Data). All these operations require WeLive Authorization.

4.3.3. Datasets

The Trento environment is completed by a list of datasets that are stored in the open data portal of the Trentino

province, under the Municipality of Trento organization, as explained in Section 4.2, that have been imported

into the Open Data Stack tool of the WeLive framework and that are exposed on the WeLive Marketplace. Such

datasets are of different kinds. Here it follows the complete list:

“Railways in Trentino”: data about the rail transport flowing in Trentino (excluding Trento-Malè line),

in GTFS format. The data are updated each time change. Main available information: lists of stops

(georeferenced), list of lines, list of racing times. Data from the Trento-Malè line are available, along

with the other of the Trentino public transport data, on the portal of the Trentino open data

(dati.trentino.it).


“Waste differentiation in 2013”: CSV data related to municipal waste produced on a monthly basis (in

tons) in the town of Trento.

“Civic numbers”: set of all points of house numbers. They are divided into two categories. HOME: for

every number there exists always and only one, is the main entrance to the building. SECONDARY: for

every number there can be different, represent any secondary entrances to the building. The data are

available in the GML, SHP, KML, DXF formats.

“Street list”: set of all linear elements that represent the road graph of the Municipality of Trento. The

data are available in the GML, SHP, KML, DXF formats.

“Shops localization”: list of shops localized by the corresponding civic number. The data are available

in the GML, SHP, KML, DXF formats.

“Council financial report”: tables are related to revenue, subdivided by title and category, and

expenditure, subdivided by title and function, noted during the reporting. The data are available, in CSV

format, from 2003 until 2011, in 9 different datasets.


5. BILBAO ENVIRONMENT

5.1. PROCESS FOLLOWED IN BILBAO FOR PLATFORM POPULATION

The population of the WeLive platform for Bilbao environment is the final stage of a process launched at the

beginning of the project and which involved the participation of several stakeholders in different online and

physical activities. The process followed in Bilbao mainly comprised two stages as can be seen in Figure 20:

A first phase named “Stakeholders Consultation Process” with the aim of collecting needs and ideas

from stakeholders in order to identify requirements. This phase consisted of organizing and executing

several activities involving external people representing several interest groups (citizens,

representatives from companies and businesses from Bilbao and representatives from Bilbao public

administration). Prior to this consultation process, several dissemination materials and

communications assets were designed with the main purpose of ensuring the high engagement of

representatives from each stakeholders group.

The second phase was accomplished internally by involving WeLive consortium members and consisted

of transforming these requirements, needs and ideas into a set of services, building blocks and datasets

that address the stakeholders´ needs.

Figure 20 – Population Process in Bilbao

As described in D1.3 – WeLive scenarios, services and building blocks v1 ([2]), the stakeholders´ consultation

process in Bilbao was launched by distributing an online questionnaire by mail in order to identify which topics

were most interesting for Bilbao stakeholders. From this activity, Bilbao task force obtained 303 questionnaires

(270 questionnaires from citizens, 43 from companies’ representatives and 10 from public administration

representatives). After the analysis of these questionnaires, it was concluded that most interesting areas of

improvement for Bilbao stakeholders are Traffic, Culture and Health as well as the most demanded services

were: cultural agenda, real-time traffic/parking information, activities for children and information about

pharmacies. For going deeper on service, building blocks and datasets definition for these areas of interest, a

second step was launched where three workshops were organized: one for each stakeholder group. In this

activity for each area of interest, a table describing facts and ideas was made. The facts referred to the problems


that Bilbao stakeholders have in their daily life. On the other hand, the ideas represented the solutions

suggested by workshops participants for addressing each need. The demographic information of the people

attending the three workshops were the following:

Workshop with Citizens Workshop attendees were 14.

12 male and 2 female.

11 employed by a third party and 3 entrepreneurs/self-employed

Workshop with companies representatives Workshop attendees were 10

All male

4 entrepreneurs/self-employed and 6 employed by a third party

Workshop with public administration representatives Workshop attendees were 5

4 female and 1 male

5 civil servant

As a result of this process where main purpose was to know in detail the demands of Bilbao stakeholders, a set

of scenarios and services were defined.

Starting from this information, Bilbao task force studied the viability of these scenarios and ideas by defining

which building blocks, datasets and infrastructures were necessary to transform each of these scenarios and

ideas into real assets and prototypes that could be further populated into the WeLive framework. This phase

involved the design and implementation of a set of assets by WeLive partner and required the participation if

stakeholders during the testing phase to identify potential deficiencies and problems to be solved before the

pilot phase II.

5.2. INTEGRATION WITH LOCAL INFRASTRUCTURES

Regarding to the integration with already existing local infrastructures, WeLive platform is integrated with

Bilbao’s Open Data portal 65[3] (Figure 21) through the Open Data Stack. The harvesting extension of the ODS

allows harvesting metadata about datasets published in external platforms. In the case of Bilbao, the entire

catalogue1 of datasets is described using the W3C standard Data Catalog Vocabulary (DCAT) [4]. This DCAT

catalogue shows metadata like the title, description and license of each dataset, resources associated to a

dataset, format of these resources, etc.

Figure 21 – Bilbao´s Open Data portal.

1 http://www.bilbao.net/opendata/es/catalogo/rdf


The harvesting extension of the ODS allows harvesting metadata from datasets hosted in other platforms like

CKAN or platforms describing their datasets using DCAT. The ODS extracts the metadata from this sources and

replicates the datasets in WeLive platform. However, the original resource (the CSV, JSON, XLS, etc. file) is linked

to the original source. In section 5.3.3, datasets harvested from Bilbao Open Data portal are described. For more

documentation about the ODS please check the WeLive online documentation ([14]).

Figure 22 – DCAT harvester.

5.3. SERVICES, BUILDING BLOCKS AND DATASETS

Bilbao’s task force has developed three services so far. All these services have been published into WeLive

framework (WeLive Marketplace) as mobile applications.

Bilbozkatu: app for allowing citizens of Bilbao vote and rate different proposals or ideas published by

other citizens and/or the town hall.

BilbOn: This service provides information about different public utilities and points of interest. This

service uses a public dataset from Bilbao, and allows users to contribute with their own POIs.

Auzonet: This app implements a social network that allows neighbors offer different solutions, based

on geographical proximity and trust.

5.3.1. Services

5.3.1.1. Bilbozkatu

This mobile application allows citizens of Bilbao voting and rating proposals and/or ideas launched by other

citizens and/or the city council about different city concerns (i.e: best place for locating a new kids playing area,

local projects’ definition, etc.). Through their contributions and votes, citizens have the opportunity to

participate, collaborate and co-decide how they like their neighborhood to become.

From the stakeholder consultation process where different stakeholders were involved in several workshops,

it was identified a common need for all of them. The stakeholders wanted to be involved in the decision making

process of Bilbao and to participate in the design of the city of the future. This was the main reason for creating

an application like Bilbozkatu which is an app for digital democracy and citizen participation. Thanks to this app,

the Bilbao city council is able to know which the most important concerns for the citizens are, and this

information could be used for easing the decision-making processes.


Figure 23 – Proposals filtering

Figure 24 – List of Proposals

Figure 25 – Detail of a Proposal,

with their ratings and votes

Figure 26 – Map of proposals by

neighborhood

Figure 27 – Comments in a proposal

Figure 28 – Statistics of a proposal

Figure 29 – Rating and commenting

a proposal

Figure 30 – Introducing a new

request

Figure 31 – Main menu of the app

Among its main functionalities, Bilbozkatu offers:

Voting campaing publication.

Campaing selection.


Campaing voting by the citizens.

Publication of the results of the voting.

Information to neighbors.

From the building blocks described in sections below, Bilbozkatu uses:

“Users feedback”

“Citizen voting” and

“In-app questionnaire” Building Blocks.

It has been developed under Ionic Framework, so as it is a multiplatform application.

5.3.1.2. Auzonet

Auzonet is a Social network for neighborhoods in Bilbao for providing solutions to the inhabitants of those

neighborhoods, based on the proximity and confidence. The main purpose of this social application is to enable

citizens to borrow the things they need from neighbors in less than 30 minutes. A citizen has the chance to

show his/her needs with other neighborhoods as well as share the things he/she can offer to other people too.

Bilbao citizens will be able to search in others offers or find something to lend to a neighborhood that has

published his/her need. This mobile application contributes to create “community” which was one of the

common needs proposed by several stakeholders during the stakeholders’ consultation process events.

Auzonet key functionalities are:

Social network based on proximity and confidence

Citizen/user registers into the service

Introduce needs or things to borrow.

Registered users will receive a push notification based on proximity and confidence

User who borrows has the possibility to rate the service.

Figure 32 – List of Auzonet

functionalities

Figure 33 – Introduce needs or

things to borrow

Figure 34 – Auzonet search screen

Users post something they want to borrow, neighbours willing to lend things get a push notification to which

they can respond in a single touch, and thus the borrowing process enabled.

From the building blocks described in sections below, Auzonet uses:

Common Building Blocks: Map interface, Users feedback, Users ranking

Core Building Blocks: logging, authentication, registry and query mapper


It has been developed under Ionic Framework, so as it is a multiplatform application.

5.3.1.3. BilbOn

This service provides information about public utilities of the city (i.e.: public toilettes, mailboxes, public bikes,

stations, pharmacies etc.). It offers a catalogue of urban POIs, geolocated news and warnings, etc. The main

purpose of this app is that citizens and visitors have more information to know better the city. Moreover, every

POI can be enriched with information and contents provided by users.

From the building blocks described in sections below, BilbOn uses:

“Nearest Point” building block to find the nearest POI from user’s actual location.

BilBon’s key functionalities are:

Urban POIs geolocation.

Search of interesting points based on user’s needs.

POIs publication, enriching the context.

Figure 35 – Filtering POIs created by citizens

Figure 36 – POI search by category

Figure 37 – POI search by text

Figure 38 – POIs located on a map

Figure 39 – POIs located on a map

Figure 40 – Details of a POI


Figure 41 – Searching by location

Figure 42 – Introducing a new POI

Figure 43 – Login


The Bilbao city pilot provides some building blocks that are currently hosted on the project’s internal open

services platform (a Cloudfoundry instance). This building blocks are published as WeLive compliant artifacts

onto the WeLive Marketplace.

The building blocks developed for the Bilbao pilot provide functionalities that are used by the different city

services explained in section 5.2.1. The list of the building blocks currently provided inside the Bilbao city pilot

are explained in the next subsections.

5.3.2.1. BB Citizens voting (Bilbozkatu)

This building block allows users voting different proposals, ideas, etc. It is specific for Bilbozkatu app. These

voting functionalities will be used in different applications and that is the reason why we have created a Building

Block for it, so as it can be reused in various apps, optimizing and reducing the developing costs.

This BB provides these methods:

Get proposals (optionally, it is possible to determine how many registers to obtain from the database,

and paginate them).

Get proposals based on different criteria (area, category, text)

Get the number of proposals grouped by area

Get the details of the proposal

Registered users can vote a proposal

Registered users can publish a new proposal

Users’ registration

5.3.2.2. BB Users feedback

This BB provides functionalities for capturing users’ feedback (ratings, comments) for each proposal, idea, POI,

etc. These feedback functionalities will be used in different applications, that is why we have created a Building

Block for it, so as it can be reused in various apps, optimizing and reducing the developing costs.

This BB is used in Bilbozkatu and provides these methods:

Introducing feedback (for a specific proposal, comment and rating)

Get feedbacks for a proposal

Get the number of feedbacks after a given date and until a given date.


Get the average rating of the feedbacks

Offer a WADL of the service.

5.3.2.3. BB Users Ranking

This BB allows generating a ranking of users for different services. These ranking functionalities will be used in

different applications, that is the reason why we have created a Building Block for it, so as it can be reused in

various apps, optimizing and reducing the developing costs.

These are its main functionalities:

Add users

Rate a user

See users’s ranking

Get the users’ list

Delete a users’s feedback

Get the list of users of a service and object.

5.3.2.4. Nearest Point Finder

This BB provides a basic functionality to those services requiring calculating the list points that are closer to a

specific location. Its main functionality is to provide, from a list of possible map locations, the one that is the

closest to the user specified location.

5.3.2.5. Image uploader

The BB provides functionality to simplify the management of user images inside services. The BB relies on Flick

to store the user images and guarantees that only the owner of each image can access his/her corresponding

images.

The main functionalities of the building block are:

Add image by user

Retrieve image of by the user

Tag image

Retrieve images with specific tag

5.3.2.6. In-app questionnaires

This BB provides functionality to create online questionnaires that can be shown inside mobile applications in

order to retrieve information about the application usage. The functionality provided by the Building Block

includes the creation of questionnaires with multiple questions and different response types (free text, closed

range) and support for internationalization in multiple languages. The stored responses can be later retrieved

in CSV format by the application owners.

The main functionalities of the building block are:

Create a questionnaire

Add questions to a questionnaire

Add a translation for a question

Add allowed responses for a question

Retrieve a questionnaire and its associated responses in a specific language

Store responses for a questionnaire

Retrieve all the responses in CSV format for an specific application or pilot.


5.3.3. Datasets

WeLive platform hosts 164 datasets for Bilbao pilot. These datasets can be classified as follows:

158 datasets harvested from Bilbao Open Data portal.

3 datasets harvested from Open Data Euskadi [5] portal (open data from Basque Government).

2 datasets generated by applications from Bilbao pilot (BilbOn and Auzonet).

1 dataset generated by the ODS from data gathered from Twitter.

Among datasets harvested from Bilbao Open Data portal, we can find datasets related to different topics like

demography, culture and leisure, economy, environment, public transportation or tourism. These datasets are

published in the following formats: 104 CSV documents, 40 RSS, 32 JSON, 33 XML, and 2 RDF.

For its usage in Bilbon application, we have harvest some datasets from Open Data Euskadi. These datasets are

related with hostelry and tourism resources in the Basque Country. Bilbon only uses data about points of

interests from Bilbao, but the application could be easily extended to cover the entire Basque Country. Datasets

harvested from Open Data Euskadi portal are the following ones:

Restaurantes, sidrerías y bodegas de Euskadi (restaurants, cider halls and cellars from Basque

Country): this dataset contains metadata and geolocation data about these hostelry locations.

Oficinas de turismo de Euskadi (tourism offices from Basque Country): this dataset contains metadata

and geolocation data about tourism offices in Basque Country.

Alojamientos turísticos de Euskadi (tourist accommodations in Basque Country): this dataset

describes metadata and geolocation data about tourist accommodations in Basque Country.

These datasets contain their resources described in JSON, CSV and XLS formats.

In addition to the harvesting of already existing datasets, three new datasets have been created for the WeLive

project: two related to apps developed within the pilot and one with data scrapped from social networks. The

datasets related to apps are the following ones:

Bilbon User POIs: this dataset stores Points of Interest created by Bilbon app users. In addition to POIs

published by datasets from Open Data Euskadi, users can create their custom POIs, sharing them with

other users.

Auzonet: this dataset contains two resources. The first one, “Locations”, describes different

neighborhoods from Bilbao, including their geolocation. The other one, “Categories”, describes

different categories used by the app.

These two datasets contain their resources described in JSON format. On the other hand, we have created a

new dataset using the Twitter Topic Harvester provided by the ODS. This dataset looks for tweets related to a

set of words related to the categories of ideas from the Open Innovation Area. These tweets are analyzed in

order to generate a set of topics that could be interesting for the citizens of Bilbao. Resultant topics are

published in JSON format.

In addition to these datasets, there is another dataset used by Bilbozkatu (another application developed within

the pilot). This dataset, named “Habitantes por barrio y sexo (totales)” (Inhabitants classified by neighborhood

and sex (totals)), described different neighborhoods from Bilbao and some demographic data about them.


6. HELSINKI-UUSIMAA ENVIRONMENT

This section describes the services, building blocks and datasets prepared for the first phase of the Finnish pilot.

6.1. PROCESS FOLLOWED IN FINLAND FOR PLATFORM POPULATION

The stakeholders’ consultation process in Helsinki-Uusimaa region includes service design methods like 1)

survey and 2) design game.

1) The web-based survey was published in the early phase of the project to collect initial information about

users’ and stakeholders’ needs, hopes and wishes regarding to future digital services. The survey

method enables involving through web based channels a high amount of citizens and stakeholders and

thereby obtaining a large quantity of information. The first part of the survey contained questions about

participants’ age, occupation, where they live/is company stablished/public administration belongs,

usage of ICT technologies and digital services, their interests in different public sectors, open data

published by public administrations and data assets freely offered by companies. The second part of

the survey contained open-ended questions about digital services that participants would like to use or

their relatives/friends would like to use, data to be opened by companies, open data wanted by

companies, open data gathered by public administrations and its usefulness, in which projects related

to open data is public administration participating and open data resources to be published by public

administrations. Additionally, participants’ contact information was asked for later participation. The

results from survey indicated that citizens and stakeholders in Helsinki-Uusimaa region were more

interested in the areas of residence, health and sport (see Figure 44). Totally 307 people from the

Capital Region of Finland took part in the survey: 267 citizens, 16 company and 24 city representatives.

Type of interest Percentage

Residence 64,60%

Health 64,16%

Sports 63,27%

Maps 61,06%

Traffic 59,73%

Tourism 57,96%

Culture 54,87%

Education and training 50,00%

Work 46,02%

Family and social services 37,17%

Environment 34,96%

Finance and taxation 32,30%

Safety 25,66%

Communication 25,66%

Zoning 21,24%

Democracy 20,35%

Management 20,35%

Properties 19,03%

Legal protection 19,03%

Livelihood 18,58%

Building 14,16%

Other 3,98%

Figure 44 – Citizens´ and stakeholders’ interests in different public sectors in Helsinki-Uusimaa region

2) A design game, based on the results from the survey, was created. The design game helped to facilitate

a user-centred design process for cross-disciplinary design groups early in the design process.

Moreover, the design game enabled framing collaborative design activities in a game format, arguably

improves idea generation and communication between citizens, public administration and companies.

The end result of the design game session was new service ideas, scenarios and needed data assets.


Altogether, four design game sessions was arranged in May 2015. Each game session attended citizens

and representatives from companies and public administration and the session took approx. three

hours which during participants developed more concrete and detailed scenarios based on needs and

ideas revealed in web based survey research. In the beginning of the game session the participants

chose five different personas for whom they would like to design a new digital service. Then

participants chose five interesting user needs to the personas. After that participants chose needed

data assets in order to create wanted digital service. In the last phase participants descried the digital

service in words and pictures. End of the game session participants presented the ideas to other teams

and then they voted the best ideas. Total 10 initial digital service concepts (see Figure 45) were created

in four game sessions. 34 persons in total took part in the game events: 32 participants in the design

games were citizens, one company and one city representatives also participated.

Figure 45 – Example: result of the design game

6.2. DESIGN PRINCIPLES

The design game sessions described in the previous Section created many great ideas – some more realistic to

implement than the others. The Finnish Task Force members (LAUREA and CNS) made the final decision on

which ideas to implement for the first WeLive pilot phase by taking into account the technical feasibility of the

ideas and available resources to implement them. An important criterion behind the decision was that services

should support each other and base (at least partially) on a common set of building blocks.

The selected Finnish pilot services base on a common theme and exchange information through a shared

database of geographic data called the “GeoDB”. The GeoDB comprises data derived from various open

datasets and is extended with data submitted by application users. The ambitious goal behind the services has

been to create a framework to handle, collect, combine, utilize and visualize all location-based data by common


means and tools (the building blocks) – despite of the origin and original format of the data. Figure 46 shows

the relationships and roles of the applications and their potential target audience.

Figure 46 – Finnish pilot services

Another common theme has been to study and enable business models for the services and building blocks.

Therefore, all Finnish pilot services, building blocks and the GeoDB are hosted in the CNS Hosting Environment,

which keeps track on building block usage and provides means to fully control access to services. During the

first pilot phase, all services will be available free of charge to all registered WeLive users so real business models

or payments are not yet applied in practice. However, detailed transaction based statistics collected by the CNS

environment allows analyzing the business potential and hosting costs of the artefacts which helps in selecting

the appropriate business models for WeLive artefacts.

The CNS Hosting Environment takes care of creating HTTP call interfaces and API specifications required for

WeLive-compatible building blocks. Inside the CNS environment, actual data processing steps are first

implemented and deployed as “Data Refining Solutions” and then mapped to building block features. Finally,

the building block is published to generate a REST API that can be called by applications. Figure 47 shows the

overall architecture of the Finnish pilot services.


Figure 47 – Architecture overview for Finnish pilot services hosted in the CNS environment

6.3. SERVICES

Three new applications has been created for the first phase of the Finnish Pilot: My Polls, My Opinion and My

Neighourhood. These applications are closely related to each other as explained in Section 6.2. The following

subsections briefly describe the applications and their main features.

6.3.1. My Polls

The My Polls application allows creating and managing location based polls (“geo-polls”) and

viewing statistics and trends for existing geo-polls. Each geo-poll includes a simple question

to be asked from citizens (e.g. “How safe is traffic at this location?”) and can be associated to

one or more locations for which the question is relevant. Each geo-poll must be associated

to an observable attribute (e.g. “safety”, “proximity” or “cleanness”) and a tag (e.g. “traffic”,

“public services” or “park”) which together define the perspective and value range for the

poll. Use of common well-defined attributes and tags for all geo-polls makes the results

comparable and allows combining them with information extracted from open data sets that

are mapped to the same attributes and tags.

My Polls is the most convenient to use as a web application but is also available as an Android application. The

application includes multiple views for different functionality. Users can switch between application views from

left side of the top menu bar shown in Figure 48. In the web browser version, there is a separate button for

each view. In the mobile version, there is drop-down menu including a list of views.


Figure 48 – My Polls menu

The main features of the application are easy to access via the application menu:

The 'My Polls' view shows user’s current polls and allows adding and editing polls (Figure 49).

The 'Charts' view shows statistics on answers submitted to user’s polls as pie charts (Figure 50).

The 'Heatmap' view shows a heatmap visualization summarizing user’s poll results. Colors of the

heatmap represent the average of given answers on that area (Figure 51).

The 'Info' view shows information about the application and a quick guide.

The 'Terms of Use' view shows application usage terms that must be accepted when using the

application for the first time.

The 'Feedback' view allows filling and submitting a questionnaire that gives valuable feedback for

application developers and the WeLive project.

The 'User Profile' window shows information about the user account used to log in.

The application can be used in Finnish and English. The language can be changed any time from the flag

show in the upper right corner.

Clicking the 'Logout' button closes the application session and logs out the user.

Figure 49 – My Polls: Create one or more location based polls to reveal the public opinion


Figure 50 – My Polls: Summary of poll answers can be viewed as pie charts

Figure 51 – My Polls: Poll heatmap shows averages of poll location answers with colors

My Polls uses the following building blocks described in Section 6.4

GeoPoll Statistics

GeoPoll Locations

GeoPoll Polls

GeoPoll Perspectives

Geo Locations

GeoPoll Tags

GeoPoll Attributes

GeoPoll My


GeoPoll Heatmaps

In addition, some of the directly called building blocks make sub-requests to other building blocks and solutions.

See the discussion about sub-requests in Section 6.3.3 for more information.

6.3.2. My Opinion

The My Opinion application allows finding open geo-polls near to a specified location (e.g.

user’s current location) and answering them. Nearby geo-polls are shown as markers on a map

wherein marker icons indicates the topic of the geo-poll based on the associated tag. Clicking

the marker shows the geo-poll details and allows users to answer to it. After submitting the

answers, the user can view statistics of answers submitted by other users for the same geo-poll

location. This motivates people to actively answer the polls in case they are interested to see

the public opinion.

My Opinion is available both as an Android application and as a web application. The application includes

multiple views for different functionality. Users can switch between application views from left side of the top

menu bar shown in Figure 52. In the web browser version, there is a separate button for each view. In the

mobile version, there is drop-down menu including a list of views.

Figure 52 – My Opinion menu


The 'Poll Map' view allows searching and adding poll locations (Figure 53), submitting answers to polls

and viewing statistics on poll answers (Figure 54).

The 'Heatmap' view visualizes poll location density as a heatmap (Figure 55). Areas colored with orange

or red have the highest density of poll locations. The heatmap can be used to find new areas with polls

to answer.

The 'Info' view shows information about the application and a quick guide.





The 'User Profile' window shows information about the user account used to log in.



Clicking the 'Logout' button closes the application session and logs the user out.


Figure 53 – My Opinion: Poll map view allows search and adding poll locations

Figure 54 – My Opinion: Answer poll questions and view statistics on answers by others


Figure 55 – My Opinion: Poll density heatmap helps finding areas with active polls

My Opinion uses the following building blocks described in Section 6.4.

GeoPoll Answers

GeoPoll Statistics

GeoPoll Locations

GeoPoll Polls

Geo Locations

GeoPoll My

GeoPoll Density Heatmap

In addition, some of the directly called building blocks make sub-requests to other building blocks and solutions.

See the discussion about sub-requests in Section 6.3.3 for more information.

6.3.3. My Neighbourhood

The My Neighbourhood application allows users to define a set of personal preferences for

a dream neighborhood, i.e. personally important location related matters that affect their

quality of life. Each personal preference should be associated to one of the existing attributes

and tags (that were used for defining geo-polls as well) and given the level of importance on

scale 1-100. Optionally, users can also add notes describing the reasons why this matter is

so important if they wish to give city managers some valuable insights for improving the

neighbourhood. The service automatically analyzes the quality of life in user’s current

neighbourhood based on the given preferences and GeoDB data including geo-poll answers

and information from open data sets. Users can also add other interesting addresses to be

analysed, e.g. their work location or potential regions they consider to moving to.


My Neighbourhood is best when used as a web application but is also available as an Android application. The

application includes multiple views for different functionality. Users can switch between application views from

left side of the top menu bar shown in Figure 56. In the web browser version, there is a separate button for

each view. In the mobile version, there is drop-down menu including a list of views.

Figure 56 – My Neighbourhood menu


The 'Preferences' view shows user’s current personal preferences and allows adding, editing or deleting

them (Figure 57).

The 'Locations' view shows user’s current set of locations and allows adding, editing or deleting them

(Figure 58).

The 'Scores' view shows a match matrix indicating how well the added locations match to user’s

personal preferences (Figure 59).

The 'Heatmap' view shows a heatmap visualization summarizing the match scores on the map. Areas

colored orange or red match user’s personal preferences very well while blue color indicates areas that

do not fit for the user (Figure 60).

Application settings can be modified in the 'Settings' view.

The 'Info' view shows this information page





The 'User Profile' window shows information about the user account you have used to log in.



Clicking the 'Logout' button closes the application session and logs the user out.

Figure 57 – My Neighbourhood: Add one or more personal preferences to define what is important to you


Figure 58 – My Neighbourhood: Add one or more interesting locations to be analysed

Figure 59 – My Neighbourhood: Match matrix summarizes how well each location matches your preferences

Figure 60 – My Neighbourhood: Match heatmap helps finding areas that match your personal preferences


In order to create match matrices and match heatmaps, My Neighbourhood calls building blocks that combine

information from various open datasets and geo-polls. Figure 61 shows an example wherein the user wants to

find a safe neighbourhood which has city rental houses. The data needed to answer to this query can be found

from different open data sets, but all the required pieces of information may be hard to find and combine.

However, GeoDB combines and normalizes the data and provides efficient geographic queries to make this kind

of location based analysis possible!

Figure 61 – My Neighbourhood: Finding a safe neighbourhood with city rental houses

My Neighbourhood uses the following building blocks described in Section 6.4.

GeoPoll Answers

GeoPoll Locations

GeoPoll Perspectives

GeoPoll Tags

GeoPoll Attributes

GeoPoll My

GeoDB Match Matrix

Geocoder

GeoDB Match Heatmap

In addition, many of the directly used building blocks have dependencies to other building blocks or data

refining solutions. For example, when My Neighbourhood makes one request to GeoDB Match Heatmap, it

triggers several sub-requests to other solutions that trigger further sub-requests and so forth. Figure 62 shows

a sequence diagram for performing a simple match heatmap request involving only one user location and

preference. In case a user has added multiple locations and preferences, the overall processing involves

significantly larger number of transactions executed concurrently inside the CNS hosting environment. The CNS

environment controls and monitors all individual transactions and supports transaction based billing in case the

called solution involves usage costs.


Figure 62 – My Neighbourhood: Sub-requests triggered by a simple match heatmap request

6.4. BUILDING BLOCKS

This Section describes the building blocks created for the first phase of the Finnish pilot. The “SOLUTION:” field

given for each building block feature (POST/GET <path>) identifies the data refining solution currently

implementing the related functionality.

6.4.1. GeoPoll Answers

Building block providing GeoDB poll answer functionality. Allows adding new answers and querying the existing

answers with different filters. Coordinates are in WSG-84 (EPSG:4326).

POST /answers

Insert an observation with location information into the database. This can be used to insert poll answers as

well as other data. Perspective_id and location_id are required, poll_id is optional.

SOLUTION: GeoDB insert_observation 1.9

POST /get_answers

Get observations from GeoDB. Deprecated, use get_by_whatever instead.

SOLUTION: GeoDB get_observations 2.0.3

POST /get_by_perspective

Get observations filtered by perspective and area. Deprecated, use get_by_whatever instead.

SOLUTION: GeoDB get_obs_by_perspective 2.0.3

POST /get_by_attr_tags

Get spatial observation data filtered by attribute, tags and area. Deprecated, use get_by_whatever instead.

SOLUTION: GeoDB get_obs_by_attr_tags_area 2.0.3

POST /get_by_whatever

Get and filter observations from GeoDB. The observations can be filtered by (longitude, latitude and distance),

attribute_id, perspective_id, tags, (timestamp and time_unit), location_ids, grid_id, layer_id, dataset_id,

poll_ids and normalization or any combination thereof. Filters in parenthesis must be provided together.

SOLUTION: GeoDB get_observations_filtered 2.0.0

6.4.2. GeoPoll Statistics


Tools for viewing GeoDB observation statistics. Currently very limited, only provides a function for getting

binned count summary for observations.

POST /get_totals

Get binned total answer counts for a list of polls.

SOLUTION: GeoDB get_totals_for_polls 1.9

6.4.3. GeoPoll Locations

This building block allows adding new poll - location associations as well as listing locations already associated

with polls. Coordinates are in WSG-84 (EPSG:4326), distances in meters.

POST /get_locations

Get locations associated with a poll within given radius of a point. Longitude and latitude parameters should be

in WSG-84 (EPSG:4326) coordinate system, distance in meters.

SOLUTION: GeoDB get_poll_locations 1.9

POST /insert_locations

Insert locations to a poll. This is restricted to polls where users are allowed to add new points and those in which

you are the owner or in the administration group.

SOLUTION: GeoDB insert_own_poll_locations 1.9

6.4.4. GeoPoll Polls

Building block for creating, editing and viewing GeoDB poll information. GeoDB polls allow you to easily collect

geospatially associated opinion data, which is automatically stored for easy retrieval, aggregation and analysis.

POST /polls

Creates a new poll for collecting location specific data. Name and description are required, as well as IDs of the

perspective and dataset to which the poll will be associated. Perspective contains information about the values

being collected, while datasets make it possible to easily keep track of different but related data. The poll

location set can also be either user expandable or limited to a set of points provided by the poll administrator.

For administrative purposes only, use geodb_insert_own_poll in end user applications instead.

SOLUTION: GeoDB insert_poll 2.0.3

POST /get_polls

Get a filtered list of the polls available in the database. The possible filters include poll names, attribute_ids,

tags, owners and poll status.

SOLUTION: GeoDB get_polls 1.9.1

POST /update_poll

Update poll information. Following information can be changed: poll name, description, license, dataset, start

time, end time, user expandability, visibility and modifiability (owner only or group). Changes will not affect

existing observation data.

SOLUTION: GeoDB update_poll 1.9

POST /insert_poll


Creates a new poll for collecting location specific data. Name and description are required, as well as IDs of the

perspective and dataset to which the poll will be associated. Perspective contains information about the values

being collected, while datasets make it possible to easily keep track of different but related data. The poll

location set can also be either user expandable or limited to a set of points provided by the poll administrator.

SOLUTION: GeoDB insert_own_poll 2.0.3

6.4.5. GeoPoll Perspectives

Tools for viewing and adding GeoDB perspectives. Perspectives are used to describe the meaning and attribute

type of the associated observation data. Well defined perspectives also allows easy data aggregation even if

data is collected from different polls or stored in different datasets.

POST /get_perspectives

Retrieve a list of existing perspectives and their information. This list can optionally be filtered with attribute

IDs, poll IDs, perspective tags and attribute name.

SOLUTION: GeoDB get_perspectives 1.9

POST /perspectives

Insert a new perspective into the database. An existing attribute ID must be provided, while name, description

and tags are optional but highly recommended.

SOLUTION: GeoDB insert_perspective 1.9.1

6.4.6. Geo Locations

Building block for adding and querying GeoDB locations. Each observation in the data must be associated with

a location, but it is possible to add a new location automatically when entering a new observation. Location

data allows querying the observations with geospatial queries. Coordinates are in WSG-84 (EPSG:4326),

distances in metres.

POST /get_locations

Return all stored locations within the given distance of the given point.

SOLUTION: GeoDB get_locations 2.0.3

POST /insert_location

Inserts a new location at given coordinates if no existing location is found within specified distance. Returns

either the inserted location or nearest found location. Minimum distance can be used if all observations or poll

answers within a radius need to be associated with a single point.

SOLUTION: GeoDB insert_or_get_location 1.9

6.4.7. GeoPoll Tags

Tools for viewing, adding, updating and deleting tags associated with GeoDB perspectives. Having correct tags

associated to a perspective allows easy searching for related polls and observation data.

POST /delete_tag

Delete perspective tags from the database.

SOLUTION: GeoDB delete_tags 2.0.3

POST /get_tags


Get a list of perspective tags, optionally filtered with a perspective ID.

SOLUTION: GeoDB get tags 2.0.1

POST /tag

Inserts a tag and/or associate a tag with a perspective.

SOLUTION: GeoDB insert_or_assign_tag 2.0.3

6.4.8. GeoPoll Attributes

Building block that allows adding and querying GeoDB attributes. Attributes define a numerical range and type

for associated perspective (and thus observations) as well as their more abstract concept.

POST /get_attributes

Get a list of attributes in the database. Attributes can be filtered by perspective IDs, attribute IDs, attribute

names and value types. Information listed for each attribute are its name, description, type, minimum and

maximum values.

SOLUTION: GeoDB get_attributes 1.9

POST /attribute

Insert a named numeric attribute into the database. The only required field is value type, but providing name,

description and minimum/maximum values (if applicable) is recommended to make the attribute more useful.

SOLUTION: GeoDB insert_attribute 2.0.3

6.4.9. GeoPoll Users

Tools for adding, modifying and deleting GeoDB users as well as viewing and updating their preferences and

personal locations. For administrative use only.

POST /permissions

Modify geodb user permissions

SOLUTION: GeoDB manage_user_permissions 1.35

POST /add_user

Insert user entry into geodb

SOLUTION: GeoDB insert_user 2.0.3

POST /delete_user

Delete user from a GeoDB

SOLUTION: GeoDB delete_user 1.35

POST /get_users

Get user information for one or more GeoDB users

SOLUTION: GeoDB get_users 2.0.3

POST /location

Insert a new user location or update an existing one


SOLUTION: GeoDB insert_or_update_user_location 2.0.3

POST /preference

Insert or update user preferences

SOLUTION: GeoDB insert_or_update_user_preference 2.0.3

POST /get_locations

Get locations set by a user

SOLUTION: GeoDB get_user_locations 2.0.3

POST /get_preferences

Get user preferences

SOLUTION: GeoDB get_user_preferences 2.0.3

6.4.10. GeoPoll My

Solutions for changing the user's personal information and preferences. This building block also contains

methods for viewing the content added by the user. These solutions require no special permissions and can be

made available to all registered users.

POST /get_polls

Get a list of your own polls and polls for which you are marked as an administrator. Returns comprehensive

information for each listed poll, including information on associated perspective and locations.

SOLUTION: GeoDB get_own_polls 1.9

POST /get_observations

Get user's own observations, for example poll answers. These can be filtered by area given as center coordinates

and distance. Coordinates are in WSG-84 (EPSG:4326), distances in metres.

SOLUTION: GeoDB get_own_observations 2.0.3

POST /get_poll_locations

Get a list of poll locations viewable by this user without additional permissions.

SOLUTION: GeoDB get_own_poll_locations 2.0.3

POST /update_username

Update your own username.

SOLUTION: GeoDB update_own_username 1.9

POST /delete_locations

Delete your own user locations with this awesome tool. Useful for managing the list of locations you are

interested in.

SOLUTION: GeoDB delete_own_user_locations 2.0.3

POST /delete_preferences

Delete your perspective associated preferences.

SOLUTION: GeoDB delete_own_user_preferences 2.0.3


POST /get_preferences

Get a list of the perspective preferences you have set.

SOLUTION: GeoDB get_own_preferences 2.2

POST /upsert_preference

Insert or update your perspective preferences. These can be used to indicate what things you prefer and what

you wish to avoid, for example you wish to maximize proximity of services but want to avoid areas with

hazardous traffic. Used to generate recommendations in My Neighbourhood app.

SOLUTION: GeoDB upsert_own_user_preference 2.2

POST /upsert_locations

Update or insert locations to the list of locations you find interesting.

SOLUTION: GeoDB upsert_own_user_locations 2.2

POST /get_locations

Get a list of locations you have marked as interesting.

SOLUTION: GeoDB get_own_locations 2.2

POST /get_licenses

Get a list of licenses you are using.

SOLUTION: GeoDB get_own_licenses 2.0.3

6.4.11. GeoHeatmap

Building block for creating heatmaps from geodata.

POST /create_average_heatmap

Visualizes the average of values associated to geolocations as a heatmap on Google Maps. The heatmap is

returned as a stand-alone HTML page which can be e.g. saved to a local computer and viewed later without

connection to the Cloud'N'Sci.fi marketplace. The colors of the heatmap at a specific map location represent

the average of input data values nearby the location.

SOLUTION: Google Maps Average Heatmaps 0.4

6.4.12. GeoDB Match Matrix

Computes a match matrix based on the given user preferences and locations. The match matrix includes a score

for each preference-location pair indicating how well does that location match to the preference. A total match

score is also returned for each location.

POST /query

Evaluates how well the given locations match to the given user preferences by computing a match matrix.

SOLUTION: Match Matrix HEL 0.6

6.4.13. Geocoder

Geocoding service which converts the given street address to (latitude, longitude) coordinates.

POST /geocode


Converts the given street address to the corresponding geolocation coordinates.

SOLUTION: Geocoder 9.5

6.4.14. Personal Data

Personal Data Building Block is a service to store and manage personal data in a highly secure and structured

way

GET /data

Manages your personal data using Citizen Data Vault. Add, Get, Update, Find or Delete personal data using tags

or ID, returns the data or ID.

SOLUTION: Personal Data 1.1.3

6.4.15. GeoDB Match Heatmap

Generates a match score heatmap for the given personal preferences and favorite locations based on all

relevant data in the GeoDB.

POST /query

Creates a match score heatmap based on GeoDB data and personal preferences.

SOLUTION: Match Heatmap HEL 0.5

6.4.16. GeoPoll Heatmaps

This building block creates heatmap visualizations showing average of poll answers.

GET /poll_answer_heatmap

Creates a heatmap visualization for the given poll.

SOLUTION: GeoPoll Answer Heatmap 2.2

6.4.17. GeoPoll Density Heatmap

Returns heatmap visualization which shows the density of poll locations on Google Maps.

GET /poll_density_heatmap

Creates a heatmap visualization showing the density of existing poll locations

SOLUTION: GeoPoll Density Heatmap 1.1

6.4.18. Geo Areas

GeoDB area related tools.

POST /insert_areas

Insert areas from a tab separated CSV file and an associated JSON metadata file. The tab separated fields are:

polygon as WKT, name, identifier, description. All fields must be present, although others than polygon may

contain an empty string. JSON fields are name (string), description (string), data_source (string) and layer_id

(integer). If layer_id is supplied, the script will try to use an existing layer info and fail if layer with given id is not

found. Otherwise a new layer is created using the supplied name, description and data_source.

SOLUTION: GeoDB insert_areas_csv 2.0.0

POST /get_area_layers


Get a list of area layers in the database.

SOLUTION: GeoDB get_area_layers 0.0.1

POST /insert_area_layer

Insert area layer information into the database. Each inserted area must be associated to an area layer, which

indicate what the areas define, e.g. Helsinki districts or Helsinki Subdistricts.

SOLUTION: GeoDB insert_area_layer 0.0.1

6.4.19. Area datasets

Manage area datasets used in other GeoDB Building Blocks

POST /insert_area_obs

Insert a set of area observation data from a CSV file and an associated JSON metadata file.

SOLUTION: GeoDB insert_area_observations 2.0.0

6.4.20. Citizen Data Vault API

The Citizen Data Vault (CDV) is the WeLive component that allows the citizens to manage their own data in a

vault. The CDV collects the citizens profile data during the interaction with the Welive tools tools. Furthermore

the CDV provides a set of API to get the user profile data and to store and manage data generated using the

third party application (User Data). All these operations require WeLive Authorization.

6.5. DATASETS

The following list includes the names, descriptions and formats of Finnish open data sets that available in the

WeLive Platform at the moment of writing this document.

Helsinki Area Service Map – Organizations: List of organizations in Helsinki area service map data. Most

of the textual data is also included in English and Swedish. JSON,XML

Helsinki-Uusimaa's twitter topics: Twitter topics posted by Helsinki-Uusimaa during the WeLive

project. JSON

Buildings of Vantaa: This dataset provides the buildings of Vantaa in polygons. The data is in GeoJSON

-format. The coordinate system used is ETRS-GK25. JSON

Parking violations in Helsinki: This dataset provides all parking violations issued in Helsinki starting

from January 2014. CSV

Pääkaupunkiseudun Palvelukartan REST-rajapinta: The REST API offers your own web-applications

easy access to the data content of the City of Helsinki Service Map. The REST API is implemented using

principles of REST architecture. Data can be queried in JSON or XML formats. JSON, XML

Pääkaupunkiseudun ilmanlaatuindeksit 2015: Air quality data for the Helsinki city area 2015. XML

City of Helsinki Budget Information 2012-2014: This dataset provides the City of Helsinki's budget

information for the years 2012, 2013 and 2014. CSV

Helsingin kaupungin palauterajapinta: The issue reporting API is used by applications for sending

service requests to the City of Helsinki. JSON

HSL:n liityntäpysäköintipaikat: Information about public parking places in Helsinki city area. JSON

Espoon kaupungin liikennetiedotepalvelun rajapinta: API to get traffic information for city of Espoo.

XML

Buildings of Espoo: This dataset provides information on buildings in Espoo. JSON


District Map of the City of Helsinki: District Map of the City of Helsinki. Coordinates in WGS 84 (WGS

1984, EPSG:4326). KML

HSL:n asiakastyytyväisyystutkimus: Asty Web is Helsinki Region Transport's internet database, which

provides research information on passenger satisfaction in public transportation. It is possible to make

custom tables, reports and graphs from your own data selection. The data can be broken down by

municipality, mode of transport or by the respondent's gender. The Asty Web database contains

Helsinki Region Transport's year-round survey material. Every year over 50 000 passengers participate

in the survey, evaluating the quality of public transport on a scale of one to five (1 = very bad, 5 = very

good). The research is conducted on public transport on weekdays between 6:00 and 18:00.

Questionnaires are distributed to randomly selected passengers. Asty Web provides survey results

starting from 2011. The customer satisfaction data is available via REST-API. The data is returned in CSV-

format and it is accessible with the HTTP GET-method. JSON

Helsingin kaupunginmuseon aineistot: Photographs, art and objects from the collections of Helsinki

City Museum. JSON …

Helsinki Area Service Map - Services by Category: Helsinki area service map service category list and

the IDs of service points associated with each category. Main language is Finnish, but category names

are also available in English and Swedish. JSON,XML

Helsinki: Pohjoismaiset suurkaupungit: The Statistical Yearbook provides a varied, statistics-based

description of Helsinki and its residents. Many of the tables also present comparative data from the

rest of the Helsinki Metropolitan Area, the Helsinki Region and Finland as a whole. Moreover, the

yearbook contains a chapter on major cities in the rest of Scandinavia and one on the capitals of

Lithuania, Latvia and Estonia, and on the City of S:t Petersburg. The book contains 257 tables in all. The

publication is bilingual and the statistical tables have headings in English. The statistical yearbook is

provided in the form of an archived Excel-file. XLSX

Vantaan avoimet työpaikat –rajapinta: API to find open jobs in city of Vantaa. JSON

Ilmansaastepitoisuudet 2014: This dataset provides Helsinki Region Environmental Services (HSY) air

pollutant information from 2014. XML

Helsinki Area Postal Code Areas: The Helsinki metropolitan postal code areas have been produced

together in a joint effort with the cities of Helsinki, Espoo and Vantaa. The data contains precise

territorial borders and information on the postal code and place of business. The postal code territorial

borders have been produced based on the municipalities' own borders and therefore they are

compatible with the municipalities' own postal code territorial borders. The accuracy of this combined

dataset differs by municipality. This is caused by the initial data and administration procedures. This

dataset was produced 1/2015. KML

Helsinki Area Service Map – Departments: Department data from Helsinki area service map. Main

language is Finnish, but English and Swedish translations are available for most of the data. JSON,XML

Traffic Accidents in Helsinki: This dataset provides statistics on traffic Accidents in Helsinki. CSV

Eduskuntavaalit Helsingissä 2015: This dataset provides statistics on the Parliamentary elections in

Helsinki 2015. XML

School service areas of the City of Helsinki: This dataset provides public school districts in the City of

Helsinki for the school year 2015-16 in vector or MapInfo-tab format. The geographic coordinate system

is ETRS-GK25. KML

Helsingin seudun sairastavuusindeksi: This dataset provides the Helsinki region morbidity index. XML

Helsinki Area Service Map - Service Points: Service points listed in Helsinki area service map. Most of

the descriptions in the data are also available in English and Swedish. JSON,XML,CSV


Pääkaupunkiseudun energiankulutus: This dataset provides energy consumption data on the

metropolitan area's and metropolitan cities' (Helsinki, Espoo, Vantaa, Kauniainen) by sector (district

heating, oil heating, electric heating, electricity for consumption, cars, other road traffic, trains, ships,

other fuel) in 1990 and 2000-2013. XML

Helsinki Area Address Catalogue: This dataset provides the regional address book of the Helsinki

metropolitan area in a CSV file. The coordinates are provided as WGS-84 latitude and longitude as well

as geom points in ETRS-GK25 (EPSG:3879) system. CSV

Kuuden suurimman kaupungin lastensuojelun vertailu: This dataset provides a comparison of child

welfare between the six largest cities. CSV

Helsinki: Turvattomuutta kokevien osuudet peruspiireittäin 2003, 2006 ja 2009: This dataset provides

the results of the Helsinki: Safety survey by area in 2003, 2006 and 2009. XLS

Population projection in the Metropolitan Area in 2015-2024: Population by age in Helsinki

Metropolitan Area by District on 1 Jan. 1992-2014 and population projection 2015-2024. CSV

Buildings of Helsinki: This dataset provides the buildings of Helsinki in polygons. The coordinate system

used is ETRS-GK25. CSV


7. NOVI SAD ENVIRONMENT

7.1. PROCESS FOLLOWED IN NOVI SAD FOR PLATFORM POPULATION

In the city of Novi Sad, for citizens’ and stakeholders’ engagement and cooperation, the following activities were

organised: 1) surveys and 2) workshops.

1) The survey was conducted in the early phase of the project. i.e. distributed questionnaires to the

different stakeholders (citizens, companies and public administrations) by e-mail. Novi Sad launched a

survey among different stakeholders in order to know their needs and expectations about the city. It

was distributed to 116 citizens, 21 companies and 9 public administrations. In the figure below the age

structure of the survey participants is presented.

Figure 63 – Age structure of survey participants

As for the results from survey, the main outcomes are presented below:

Figure 64 – Personal digital needs of examinees - the most

common answers (in percentages)

Figure 65 – Examinees' needs for public service sectors - the most

common answers (in percentages)

The results in the Figures are presented as the percentage of examinees’ answers towards specific

topics. The survey’s results are analysed and based on that it was concluded that the stakeholders are

mostly interested in:

Health services and information

Transportation and traffic

Administration /Public services (Legal protection, family and social services, finance, taxation, real

estate)

Education and culture

Maps

Employment

19,83%

54,31%

12,93%9,48%

3,45%

Age 18-25

Age 26-33

Age 34-41

Age 42-49

Age 50-57

38,7135,48

32,2629,03

25,8116,13

11,296,456,456,45

4,84

0 20 40 60

Health services and…

Transportation…

Education

Taxes

Employment

Real estate

706767

636059

5754

444241

343433

292928

2116

127

0 20 40 60 80

Maps

Culture

Tourism

Habitation

Security

Finance and Taxing

Existence


Environment

2) After deep analysis of survey results, several workshops with smaller groups of people were organised.

During these workshops, different planned services were presented and discussed to obtain feedback,

which was used to improve the functionality. Based on the survey results people were separated in

smaller groups depending on the group of stakeholder (citizen, companies and public administration)

and each workshop focused on specific services. Taking advantage of the fact that City of Novi Sad is

participating in several international scientific and research projects, funded by the European Union,

and all of them aimed at improving the public services system in Novi Sad by introducing innovation

through the use of modern technology, the City has organized a promotional campaign entitled "Novi

Sad - Smart City”. This promotional campaign "Novi Sad - Smart City" includes the following activities

and all of them were launched in the scope of WeLive project:

Series of workshops in local communities in Novi Sad on the theme "Novi Sad - Smart City" that

bring together representatives of the tenants' councils and interested citizens, providing a platform

for their ideas, comments and suggestions to influence the development of the City, and thus the

places of their immediate residence.

Workshops for local self-government for 70 LS representatives in total from 24th to 26th August

2015 four workshops were organized for those representatives who are currently not involved in

projects, but are working on the improvement of these fields, or will get involved in the provision

of services through the new platforms, since the development of the Novi Sad Sustainable

Development Strategy is valid through 2020 is in progress and it covers topics such as good

government and smart Cities.

General public events were organized depending on the possibilities and promoted several city and

project partner websites (five being targeted minimum). Moreover, the city representative

promoted the project: Marijana Dukić Mijatović, Head of the Local Economic Development Office of

the City of Novi Sad made the statement for local TV, explaining the main aim of project is to

improve domestic administration using technologies. Moreover, the public event titled Novi Sad, a

smart city – activities and opportunities held on 2nd February 2015 at the City Assembly of Novi

Sad premises was also hosted by Mrs Dukic Mijatovic.

The objective of all workshops was to provide information, exchange of opinions and inclusion of

citizens in the projects. In addition, as several pilot projects were conducted at the mentioned

promotions, the pool of future respondents and participants was expanded. On the workshops

presented we summarized results from the survey and discussed about new ideas and proposals with

participants. Based on these discussions we have collected more inputs and based on that scenarios

and services are prepared.

7.2. INTEGRATION WITH LOCAL INFRASTRUCTURE

On the territory of Serbia are among the first to try to collect information open for a municipality. Open data

provided by the City of Novi Sad located in multiple sources. One source of open data is CKAN node used in the

CLIPS project. In addition, used web services that are in the data center PUC Informatika. Other data are

collected as part of the WeLive project housed in ODS. For easier data management, all data CVS or JSON

format. The figure shows how the data is stored in the municipality of Novi Sad. Linking data from WeLive

project m is carried out through the ODS and building blocks.


Figure 66 – Data sources in Novi Sad

In the figure 66 are represent

7.3. SERVICES, BUILDING BLOCKS, DATASETS

The users of the WeLive framework involved in the activities of the first iteration of the Novi Sad pilot will

interact with an environment that has been populated with a set of WeLive-compliant artefacts. Such artifacts

are published in the WeLive marketplace and are of three kinds: services, building blocks and datasets. The

following sub-sections provide the details about them.

7.3.1. Services

For the WeLive Pilot Phase 1, the Novi Sad task force has implemented three public service applications, namely:

Safe City Trip

Relocation Advisor

Public Procurement Transparency

Applications are available to WeLive users through the WeLive Marketplace and through the WeLive Player app.

They are actually Android apps and, thus, are available for download from the Google Play app store. For the

applications Safe City Trip and Relocation Advisor there is also web versions of applications.

The services offered within the three applications have been identified with the help of citizen during the

engagement activities executed by the Novi Sad task force during the first year of the project, which are

described in [2].

System Requirements for Safe City Trip and Relocation Advisor web applications are: Windows XP, Windows

Server 2003 and Windows Vista, Windows 7, Windows 8, Windows 8.1, and Windows 10.

Systems Requirements for Safe City Trip, Relocation Advisor, and Public Procurement Transparency support on

android smart phones support: Android 3.0., Android 4.0., Android 4.1., and Android 4.4.

The applications are described in details in the following sections.

7.3.1.1. Relocation Advisor


Relocation Advisor is both web and android service which allows citizens and business people to find an

appropriate apartment based on open data-information on public utility infrastructure in relation to their

residential purposes, citizens are able to get data about vicinity of parks, playgrounds, kindergartens, schools,

as well as traffic congestion, noise, and other information related to environment and neighborhood of their

place of interest. This information will give better insight about considered city area for living purposes.

For the web access to the service, follow the link [16]. If a user want to download the application on smart

phone, it should look for Relocation Advisor application on Google Play under WeLive project.

Figure 67 shows the window with several boxes and map of Novi Sad.

In the upper part of the screen, there are three boxes which users should fill. The first one is the street which

they would like to check. Once they found the street, the second box is asking them to be more precise of the

exact block where their building is placed. Finally, the last box is the purpose of their relocation to the

mentioned address (living, business, or other purposes; options A, B, and C respectively). Below the map of

Novi Sad with requested address, there is a scale measuring the quality of the air in that area. The button search

is marked with the blue color.

Once the button search is pressed, several options and types of information are shown in the boxes below the

map. Relocation Advisor application users get information regarding the quality of the air in the typed address

as the first option shown.

Facilities nearby the address such as pharmacies, ambulances, schools, cinemas, banks, etc. are under the

second option. There are also information about sewerage system, infrastructure of the roads, pedestrian

roads, hot water networks, electricity networks, and other information relevant for users who want to move to

specific neighbourhood. All information are available in one window and under the same umbrella of data.

The third option shows all the schools in the city of Novi Sad. To see particular school nearby the address a user

is looking for, it is enough to zoom the map and see only schools close to the requested address. By clicking on

any school shown on the map, the information about the school appear in new window (school address, phone

number, and the web site). The example of one school in Novi Sad and its information is shown Error! Reference

ource not found..

For each school in Novi Sad, it is possible to see the route from the requested address in the application to any

school. To request this option, users only need to click the button show the route which is in the window below

the map on the right from the school name and the distance shown next to the school name (blue button,

Prikaži Putanju). After requesting the route from user's street to the specific school, the map shows the route

marked with the blue color as showed in Figure 69.

The fourth option is showing the bus lines in Novi Sad. Particularly, when specific address is typed, the

application shows all the bus lines passing by around the mentioned street. They are all mentioned below the

map, as well as their routes, and the possibility to show the whole route with all bus stops. This option is valid

once the blue button next to the bus line description is pressed (Prikaži Stanice). It is shown in Figure 70.

As it could be seen in the Figure 65, blue buttons in the right bottom of the window are different bus lines and

their stops on the whole route through the city. By clicking on each stop and zooming the map, it is possible to

see exact point where the bus stop is. To zoom the map, users can use two buttons in the right bottom corner

of the map marked as + and -. The button + is to zoom map in and make it bigger, while the button - is to zoom

map out and make it smaller.


Finally, the last option is to check parking spots in nearby the requested address. This option gives input to

users in parking nearby, exact position, as well as if it is free of charge or not and if it has spots for people with

special needs. On the right side of the window under the map, as shown on the Figure 66, people can request

to see where is the parking they want to use. The little icon of parking shows up on the map after the request.

It is shown in Figure 71.

To leave the application, it is enough to press the black buttom in the upper right corner in both android and

web applications.


Figure 67 – The first window of Relocation Advisor application in both Web and Android

service

Figure 68 – Information regarding

one of schools in Novi Sad

Figure 69 – Route from requested address to

one of the schools in Novi Sad

Figure 70 – Bus stops on requested bus line

Figure 71 – Parking places nearby requested address


7.3.1.2. Safe City

Safe city trip is both web and android service that allows citizens to make optimal city trip planning based on

their specific needs. Based on the information about pollen (to be implemented), traffic congestion and quality

of surface water, they will get the optimal route to safely go by bicycle and enjoy in swimming and outdoor

activities. Furthermore, they will be able to avoid unexpected roadwork and congested streets.

For the web access to the service, follow this link [17]. If a user wants to download the application on smart

phone, it should look for Safe City Trip application on Google Play under WeLive project.

The first window appearing in both smart phones and web browser should be the starting point for using the

application. It consists of options available for users: starting and final point of the user's route, water quality,

noise, traffic, and the button requesting the mentioned route.

Figure 72 shows the window with several boxes and map of Novi Sad.

As shown in Figure 72, several options are available for users. The green arrow shows where the user should

type starting point of his/her trip. The red arrow is the final point of the trip and the user should type his final

destination in the box marked with the red arrow. In order to find the best route for his/her trip, the user should

press the blue button Nađite Putanju placed below all boxes in the window on the left. It is marked with the

black arrow in Figure 72.

Once the user decides to find its route from one place to another, the application will allow him/her to choose

between reaching the final destination by car or bicycle or on foot. After pressing the blue button Nađite

Putanju, the route is shown on the map with the blue line which is the route that the user requested. It is shown

below in Figure 73.

Other options in this application mentioned before are the water quality, noise in the city, and the traffic. Each

of them can be marked by the user on their gray buttons Kvalitet Vode, Buka, and Saobraćaj respectively. Once

the button and option is marked, the gray buttons turn to blue colour which is the sign that the user requested

some action.

If the user wants to know the quality of the water in the city, he/she needs to press Kvalitet Vode button and

the new window will show the information regarding quality of water in Novi Sad. How it looks is shown below

in Figure 74.

The window of the quality of water in Novi Sad is giving information such as temperature, color, smell, Ph value,

level of O2, etc. The window can be left easily with the button Zatvori in the right bottom corner of the window.

After that, the application will return the user to the main window where his/her route will be still available.

The second option that could be checked in Safe City Trip is noise level in Novi Sad. Noise levels are shown on

the map of Novi Sad with or without requested route from the user, as long as the button for noise is marked.

When the action is requested, the blue microphones are exposed on the map of Novi Sad as shown in Figure

75.


Figure 72 –The first window of Safe City Trip application in both web and android service

Figure 73 – The route which the

user has requested

Figure 74 – Window showing the quality of

water in Novi Sad

Figure 75 – Microphones shown on the

map presenting the noise levels in Novi

Sad

Figure 76 – Noise level in the city

of Novi Sad

Figure 77 – Traffic buttons showing the

amount of traffic in the city

Figure 78 – Information regarding traffic

in specific area in the city of Novi Sad


Once the microphones appear on the map as it pointed with the black arrow on the Figure 70, in order to see

the noise level in different parts of the city, users should click on the microphone close to the place they would

like to go or live or where they just plan to see the noise level, and the new window with the noise level

information will appear. It shows the noise in decibels (dB) and for the period of the last six months or the last

year. Once users have checked the noise level, they can easily close the window by clicking the button in the

right bottom Zatvorite, or they can just use close button on the right top. Once the window is closed, the

application is back to the map of Novi Sad and requested address or route. Figure 75 shows how the window

and information regarding noise in different parts of Novi Sad look like.

Finally, the last option for users available in Safe City Trip application is to check traffic in the city and on the

routes they would like to take. The action for finding the traffic in the city is taken by pressing the button for

traffic in the box on the left side of the map. Once the button Saobraćaj (Traffic) is pressed, the screen in Figure

77 appears.

As shown in Figure 77, there are many green and orange circles showing the level of traffic in different parts of

the city. There is one more possible circle to appear (red one) and each of them is representing the density of

the traffic and cars in the city. The red circle is showing the high density in the traffic, orange is presenting

medium density, while the green one means low density of the traffic in Novi Sad or particular area. Users can

get an insight without pressing any of the circle what is the traffic around particular areas and neighbourhoods.

However, there is also an option for users to see exactly how crowded is in the city by clicking on any circle they

are interested in. If users want to know more, information on how many cars are passing by in which streets,

and how is the traffic in general, up to dated every five minutes, they can get by clicking on specific circle on

the map. Once they do so, a window with all mentioned information appears as in Figure 78.

The first column is showing the streets covered by the circle, the second one is giving the insight about the way

traffic is running. The third one is showing the date and the last one is showing the time which is as mentioned

before up to dated every 5 minutes. For closing the window with information about the traffic, they can easily

close it by clicking the button in the right bottom Zatvorite, or they can just use close button on the right top.

Once the window is closed, the application is back to the map of Novi Sad and requested address or route.

To leave the application, it is enough to press the black buttom in the upper right corner in both android and

web applications.

7.3.1.3. Public Procurement Transparency

Public procurement transparency & Public procurement follower is the service that allows public administration

and citizens to follow Public procurement process. This service allows citizens and companies to receive clear

information about new competitions that they could apply to, accompanied with the possibility to obtain

information on companies from the same activity, the concluded agreements and similar. For public

administration persons, it will allow perceiving weaknesses and advantages of applying the Law in practice,

giving the possibility of simplifying the procedures and steps and having the initiative to amend the Law on

Public Procurement. Also, based on self-government public procurement, open data can be used for making

various studies and analysis of importance for the City.


This service is provided through the smart phone application called Public procurement transparency under the

project WeLive. If a user want to download the application on smart phone, she should look for Public

procurement transparency application on Google Play. The picture in Figure 79 shows the application's logo.

After choosing to start checking on public procurement, the user can choose between three options Public

procurement (Nabavke), Statistics (Statistika), or Information about the application (O aplikaciji). Options are

shown in Figure 80.

Since majority of users using this application are interested in looking for public procurement, the first option

to choose is public procurement (Nabavke). When choosing the option public procurement, many different

public procurement from various companies appear. The user should choose the one he/she is interested in.

The new window should look like in Figure 81.

Various companies are presented and by clicking on one of them, more information regarding the public

procurement of the company appears in the new window. Any of these companies and their public

procurement can be easily checked through this application.

Once the company has been chosen by the user, the information about public procurement of the company

shows in the new window. The following information regarding company's public procurement are shown

respectively: number of procurement, who ordered it, the date, document's name, phone number, contact

person, and place of the company, as it is shown in Figure 82.

For leaving the chosen company, the user can click on the arrow in the left top corner as shown in the figure.

The application will return the user to the page with all other companies and possibilities to choose some other

tab such as statistics or about the application. The blue arrow is presenting the button which should be pressed

in order to go back where the list of all companies are.

As mentioned before, other tabs and options are available in the application. One of them is statistics

application, which shows the user the number of public procurement in different cities in Serbia, but also in

particular parts of Serbian capital Belgrade (as it is huge area with a lot of companies and public procurements).

The window of Statistics tab should be like in Figure 83.

To leave the application, it is enough to press the black buttom in the upper right corner or just to press the

button for accessing the main many on the user's smart phone.


Figure 79 – Public procurement

transparency application logo and

first page

Figure 80 – Options available in the

application

Figure 81 – Companies' public

procurement options

Figure 82 – Information about the

company, which the user chose to get

information about

Figure 83 – Statistics


The building blocks developed for the Novi Sad pilot provide functionalities that are used by the different city

services explained in the previous section 7.3.1. The list of the building blocks currently provided inside the Novi

Sad city pilot are explained in more details below. These services are developed as REST API using NodeJS

Express Framework. Currently they are deployed locally.

7.3.2.1. Water and air quality

This service provides a report about water quality of river Danube in Novi Sad. Data about water quality are

obtained from this site ([15]).

Information about air quality are obtained from the Environmental Protection Agency site. For WeLive Project

we developed services to get data from Environmental Protection Agency site. The building block encompasses

3 methods:


Air quality for today - http://welive.nsinfo.co.rs/sepaToDay

Air qualitz for week - http://welive.nsinfo.co.rs/sepaWeek

Air quality for month - http://welive.nsinfo.co.rs/sepaMonth

7.3.2.2. Traffic analyzer

This building block returns information about traffic grabbed from service available at this URL:

http://94.247.200.39/traffic

7.3.2.3. Citizen Data Vault API

The Citizen Data Vault (CDV) is the WeLive component that allows the citizens to manage their own data in a

vault. The CDV collects the citizens profile data during the interaction with the Welive tools tools. Furthermore

the CDV provides a set of API to get the user profile data and to store and manage data generated using the

third party application (User Data). All these operations require WeLive Authorization.

7.3.3. Datasets

Novi Sad pilots will use only external datasets that are already publicly available and do not include any personal

data (at least not during the first pilot):

“Parking places”: data about Parking places in Novi Sad, provide by PUC Parking servis Novi Sad

“Schools”: all schools in Novi Sad provide by Serbian guverment

“Bus lines”: all bus lines and bus stations in Novi Sad, provide by PU gradsko saobracajno Novi Sad

“Noise”: nose report form 2014 – 2016 provide by City Administration for Environmental Protection

“Taksi stajalista”: taxi station in Novi Sad, provided by tourist organization of Novi Sad

“Bankomati”: ATMs , provided by tourist organization of Novi Sad

”PARKING ZA TURISITČKE AUTOBUSE”: parking for tourist buses, provided by tourist organization of

Novi Sad

“Fakulteti” : Registry of facultys in Novi Sad, provided by tourist organization of Novi Sad

“Pozorista”: registry of theatre in Novi Sad, provided by tourist organization of Novi Sad

“Parkinzi za bicikle”: registry of bike parking, provided by tourist organization of Novi Sad

“Policija”: polices stations in Novi Sad, provided by tourist organization of Novi Sad

“Sudovi”: courts in Novi Sad, provided by tourist organization of Novi Sad

“Poste”: post offices in Novi Sad, provided by tourist organization of Novi Sad

“Bolnice”: hospitals in Novi Sad, provided by tourist organization of Novi Sad

“Sportski centri I nautika” : sport centers in Novi Sad, provided by tourist organization of Novi Sad

“kulturni centri”: Cultural centers in Novi Sad, provided by tourist organization of Novi Sad

“Galerije”: gallerys in Novi Sad, provided by tourist organization of Novi Sad

“Parking zone TONS”: parking zones in Novi Sad, provided by tourist organization of Novi Sad

“Apotekarska ustanova Novi Sad”: registry of pharmacys

“Broj stanovnika po naselju” : population by settlements in Novi Sad

“Starosna struktura po mestima”: age structure of the population by places

“Muzeji”: Museums in Novi Sad

“Turisticka organizacija”: Touris offices in Novi Sad

http://welive.nsinfo.co.rs/sepaToDay

http://welive.nsinfo.co.rs/sepaWeek

http://welive.nsinfo.co.rs/sepaMonth

http://94.247.200.39/traffic

https://dev.welive.eu/ods/en/dataset/taksi-stajalista


8. CONCLUSIONS

In this deliverable we reported about the environments created in the four cities/region where the WeLive

project is running the first round of its pilot experimentation. Such environments were described under all

points of view. We started with recalling the common infrastructural component consisting of the centralized

instance of the WeLive framework. Then, for each of the pilot cities, we described the peculiarities of the

relevant environments both from the point of view of possible other pieces of local pieces of infrastructures

integrated into the common framework and from the point of view of the artefacts made available onto the

framework itself. Instances of such local infrastructures are the pre-existing open data and open service

catalogues available in some pilot cities/region. About artefacts, all pilot task forces described the services, the

building blocks and the actual datasets they have made available onto the framework to enable the activation

of the urban service co-creation process. We also focused on the activities that led to the creation of such

environments. By briefly recalled the engagement processes that took place in each pilot city/region, thus

establishing a link between the aforementioned artefacts and the activities that generated them.

The quantitative outcome stemming from the population activities is summed up in the Table 2:

Pilot city/region Datasets Building blocks Mobile apps

Trento 16 10 3

Bilbao 164 6 3

Helsinki-Uusimaa 31 20 3

Novi Sad 23 3 3

TOTAL 237 55 13

Table 2 – Quantitative outcome of population activities

The activities related to the population of the framework generated also other different and partially

unexpected qualitative results. In particular, the collaboration amongst the municipalities involved in the pilots

brought them to compare the relevant experiences made during the population and produced some

consideration that are very useful for the continuation of the project and for the future adoption of its results.

The first of such considerations is the suggestion of better analyzing the potential reuse of some buildings blocks

by the different cities to apply them to the apps developed in order to improve them. Then, the same concept

of reuse can be applied to the developed apps themselves. The adaptation of developed apps in order to be

deployed by other cities should be analyzed. Finally at the level of the datasets, the opportunity of reusing data

sharing them between cities should also be assessed. Overall, the population process highlighted the need to

investigate a way to share and reuse artefacts, so that, where possible, they can be easily adapted to be

exploited in other cities. About building blocks and services, in particular, it should be investigated how they

can be replicated in cities different from the original one in which they were devised, under the only

requirement that new city datasets in the same format required should be provided as input to the building

block or service. All these topics are good hints for the work to be done for the second phase of the project.


9. ABBREVIATIONS

API Application Programming Interface

BB Building Block

CKAN Comprehensive Knowledge Archive Network

CNS Cloud ‘N’Sci

CSV Comma Separated Value

DCAT Data Catalog Vocabulary

DoA Description of Action

DXF Drawing eXchange Format

EU European Union

GML Geography Markup Language

GTFS Google Transit Feed Specification

HTTP Hypertext Transfer Protocol

ICT Information and Communication Technologies

JSON JavaScript Object Notation

KML Keyhole Markup Language

KML Keyhole Markup Language

ODS Open Data Stack

PaaS Platform as a Service

POI Point Of Interest

REST Representational State Transfer

SHP Extension of the shape files

USDL Unified Service Description Language

WADL Web Application Description Language

WP Work Package

WSDL Web Service Description Language


10. REFERENCES

[1] Trentino open data portal, http://dati.trentino.it/

[2] H2020-INSO-2014, WeLive project deliverable, “D1.3 - WeLive scenarios, services and building

blocks v1 “, final version, WeLive consortium, September 2015

[3] H2020-INSO-2014, WeLive project deliverable, “D3.1 – Methodologies and validation of the

integration of the WeLive environment v1“, draft version, WeLive consortium, August 2016

[4] H2020-INSO-2014, WeLive project deliverable, “D2.1 - Report on the WeLive Open Innovation

and crowdsourcing tools v1“, final version, WeLive consortium, December 2015

[5] H2020-INSO-2014, WeLive project deliverable, “D2.3 - WeLive Open Innovation and

crowdsourcing tools v1 “, final version, WeLive consortium, December 2015

[6] H2020-INSO-2014, WeLive project deliverable, “D2.5 - Report on the Open Data and User

generated Data Layer v1 “, final version, WeLive consortium, March 2016

[7] H2020-INSO-2014, WeLive project deliverable, “D2.7 - Open Data and User generated Data

Layer v1“, final version, WeLive consortium, March 2016

[8] H2020-INSO-2014, WeLive project deliverable, “D2.9 - Report on the WeLive Open Service

Layer v1“, final version, WeLive consortium, March 2016

[9] H2020-INSO-2014, WeLive project deliverable, “D2.11 - Open Service Layer v1“, final version,

WeLive consortium, March 2016

[10] H2020-INSO-2014, WeLive project deliverable, “D2.13 - Report on the Tools and components

for personalization and transparency v1 “, final version, WeLive consortium, March 2016

[11] H2020-INSO-2014, WeLive project deliverable, “D2.15 - Tools and components for

personalization and transparency v1 “, final version, WeLive consortium, March 2016

[12] H2020-INSO-2014, WeLive project deliverable, “D3.3 – Guidelines for the integration and

population of the WeLive environment v1“, draft version, WeLive consortium, August 2016

[13]

H2020-INSO-2014, WeLive Annex I to the GA “Description of Action” (645845). WeLive – A

neW concept of pubLic administration based on citizen co-created mobile urban services,

February 2015.

[14] Online documentation of the WeLive Open Data Stack component,

https://dev.welive.eu/documentation/user-guide/ods/index.html

[15] Novi Sad Environmental Protection Agency site, http://80.93.233.118:8080/apex/f?p=406:2:0

[16] Relocation advisor app Web link, http://relocation-advisor.dev.welive.eu/account/login

[17] Safe City app Web link, http://safe-trip.dev.welive.eu/safe-trip/account/login

https://dev.welive.eu/documentation/user-guide/ods/index.html

http://80.93.233.118:8080/apex/f?p=406:2:0

http://relocation-advisor.dev.welive.eu/account/login

http://safe-trip.dev.welive.eu/safe-trip/account/login


11. COMMENTS FROM EXTERNAL REVIEWERS

11.1. TRENTO

1/12/2016

Issue Yes No Score

(1=low to 5=high) Comments

Is the architecture of the document correct?

X 5

Does the architecture of the document meet the objectives of the work done?

X 5

Does the index of the document collect precisely the tasks and issues that need

to be reported?

X 5

Is the content of the document clear and well described?

X 4 In page 22: “Bilbao’s task force has developed three services so far.” But the services listed below are 4.

Does the content of each section describe the advance done during the

task development?

X 4 In the conclusions, it would be good in my opinion, to add a comment on the importance that the four virtual environment to share (putting them to pool) building blocks and services, so that, where possible, can be easily adapted to be implemented in other cities, with the only requirement to provide as input to the BB / service, the new city datasets in the same format required.

Does the content have sufficient technical description to make clear the research and development performed?

X 4

Are all the figures and tables numerated and described?

X 5

Are the indexes correct? X 5

Is the written English correct? X 5

Main technical terms are correctly referenced?

X 5

Glossary present in the document? X 5

Giacomo Fioroni

[email protected]

Municipality of Trento


11.2. BILBAO

1/12/2016

Issue Yes No Score

(1=low to 5=high) Comments

Is the architecture of the document correct?

Yes 5

Does the architecture of the document meet the objectives of the

work done?

Yes 5

Does the index of the document collect precisely the tasks and issues

that need to be reported?

Yes 5

Is the content of the document clear and well described?

Yes 5

Does the content of each section describe the advance done during the

task development?

Yes 4 The chapter of conclusions is very summarized and it may be interesting to include consolidated information, quantitative number of building blocks, and qualitative synergies between cities.

Does the content have sufficient technical description to make clear

the research and development performed?

Yes 4 It would be useful to include the link to the technical description of the Open Data Stack to include context information about the relationship with the data portals of the cities of consortium.

Are all the figures and tables numerated and described?

Yes 5

Are the indexes correct? Yes 5

Is the written English correct? Yes 5

Main technical terms are correctly referenced?

Yes 4

Glossary present in the document? Yes 5

Josu Santacruz

[email protected]

Bilbao City Council


12. ANNEX I – ETHICAL COMPLIANCE CHECK

1) How should we take into

account the WeLive Code of

Conduct? Does our work support

the WeLive Innovation model?

Should the Welive Code of

Conduct and/or Innovation model

be developed based on our work?

(> see the WeLive Code of

Conduct)

All the activities related to the setup of the WeLive environments

has been conducted taking into account the principles of the

WeLive code of conduct. In particular, the processes for the

selection of the artefacts to be loaded onto the framework adheres

strictly to point 1 and 2 of the WeLive Code of Conduct. Point 4 is

addressed explicitly, by describing this selection process as part of

the deliverable. Users’ data within the services provided for the

population of the framework are managed fulfilling the dignity,

privacy and protection requirements stated in point 7.

About the support provided by the work described in this

deliverable to the WeLive Innovation model, it has been recalled in

the appropriate places in this document how the population of the

framework represents itself a means by which the WeLive

Innovation Model is supported and the WeLive Innovation Process

is triggered.

2) What requirements does the

new Data Protection Act sets for

our work? Consent forms? Access

to data and right to be forgotten?

Transfer to third countries?

Privacy by Design? The use of data

for public purposes? The

governance model and

responsibilities? Hackering

issues? (> see WeLive Data

protection document, the New

Data Protection Act and D8.6)

The population of the WeLive framework described in this

document took place in 2016 and, therefore, it is not subject to the

prescription of the new Data Protection Act. Of course, when the

new Data Protection Act will come into play all the artefacts

(services, building blocks and datasets) will be revised to assess

their compatibility with the new regulations.


account WeLive Terms of Use in

our development work? Should

they be developed based on what

we will do? (> see WeLive Terms

of Use and D8.6)

All the services developed for the population of the framework

force users to read and accept the WeLive Terms and Conditions

before entering the service itself. No need has been detected to

revise such Terms during the development work.


account Consent Forms, data

protection and authorizations in

our research? Is it necessary to

collect personal information?

How is our data management? (>

see the D5.3, current templates

for the Consent forms, D8.1 and

D8.6)

These questions do not apply since the work described in this

document does not focus on that kind of citizens’ engagement that

involve consent forms, collection of data and authorizations.


5) Is accuracy and precision of

WeLive personal/other data an

issue to be taken into our

development work? (> see the

D5.3)

This question does not apply since the work described in this



6) How should we make it possible

for vulnerable people to also take

part into development work? How

are the Consent forms? Are the

participating methods suitable?

How about marketing material? (>

see the D5.3)

These questions do not apply since the work described in this



7) Does the local data protection

set requirements for our work?

Does our work deal with data

transfer to third countries? Do we

need authorizations for the use of

external data? (> see local data

protection act (and after 2018 the

new Data Protection Act), D8.42

and D8.4)

Local data protection regulations impose constraints that must be

fulfilled when exposing datasets onto the WeLive framework. The

population activities presented relatively to datasets will cause un

update of the data management plan. When populating the

platform we took care of providing the right acknowledgement and

attribution to the owner or distributor of the data.

8) Is there any other issues, which

are relevant from the viewpoint of

our work? If yes, discuss the

situation with the Ethics Board

before starting the work.

No other issue.

Documents

D3.5 TRENTO, BILBAO, FINNISH REGION AND NOVI SAD ... · D3.5 – Trento, Bilbao, Finnish Region and Novi Sad Environment v1 page 7 2. INTRODUCTION The 2010 edition of the EU eGovernment