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

A neW concept of pubLic administration based on citizen co-created mobile urban services Grant Agreement: 645845

D3.5 – TRENTO, BILBAO, FINNISH REGION AND 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.

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

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

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

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

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

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

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

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

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.

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

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 (), Novi Sad (Serbia), Bilbao (), 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.

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

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.

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

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.

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

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

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

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 Digital helpdesk where submit all kind of dossier. Booking on–line of public services 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 Service or app with more info about waste recycling. Reporting about management / decorum 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

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

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

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

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

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

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

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

Figure 4 – List of street cleaning Figure 5 – Map of street cleaning Figure 6 – Search for street cleaning occurrences occurrences occurrences

Figure 7 – Schedule of cleaning for a Figure 8 – Details of a street Figure 9 – Favorite streets street cleaning occurrence

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.

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

Figure 10 – Bikes availability within Figure 11 – List of shared bike Figure 12 – Shared bike station on a shared bike station station 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).

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

Figure 14 – Bus line selector Figure 15 – Train line selector Figure 16 – Sample bus line timetable

Figure 17 – Bus stops on the city Figure 18 – Next runs at a given bus Figure 19 – Favorite lines, stops and map stop 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).

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

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

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

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

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

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

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

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

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

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.

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

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 Figure 27 – Comments in a proposal Figure 28 – Statistics of a proposal neighborhood

Figure 29 – Rating and commenting Figure 30 – Introducing a new Figure 31 – Main menu of the app a proposal request

Among its main functionalities, Bilbozkatu offers: Voting campaing publication. Campaing selection.

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

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 Figure 33 – Introduce needs or Figure 34 – Auzonet search screen functionalities things to borrow

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

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

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

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

Figure 41 – Searching by location Figure 42 – Introducing a new POI Figure 43 – Login

5.3.2. Building blocks 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.

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

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.

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

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.

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

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.

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

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

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

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.

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

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.

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

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

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

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

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

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 main features of the application are easy to access via the application 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 '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 the user out.

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

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

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

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.

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

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 main features of the application are easy to access via the application 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 '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 you have 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 the user out.

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

3,45% 9,48% 19,83% Age 18-25 12,93% Age 26-33 Age 34-41 54,31% Age 42-49 Age 50-57

Figure 63 – Age structure of survey participants

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

7 Real estate 4,84 12 Existence 16 6,45 21 Employment 6,45 28 Finance and Taxing 29 6,45 29 33 Taxes 11,29 Security 34 34 16,13 41 Habitation 42 Education 25,81 44 54 29,03 Tourism 57 59 Transportation… 32,26 60 Culture 63 35,48 67 67 Health services and… 38,71 Maps 70 0 20 40 60 0 20 40 60 80

Figure 64 – Personal digital needs of examinees - the most Figure 65 – Examinees' needs for public service sectors - the most common answers (in percentages) 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

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

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.

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

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

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

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.

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

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.

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

Figure 68 – Information regarding Figure 67 – The first window of Relocation Advisor application in both Web and Android one of schools in Novi Sad service

Figure 69 – Route from requested address to Figure 70 – Bus stops on requested bus line one of the schools in Novi Sad

Figure 71 – Parking places nearby requested address

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

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.

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

Figure 73 – The route which the Figure 72 –The first window of Safe City Trip application in both web and android service user has requested

Figure 74 – Window showing the quality of Figure 75 – Microphones shown on the Figure 76 – Noise level in the city water in Novi Sad map presenting the noise levels in Novi of Novi Sad Sad

Figure 77 – Traffic buttons showing the Figure 78 – Information regarding traffic amount of traffic in the city in specific area in the city of Novi Sad

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

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.

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

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

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

Figure 79 – Public procurement Figure 80 – Options available in the Figure 81 – Companies' public transparency application logo and application procurement options first page

Figure 82 – Information about the Figure 83 – Statistics company, which the user chose to get information about

7.3.2. Building blocks 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:

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

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

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

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.

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

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

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

10. REFERENCES

[1] Trentino open data portal, http://dati.trentino.it/ H2020-INSO-2014, WeLive project deliverable, “D1.3 - WeLive scenarios, services and building [2] blocks v1 “, final version, WeLive consortium, September 2015 H2020-INSO-2014, WeLive project deliverable, “D3.1 – Methodologies and validation of the [3] integration of the WeLive environment v1“, draft version, WeLive consortium, August 2016 H2020-INSO-2014, WeLive project deliverable, “D2.1 - Report on the WeLive Open Innovation [4] and crowdsourcing tools v1“, final version, WeLive consortium, December 2015 H2020-INSO-2014, WeLive project deliverable, “D2.3 - WeLive Open Innovation and [5] crowdsourcing tools v1 “, final version, WeLive consortium, December 2015 H2020-INSO-2014, WeLive project deliverable, “D2.5 - Report on the Open Data and User [6] generated Data Layer v1 “, final version, WeLive consortium, March 2016 H2020-INSO-2014, WeLive project deliverable, “D2.7 - Open Data and User generated Data [7] Layer v1“, final version, WeLive consortium, March 2016 H2020-INSO-2014, WeLive project deliverable, “D2.9 - Report on the WeLive Open Service [8] Layer v1“, final version, WeLive consortium, March 2016 H2020-INSO-2014, WeLive project deliverable, “D2.11 - Open Service Layer v1“, final version, [9] WeLive consortium, March 2016 H2020-INSO-2014, WeLive project deliverable, “D2.13 - Report on the Tools and components [10] for personalization and transparency v1 “, final version, WeLive consortium, March 2016 H2020-INSO-2014, WeLive project deliverable, “D2.15 - Tools and components for [11] personalization and transparency v1 “, final version, WeLive consortium, March 2016 H2020-INSO-2014, WeLive project deliverable, “D3.3 – Guidelines for the integration and [12] population of the WeLive environment v1“, draft version, WeLive consortium, August 2016 H2020-INSO-2014, WeLive Annex I to the GA “Description of Action” (645845). WeLive – A [13] neW concept of pubLic administration based on citizen co-created mobile urban services, February 2015. Online documentation of the WeLive Open Data Stack component, [14] 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

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

