DELIVERABLE
Project Acronym: SDI4Apps
Grant Agreement number: 621129
Project Full Title: Uptake of Open Geographic Information Through Innovative
Services Based on Linked Data
D6.2 INITIAL DEPLOYMENT OF SINGLE
PILOT PLATFORMS
Revision no. 08
Authors: Anna Builo- Hoļme(Zemgale Planning Region)
Austra Irbe (Zemgale Planning Region)
Dzmitry Kozhukh (Help Service – Remote Sensing)
John O'Flaherty (The National Microelectronics Applications Centre Ltd)
Karel Charvat (Czech Centre for Science and Society)
Martin Tuchyňa (Slovak Environment Agency)
OtakarČerba (University of West Bohemia)
Pavel Vlach (University of West Bohemia)
Tomáš Kliment (e-Pro)
Zuzana Okániková (ProNatur)
Project co-funded by the European Commission within the ICT Policy Support Programme
Dissemination Level
P Public X
C Confidential, only for members of the consortium and the Commission Services
D6.1 Data Models and Platform Specifications for Single Pilots
Page 3 of 67 © SDI4Apps Consortium 2015
REVISION HISTORY
Revision Date Author Organisation Description
01 11/08/2015 Austra Irbe ZPR
Initial structure proposal
02 17/08/2015 Karel Charvat
Martin Tuchyňa
CCSS
SAZP Comments,
structural changes, additional
subchapters
03 10/09/2015 John O'Flaherty MAC
Pilot description
04 21/08/2015 Otakar Čerba
Karel Charvat
UWB
CCSS Pilot description
05 22/08/2015 Martin Tuchyňa
Tomáš Kliment
Zuzana
Okániková
SAZP
e-Pro
ProNatur
Pilot description
06 25/08/2015 Dzmitry Kozhukh
Karel Charvat
HSRS
CCSS Pilot description
07 28/08/2015 Austra Irbe
Anna Builo-
Hoļme
ZPR
ZPR Introduction, conclusions,
editorial changes
08 19/10/2015 Austra Irbe
Dzmitry Kozhukh
Karel Charvat
ZPR
HSRS
CCSS
Minor changes, corrections
Statement of originality:
This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both.
Disclaimer:
Views expressed in this document are those of the individuals, partners or the consortium and do not represent the opinion of the Community.
D6.1 Data Models and Platform Specifications for Single Pilots
Page 4 of 67 © SDI4Apps Consortium 2015
TABLE OF CONTENTS
Revision History ................................................................................................................. 3
Table of Contents .............................................................................................................. 4
List of Tables .................................................................................................................... 6
List of Figures ................................................................................................................... 7
Executive Summary ............................................................................................................ 8
1 Introduction ................................................................................................................ 9
1.1 About the project ................................................................................................... 9
1.2 About the deliverable .............................................................................................. 9
2 Easy data access – pilot 1 ............................................................................................... 11
2.1 Applications and Services ......................................................................................... 11
2.1.1 Applications .................................................................................................... 11
2.1.2 Services ......................................................................................................... 16
2.2 Cloud deployment .................................................................................................. 19
2.3 Future outlook ...................................................................................................... 19
3 Open Smart Tourist Data - Pilot 2..................................................................................... 21
3.1 Applications and Services ......................................................................................... 23
3.1.1 Applications .................................................................................................... 23
3.1.2 Services ......................................................................................................... 27
3.2 Cloud deployment .................................................................................................. 29
3.3 Future Outlook ...................................................................................................... 30
4 Open sensor network – Pilot 3 ......................................................................................... 31
4.1 Application and Services .......................................................................................... 31
4.1.1 Application ..................................................................................................... 31
4.1.2 Service .......................................................................................................... 32
4.2 Cloud deployment .................................................................................................. 38
4.3 Future outlook ...................................................................................................... 38
5 Open Land Use Map – Pilot 4 ........................................................................................... 39
5.1 Application an Services ............................................................................................ 42
5.1.1 Application ..................................................................................................... 42
5.1.2 Services ......................................................................................................... 43
5.2 Cloud deployment .................................................................................................. 45
5.3 Future outlook ...................................................................................................... 45
6 Open INSPIRE4YOUTH – Pilot 5 ........................................................................................ 47
6.1 Applications and Services ......................................................................................... 47
D6.1 Data Models and Platform Specifications for Single Pilots
Page 5 of 67 © SDI4Apps Consortium 2015
6.1.1 Applications .................................................................................................... 47
6.1.2 Services ......................................................................................................... 52
6.2 Cloud deployment .................................................................................................. 54
6.3 Future outlook ...................................................................................................... 54
7 Ecosystem Services Evaluation – Pilot 6 .............................................................................. 55
7.1 Applications and Services ......................................................................................... 56
7.1.1 Application ..................................................................................................... 57
7.1.2 Service .......................................................................................................... 61
7.2 Cloud deployment .................................................................................................. 62
7.3 Future Outlook ...................................................................................................... 62
8 Conclusion ................................................................................................................. 64
9 Annex 1 .................................................................................................................... 65
D6.1 Data Models and Platform Specifications for Single Pilots
Page 6 of 67 © SDI4Apps Consortium 2015
LIST OF TABLES
Table 1 Easy Data Access pilot ETIS service stakeholder crowdsourcing apps ...................................... 14
Table 2 Easy Data Access pilot Potential MonumentsGround Truthing Application ............................... 16
Table 3 Easy Data Access pilot service: Advanced Visualisations ..................................................... 17
Table 4 Easy Data Access pilot service: Data Harmonisation .......................................................... 17
Table 5 Easy Data Access pilot service: Integration of mobile Apps ................................................. 18
Table 6 Easy Data Access pilot service: Interoperability between local & global geospatial models .......... 18
Table 7 Easy Data Access pilot service: Linked Open Data ............................................................ 19
Table 8 SPOI basic properties ............................................................................................... 22
Table 9 Open Smart Tourist Data Application ............................................................................ 24
Table 10 Open Smart Tourist Crowdsourcing Application .............................................................. 26
Table 11 Open Smart Advertisement Application........................................................................ 27
Table 12 Open Smart Tourist Data pilot service: Relational database ............................................... 28
Table 13 Open Smart Tourist Data pilot service: No-SQL database .................................................. 29
Table 14 Open Smart Tourist Data pilot service: Map portal .......................................................... 29
Table 15 IoT discovery Application ......................................................................................... 32
Table 16 Open sensor network pilot service: IoT discovery service .................................................. 33
Table 17 Open Land Use Application ....................................................................................... 43
Table 18 Open Land Use Map pilot service: Data editor ................................................................ 44
Table 19 Open Land Use Map pilot service: WMS service – original data layers .................................... 44
Table 20 Open Land Use Map pilot service: WMS and WFS service of composite OpenLandUse Map ........... 45
Table 21 Map Composer Application ....................................................................................... 48
Table 22 Thematic Map Viewer ............................................................................................. 49
Table 23 Mobile Thematic Viewer .......................................................................................... 52
Table 24 Open INSPIRE4YOUTH pilot service – Catalogue service .................................................... 53
Table 25 Open INSPIRE4YOUTH pilot service – Visualisation services ................................................ 54
Table 26 Ecosystem Services Evaluation Application ................................................................... 61
Table 27 Ecosystems Evaluation pilot service: WMS/WCS service for Ecosystem service pilot .................. 62
D6.1 Data Models and Platform Specifications for Single Pilots
Page 7 of 67 © SDI4Apps Consortium 2015
LIST OF FIGURES
Figure 1 SPOI coverage ....................................................................................................... 22
Figure 2 SPOI data model .................................................................................................... 23
Figure 3 Sample of map client application ............................................................................... 25
Figure 4 Sense2Web platform ............................................................................................... 34
Figure 5 Registering form example ......................................................................................... 35
Figure 6 Description Lookup ................................................................................................. 35
Figure 7 Update ................................................................................................................ 36
Figure 8 Delete ................................................................................................................ 36
Figure 9 SPARQL template ................................................................................................... 37
Figure 10 Search by keyword ................................................................................................ 38
Figure 11 Objects location ................................................................................................... 38
Figure 12 LAU2 table structure ............................................................................................. 40
Figure 13 Spatial resolution of different data sets in Open Land Use Map .......................................... 40
Figure 14 Open Land Use Map example ................................................................................... 41
Figure 15 Mobile Thematic Viewer layout ................................................................................ 50
Figure 16 Mobile Thematic Viewer layout 2 .............................................................................. 51
Figure 17 Ecosystem Services evaluation pilot User App ............................................................... 55
Figure 18 Open Data Node overview ....................................................................................... 56
Figure 19 Functional areas of Ecosystem Services evaluation pilot User App ...................................... 57
Figure 20 Graphical user interface with the dataset layers used for ESE webapp ................................. 57
Figure 21 Graphical user interface of the UnifiedViews ................................................................ 58
Figure 22 Graphical user interface of the midPoint ..................................................................... 58
Figure 23 Graphical user interface of the ODN CKAN ................................................................... 59
Figure 24 Functional areas of Ecosystem Services evaluation pilot User App ...................................... 63
D6.1 Data Models and Platform Specifications for Single Pilots
Page 8 of 67 © SDI4Apps Consortium 2015
EXECUTIVE SUMMARY
D6.2 contains basic information about six pilot deployment as: description of functionalities, services and apps, cloud deployment, future outlook regarding pilot development.
D6.2 is structured in eight chapters: introduction, separate chapter for each pilot description, which is divided in several subchapters addressing different aspects of pilot deployment, and conclusion.
D6.1 Data Models and Platform Specifications for Single Pilots
Page 9 of 67 © SDI4Apps Consortium 2015
1 INTRODUCTION
1.1 About the project
The advancements of ICT technologies and shift towards Linked Open Data give opportunity and challenge for innovation based on reuse of geospatial information (GI). Never the less low-cost tools combing a user-friendly and customized data interactions are still in an early stage. Spatial data can benefit in decision making, planning and managing many aspects of socio-economic activities. Pressure is growing on different institutions and local authorities to actively reuse and share GI 1. This role is demanding in terms of technical knowledge and resources as different software components are required to develop and deploy spatial data infrastructure (SDI).
SDI4Apps creates cloud based framework with open API and aims to promote further reuse of generated solutions, experiences and digital resources for the benefit of different user groups as SMEs, experts, public bodies and citizens. Main target of SDI4Apps is to reduce the gap between SDI experts and micro SMEs and individuals developing applications (apps) based on GI. Provided solutions relieve possibility to collect, store and - what is most important- share different data supporting easy discovery and accessibility of spatial data. SDI4Apps goal is to ensure positive interaction between INSPIRE and various voluntary initiatives as well as to promote building of a successful business on the basis of European SDIs.
1.2 About the deliverable
The WP6 “Internal Pilot Applications” is devoted to SDI4Apps framework and tools evaluation using pilot deployment and demonstrations. To validate solutions created by SDI4Apps six pilots are used:
1. Easy Data Access, 2. Open Smart Tourist Data, 3. Open Sensor Network, 4. Open Land Use Map Through VGI, 5. Open INSPIRE4Youth, 6. Ecosystem services evaluation.
Pilot Scenarios and Use Cases are rather diverse and cover various sectors as tourism, land management, environment, agriculture, education and research. Involving very different stakeholders, using different data and functionalities pilots represent the diverse possible use of SDI4Apps Cloud platform and created Open API. Pilots are basis for validation of the platform usability and usefulness, demonstrations and testing of SDI4Apps created Cloud Platform. According to Deliverable 8.3 Definition of Promotion Campaign Pilots can also be seen as tool for dissemination activities to reach different target groups, such as:
1. Tourist SME’s, 2. Urban and regional development agencies/institutions, 3. Public administrations, 4. Scientists, 5. IGOs/INGOS/NGOs/National governments, 6. Public agencies concerned, related or affected in any issue surrounding aggregation, processing and
analysis of spatial and tourist data in the context of the regional development, 7. Developers, 8. Society in general, 9. Specific target groups identified by each pilot developers.
There are the following four deliverables in WP6:
1 “Development of a Mobile Mapping Solutions for Spatial Data Collection Using Open Source Technologies”, de Abreu Freire, C., E., Painho, M. Procedia Technology, 2014, available at http://www.sciencedirect.com/science/article/pii/S2212017314003429
D6.1 Data Models and Platform Specifications for Single Pilots
Page 10 of 67 © SDI4Apps Consortium 2015
D6.1 Data Models and Platform Specifications for Single Pilots due June 2015. Report describes components and data models of each pilot.
D6.2 Initial Deployment of Single Pilot Platforms due October 2015 - the current deliverable. Main result of this deliverable is deployed Pilot Platforms.
D6.3 Progress Report and Pilot Platforms Update due March 2016. The deliverable will include description of updates regarding all pilots and pilot activities.
D6.4 Progress Report and Final Pilot Platforms Release due March 2017. The deliverable will include pilot descriptions and pilot updates.
The current D6.2 contains basic information about six pilot deployment as: description of functionalities, services and Apps, cloud deployment, future outlook regarding pilot development. D6.2 is structured in eight chapters: Introduction, separate chapter for each pilot description, which is divided in several subchapters addressing different aspects of pilot deployment, and Conclusion.
D6.1 Data Models and Platform Specifications for Single Pilots
Page 11 of 67 © SDI4Apps Consortium 2015
2 EASY DATA ACCESS – PILOT 1
The aim of the Easy Data Access pilot application is to adapt an Open API which will support easy integration of new applications with existing SDIs. The pilot, which is focused on the Burren National Park in Ireland 2 , is supporting the wider communities’ identification, reporting, and recording of tourist destinations and ground truthing of protected heritage sites datasets in collaboration with the Burren LIFE3 and SmartOpenData4 projects. The pilot will use the SDI4Apps cloud platform to enable mobile Apps and services that involve various targeted communities of users through awareness, using social media, crowd-sourcing and open map-based geospatial data.
As explained in D6.1 (Data models and platform specifications for single pilots), from initial Social Validation meetings and discussions with the various stakeholder groups in the Burren, as described in D2.2 (Social Validation Methodology), the following apps and services were identified as being potentially most beneficial to them;
1. SDI4Apps enabled European Tourism Indicator System (ETIS) Apps and Services for the Burren and European GeoParks Network, to support Tourism for Conservation
2. SDI4Apps enabled App to Ground-Truth potential Protected Heritage sites.
2.1 Applications and Services
2.1.1 Applications
From initial Social Validation meetings and discussions with the various stakeholder groups in the Burren, as described in D2.2 (Social Validation Methodology), the following apps and services were identified as being potentially most beneficial to them;
1. SDI4Apps enabled European Tourism Indicator System (ETIS) Webservice and various stakeholder crowdsourcing apps for the Burren and European GeoParks Network, to support Tourism for Conservation
SDI4Apps will enable an ETIS Webservice and Apps for the Burren and European GeoParks Network. ETIS is a new EU standard5, that is a local community led process for monitoring, managing, and enhancing the sustainability of a tourism destination. SDI4Apps will enable streamlining and enhancing the current manual system by transforming the current manual system to Linked Open Geospatial Data. The Burren Geopark has adopted the ETIS for the Sustainable Management of Destinations to monitor and measure performance, and is one of 100 destinations in Europe that are currently piloting this system. In addition, Failte Ireland, the national tourism development authority, has expressed interest in using the Geopark’s work on the ETIS as a pilot for assessing for larger-scale, national projects. The SD4Apps platform enabled apps will directly contribute to the project’s objective “To show measurable environmental, social and economic benefits of the model”, and be part of the model that can be transferred to all European GeoParks, and thus enable its long-term sustainability and exploitation by MAC.
2. SDI4Apps enabled App to Ground-Truth potential Protected Monument sites.
The SDI4Apps platform will enable the provision of an App service to mobilize a very motivated community, by enabling visitors and people interested in their local heritage, to seek out and
2As described in D6.1 3 See www.burren.ie 4www.smartopendata.eu 5 Defined as an Excel Spreadsheet dataset and PDF Guide at http://bookshop.europa.eu/en/the-european-
tourism-indicator-system-pbNB3213182/
D6.1 Data Models and Platform Specifications for Single Pilots
Page 12 of 67 © SDI4Apps Consortium 2015
ground truth6potential monument sites in the Burren National Park and beyond. Verified sightings will be added to the Irish National Monuments Database7.
Both pilot services were identified and requested through User Validation/Co-design meetings and
discussions with the GeoPark stakeholder groups, as providing the most immediate benefit/added value to
them8. So the services will be tested and ultimately validated by those groups using the services when they
are operational on the SDI4Apps platform9.
Application ID: A1.1
Name of the app: European Tourism Indicator System (ETIS) service
stakeholder crowdsourcing apps (Visitors, Residents and
Enterprises).
Application description: The SDI4Apps enabled European Tourism Indicators
System (ETIS) web service for sustainable management at
destination level, will streamline and enhance the current
manual toolkit standard, as specified DG Growth, Internal
Market, Industry, Entrepreneurship & SMEs, Sustainable
Tourism10
Application URL: Not yet defined until the service is implemented on the
SDI4Apps Platform using the SDI4Apps Enablers.
Supported functionality /
capabilities: The SDI4Apps enabled European Tourism Indicators
System (ETIS) web service will enable the Burren GeoPark
initially (and all other GeoParks subsequently) to:
1. Set up their destination with suitable indicators
and targets (by its Local Destination Coordinator
and Stakeholder Working Group).
2. Provide online data collection by each stakeholder
group (including Destination management,
Enterprise, Resident and Visitor Surveys) – this
will include automatic updating from appropriate
online source databases.
3. Review progress and results achieved to date at
their destination by Monitoring Results and
Charting Destination, Enterprises, Residents,
6 Ground truthing is the process of gathering data in the field that either complements or disputes airborne
remote sensing data collected by aerial photography, satellite sidescan radar, or infrared images
(http://www.missiongroundtruth.com/groundtruth.html), see also http://en.wikipedia.org/wiki/Ground_truth 7 Mapped at http://webgis.archaeology.ie/NationalMonuments/FlexViewer/, and which is compliant to
INSPIRE Protected Site Theme – PS v3.2 -
http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_PS_v3.0.pd 8As described in D2.2 9As discussed in D2.2. 10http://ec.europa.eu/growth/sectors/tourism/offer/sustainable/indicators/index_en.htm
D6.1 Data Models and Platform Specifications for Single Pilots
Page 13 of 67 © SDI4Apps Consortium 2015
Visitors Impressions, Spending and Time – this will
include automatic geographic visualization by
linking to appropriate Geospatial data sources.
This will enable the Stakeholder Working Group
and visualization by the various stakeholders to
provide an ongoing community “crowdsourcing
verification” that the results and data being
entered matches the perceptions of the various
stakeholders.
4. Provide benchmarking with other destinations
(e.g. other GeoParks) through each of these views
and access to their linked open datasets11.
5. The web service will be accessible on PCs, Tablets
and Smart Phones.
Related services: The services (with IDs) which are needed by the apps are
(as defined below)
S1.1 - Advanced Visualisations
S1.2 - Data Harmonisation
S1.3 - Integration of Mobile Apps.
S1.4 - Interoperability between local & global geospatial models
S1.5 - Linked Open Data
Datasets required The Datasets (with IDs) required by this app (as defined
in D6.1) are the DS1.1 – ETIS Dataset
Timeplan for the development: Will be operational in October 2015, and then
continuously improved throughout the remainder of task
T6.1 to the end of the project in March 2017
Responsibility for the
development:
Ed Keane, MAC. [email protected]
Detailed description of planned or
already carried out testing:
The planned implementation of the service on the
SDI4Apps platform using the SDI4Apps Enablers is not yet
complete.
Early demonstration in the SmartOpenData project12, has
established the basic required functionality and utility
with users.
Role of the user: Users (visitors, enterprises and residents) on the Burren
will input and use the Apps.
11 The pilot may find that the ongoing community stakeholders’ crowdsourcing verification at point 3, may not be adequate for the Geoparks Network, who may prefer to include independent 3rd party verification of the data to ensure the integrity of the ETIS benchmarking across the Geoparks. This may require another visualisation option across the destinations to verify that the data being entered is good as basically the GeoParks will be competing with each other in the GeoParks Network benchmarking exercise. 12www.smartopendata.eu
D6.1 Data Models and Platform Specifications for Single Pilots
Page 14 of 67 © SDI4Apps Consortium 2015
Role of the administrator: The Burren GeoPark Manager and her team will define
their targets and elements of the ETIS standard they
wish to use to manage their GeoPark, and then monitor
and manage the crowdsourced data coming into the
service.
Offline use: Yes Apps will use the SDI4Apps Enablers for offline data
input, but data access will need real-time online access
to the service.
Who is responsible for the
application management?
MAC
Notes and issues Graphical user interface – Standard HTML5 browser
Viewing the Burren ETIS dataset as progress charts,
and associated GI images
Table 1 Easy Data Access pilot ETIS service stakeholder crowdsourcing apps
Application ID: A1.2
Name of the app: Potential Monuments Ground Truthing Application
Application description: This App will enable visitors and people interested in their local heritage, to seek out and ground truth13 potential Monument sites in the Burren and beyond.
Application URL: Not yet defined until the service is implemented on the
SDI4Apps Platform using the SDI4Apps Enablers.
Supported functionality /
capabilities:
The Monuments Ground Truthing App will: 1. Introduce the National Monuments Service, and direct
users to browse open satellite map sources such as GoogleMaps14 and BingMaps15, to find potential archaeological sites in their chosen area (or their current locations if they are already on site). Later on, further Geographic Information sources from the Heritage Council Map Viewer, may also be included.
2. Allow the user to access a database of previous ground truthing observations, and the Heritage Council’s Map Viewer to determine if a chosen site is already recorded by the National Monuments Service as a national monument or has been previously crowd-source reported. If so the user can continue to investigate their chosen area for other potential sites.
3. Support the user on-site to ground truth a potential archaeological site. This will involve using their phone or tablet to take a number of photographs, record notes, note the geo-location using their phone’s GPS,
13Ground Truthing is a Crowdsourcing/VGI process of gathering data in the field, to either complement or dispute remotely collected data.d 14www.googlemaps.com 15www.bing.com/maps/
D6.1 Data Models and Platform Specifications for Single Pilots
Page 15 of 67 © SDI4Apps Consortium 2015
as well as their own identity. 4. The recorded information will be uploaded to a LOD
database that will be mainly CSV with the images and associated maps & GI.
5. Field Monument Advisers, National Monuments Service staff, and other experts (as well as people who may be interested in the app, such as members of the BurrenBeo Volunteers, Institute of Archaeology of Ireland, GeoPark/BFCP Team) will have access to a webservice to authenticate each crowd-sourced ground truthing observation uploaded to the LOD database. They will be able to inform and/or post further queries to the person who uploaded the observations. They will also be able to delete any defamatory, malicious or frivolous observations. All other observations, will then be visible to the general public on a map, showing the protected monuments (via the Heritage Council’s Map Viewer), the crowd-sourced ground truthing observations that are potential national monuments, as well as those that are not (to avoid people wasting their time investigating them again).
After suitable further verification by the National
Monuments Service (using the SDI4Apps enabled
webservice), the validated new monuments will also be
recorded in the National Monuments Service’s ESRI
ArcGIS Map Viewer system16.
Related services: The services (with IDs) which are needed by the apps are
(as defined below)
S1.1 - Advanced Visualisations
S1.2 - Data Harmonisation
S1.3 - Integration of Mobile Apps.
S1.4 - Interoperability between local & global geospatial models.
S1.5 - Linked Open Data.
Datasets required DS1.2 Potential Monuments Voluntary Geographic
Information Dataset, as defined in D6.1
Timeplan for the development: Will be operational in October 2015, and then
continuously improved throughout the remainder of task
T6.1 to the end of the project in March 2017
Responsibility for the
development:
Ed Keane, MAC. [email protected]
Detailed description of planned or
already carried out testing:
The planned implementation of the service on the
SDI4Apps platform using the SDI4Apps Enablers is not yet
16At http://webgis.archaeology.ie/nationalmonuments/flexviewer/.
D6.1 Data Models and Platform Specifications for Single Pilots
Page 16 of 67 © SDI4Apps Consortium 2015
complete.
Early demonstrations in the SmartOpenData project17,
have established the basic required functionality and
utility with users.
Role of the user: Will use the use App as described above.
Role of the administrator: Will use the use App as described above
Offline use: Yes, App will be used offline for data input, but not for
data access.
Who is responsible for the
application management?
MAC
Notes and issues Graphical user interface – Standard HTML5 browser.
Implementing the National Monuments VGI Ground-
Truthing process as indicated above for individual
users.
Viewing, searching, editing for the Heritage Council
and National Monuments Service staff.
Table 2 Easy Data Access pilot Potential Monuments Ground Truthing Application
2.1.2 Services
As reported in D2.2 the services from the SDI4Apps infrastructure point of view that will be necessary for
the above mentioned apps, are as follows:
Advanced visualisations
Data harmonisation
Integration of mobile apps
Interoperability between local & global geospatial models.
Linked Open Data
As discussed in D6.1 these are mapped to the SDI4Apps Enablers defined in D3.1, D3.2.1 and D3.5, to
provide the following Easy Data Access pilot service tables (from D6.1):
Service ID: S1.1
Name of the service: Advanced Visualisations
Service description: As defined in the WP3 and WP4.
Supported functionality /
capabilities:
Advanced Visualisation framework & API (of GI & non-GI
components)
Related apps: A1.1, A1.2
17www.smartopendata.eu
D6.1 Data Models and Platform Specifications for Single Pilots
Page 17 of 67 © SDI4Apps Consortium 2015
Timeplan for the development: As defined in the WP3 and WP4.
Responsibility for the development: As defined in the WP3 and WP4.
Detailed description of planned or
already carried out testing:
As defined in the WP3 and WP4.
Service run by the SDI4Apps
platform?
Yes
Notes and issues Will use the HSLayers and HSLayers NG SDi4Apps Enablers.
Table 3 Easy Data Access pilot service: Advanced Visualisations
Service ID: S1.2
Name of the service: Data Harmonisation
Service description: As defined in the WP3 and WP4.
Supported functionality /
capabilities:
Scalable GI to LOD transformation and harmonisation service, from many heterogeneous database sources, including HALE support.
Related apps: A1.1, A1.2
Timeplan for the development: As defined in the WP3 and WP4.
Responsibility for the development: As defined in the WP3 and WP4.
Detailed description of planned or
already carried out testing:
As defined in the WP3 and WP4.
Service run by the SDI4Apps
platform?
Yes
Notes and issues Will use the Sesame/D2RQ/Postgres-XL-PostGIS SDi4Apps Enablers as tabulated above.
Table 4 Easy Data Access pilot service: Data Harmonisation
Service ID: S1.3
Name of the service: Integration of Mobile Apps.
Service description: As defined in the WP3 and WP4.
Supported functionality /
capabilities:
Scalable crowdsourced/VGI real-time data collection with Open API
Related apps: A1.1, A1.2
D6.1 Data Models and Platform Specifications for Single Pilots
Page 18 of 67 © SDI4Apps Consortium 2015
Timeplan for the development: As defined in the WP3 and WP4.
Responsibility for the development: As defined in the WP3 and WP4.
Detailed description of planned or
already carried out testing:
As defined in the WP3 and WP4.
Service run by the SDI4Apps
platform?
Yes
Notes and issues Will use the SDi4Apps Enabler providing Postgres-XL clustered database with PostGIS extension, nginx web server with MapProxy caching, HAProxy load-balancer, &Apache.
Table 5 Easy Data Access pilot service: Integration of mobile Apps
Service ID: S1.4
Name of the service: Interoperability between local & global geospatial models.
Service description: As defined in the WP3 and WP4.
Supported functionality /
capabilities:
Scalable Geo‐focused Crawler for automatic collection of OGC services endpoints representing spatial content available via the deep web.
Related apps: A1.1, A1.2
Timeplan for the development: As defined in the WP3 and WP4.
Responsibility for the development: Who is responsible for the development?
Detailed description of planned or
already carried out testing:
As defined in the WP3 and WP4.
Service run by the SDI4Apps
platform?
Yes
Notes and issues Will use the SDi4Apps Enabler providing Micka metadata catalogue management system, supporting discovery of existing geospatial data and services.
Table 6 Easy Data Access pilot service: Interoperability between local & global geospatial models
Service ID: S1.5
Name of the service: Linked Open Data
Service description: As defined in the WP3 and WP4.
Supported functionality / Scalable INSPIRE GI schema to LOD transformation &
D6.1 Data Models and Platform Specifications for Single Pilots
Page 19 of 67 © SDI4Apps Consortium 2015
capabilities: harmonisation service, with persistent URIs.
Scalable RDF Triple Storage service for LD (such as
Virtuoso)
Semantic indexing infrastructure to transform GI to
LOD
Scalable MapServer and GeoServer implementation
Related apps: A1.1, A1.2
Timeplan for the development: As defined in the WP3 and WP4.
Responsibility for the development: As defined in the WP3 and WP4.
Detailed description of planned or
already carried out testing:
As defined in the WP3 and WP4.
Service run by the SDI4Apps
platform?
Yes
Notes and issues Will use the following SDi4Apps Enablers:
Geoserver
MapServer Web Map Service
Sesame triple store framework &D2RQ Platform.
Sesame/D2RQ/Postgres-XL-PostGIS
Virtuoso
Table 7 Easy Data Access pilot service: Linked Open Data
2.2 Cloud deployment
Initially deployment of the Easy Access pilot in the cloud environment is likely to require one (or at most a
few) virtual machines (VM). As usage grows the services will require the inherent static and dynamic
scalability of the Cloud platform, as their VGI/crowdsourcing will lead to increasing content and is likely to
be bursty as each targeted user group will tend to input content at similar times.
Standard VMs will be required for deployment (as discussed in D6.1)
Running the SDI4Apps Platform and Enablers (as above), running on Linux or Ubuntu Linux.
Fairly limited storage (<20GB) as the Easy Data Access pilot is not data intensive, but it will include
images, maps and other objects such as videos and audio files.
No other special requirements are envisaged at this time.
2.3 Future outlook
In the future it is foreseen that the functionality of both services will be updated based on feedback from users during the pilot. As the ETIS service is based on a standard, it is likely to be just incrementally improve. However it is expected that user feedback and requests are likely to broaden and improve the Ground-Truthing App. In both cases, their data/content models are expected to remain fairly constant.
Beyond that, MAC aims to sustain and exploit the ETIS service by targeting further GeoParks in Europe, once this project ends. So once proven by the Burren Team, with the Burren as a reference site, further GeoParks will be encouraged to implement similar activities, and provide benchmarking with other
D6.1 Data Models and Platform Specifications for Single Pilots
Page 20 of 67 © SDI4Apps Consortium 2015
destinations (e.g. other GeoParks) through each of these views and access to their linked open datasets.The pilot may find that the ongoing community stakeholders’ crowdsourcing verification, may not be adequate for the Geoparks Network, who may prefer to include independent 3rd party verification of the data to ensure the integrity of the ETIS benchmarking across the Geoparks. This may require another visualisation option across destinations to verify that the data being entered is good as basically the GeoParks will be competing with each other in the GeoParks Network benchmarking exercise.
In the short-term the benefits of the Ground-Truthing App will be increased special interest tourists visiting the Burren, and other supported sites, and greater awareness of the Irish Protected Monuments sites. For instance, the App may help Burren farmers (as well as Irish farmers generally) to determine if their farm might contain a potential National Monument Site (especially field systems) on their land. In addition, the app and process will be very educational and will probably be used by teachers and students to discover and contribute to their local heritage. For instance, it could complement the courses and practical local environmental work carried out by BurrenBeo Trust18. However beyond that MAC, aims to apply the Ground-Truthing App to further locations (both within and outside of Ireland) and other applications (such as crowdsource reporting instances in the control of Invasive Alien Species19, pollution events).
18www.burrenbeo.com 19See for instance http://ec.europa.eu/environment/nature/invasivealien/index_en.htm and http://invasivespeciesireland.com/ and
D6.1 Data Models and Platform Specifications for Single Pilots
Page 21 of 67 © SDI4Apps Consortium 2015
3 OPEN SMART TOURIST DATA - PILOT 2
Shift of paradigm of the tourist industry is in connection with collecting, sharing, spreading and propagation of information. Previous forms (personal recommendations, printed catalogues, reservation letters or phone calls) are in remission and they are replaced by electronic forms. But electronic forms are also changing. They are moving from centralized databases and big global providers to more personalized information created by local subjects of tourist industry. The main objective of this project is to support these local or regional subjects and their information management, because we believe that the combination of local and global information and systems represents the best added value for all participants of the tourist industry.
The Open Smart Tourist Data pilots will support related business subjects such as easy integration of the SDI4Apps platform into proprietary solutions (thanks to the implementation of standards), reusing and sharing of existing information resources, channels and tools. Open Smart Tourist Data will integrate users’ data, free and open global data, SDI4Apps Team’s data, crowdsourced data and social media
Data and information represents keywords of current society as well as contemporary tourism and the tourist industry. Both are major subjects of the tourist industry (participants and providers) that deal with data and information and need them mainly for communication within each group and also between both groups of tourism subjects. Data and information involve a huge number of varied items related to selection of destination or offer of services of the tourist industry. Data and information do not mean just spatial data sets, maps, web cameras, hand-outs or catalogues, but also personal information such as recommendations, comments on social media channels, published private photos or stories.
Existing solutions for the tourist industry based on information technologies (IT) are focused mainly on one component of information such as global information, local or regional data or social media and crowd-sourcing. The main problem of this approach is that various types of information are collected and managed at different levels. For example, it is possible to have a central database of roads on the European level, but it is not possible to maintain up-to-date uniform information about accommodation, services, events, etc.
On the other hand, there are local systems, which are collecting this information. These systems usually cover small regions or groups of service providers with up-to-date data, but the problem of such local information systems is their heterogeneity and usability. All users (including SMEs participating on the tourist industry and being not focused on information technologies) or such data and information are limited by their heterogeneities that cover various data models, data formats, types of information, level of detail, semantics (terminology), portrayal rules, geometry, coordinates and coordinate systems and above all the updating frequency. Travellers have their own requirements. They want to find interesting, attractive and credible information simply and fast without any difficulties.
Pilot 2 includes two main parts:
Database of Points of Interest (SPOI)
Visualization of SPOI data via HS Layers map client.
SPOI
characteristic
Description
Data amount 4 206 573 Points of Interest
Coverage Europe (45 countries) and majority of African countries (see blue areas on the map below)
D6.1 Data Models and Platform Specifications for Single Pilots
Page 22 of 67 © SDI4Apps Consortium 2015
Data sources OpenStreetMap
GeoNames.org (dumps)
Local data – documents from Posumavi region, Sicily and travel agency
Data from POI repositories (POI Plaza)
Semantic data – experimental ontologies (OWL) of UWB (ski resort, sight in Rome)
POI classification SPOI contains nine fundamental classes adopted from the data model used for data of the Waze navigation tool.
Links Several POIs are linked to DBpedia and GeoNames.org.
There are also DBpedia and GeoNames.org links to particular countries containing POIs.
The main classification of POIs is accessible through URI.
Table 8 SPOI basic properties
Figure 1 SPOI coverage
SPOI (as the main output of the Pilot 2) is the seamless and open resource of POIs that will be available for other users to download, search or use in applications and services. The data model (see Figure) of SPOI comes from review of literature, existing data (for example OpenPOIs), recommendations of W3C and OGC and user requirements. The current version of the data set has been created as a harmonized combination of selected OpenStreetMap data, experimental ontologies developed in the Section of Geomatics of the University of West Bohemia, local data provided by the Uhlava region (Czech Republic) and other data mentioned above. The transformation was realized by XSLT templates and Saxon processor. Data are stored in the Virtuoso tool as RDF triples. SPOI is published via map client and SPARQL endpoint which enables comfortable, efficient and standardized querying of data.
D6.1 Data Models and Platform Specifications for Single Pilots
Page 23 of 67 © SDI4Apps Consortium 2015
Figure 2 SPOI data model
Pilot 2 uses mainly respected and open web standards such as RDF format, SPARQL query language or several vocabularies (for example FOAF or RDFS). The data storage and SPARQL endpoint is implemented in Virtuso tool. For visualization the HS Layers NG is used.
Both application are accessible on the Internet – SPOI as SPARQL endpoint (http://ha.isaf2014.info:8890/sparql) or web page (http://gis.zcu.cz/spoi/), map client (http://ng.hslayers.org/examples/geosparql/). User can test both application and provide feedback to the authors and developers. There is also intensive communication among developers group. For example during last two months there were several important changes in SPOI data model caused by feedback from project team.
3.1 Applications and Services
3.1.1 Applications
Application ID: A2.1
Name of the app: Open Smart Tourist Data Application
D6.1 Data Models and Platform Specifications for Single Pilots
Page 24 of 67 © SDI4Apps Consortium 2015
Application description:
Application will provide useful information for tourism in the form of routes and POIs. The application will enable searching of routes based on parameters (for example type of road) and switching among POI categories.
Application URL: http://ng.hslayers.org/examples/geosparql/
Supported functionality / capabilities:
Routing
Functions of traditional map portal (zooming, panning, layer switching)
Related services: S2.1 (Relational database), S2.2 (No-SQL database), S2.3 (Map portal)
Datasets required DS2.1(SDI4Apps POIs), DS2.2 (Joint Road Data)
Timeplan for the development:
The application will be developed according to spontaneous and incremental Living Lab approach which require flexibility and continual communication with users.
Responsibility for the development:
Otakar Cerba (UWB), Jachym Kellar (UWB), Raitis Berzins (BOSC), Dmitrij Kozuch (HSRS), Karel Charvat (CCSS)
Detailed description of planned or already carried out testing:
See time plan for development.
Role of the user: User - tourist
Uses information, provides feedback
Role of the administrator:
Administrator, Manager - Data and services maintenance, Other development
Offline use: No
Who is responsible for the application management?
Administrator
Notes and issues -
Table 9 Open Smart Tourist Data Application
D6.1 Data Models and Platform Specifications for Single Pilots
Page 25 of 67 © SDI4Apps Consortium 2015
Figure 3 Sample of map client application
Application ID: A2.2
Name of the app: Open Smart Tourist Crowdsourcing
Application description: Mobile application will support automatic tracking of roads and collection of POI.
Application URL: http://portal.sdi4apps.eu/tourist-data
Supported functionality / capabilities:
Automatic tracking
Mobile displaying maps
Collection of POI including photos
D6.1 Data Models and Platform Specifications for Single Pilots
Page 26 of 67 © SDI4Apps Consortium 2015
Related services: S2.1 (Relational database), S2.2 (No-SQL database), S2.3 (Map portal)
Datasets required DS2.1(SDI4Apps POIs), DS2.2 (Joint Road Data)
Timeplan for the development:
The application will be developed according to spontaneous and incremental Living Lab approach which require flexibility and continual communication with users.
Responsibility for the development:
Premysl Vohnout (BOSC)
Detailed description of planned or already carried out testing:
Planed to make publicly available till end of 2015 year
Role of the user: User - tourist
Feedback provider
Role of the administrator: Administrator, Manager - Data and services maintenance, Other development
Offline use: Yes
Who is responsible for the application management?
Administrator
Notes and issues -
Table 10 Open Smart Tourist Crowdsourcing Application
Application ID: A2.3
Name of the app: Open Smart Advertisement
Application description: Application will allow to be embedded into Web pages of Travel Agencies, regional Agencies etc.
Application URL: Not yet publicly available
Supported functionality / capabilities:
Embed
D6.1 Data Models and Platform Specifications for Single Pilots
Page 27 of 67 © SDI4Apps Consortium 2015
Open API
Routing
Functions of traditional map portal (zooming, panning, layer switching)
Related services: S2.1 (Relational database), S2.2 (No-SQL database), S2.3 (Map portal)
Datasets required DS2.1(SDI4Apps POIs), DS2.2 (Joint Road Data)
Timeplan for the development: The application will be developed according to spontaneous and incremental Living Lab approach which require flexibility and continual communication with users.
Responsibility for the development:
Karel Charvat (CCSS)
Detailed description of planned or already carried out testing:
See time plan for development.
Role of the user: User - tourist
Feedback provider
Role of the administrator: Administrator, Manager - Data and services maintenance, Other development
Offline use: Yes
Who is responsible for the application management?
Administrator
Notes and issues -
Table 11 Open Smart Advertisement Application
3.1.2 Services
Service ID: S2.1
Name of the service: Relational database
D6.1 Data Models and Platform Specifications for Single Pilots
Page 28 of 67 © SDI4Apps Consortium 2015
Service description: A relational database storing and providing spatial data (route segments) and enabling SQL queries.
Supported functionality / capabilities: SQL queries
Interconnection to map client
Related apps: A2.1, A2.2., A2.3
Timeplan for the development: The service is developed only an implementation is necessary. It will realized to the end of 2015.
Responsibility for the development: HSRS
Detailed description of planned or already carried out testing:
There is implemented and tested MySQL database with selected datasets.
Service run by the SDI4Apps platform? Yes
Notes and issues
Table 12 Open Smart Tourist Data pilot service: Relational database
Service ID: S2.2
Name of the service: No-SQL database
Service description: A no-SQL database storing and providing RDF triples and enabling SPARQL queries.
Supported functionality / capabilities: SQL queries
Interconnection to map client
Related apps: A2.1, A2.2., A2.3
Timeplan for the development: The service is developed only an implementation is necessary. It will realized to the end of 2015.
Responsibility for the development: HSRS
Detailed description of planned or There is implemented and tested Virtuoso database with
D6.1 Data Models and Platform Specifications for Single Pilots
Page 29 of 67 © SDI4Apps Consortium 2015
already carried out testing: selected datasets (SPOI knowledge base).
Service run by the SDI4Apps platform? Yes
Notes and issues
Table 13 Open Smart Tourist Data pilot service: No-SQL database
Service ID: S2.3
Name of the service: Map portal
Service description: A service providing function of traditional map portal (zooming, panning, layer switching).
Supported functionality / capabilities: Combination of RDF data, traditional spatial data, APIs and Linked data.
Related apps: A2.1, A2.2., A2.3
Timeplan for the development: The service is developed only an implementation is necessary. It will realized to the end of 2015.
Responsibility for the development: HSRS
Detailed description of planned or already carried out testing:
The first version of map services is available and tested.
Service run by the SDI4Apps platform? Yes
Notes and issues
Table 14 Open Smart Tourist Data pilot service: Map portal
3.2 Cloud deployment
The implementation of cloud environment is still discussed. There are several possibilities how to exploit benefits of cloud solution and transfer several functionalities such as data harmonization (which is time and memory consuming) or data storage (at this point server engine Virtuoso is used).
D6.1 Data Models and Platform Specifications for Single Pilots
Page 30 of 67 © SDI4Apps Consortium 2015
3.3 Future Outlook
As the SDI4Apps project is ongoing the following actions will be carried out regarding Pilot Open Smart Tourist Data:
Extension of information resources (imported data, links, APIs)
Optimization of data model, data storage and processing
Context-based application (user will get only information related to concrete users' needs)
Re-design of the map client
Itineraries
Cartographic challenges (clustering)
Analyses & routing application
Open Smart Advertisement application.
D6.1 Data Models and Platform Specifications for Single Pilots
Page 31 of 67 © SDI4Apps Consortium 2015
4 OPEN SENSOR NETWORK – PILOT 3
Agriculture requires the collection, storage, sharing and analysis of large quantities of spatially referenced data. For this data to be effectively used, it must be transferred between different hardware, software and organisations. These data flows currently present a hurdle to uptake of precision agriculture as the multitude of data models, formats, interfaces and reference systems in use result in incompatibilities. Management of huge amounts of data is a challenge. Spatio-temporal data is increasingly collected by remote or in-situ sensors rather than by field campaigns. The wireless communications have several benefits, but also pose challenges to the data exchange reliability and power supply. Sensor calibration and deployment as well as maintenance of sensors need resources and technical skills and increase the costs of data acquisition. Both increasing the amount of data and awareness of data quality issues highlight importance that metadata are attached to sensor data.
The current implementation was focused on implementation of catalogue for sensor data. IoT Discovery from FI WARE was selected as a candidate. It is now integrated with rest of SDI4Apps services.
4.1 Application and Services
4.1.1 Application
Application ID: A3.1
Name of the app: IoT discovery
Application description:
In general IoT Discovery act as a meeting point for IoT Context Producers to register the availability of their Things and Sensor devices, and for IoT Context Consumers to discover them. IoT Discovery is using either the OMA NGSI-9 messaging protocol, or the Sense2Web API that supports Linked Open Data.
Application URL: http://147.251.253.187/s2w/
Supported functionality / capabilities:
Discovery of sensors in distributed environment and their semantic description
Related services: S3.1 (Senslog)
Datasets required PosgreSQL
Timeplan for the development:
The solution was installed and we started testing. Main testing will be during Danube Hackathon
Responsibility for the development:
Michal Kepka, Marek Splichal
Detailed description of planned or already carried out testing:
The testing already started, RESTful API and NGSI API was tested for the beginning.
Role of the user: Registering sensors, searching for sensors
Role of the administrator:
System administration
D6.1 Data Models and Platform Specifications for Single Pilots
Page 32 of 67 © SDI4Apps Consortium 2015
Offline use: No
Who is responsible for the application management?
Michal Kepka
Notes and issues
Table 15 IoT discovery Application
4.1.2 Service
Service ID: S3.1
Name of the service: IoT discovery
Service description: IoT Discovery consists of two modules: 1. NGSI-9 Server:
Server provides a repository for the storage of NGSI entities only
Allows NGSI-9 clients to: - Register context information about Sensors and Things - Discover context information using ID, attribute, attribute domain, and
entity type
NGSI-9 clients include other FIWARE GEs, such as the Data Handling GE and the Device Management GE for registration, and the IoT Broker for discovery.
2. Sense2Web Linked-data platform:
Provides a semantic repository for IoT providers to register and manage semantic descriptions (in RDF/OWL) about their "Things"; Thing can be Sensor/Actuator Devices, virtual computational elements (e.g. data aggregators), virtual representations of any Physical Entity
Provides to discover registered IoT elements using: - Retrieve descriptions in RDF - A probabilistic search mechanism that provides recommended and ranked
search results for queries that don’t provide exact matching property values
- Semantic querying via SPARQL - An association mechanism that associates Things and sensors based on
their shared attribute (e.g. temperature) and spatial proximity, which can then be queried via SPARQL
Supported functionality / capabilities:
Both modules serve as a service discovery mechanism (SDM) for IoT Descriptions. An SDM is analogous to a registry or directory, and can be seen as a "yellow pages" for IoT entities, whereby can be discovered information about the IoT entity, such as what attributes can be queried about, and metadata about those attributes which provide more detailed information about it. It also provide information on how to reach it. It allows users to discover or check what is available and know where actual context sources are, and avoid unnecessary network overload of IoT context providers, especially if the context provider have constrained resources, such as gateways, or any wireless
D6.1 Data Models and Platform Specifications for Single Pilots
Page 33 of 67 © SDI4Apps Consortium 2015
device. The platform currently supports IoT Descriptions based on the IoT-A Project20, but can be extended to support other types. A Web User interface is provided for users to create, read, update and delete (CRUD) semantically-annotated IoT Descriptions, and also link them to other Linked Open Data (LOD) resources on the Web. According to testing results, storages of NGSI-9 Server and of Sense2Web linked-data platform are not connected together. Elements stored in storage of Sense2Web module can’t be queried from API of NGSI-9 Server module and vice versa.
Related apps: A3.1
Timeplan for the development:
Solution is installed and tested
Responsibility for the development:
Michal Kepka
Detailed description of planned or already carried out testing:
Testing started
Service run by the SDI4Apps platform?
Yes
Notes and issues
Table 16 Open sensor network pilot service: IoT discovery service
NGSI-9 Server description
The NGSI-9 server allows NGSI-9 clients to register and discover descriptions about the availability their IoT entities, which are based on the NGSI context entity model.
The main components of the NGSI-9 server is the NGSI-9 handler and the NGSI-9 store. The NGSI-9 handler acts as the configuration manager. The NGSI-9 handler is responsible for handling requests based the corresponding function, and also handling the representation of the request/response based on what the client sends and expects (currently XML or JSON). The NGSI-9 store is responsible for the storage of registrations and subscriptions, and querying the store based on a client's discovery request.
According to testing results, NGSI-9 Server is not yet working properly.
Sense2Web Platform
This component addresses the discovery of IoT objects, by providing a repository for IoT Context Producers to register their IoT Things, Resources, and Devices, using semantically-annotated Descriptions based on the Internet of Things Architecture21ontology models. One of the main goals of this component is to make use of semantic annotation in order to apply formal naming and relational conventions to the description of an IoT Object, which is explicitly absent in NGSI-9/10. The component makes use of the Sense2Web IoT Linked Data Platform baseline asset, which provides a repository for the CRUD (Create, Read, Update and Delete) management of semantic IoT descriptions, that complies with the IoT-A ontology 22 models. Sense2Web can also associate different IoT object ontologies to domain data and other resources on the Web using Linked Open Data.
20http://iot-a.eu/ 21http://www.iot-a.eu/public 22http://iot.ee.surrey.ac.uk/s2w/share/ontologies/iot-a/original/
D6.1 Data Models and Platform Specifications for Single Pilots
Page 34 of 67 © SDI4Apps Consortium 2015
This component provides a set of interfaces a user can interact with. The first is a Web User Interface whereby a user can perform CRUD operations on the IoT Descriptions, and also query the IoT Descriptions as well. When registering or updating, a user can either upload an IoT Description or complete a form which is then sent to the server to be converted to RDF, and storing it in the RDF database.
The second interface is a RESTful CRUD and SPARQL interface. This interface mainly supports M2M interactions. An application can also perform CRUD operations on the IoT descriptions in the repository, and query for a particular piece of information from the descriptions using SPARQL.
The third interface allows users to query about an IoT description using keywords or templates that share the same structure as the IoT description. This type of query input is handled by the IoT Search Engine, which will search for the relevant query.
Figure 4 Sense2Web platform
Description of Web User Interface
Register
The current ontologies that are supported are the IoT-A ontologies that define a Resource, Virtual Entity and Service. Registering can be done either by uploading a description file or by completing a form. The form will not be accepted unless an ID, Name and Latitude/Longitude coordinates are at least entered. Once the form is submitted the page will return links for viewing the RDF result of the submission in various formats i.e. RDF/XML, RDF/XML-ABBREV,RDF/JSON, N3, N-TRIPLE and TURTLE.
D6.1 Data Models and Platform Specifications for Single Pilots
Page 35 of 67 © SDI4Apps Consortium 2015
Figure 5 Registering form example
Lookup
To lookup a description, the relevant repository needs to be selected i.e. Resource, Entity, Service. The ID of the description in question must then be entered.
Figure 6 Description Lookup
Update
D6.1 Data Models and Platform Specifications for Single Pilots
Page 36 of 67 © SDI4Apps Consortium 2015
The Update page is similar to the Register page with the exception that the current values for a description can be retrieved and populated into the fields by entering the ID of the description in question, and clicking on the "retrieve" button.
Figure 7 Update
Delete
To delete a description, the relevant repository needs to be selected i.e. Resource, Entity, Service. The ID of the description in question must then be entered.
Figure 8 Delete
D6.1 Data Models and Platform Specifications for Single Pilots
Page 37 of 67 © SDI4Apps Consortium 2015
Query
The platform supports SPARQL for querying IoT descriptions. When choosing a particular type of description, the respective SPARQL template is provided for a user to use and edit.
Figure 9 SPARQL template
Discover
In the case where a user does not know the description or the exact naming for its attributes that the user is looking for, the probabilistic search engine can be used to provide recommended and ranked suggestion for a description relevant to the search input. Here the user should enter a keyword for as many fields as required.
D6.1 Data Models and Platform Specifications for Single Pilots
Page 38 of 67 © SDI4Apps Consortium 2015
Figure 10 Search by keyword
Locate
A simple map application is provided to show the location of a Resource or Entity. Clicking on a particular Object will display its main properties and a link to its description. But testing shows that publishing of Objects locations is not working properly.
Figure 11 Objects location
Examples of RDF forms can be seen in Annex 1.
4.2 Cloud deployment
Regarding Open Sensor network pilot one virtual machine with Debian 8 Jessie is used for deployment, but is possible to install on any system (Linux, Windows, BSD, …) capable to run Java containers and MySQL (MariaDB).
4.3 Future outlook
In next stage interfaces will be implemented for accessing sensors data. Development of Apps will be ongoing till February 2016. Improvements and updates according to validation results will be implemented to ensure that created solution meets the needs of user.
D6.1 Data Models and Platform Specifications for Single Pilots
Page 39 of 67 © SDI4Apps Consortium 2015
5 OPEN LAND USE MAP – PILOT 4
This pilot intends to create as detailed land-use map as it is possible. Speaking about the geographic extent - it will start from Czech Republic and then it will extend to other European countries and may be with the time it will become global.
Nowadays lots of various spatial datasets related to land use are being created and becoming accessible for public on internet. To mention a couple well known: Corine Land Cover23, Urban Atlas24 . Generally we can say, that land use data is very useful and important for various planning decisions whether we look at global, regional or local levels. For most people however the local level is the most important (many more of us will be interested to check land use in locality of the house that we wish to buy than for example to check what is the difference in land use on a global level (i.e. between all EU countries) and then correlate results with some other indicator. For this reason mentioned datasets that are mostly meant to be used on a global/regional level by experts in the fields of urban planning, environmental science etc. That is the reason why it was decided to select Czech Republic as an initial area for this pilot. Such sources as digital cadastral map (map with geometries of land parcels and basic information about them from RUIAN (registry of territorial identification, addresses and real estates)) and LPIS (land parcel identification system) data are available in big part of Czech Republic. From all these mentioned sources it is possible to create quite detailed land use map that will be useful for general public.
So speaking about data sources for the map - following are used for the pilot (they more or less go from top to the bottom from spatially most detailed to the spatially least detailed):
Data sources for the pilot area:
1. Cadastral data (RUIAN) 2. LPIS data 3. Spatial data (functional areas) 4. Urban Atlas 5. Corine Land Cover.
Not on the whole territory of the republic all mentioned datasets are available (as of 31.07.2015 about 88.1% cadastral units are this way or another fully or partially available (some are vectorised from more or less up-to-date analogue map / some are newly mapped25, not all however have land use attribute filled, on the other side some have attribute type of parcel - from which land use can be derived). For the reason of this incompleteness and to some degree uncertainty - the additional data sources are needed to cover the gaps and to help identify parcel’s land use. For that reason other sources of data are also used, otherwise if everything would be mapped and have attribute land use filled there wouldn’t be need for this combinations.
Regarding technical solution - the data for the project is downloaded and stored in PostgreSQL database. The concept of the database is influenced by the huge volume of highly detailed spatial data that we are dealing with (there are about 17 000 000 parcels available in vector format for the whole country - and as vectorization/mapping of cadastral map is ongoing - this number will increase, also there are many thousands of features in other layers).
Database structure:
1. Master table 2. Child table that inherit from master table.
Taking this into account it was decided to divide the data by the LAU2 administrative units (corresponds to Czech obce - there are around 6200 of them in the country): each LAU2 table with the land use features is a separate child table that inherits from the master table that has the following structure:
23http://www.eea.europa.eu/data-and-maps/data/clc-2006-vector-data-version-3 24http://www.eea.europa.eu/data-and-maps/data/urban-atlas 25http://www.cuzk.cz/Katastr-nemovitosti/Digitalizace-a-vedeni-katastralnich-map/Digitalizace-katastralnich-map/Digitalizace-katastralnich-map.aspx
D6.1 Data Models and Platform Specifications for Single Pilots
Page 40 of 67 © SDI4Apps Consortium 2015
Figure 12 LAU2 table structure
The features inside each LAU2 table are made up based on the following rule:initially each table gets filled in with land parcels (most detailed level).In case if vector land parcels don’t exist in that given LAU2 - or don’t cover the whole LAU2 region - we go to the next level : LPIS data - and fill with it what isn’t filled with land parcels (geometrically LPIS - Cadastre) - after that , again, if not everything in LAU2 is filled with Cadastre+LPIS we go to available spatial plans and fill gaps with this data, if again some gaps left - we use Urban Atlas to fill it - if not - Corine Land Cover (this dataset is the least detailed but covers the whole Czech Republic). So in the end we have the database covering the whole pilot area - Czech Republic.
At the first following image (Figure 12)you can visually see the spatial resolution of some mentioned datasets (yellow - cadastral data, green - LPIS, orange - Urban Atlas, brown - Corine Land Cover). And at the second(Figure 14) how the composite Land Use Map will look like.
Figure 13 Spatial resolution of different data sets in Open Land Use Map
D6.1 Data Models and Platform Specifications for Single Pilots
Page 41 of 67 © SDI4Apps Consortium 2015
Figure 14 Open Land Use Map example
The same principle as for making the map geometry - also applies for defining the features’ land use. I.e. we have parcels without defined land use then we overlay them with the next most detailed dataset - LPIS, then in case if parcel lies within LPIS unit - we assign it the same land use as that LPIS unit. In case if LPIS dataset doesn’t cover that parcel we check spatial plan dataset, in case of success we assign land use from spatial plan, in case not further check with Urban Atlas and further if again not successful - with Corine Land Cover dataset.
The Land Use classification is based on Hierarchical INSPIRE Land Use Classification System (HILUCS)26as well as colour scheme for the visualization.The translation tables that are used to translate original Land Use/ Land Cover classes into HILUCS are legacy of Plan4Business project. Can be also used/modified in this project.
The project will be put on a portal where the following layers will be available for interactive map exploration:
Corine Land Cover (translated to HILUCS)
Urban Atlas (translated to HILUCS)
available Spatial Plans (translated to HILUCS): those can be subdivided into current and planned land use based on from when to when spatial plan is valid
LPIS data (translated to HILUCS)
Cadastral data (translated to HILUCS)
the abovementioned highly detailed composite Land Use Map
Basemaps (topographic and satellite).
The registered users will be able to change the land use of features - if they find mistakes. In initial version of the app - probably there will not be option to edit geometries- due to the reason that the feature with distinct land use smaller than land parcel can be hardly imagined. In future however as more and more countries will be added - this possibility to edit geometries can be implemented.
Pilot includes one main already described application - that allows browsing and editing land use map.
26http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_LU_v3.0rc2.pdf
D6.1 Data Models and Platform Specifications for Single Pilots
Page 42 of 67 © SDI4Apps Consortium 2015
5.1 Application an Services
5.1.1 Application
Application ID: A4.1
Name of the app: Open Land Use Application
Application
description:
Application will provide to general public various datasets (CLC, Urban Atlas,
available spatial plans: current and planned land use, LPIS, cadastral map...) related
to land use. On top of these sources the composite open land use map will be
created that will cover the whole area and will be as precise geometrically and
factually as possible. That map will be available for editing by users (registered users
will be able to change land use of feature if he notices error). Also the data will be
opened through either custom API or may be as a WFS service.
Application URL: Currently at http://ng.hslayers.org/examples/openlanduse/
Supported
functionality /
capabilities:
Functions of traditional map portal (zooming, panning, layer switching)
Querying features
Editing features’ attribute
Related services: WMS of the mentioned layers; WFS service of the composite map
Datasets required DS4.1 that includes mentioned datasets as cadastral map, LPIS, available spatial
plans, Urban Atlas and Corine Land Cover.
Timeplan for the
development:
The application will be developed according to spontaneous and incremental Living
Lab approach which require flexibility and continual communication with users.
Responsibility for
the development:
Otakar Cerba (UWB), Jachym Kellar (UWB), Raitis Berzins (BOSC), Dmitrij Kozuch
(HSRS), Karel Charvat (CCSS)
Detailed description
of planned or
already carried out
testing:
There were first deployment for Czech Republic, till end of the year deployment of
five other countries is expected.
Role of the user: User - general public - and experts in related fields (urban planning, environmental
D6.1 Data Models and Platform Specifications for Single Pilots
Page 43 of 67 © SDI4Apps Consortium 2015
science etc.)
Role of the
administrator:
Administrator, Manager - Data and services maintenance, Other development
Offline use: No
Who is responsible
for the application
management?
Administrator
Notes and issues -
Table 17 Open Land Use Application
The implementation of application is thought to be following. The data will be stored in PostgreSQL
database, the visualizations will be made with the help of Mapserver/Geoserver. The application interface,
basic viewing, querying and editing functionalities will be based on HS Layers NG js library.
5.1.2 Services
Service ID: S4.1
Name of the service: Data editor
Service description: The editor will allow edit data using Web and mobile interface.
Supported functionality /
capabilities:
Edit attributes
Edit objects
Add objects
Related apps: A4.1
Timeplan for the development: September 2015
Responsibility for the development: HSRS
Detailed description of planned or
already carried out testing:
Testing will start from October.
Service run by the SDI4Apps
platform?
Yes
D6.1 Data Models and Platform Specifications for Single Pilots
Page 44 of 67 © SDI4Apps Consortium 2015
Notes and issues
Table 18 Open Land Use Map pilot service: Data editor
Service ID: S4.2
Name of the service: WMS Service with source layers
Service description: WMS OGC service that will display source data layers used for Open Land Use Map generation. By that for now is meant following layers:
Cadastral data
LPIS data
Urban Atlas
Corine landcover In future is possible that there will be other data layers added such as urban plans.
Supported functionality /
capabilities:
WMS requests:
GetCapabilities
GetMap
GetLegend
GetFeatureInfo
Related apps: A4.1
Timeplan for the development: September 2015
Responsibility for the development: HSRS
Detailed description of planned or
already carried out testing:
Testing will start from October.
Service run by the SDI4Apps
platform?
Yes
Notes and issues
Table 19 Open Land Use Map pilot service: WMS service – original data layers
Service ID: S4.3
Name of the service: WFS and WMS Service with resulting OpenLandUse
Map
Service description: WFS and WMS OGC service that will display resulting OpenLandUse Map. This service will provide composite data layer that has been created by combining all available
D6.1 Data Models and Platform Specifications for Single Pilots
Page 45 of 67 © SDI4Apps Consortium 2015
data layers to achieve the most precise land use map.
Supported functionality /
capabilities:
WMS requests:
GetCapabilities
GetMap
GetLegend
GetFeatureInfo
WFS requests:
GetCapabilities
GetFeature
Related apps: A4.1
Timeplan for the development: September 2015
Responsibility for the development: HSRS
Detailed description of planned or
already carried out testing:
Testing will start from October.
Service run by the SDI4Apps
platform?
Yes
Notes and issues
Table 20 Open Land Use Map pilot service: WMS and WFS service of composite OpenLandUse Map
5.2 Cloud deployment
Open Land Use Map pilot application has been deployed, configured and tested on Debian Linux operating system, but can run on any Linux Distro, or Windows machine. It is platform independent.
5.3 Future outlook
In the future regarding Open Land use Map Pilot several actions are intended:
Getting new data sources for other countries/regions
Implementing continuous data update from used sources (i.e. cadastral map is getting updated
every day - to immediately pull these updates to our database , without losing relevant
information, that are already in the database)
D6.1 Data Models and Platform Specifications for Single Pilots
Page 46 of 67 © SDI4Apps Consortium 2015
Implementing other editing functionalities except just changing features’ attributes.
D6.1 Data Models and Platform Specifications for Single Pilots
Page 47 of 67 © SDI4Apps Consortium 2015
6 OPEN INSPIRE4YOUTH – PILOT 5
The pilot is focused on utilization of environmental data (maps) for educational and gaming purposes. The main components of the environment will be introduced - water, air, soil, forests, nature protection, climate information, landscape, waste management, forest management etc. Each component has its actual condition measured for the region. Depending on data availability this measured condition can be compared with a European standard. All this will be made available in an entertaining manner - no school textbooks.
The main user group for this Atlas are students - higher grades of elementary schools, high schools and universities. However it should be appealing also for any adult person interested in topic.
6.1 Applications and Services
6.1.1 Applications
Map Composer
The application is providing the necessary functionality for displaying geographic data on a map and then creating a map composition (a thematic map) that can contain several data layers. After the map composition is created, i.e. detailed definition and metadata of each layer of the composition along with the composition itself, it can be saved as a JSON-styled text document. Then, this document can be read and visualized by an HSLayers NG-based web application. So, the main purpose of the application is to share visualized geographic data between users.
Map Composer is currently it is able to display map layers that come from the following services/sources: WMS, WFS, WCS, KML, GeoRSS, GML, GeoJSON and SOS. A user can then combine the layers he wishes into a composition that will be saved as an .hsl file (JSON styled text document that contains all necessary definitions and metadata of each layer and composition itself). It is further intended that the user will publish the composition he has created and share it with other users. It can be done in several ways: if user sets composition to “public” it can be viewed by other users of the platform in the Thematic Atlas web-application or the user can use Embed Map utility (feature of Thematic Atlas) to generate link to insert the map window with composition into any web-page (as data object, iframe etc.).
In the context of the project the Map Composer is playing very important role as it is allowing thematic map creation. With the help of this application users can overlay data from different sources and visually explore patterns in data and relationships between different data layers. The application is intuitive enough even for users that don’t have strong background in GIS.
Application ID: A5.1
Name of the apps Map Composer
Application description Map composer is supporting preparation of MAp composition from available services
Application URL: http://portal.sdi4apps.eu/view
Supported functionality / capabilities: Discovery services, Compose services
Related services: S5.1 (Catalogue service) S5.2 (Visualisation service)
D6.1 Data Models and Platform Specifications for Single Pilots
Page 48 of 67 © SDI4Apps Consortium 2015
Datasets required Metadata catalogue
Timeplan for the development: Application is deployed
Responsibility for the development: Premysl Vohnout, Raitis Berzins
Detailed description of planned or already carried out testing:
The Apps is ready for testing
Role of the user: Prepare composition
Role of the administrator: Manage application
Offline use: No
Who is responsible for the application management?
Raitis Berzins
Notes and issues
Table 21 Map Composer Application
Thematic Map Viewer
Thematic Map Viewer is serving this purpose as well as it provides tools to search compositions in the project catalogue using different search criteria as search by text string in title/abstract, filter by keywords, search by current map extent. It is map-centred application. The map clearly dominates the screen. The second most dominant element is Composition panel. This panel contains detailed information about the current composition (composition abstract as well as detailed info (name, legend, and source) about layers that comprise the composition) as well as it allows user to search compositions saved in the project’s catalogue.
Application ID: A5.2
Name of the apps Thematic Map Viewer
Application description Thematic Map Viewer allows display prepared map composition
Application URL: Temporally on http://ng.hslayers.org/examples/compositions/
Supported functionality / capabilities: Discovery services, View services
Related services: S5.1 (Catalogue service) S5.2 (Visualisation service)
Datasets required Metadata catalogue
Timeplan for the development: Application is deployed
Responsibility for the development: Premysl Vohnout, Raitis Berzins
Detailed description of planned or already carried out testing:
App is ready for testing
D6.1 Data Models and Platform Specifications for Single Pilots
Page 49 of 67 © SDI4Apps Consortium 2015
Role of the user: Visualise and access Map information
Role of the administrator: Administration of compositions
Offline use: No
Who is responsible for the application management?
Premysl Vohnout
Notes and issues N/A
Table 22 Thematic Map Viewer
Mobile Thematic Viewer
It is mobile version of Thematic Viewer. The mobile application being developed as a part of the SDI4Apps project is a result of the HS-Layers framework and mobile specific code integration. It utilises PhoneGap framework, which packs HTML, CSS3 and JavaScript code into an installation package. Apache Cordova is the software developer uses to compile the application with PhoneGap. Because PhoneGap is based on rendering the application via web view, not the platforms UI framework, the source code does not have to be platform specific and can still benefit from the native device APIs. As the consequence of employing web views, performance and other issues may arise.
One such issue is the fact that Android devices prior to V4.4.3 KitKat uses the default Android browser to render the web view, which does not provide GPU acceleration and restricts CPU support if the application calls for GPU acceleration. This results in severe performance decrease and has to be dealt with. Subsequent Android versions use Chromium for web view rendering, which does support GPU acceleration. The Crosswalk webview plug-in for Cordova solves this issue by incorporating Chromium directly in the application package. That increases the package size by approximately 20 MB, which could be undesirable.
Another matter addressed was usage of proxy service by HS-Layers. The service could not be utilised in the application, because it is written in Python, which is unsupported by Cordova by default. Cordova instead uses domain whitelisting for various types of HTTP requests (images, stylesheets, scripts, etc.), so a simple URL may be used for search queries and JSON or image requests if whitelisted properly. HS-Layers components that make HTTP requests needed to be modified so they make a request with simple URL in the mobile version, but still serve the URL to the proxy service on desktop. A JavaScript mobile variable was defined in the index.html file of the Cordova application and a conditional statement in each component verifies if this variable is defined.
Geolocation component also needed to be rewritten to use native geolocation API via the Cordova Geolocation plug-in. This allows for usage of high precision GPS service. A GPS logging functionality was also introduced as a part of the mobile geolocation component. It employs a WebSQL database to store location information (available values are longitude, latitude, altitude, horizontal accuracy, current velocity and heading). Another storage options are also available, including local file storage or other database types. This logging functionality can be extended to display various statistics about created GPS tracks or the tracks themselves as features on the map. Displaying velocity and altitude as well as centring on the user’s current position functions as intended.
Mobile specific layout was dealt with mainly at the Dresden 2015 hackathon. A CSS stylesheet is used to redefine properties of relevant classes. The mobile toolbar is proposed to be located on the bottom of the screen and to contain only four buttons, namely Layer manager, Search, Geolocation and one specific to each example. This results in a simpler layout that is easier to use on a mobile device than the desktop layout.
D6.1 Data Models and Platform Specifications for Single Pilots
Page 50 of 67 © SDI4Apps Consortium 2015
Figure 15 Mobile Thematic Viewer layout
There are tasks that are yet to be addressed. A priority is to improve the application’s performance, which is unsatisfactory at the moment and is partly linked to WMS service rendering. Another task is to design new zoom buttons located on the right side of the screen, as the whole mobile layout will be designed for right-handed person, but a user setting to switch to left-handed layout is also a possibility. Further improving the mobile layout and testing the application on a physical device will also follow.
D6.1 Data Models and Platform Specifications for Single Pilots
Page 51 of 67 © SDI4Apps Consortium 2015
Figure 16 Mobile Thematic Viewer layout 2
Application ID: A3.1
Name of the apps Mobile Thematic Map Viewer
Application description Map Thematic Viewer is mobile version of Thematic Viewer
Application URL: Till now not publicly available, it is in testing mode, it is Smartphone Apps
Supported functionality / capabilities: Discovery services, View services
Related services: S5.1 (Catalogue service) S5.2 (Visualisation service)
Datasets required Metadata catalogue
Timeplan for the development: Application is tested
Responsibility for the development: Šimon Leitgeb, Premysl Vohnout
D6.1 Data Models and Platform Specifications for Single Pilots
Page 52 of 67 © SDI4Apps Consortium 2015
Detailed description of planned or already carried out testing:
The Apps is ready for testing
Role of the user: Visualize data in concrete location
Role of the administrator: Manage system
Offline use: No
Who is responsible for the application management?
Šimon Leitgeb, Premysl Vohnout
Notes and issues
Table 23 Mobile Thematic Viewer
6.1.2 Services
For management of Geographic Metadata Micka will be used. Micka, developed by HSRS, is used as a metadata catalogue for SDI4Apps. MICKA is a complex system for metadata management (metadata creation, editing, storing, etc.) used for building SDI or geoportal solutions. It contains tools for editing and management of metadata for spatial information, web services and other sources (documents, web sites, etc.). It includes online metadata search engine, portrayal of spatial information and download of spatial data to local computer.
MICKA fully complies with the ISO 19115 standard. It can be integrated with map applications and it is multilingual. The web catalogue service uses OGC specifications (standards).
MICKA is compatible with obligatory standards for European SDI building (INSPIRE). Therefore it is ready to be connected with other nodes of prepared networked metadata catalogues (its compatibility with pilot European geoportal is continuously being tested).
Virtuoso is an innovative industry standards compliant platform for native data, information, and knowledge management. It implements and supports a broad spectrum of query languages, data access interfaces, protocols, and data representation formats that includes: SQL, SPARQL, ODBC, JDBC, HTTP, WebDAV, XML, RDF, RDFa, and many more.
Service ID: S5.1
Name of the service: Catalogue service
Service description: Catalogue service allows search for OGC services (WMS, WFS, KML, WCS) GeJson services and map compositions
Supported functionality / capabilities: CSW
Related apps: A5.1, A5.2 A5.3
Timeplan for the development: Implemented
Responsibility for the development: Premysl Vohnout, Stepan Kafka
Detailed description of planned or already carried out testing:
The solution was commercially tested
D6.1 Data Models and Platform Specifications for Single Pilots
Page 53 of 67 © SDI4Apps Consortium 2015
Service run by the SDI4Apps platform? Yes
Use of OpenAPI functionality: basic and advanced
BAsic CSW
Notes and issues
Table 24 Open INSPIRE4YOUTH pilot service – Catalogue service
Visualisation services
Visualisation services are based on HSlayers NG engine. HSlayers NG is an online mapping library which operates in a web browser. It extends OpenLayers 3 functionality and takes some ideas from the original HSlayers library, but doesn’t use Ext3 as the frontend javascript framework and is more lightweight in general. That’s why the NG or “Next Generation” is added to its name. It is still under development and published under GNU/GPL licence version 3. HSLayers is built in a modular way which enables the modules to be freely attached and removed as far as the dependencies for each of them are satisfied. The dependency checking is done automatically.
Map: The map functionality is provided by OpenLayers3 and extended by some controls like navigation bar, scale line, attribution dialog, GPS and compass tracking etc. It supports multi-touch gestures, but the performance is highly dependent on the browser and mobile device hardware so can be a bit slower than in native applications.
Layer manager and legend: Layer manager (Figure 8) is used for listing all the map layers, displaying or hiding them and setting the transparency. The user can view layers metadata and attribution by clicking on it. A legend is fetched from the server and displayed in a separate panel for all the wms layers on the map. Grouping of layers in containers is also provided which enables a more user friendly and organized representation of layers for
OGC Web Services context parser: This is used for GetCapabilities requests to different map servers and parsing the response. It can then be used for automatic or user initiated generation of map layers only by knowing the URL to the specific OGC standardized map service.
Query tool: This generates a GetFeatureInfo request for every WMS layer on the map and displays the list of features and their attributes at the specified coordinate. For vector layers the attribute list is generated directly on client side without server interaction.
Search field: This provides a field for entering a name of a place and displaying a list of possible geographical names which begin with the phrase entered. Zooms the map to the place selected. It uses api.geonames.org service as the database, but in the future will be extended to different data sources.
Print dialog: This is used for printing the map with the users’ browser print dialogue. The printing is done completely on client side by using HTML5 canvas graphics enabling a good performance. For it to work WMS server has to be configured to have Access-Control-Allow-Origin header (CORS support).
Permalink: This provides the user with a URL which describes the current map state and view enabling the sharing and bookmarking of different map compositions. It also serves as a URL API when using HSLayers NG applications in an iframe or similar embedded environment.
Linked Open Data explorer: Eurostat explorer (Figure 9) is a demo application (module) which queries Semantic Web data sources via SPARQL endpoints. It demonstrates the feasibility of automatic query building for Eurostat report data and displaying it on a map of NUTS2 regions (specified in GeoJSON file) according to the calculated transparency ratios. On the server side it uses a Virtuoso Universal Server which is a middleware and database engine hybrid that combines the functionality of a traditional
D6.1 Data Models and Platform Specifications for Single Pilots
Page 54 of 67 © SDI4Apps Consortium 2015
RDBMS, ORDBMS, virtual database, RDF, XML, free-text, web application server and file server functionality in a single system.
Measurement tool: This provides the measurement of distances of polylines and areas of polygons in metric units.
Panoramio layer and info panel: This is used mainly for touristic purposes (Figure 10). It creates a special layer which contains the thumbnails of scenic landscape photos from user generated and open database called “Panoramio”. The photos are displayed in the place where they were taken. It uses Panoramios API, to get the most popular images in the current map extent. The number of images returned is dependent on the screen size of the users’ device.
Service ID: S5.2
Name of the service: Visualisation services
Service description: Visualisation services are basic tools for all three Apps
Supported functionality / capabilities: Discovery and visualisation
Related apps: A5.1, A5.2 A5.3
Timeplan for the development: Implemented
Responsibility for the development: Premysl Vohnout, Raitis Berzins
Detailed description of planned or already carried out testing:
The solution was tested
Service run by the SDI4Apps platform? Yes
Use of OpenAPI functionality: basic and advanced HS LAyers advanced API
Notes and issues N/A
Table 25 Open INSPIRE4YOUTH pilot service – Visualisation services
6.2 Cloud deployment
Pilot Open INSPIRE4YOUTH is using one virtual machine. It is deployed, configured and tested on Debian Linux operating system, but can run on any Linux Distro, or Windows machine. It is platform independent.
6.3 Future outlook
The main focus will be on publishing data and preparation of Map Composition with different educational content. It is planned for Danube Hackathon. In next stage VGI tools will be implemented.
D6.1 Data Models and Platform Specifications for Single Pilots
Page 55 of 67 © SDI4Apps Consortium 2015
7 ECOSYSTEM SERVICES EVALUATION – PILOT 6
Ecosystem services pilot (ESE) is focused on the development and integration of information resources on top of the SDI4Apps framework for the ecosystem evaluation with visualisation of the ecosystem services values for particular location of the interest.
ESE pilot provides user web application allowing visualisation and browsing options of individual layers
produced for ecosystem services, including overall assessment of ecosystem services value layer. In
addition to that app provides identification information related to the selected ecosystem service layer.
Application is available via following URL: http://skpilot-viewer.virt.ics.muni.cz/ol3/eng/
Figure 17 Ecosystem Services evaluation pilot User App
In order to support wider use, two language versions of the application have been prepared (English,
Slovak).
In order to support the possibility to transform, store and publish linked open data, Open Data Node
framework have been also deployed: https://cloud48b.cerit-sc.cz/about
D6.1 Data Models and Platform Specifications for Single Pilots
Page 56 of 67 © SDI4Apps Consortium 2015
Figure 18 Open Data Node overview
In order to deploy initial version of the pilot, following set of SDI4Apps functionality components have been
taken into the consideration:
Generic enablers
Specific enablers for SDI domain
Harmonisation toolset
Semantic toolset for linked data harmonisation
Analytical and modelling toolset
Visualisation toolset
There are also foreseen test activities focused on testing methodology adopted for checking both the
integration of basic cloud components with the other advanced tools such as visualization and data
management module and the interoperability of different type of data and source managed by SDI4APPs
platform.
7.1 Applications and Services
Main motivation for the development of ESE pilot application came with the effort to support the process of
assessment of the state of ecosystems and their services and demonstrate the related outcomes. Although
the concepts of ecosystem services benefits are not brand new, there have been limited amount of
examples of ecosystem services made available in connection to the spatial context. With that in mind ESE
pilot provides an example of simple web application interface offering an access to the visualisation and
simple queries against datasets created to present the particular evaluated ecosystem service on the
national level. One of the main challenges in Slovakia is availability of the relevant input data. Therefore
for the needs of this pilot, set of initial datasets have been prepared and offered via ESE pilot.
Linked open data can represent very important potential input for the ESE procedures in the near future.
At the same time any data resources generated in connection to the ecosystem services evaluation can be
made available under the open licence and with the support of the perspective tools and networks.
Therefore OpenDataPlatform have been deployed in order to explore the potential of this platform to
support harmonised open and where possible also linked data.
D6.1 Data Models and Platform Specifications for Single Pilots
Page 57 of 67 © SDI4Apps Consortium 2015
7.1.1 Application ESE webapp is composed from single web interface offering the possibility to visualise the content of the
ecosystem services layers, change their transparency and visibility as well as provide the related attribution
information on top of the OpenStreetMap layer.
Figure 19 Functional areas of Ecosystem Services evaluation pilot User App
Datasets used for the ESE webapp have been prepared and published via Geoserver machine readable interface:http://147.251.252.167:8080/geoserver/web/?wicket:bookmarkablePage=:org.geoserver.web.demo.MapPreviewPage
Figure 20 Graphical user interface with the dataset layers used for ESE webapp
In order to support semantic data harmonisation OpenDataNode framework has been deployed, allowing transformation of heterogeneous structured data resources and linking to the available third parties 5* linked data resources (http://5stardata.info/en/).
D6.1 Data Models and Platform Specifications for Single Pilots
Page 58 of 67 © SDI4Apps Consortium 2015
OpenDataNode represents the framework composed from following set of components:
UnifiedViews - ETL capabilities, both for Linked Data and tabular/relational data, to allow publishers to convert, clean, enrich and link data before publishing as Open Data (https://cloud48b.cerit-sc.cz/unifiedviews/)(Figure 21)
midPoint - ODN’s Single-Sign-On (SSO) user management, authentication and authorization systems organizations may already be using (https://cloud48b.cerit-sc.cz/midpoint/) (Figure 22)
CKAN - providing internal and external cataloguing of the resources (https://cloud48b.cerit-sc.cz/internalcatalog/) (Figure 23)
Figure 21 Graphical user interface of the UnifiedViews
Figure 22 Graphical user interface of the midPoint
D6.1 Data Models and Platform Specifications for Single Pilots
Page 59 of 67 © SDI4Apps Consortium 2015
Figure 23 Graphical user interface of the ODN CKAN
Application ID: A6.1
Name of the app: SK Pilot Ecosystem Services Evaluation
Application description: Application providing the visualisation and browsing options of individual layers produced for ecosystem services, including overall assessment of ecosystem services value layer.
Application URL: http://skpilot-viewer.virt.ics.muni.cz/ol3/eng/
D6.1 Data Models and Platform Specifications for Single Pilots
Page 60 of 67 © SDI4Apps Consortium 2015
Supported functionality / capabilities:
Visualisation toolset
Related services: S6.1 WMS/WCS service for Ecosystem service pilot
Datasets required DS6.1 Corine land cover
DS6.2 Protected sites
DS6.3 Administrative boundaries (SVM 50)
DS6.4 Livestock statistics
DS6.5 Wood (Paper pulp) production
DS6.6 Number of livestock per hectare of pasture
DS6.7 Carbon sequestration based on land types
DS6.8 Landscape quality from tourism perspective
DS6.9 Biodiversity
DS6.10 Overall assessment of ecosystem services
DS6.11 Cultural sites interesting for tourism - Castles, Chateaus, Ruins
DS6.12 Natural sites interesting for tourism - spas, thermal springs, caves, waterbodies
DS6.13 Sites of UNESCO world natural and cultural heritage
DS6.14 Tourism and recreation zones
DS6.15 Population density
Timeplan for the development:
Initial version to be operated by the month 15 and consequently updated based on the interaction with the stakeholders.
Responsibility for the development:
Martin Tuchyna (SAZP)
Zuzana Okanikova, Marek Hubáček (Pronatur)
Tomáš Kliment (E-PRO)
Detailed description of planned or already carried out testing:
Initial testing is foreseen in combination of SDI4Apps consortium members and selected stakeholders.
Role of the user: Use of the application by visualising and browsing the content. Later on contributing with the crowdsourcing data with real time integration into the app.
Role of the administrator: Maintenance and further development.
Offline use: Initial version of the app supports only online mode.
D6.1 Data Models and Platform Specifications for Single Pilots
Page 61 of 67 © SDI4Apps Consortium 2015
Who is responsible for the application management?
Martin Tuchyna (SAZP)
Zuzana Okanikova, Marek Hubáček (Pronatur)
Tomáš Kliment (E-PRO)
Notes and issues
Table 26 Ecosystem Services Evaluation Application
7.1.2 Service
Description of Service that is needed for Ecosystem Evaluation Application from the SDI4Apps infrastructure:
Service ID: S6.1
Name of the service: WMS/WCS service for Ecosystem service pilot
Service description: An OGC Web map services providing the machine readable access to the particular ecosystem services layers, including overall assessment of ecosystem services value layer.
Supported functionality / capabilities:
Visualisation, overlay
Related apps: Insert app IDs for which the service is relevant.
Timeplan for the development:
brief, realistic
Responsibility for the development:
Martin Tuchyna (SAZP) Zuzana Okanikova, Marek Hubáček (Pronatur) Tomáš Kliment (E-PRO)
Detailed description of planned or already carried out testing:
Initial version to be operated by the month 15 and consequently updated based on the interaction with the stakeholders.
Service run by the SDI4Apps platform?
Yes
Use of OpenAPI functionality: basic and advanced
Basic
Notes and issues Initial version of the web API:
D6.1 Data Models and Platform Specifications for Single Pilots
Page 62 of 67 © SDI4Apps Consortium 2015
http://147.251.252.167:8080/geoserver/sk_pilot_ess_rasters/wms
http://147.251.252.167:8080/geoserver/sk_pilot_ess_rasters/wcs
Table 27 Ecosystems Evaluation pilot service: WMS/WCS service for Ecosystem service pilot
7.2 Cloud deployment
ESS pilot has been deployed using 4(+1) virtual machines with the same technical parameters (2x CPU, 8GB memory, 100GB HDD) as follows:
Web GIS server: GeoServer open source (machine name: sdi4apps_sazp_geoserver) + planned for testing Mapserver (name: )
Web Server: Running the front end OL3 application (name: sdi4apps_sazp_ol3)
DB server: Running DBMS Postgres XL (name:sdi4apps-postgresxl) Metadata catalogue: Runnning Geonetwork opensource catalogue application
(name: smopda_sazp_geonetwork3) Open Data Node is operated on following WMs: 1.)cloud48b.cerit-sc.cz HW:
CPU: 1 x virtual procesor Intel Xeon E312xx (1-core) RAM: 8 GB STORAGE: OS - 40GB, data - 390GB
SW: Open data node (ODN) deployment, including installation of underlying components:
2 x CKAN - catalogue system ODN-Midpoint - user accounts management ODN-CAS - integrated login and authorisation ODN-SOLR - fulltext indexing Unifiedviews frontend - ETL tool - user front end Unifiedview backend - ETL tool - engine Apache HTTP server - web server PostgreSQL - DBMS Virtuoso OpenSource Edition - DBMS and triplestore slapd - OpenLDAP server
2.) cloud72b.cerit-sc.cz HW:
CPU: 1 x virtual processor Intel Xeon E312xx (1-core) RAM: 3 GB STORAGE: OS - 10GB, data - 10GB
SW: Standalone Parliament Triplestore deployment.
7.3 Future Outlook
For the upcoming period focus for other relevant data will be extended as from relevant and available
resources made available by project partners, as well as from international resources (INSPIRE, GEOSS,
Copernicus) including the crowdsourcing resources. Closer alignment with other SDI4Apps framework
D6.1 Data Models and Platform Specifications for Single Pilots
Page 63 of 67 © SDI4Apps Consortium 2015
enablers’ functionality is foreseen, utilising the dedicated events like the DanubeHack event foreseen to
take place in mid of October 201527.
Figure 24 Functional areas of Ecosystem Services evaluation pilot User App
27http://www.danubehack.eu
D6.1 Data Models and Platform Specifications for Single Pilots
Page 64 of 67 © SDI4Apps Consortium 2015
8 CONCLUSION
Pilot development has already started during first year of the project and has been ongoing continuously
with aim to show possible benefits of SDI4Apps platform use. At this stage of project in six pilots’
altogether ten SDI4Apps framework demonstration applications have been deployed:
European Tourism Indicator System (ETIS) service stakeholder crowdsourcing
Potential Monuments Ground Truthing
Open Smart Tourist Data
Open Smart Tourist Crowdsourcing
Open Smart Advertisement
IoT discovery
Open Land Use
Map Composer
Thematic Map Viewer
Ecosystem Services Evaluation.
During second year of the SDI4Apps project main functionalities, services and basic data sets have been
prepared to give rise for future development, end user involvement and Pilot improvement. Due some
challenges of deployment not all applications are available for external use. Faced difficulties will be
solved in close cooperation between Pilot developers and SDI4Apps Platform developers. The part of Apps is
already publicly available through portal.sdi4apps.eu http://sdi4apps.eu/spoi/ or have its own Web pages.
The results are now moved on SDI4App cloud.
In future development of project all created Pilot Applications will be tested by internal and external users
as discussed in D.2.2. Overall Pilots are ready for Internal Validation that will be focused on pilot usability
by end users and External Validation that will be focused on usability of APIs for external users.
D6.1 Data Models and Platform Specifications for Single Pilots
Page 65 of 67 © SDI4Apps Consortium 2015
9 ANNEX 1
Examples of RDF forms
Entity example
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:j.0="http://www.surrey.ac.uk/ccsr/ontologies/VirtualEntityModel.owl#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#" >
<rdf:Description rdf:about="http://www.surrey.ac.uk/ccsr/ontologies/VirtualEntityModel.owl#UNIS-TEST-02">
<rdf:type rdf:resource="http://www.surrey.ac.uk/ccsr/ontologies/VirtualEntityModel.owl#VirtualEntity"/>
<j.0:metadataType rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:metadataType>
<j.0:hasStartDate rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:hasStartDate>
<j.0:hasType rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Room</j.0:hasType>
<j.0:metadataValue rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:metadataValue>
<j.0:value rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:value>
<j.0:isAssociatedToService rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:isAssociatedToService>
<j.0:isMobile rdf:datatype="http://www.w3.org/2001/XMLSchema#string">No</j.0:isMobile>
<j.0:hasGlobalIdentifier rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:hasGlobalIdentifier>
<j.0:hasEndTime rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:hasEndTime>
<j.0:hasLocalIdentifier rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:hasLocalIdentifier>
<j.0:hasLocalLocation rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:hasLocalLocation>
<j.0:hasLatitude rdf:datatype="http://www.w3.org/2001/XMLSchema#string">49</j.0:hasLatitude>
<j.0:hasAltitude rdf:datatype="http://www.w3.org/2001/XMLSchema#string">0</j.0:hasAltitude>
<j.0:hasStartTime rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:hasStartTime>
<j.0:hasOwner rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:hasOwner>
<j.0:hasAttributeName rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:hasAttributeName>
<j.0:hasEndDate rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:hasEndDate>
D6.1 Data Models and Platform Specifications for Single Pilots
Page 66 of 67 © SDI4Apps Consortium 2015
<j.0:hasLongitude rdf:datatype="http://www.w3.org/2001/XMLSchema#string">14</j.0:hasLongitude>
<j.0:hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Room 02</j.0:hasName>
<j.0:hasGlobalLocation rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:hasGlobalLocation>
<j.0:hasAttributeType rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:hasAttributeType>
</rdf:Description>
</rdf:RDF>
Resource example
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:j.0="http://www.surrey.ac.uk/ccsr/ontologies/ResourceModel.owl#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#" >
<rdf:Description rdf:about="http://www.surrey.ac.uk/ccsr/ontologies/ResourceModel.owl#SC-TEST-01">
<j.0:isExposedThroughService rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:isExposedThroughService>
<j.0:hasAltitude rdf:datatype="http://www.w3.org/2001/XMLSchema#string">348.550140</j.0:hasAltitude>
<j.0:hasLongitude rdf:datatype="http://www.w3.org/2001/XMLSchema#string">13.352194</j.0:hasLongitude>
<j.0:hasType rdf:datatype="http://www.w3.org/2001/XMLSchema#string">http://www.surrey.ac.uk/ccsr/ontologies/ResourceModel.owl#Sensor</j.0:hasType>
<j.0:isHostedOn rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:isHostedOn>
<j.0:hasGlobalLocation rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:hasGlobalLocation>
<j.0:hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string">SC Temperature</j.0:hasName>
<j.0:hasLocalLocation rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></j.0:hasLocalLocation>
<j.0:hasTimeOffset rdf:datatype="http://www.w3.org/2001/XMLSchema#string">CET</j.0:hasTimeOffset>
<rdf:type rdf:resource="http://www.surrey.ac.uk/ccsr/ontologies/ResourceModel.owl#OnDeviceResource"/>
<j.0:hasTag rdf:datatype="http://www.w3.org/2001/XMLSchema#string">temperature</j.0:hasTag>
<j.0:hasLatitude rdf:datatype="http://www.w3.org/2001/XMLSchema#string">49.725442</j.0:hasLatitude>
</rdf:Description>
</rdf:RDF>
Service example
D6.1 Data Models and Platform Specifications for Single Pilots
Page 67 of 67 © SDI4Apps Consortium 2015
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:j.0="http://www.surrey.ac.uk/ccsr/ontologies/ServiceModel.owl#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#" >
<rdf:Description rdf:about="http://www.surrey.ac.uk/ccsr/ontologies/ServiceModel.owl#test-service-01">
<j.0:hasLongitude rdf:datatype="http://www.w3.org/2001/XMLSchema#string">13.351754</j.0:hasLongitude>
<j.0:hasType rdf:datatype="http://www.w3.org/2001/XMLSchema#string">http://www.surrey.ac.uk/ccsr/ontologies/ServiceModel.owl#RestfulServiceEndpoint</j.0:hasType>
<j.0:supportsMethod rdf:datatype="http://www.w3.org/2001/XMLSchema#string">http://www.surrey.ac.uk/ccsr/ontologies/ServiceModel.owl#Create</j.0:supportsMethod>
<j.0:hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Temperature service</j.0:hasName>
<j.0:hasAltitude rdf:datatype="http://www.w3.org/2001/XMLSchema#string">350.729156</j.0:hasAltitude>
<j.0:hasOutput rdf:datatype="http://www.w3.org/2001/XMLSchema#string">http://testserver.com/output</j.0:hasOutput>
<j.0:endpointPort rdf:datatype="http://www.w3.org/2001/XMLSchema#string">8080</j.0:endpointPort>
<j.0:endpointProtocol rdf:datatype="http://www.w3.org/2001/XMLSchema#string">http</j.0:endpointProtocol>
<j.0:hasLatitude rdf:datatype="http://www.w3.org/2001/XMLSchema#string">49.725275</j.0:hasLatitude>
<j.0:endpointPath rdf:datatype="http://www.w3.org/2001/XMLSchema#string">testserver/sensor/temperature</j.0:endpointPath>
</rdf:Description>
</rdf:RDF>