11. COMMENTS FROM EXTERNAL REVIEWERS 11.1. TRENTO 1/12/2016

Score Issue Yes No Comments (1=low to 5=high) Is the architecture of the document X 5 correct? Does the architecture of the document X 5 meet the objectives of the work done? Does the index of the document collect X 5 precisely the tasks and issues that need to be reported? Is the content of the document clear X 4 In page 22: “Bilbao’s task force and well described? has developed three services so far.” But the services listed below are 4. Does the content of each section X 4 In the conclusions, it would be describe the advance done during the good in my opinion, to add a task development? 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 X 4 technical description to make clear the research and development performed? Are all the figures and tables X 5 numerated and described? Are the indexes correct? X 5 Is the written English correct? X 5 Main technical terms are correctly X 5 referenced? Glossary present in the document? X 5

Giacomo Fioroni giacomo_fioroni@.trento.it Municipality of Trento

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

11.2. BILBAO 1/12/2016

Score Issue Yes No Comments (1=low to 5=high) Is the architecture of the document Yes 5 correct? Does the architecture of the Yes 5 document meet the objectives of the work done? Does the index of the document Yes 5 collect precisely the tasks and issues that need to be reported? Is the content of the document clear Yes 5 and well described? Does the content of each section Yes 4 The chapter of conclusions is describe the advance done during the very summarized and it may be task development? interesting to include consolidated information, quantitative number of building blocks, and qualitative synergies between cities. Does the content have sufficient Yes 4 It would be useful to include the technical description to make clear link to the technical description the research and development of the Open Data Stack to include performed? context information about the relationship with the data portals of the cities of consortium. Are all the figures and tables Yes 5 numerated and described? Are the indexes correct? Yes 5 Is the written English correct? Yes 5 Main technical terms are correctly Yes 4 referenced? Glossary present in the document? Yes 5

Josu Santacruz [email protected] Bilbao City Council

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

12. ANNEX I – ETHICAL COMPLIANCE CHECK

1) How should we take into All the activities related to the setup of the WeLive environments account the WeLive Code of has been conducted taking into account the principles of the Conduct? Does our work support WeLive code of conduct. In particular, the processes for the the WeLive Innovation model? selection of the artefacts to be loaded onto the framework adheres Should the Welive Code of strictly to point 1 and 2 of the WeLive Code of Conduct. Point 4 is Conduct and/or Innovation model addressed explicitly, by describing this selection process as part of be developed based on our work? the deliverable. Users’ data within the services provided for the (> see the WeLive Code of population of the framework are managed fulfilling the dignity, Conduct) 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 The population of the WeLive framework described in this new Data Protection Act sets for document took place in 2016 and, therefore, it is not subject to the our work? Consent forms? Access prescription of the new Data Protection Act. Of course, when the to data and right to be forgotten? new Data Protection Act will come into play all the artefacts Transfer to third countries? (services, building blocks and datasets) will be revised to assess Privacy by Design? The use of data their compatibility with the new regulations. for public purposes? The governance model and responsibilities? Hackering issues? (> see WeLive Data protection document, the New Data Protection Act and D8.6) 3) How should we take into All the services developed for the population of the framework account WeLive Terms of Use in force users to read and accept the WeLive Terms and Conditions our development work? Should before entering the service itself. No need has been detected to they be developed based on what revise such Terms during the development work. we will do? (> see WeLive Terms of Use and D8.6) 4) How should we take into These questions do not apply since the work described in this account Consent Forms, data document does not focus on that kind of citizens’ engagement that protection and authorizations in involve consent forms, collection of data and authorizations. 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)

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

5) Is accuracy and precision of This question does not apply since the work described in this WeLive personal/other data an document does not focus on that kind of citizens’ engagement that issue to be taken into our involve consent forms, collection of data and authorizations. development work? (> see the D5.3) 6) How should we make it possible These questions do not apply since the work described in this for vulnerable people to also take document does not focus on that kind of citizens’ engagement that part into development work? How involve consent forms, collection of data and authorizations. are the Consent forms? Are the participating methods suitable? How about marketing material? (> see the D5.3) 7) Does the local data protection Local data protection regulations impose constraints that must be set requirements for our work? fulfilled when exposing datasets onto the WeLive framework. The Does our work deal with data population activities presented relatively to datasets will cause un transfer to third countries? Do we update of the data management plan. When populating the need authorizations for the use of platform we took care of providing the right acknowledgement and external data? (> see local data attribution to the owner or distributor of the data. protection act (and after 2018 the new Data Protection Act), D8.42 and D8.4) 8) Is there any other issues, which No other issue. are relevant from the viewpoint of our work? If yes, discuss the situation with the Ethics Board before starting the work.

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