D1 4 System Architecture v1 - i-locate · 2014-07-01 · i-locate - Indoor/outdoor LOCation and...

i-locate - Indoor/outdoor LOCation and Asset management Through open gEodata (GA 621040)

File: D1 4_System_Architecture.docx D1.4

Page: 1 of 134 System Architecture

COVER PAGE

DELIVERABLE

Project Acronym: i-locate

Grant Agreement number: 621040

Project Title: Indoor/outdoor LOCation and Asset management Through open gEodata

D1.4 – System Architecture

Revision: [Final]

Authors:

Anestis Trypitsidis (EPSGR), Alkis Astyakopoulos (EPSGR), Giuseppe Conti (TRILOGIS), Martino

Salvetti (TRILOGIS), Massimo Barozzi (TRILOGIS), Leonardo Plotegher (TRILOGIS), Nicola

Dorigatti (TRILOGIS), Stefano Piffer (TRILOGIS), Theo Arentze (TU/e), Ion Barosan (TU/e), Sorin

Pop (Fida), Daniele Miorandi (u-Hopper), Iacopo Carreras (u-Hopper), Lucian Brancovean

(INDSOFT), Erik Mademann (ZIGPOS), Scott Cadzow, Claudio Eccher (FBK), Simona Anzivino

(FBK), Elisa Morganti (FBK)

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




REVISION HISTORY AND STATEMENT OF ORIGINALITY

Revision History

Revision Date Author Organisation Description v1.0 4/4/2014 Anestis Trypitsidis EPSGR Structure of the document

4/5/2014 Ion Barosan TU/e Routing - Proposal

5/5/2014 Daniele Miorandi u-Hopper Middleware Layer - Structure

5/5/2014 Lucian Brancovean INDSOFT Portal & Conversion Tool

15/5/2014 Scott Cadzow C3L Security Layer

15/5/2014 Erik Mademann ZIGPOS Middleware layer - Comments

V2.0 19/5/2014 Anestis Trypitsidis EPSGR 1st Contribution

21/5/2014 Sorin Pop FIDA Mobile Architecture (2)

25/5/2014 Scott Cadzow C3L Draft Security Layer

26/5/2014 Daniele Miorandi u-Hopper Middleware Layer (1)


V2.5 28/5/2014 Anestis Trypitsidis EPSGR Update and merge (1)

28/5/2014 Theo Arentze TU/e Routing part


1/6/2014 Theo Arentze TU/e Routing part (1)

1/6/2014 Lucian Brancovean INDSOFT Portal & Conversion Tool (2)


v3.0 2/6/2014 Anestis Trypitsidis EPSGR 2nd Review

12/6/2014 Nicola Dorigatti TRILOGIS Geofencing part

14/6/2014 Martino Salvetti TRILOGIS Asset Management

16/6/2014 Theo Arentze TU/e Routing part (2)

16/6/2014 Scott Cadzow C3L Security parts

16/6/2014 Leonardo Plotegher TRILOGIS Camera Surveillance


18/6/2014 Nicola Dorigatti TRILOGIS Communication Bus

18/6/2014 Ion Barosan TU/e Routing part (3)

19/6/2014 Nicola Dorigatti TRILOGIS Spatial Solver


19/6/2014 Martino Salvetti TRILOGIS Asset Management (2)

19/6/2014 Giuseppe Conti TRILOGIS Data Layer review

20/6/2014 Giuseppe Conti TRILOGIS Middleware layer review

20/6/2014 Iacopo Carreras u-Hopper Data layer Contribution


25/6/2014 Giuseppe Conti TRILOGIS Review of the document

26/6/2014 Daniele Miorandi u-Hopper Application Layer (3)

25/6/2014 Giuseppe Conti TRILOGIS Final review of the document

v.4.5 28/6/2014 Anestis Trypitsidis EPSGR Final version

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.

1 List of references

Number Full reference

1 i-locate deliverable D1.1 – Use cases description and Privacy Threat Vulnerability and

Risk Analysis. Available online from: http://www.i-locate.eu/public-deliverables/

2 i-locate deliverable D1.3 - Pilot scope description and system requirements. Available

online from: http://www.i-locate.eu/public-deliverables/

3 i-locate deliverable D.2.1 – Data Survey Report. Available online from: http://www.i-

locate.eu/public-deliverables/

4 ISO/IEC 24730-1:2014 standard on “Information technology — Real-time locating

systems (RTLS)” Available online from:

http://www.iso.org/iso/catalogue_detail.htm?csnumber=38840

5 ISO 55000:2014, Asset management - Overview, principles and terminology.

Available online from: http://www.iso.org/iso/catalogue_detail?csnumber=55088

6 ISO 55001:2014, Asset management - Management systems – Requirements.

Available online from: http://www.iso.org/iso/catalogue_detail?csnumber=55089

7 ISO 55002:2014, Asset management - Management systems – Guidelines for the

application of ISO 55001. Available online from:

http://www.iso.org/iso/catalogue_detail?csnumber=55090

8 ISO 8601:2004, Data elements and interchange formats – Information interchange –

Representation of dates and times. Available online from:


9 OGC - CityGML. Available online from

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

http://www.i-locate.eu/public-deliverables/








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




10 Open Geospatial Consortium Inc. (2014). OGC® IndoorGML v.0.9.0 (OGC reference

number OGC 14-005r1). Available online from:

http://www.opengeospatial.org/projects/groups/indoorgmlswg

11 CityGML. Available online from: http://www.citygml.org/

12 Industry Foundation Classes (IFC) for data sharing in the construction and facility

management industries. Available online from:

http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=516

22

13 ISO 19107:2003, Geographic information -- Spatial schema. Available online from:

http://www.iso.org/iso/catalogue_detail.htm?csnumber=26012

14 Wikipedia. SAML approach to IdM and authentication . Avaialble online from: http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language#mediaviewer/File:Saml2-

browser-sso-redirect-post.png

15 ISO 19111

16 CivicFlow “Civic engagement has never been so easy!”. Available online from: http://www.civicflow.com/

17 OmniClass™. Available online from: http://www.omniclass.org/

18 Moving Features. Available online from:

http://www.opengeospatial.org/projects/groups/movfeatswg

19 WMS – Web Map Service online from: http://www.opengeospatial.org/standards/wms

20 WFS – Web Feature Service Available online from:

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

http://www.opengeospatial.org/projects/groups/indoorgmlswg



http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language#mediaviewer/File:Saml2-browser-sso-redirect-post.png

http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language#mediaviewer/File:Saml2-browser-sso-redirect-post.png

http://www.civicflow.com/

http://www.omniclass.org/

http://www.opengeospatial.org/projects/groups/movfeatswg

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

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




2 Table of Acronyms

Acronym Description

API Application Programming Interface

App Application

BLE Bluetooth Low Energy

CityGML City Geography Markup Language

CM Content Management

COMPASS Chinese Global Navigation Satellite System

CRS Coordinate Reference Systems

CSV Comma-Separated values

DBA DataBase Administrator

DBMS Database Management System

DBMS DataBase Management System

DoW Description of Work

EDAS EGNOS Data Access Service

EGNOS European Geostationary Navigation Overlay Service

ESB Enterprise Service Bus

ESP Encapsulating Security Payload

ETA Expected Time of Arrival

GeoDB GeoDatabase

GI Geographic Information

GLONASS Russian satellite navigation system

GMES Global Monitoring for Environment and Security

GML Geography Markup Language

GNSS Global Navigation Satellite System

GPS Global Positioning System




GPS Global Position System

GTFS General Transit Feed Specification

GUI Graphical User Interface

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

HVAC Heating, Ventilation, and Air Conditioning

IdM Identity Management

IdP Identity Provider

IFC Industry Foundation Classes

IP Internet Protocol

IPsec IP Security

ISO International Standard Organisation

JS JavaScript

JPEG Joint Photographic Experts Group

JSON JavaScript Object Notation

KML Keyhole Markup Language

LBS Location Based Services

LGPL Java code library

MLS Multiple Layered Space representation

MLS Multi-Layered Space

MLSM Multi-Layered Space Model

MLSM Multi-Layered Space Model

NRG Node-Relation Graph

OCCS OmniClass Construction Classification System

OGC Open Geospatial Consortium

OS Operating System

OSM OpenStreetMap




OTP OpenTripPlanner

OWL Ontology Web Language.

POI Point of Interest

QRCode Quick Response code

REST Representational state transfer

RP Relying Party

RTLS Real-Time Locating Systems

SAML Security Assertion Markup Language

SDK Software Development Kit

SKOS Simple Knowledge Organization System

SiSNeT Signal in Space through the Internet

SQL Structured Query Language

SSO Single Sign- On

TIFF Tagged Image File Format

TLS Transport Layer Security

URI Uniform Resource Identifier

VGI Volunteered Geographic Information

VPN Virtual Private Network

WFS Web Feature Service

Wi-Fi Wireless Fidelity

WMS Web Map Service

WP Work Package

XACML eXtensible Access Control Markup Language

XHTML Extensible HyperText Markup Language

XML Extensible Markup Language




3 Executive Abstract

This document is the final outcome of a range of different activities that had first brought to the

release of earlier deliverables. In fact this deliverable finalises the results of the first work package,

building on top of D1.1 – Use cases description and Privacy Threat Vulnerability and Risk Analysis

[1] and D1.3 - Pilot scope description and system requirements [2], to release the final specifications

of the i-locate toolkit and portal.

In particular, the initial analysis had provided a comprehensive view of the different stakeholders

involved, of the user’s need, of the pilot site constraints, of the data available to the pilot, of the legal

constraints. This analysis has gone through an abstraction and generalisation process leading to the

definition of a general framework, whose specifications are detailed within this document, capable

to account for a variety of different scenarios and that, in addition, can be further extended –thanks

to its modularity- whenever new features will be required.

It is important to note that, although the authors have strained to define, to the greatest possible

degree, the features envisaged at this stage, due to the complexity of the overall system, some of

the details presented within this document as well as the software interfaces defined for its

components, may change during later development activities. In fact, although we do not foresee

major variation of the overall concept, it is likely that the final solution will include minor changes and

deviations from the initial specifications initially defined within this document. Nevertheless, the

importance of this document remains unchanged as this document has been essential to define a

common shared view of the entire framework. Whenever changes will occur to the design of the

system, they will be formalised and as updated within this document.

This document, has been the result of the work of various i-locate partners, as detailed in the cover

page of this document, with additional strategic advise provided by members of the advisory board

of the project. To this extent, the authors wish to acknowledge the recommendations provided by

several members of the advisory board during the definition of the system architecture detailed within

this deliverable, namely:

Mr John Herring, Senior Architect at Oracle Corporation, convener of HMMG at ISO/TC211,

convener Working group 9 - Information management at ISO TC 211, Liaison Representative

for OGC at CEN 287, who had advised, from the first days of the project, on the adoption of

Poincaré duality for generation of indoor connectivity graphs.

Mr Bart De Lathouwer, Director of Interoperability Programs, at Open Geospatial

Consortium Europe, who has advised on adoption of relevant OGC standards including

OpenLS and, most notably, IndoorGML.

Prof. Ki-Joune Li, Pusan National University, Korea and chairman of IndoorGML Standard

Working Group (SWG), who has advised on several aspects regarding specific use of and

support for IndoorGML and its possible extension for asset management purposes.

Mr Patrick Hogan, World Wind project manager at NASA AMES, for its support on use and

extension of World Wind technology –including the mobile version for Android- within the i-

locate toolkit.

Mr Giovanni Corcione, Master Principal Sales Consultant at Oracle Italia, for its advise on

use of Oracle Spatial and Graph features for the i-locate portal.




Mr Marek Strassenburg-Kleciak, Senior Manager New Business Development of Elektrobit

Automotive GmbH (Germany) and elite developer of OSM (OpenStreetMap) 3D, who has

provided advice on integration with OSM indoor data model.




4 Table of content

1 LIST OF REFERENCES 3

2 TABLE OF ACRONYMS 5

3 EXECUTIVE ABSTRACT 8

4 TABLE OF CONTENT 10

6 INTRODUCTION 15

6.1 Scope 15

6.2 Organization of the Document 16

7 INTRODUCTION TO OVERALL FEATURES AVAILABLE TO THE USERS 17

7.1 Selected Applications 17 7.1.1 The “Core” App 17 7.1.2 Interfaces for Supporting Staff 20 7.1.3 Interfaces for Specialists 21 7.1.4 Interface for Lay Users 21

8 DATA LAYER 23

8.1 Overall Approach 23

8.2 Data Level Unified Architecture 23

8.3 Vast Support for Standards 24 8.3.1 i-locate as the First Implementation of IndoorGML 25 8.3.2 Binding to OSM 30

8.4 i-locate Extended Data Model 32 8.4.1 Positioning data model data model 32 8.4.2 Indoor graph and location based services 34 8.4.3 Asset management data model 37

8.5 Semantic description of indoor spaces 46

8.6 Versioning 47 8.6.1 ORACLE CM SDK 48

8.7 Security and authentication 50

9 MIDDLEWARE LAYER 52

9.1 Introduction 52

9.2 Overall approach 52

9.3 Identity Management 55

9.4 Localization services 57 9.4.1 Outdoor localization 57

9.4.1.1 APIs 58 9.4.2 Indoor localization 58

9.4.2.1 1st mode API - pull 59 9.4.2.2 2nd mode API - pull 60 9.4.2.3 3rd mode API - pull 61 9.4.2.4 4th mode API - push 61




9.4.3 ISO 24730 compliant localisation 62

9.5 Spatial Solver Service 65 9.5.1 APIs 65

9.6 Routing service 69 9.6.1 Indoor routing 70 9.6.2 Outdoor routing 71 9.6.3 Routing proxy 71 9.6.4 Routing APIs 72

9.6.4.1 API for outdoor routing only 72 9.6.4.2 API for indoor only 75 9.6.4.3 APIs for integrated indoor-outdoor 77

9.7 Geofencing Service 78 9.7.1 APIs 79

9.8 Monitoring service 81 9.8.1 APIs 81

9.9 Location Analytics 82 9.9.1 APIs 82

9.10 Asset Management 84 9.10.1 Backend module 86

9.10.1.1 Asset management features 89 9.10.1.2 Event management mechanism 89 9.10.1.3 Management of “asset management” processes 90 9.10.1.4 Role management 91 9.10.1.5 Management of historical data 92

9.10.2 Frontend module 94 9.10.3 Integration with the server component 95 9.10.4 Synchronization 95

9.11 Crowdsourcing module 97 9.11.1 APIs 97

9.12 Configuration 98 9.12.1 APIs 98

9.13 Spatial Services 100 9.13.1 API based on standard web-services by OGC 100

9.14 Upload/Download Service 102

9.15 Communication Bus 104

10 CAMERA SURVEILLANCE SUBSYSTEM 106

10.1 APIs 106

11 DYNAMIC VIEW 111

12 APPLICATION LAYER 116

12.1 The Mobile Application 116

12.2 The Web Application 121

12.3 Communication 124

13 PORTAL INFRASTRUCTURE 125




13.1 Web Browser Layer 126 13.1.1 Guest view map screen 127 13.1.2 Login screen 127 13.1.3 Site status and operations screen 128 13.1.4 Staging map preview screen 128 13.1.5 Special map view screen 128 13.1.6 Map control implementation 128

13.2 Web Server Layer 128 13.2.1 Introduction 128 13.2.2 Geoserver 129 13.2.3 Outdoor Map Service 129

13.2.3.1 Base Map Service 129 13.2.3.2 OSM connector 130 13.2.3.3 Other Connectors 130

13.2.4 Web application 130 13.2.4.1 Map Editing Service 130 13.2.4.2 Page Controllers 132 13.2.4.3 Map Overlay 132 13.2.4.4 Map Upload Service 132 13.2.4.5 Map Export Service 133 13.2.4.6 Site Service 133 13.2.4.7 User Service 134 13.2.4.8 Geographical and Topological Model Checker 134

13.2.5 Geospatial Data 134




5 Table of Figures

Fig 1: the overall approach followed for the architecture of i-locate 16

Fig 2: Top: the functional mock-up of the POI searching interface. Centre: the mock-up of the map

searching interface. Bottom: the mock-up of the interface used for mapping and navigation. 19

Fig 3: functional mock-up of the interface for the supporting staff 20

Fig 4: functional mock-up of the interface for operational purposes 21

Fig 5 : an example of functional mock-up of the application for lay people. In this case the mock-up

depicts the typical features needed for the management of health bookings. 22

Fig 6: architectural representation of the data level 24

Fig 7: The different semantic differences among spaces. Source: IndoorGML v.0.9.0 [10]. 26

Fig 8: A representation of Poincaré duality 27

Fig 9: A view of the topographic space (left), of the adjacency graph in dual space (centre) and

connectivity graph in dual space (right). Source: IndoorGML v.0.9.0 [10]. 28

Fig 10: UML diagram of Multi-Layered Space representation. Source: IndoorGML v.0.9.0 [10]. 29

Fig 11: i-locate data model as partial bridge between OSM and IndoorGML 30

Fig 12: the OSM structure where indoor:area (the border of the rooms in red) are linked through an

indoor:highway (the blue graph connecting the rooms) which connects indoor:door(s) (black circles

representing the doors) or to entrance(s) of the building (black diamonds representing the two

entrance points at the bottom and top of the figure. Figure courtesy of Elektrobit Automotive GmbH.

32

Fig 13: Overall Positioning data model 33

Fig 14: Anchor Node Connecting Indoor and Outdoor Networks. Source: [10]. 37

Fig 15: UML class diagram of Asset Management data model proposed in i-locate 39

Fig 16: Example of a composite asset. AssetType and Asset objects are instantiated 40

Fig 17: The objects representing two IndoorAssetManagement:Process objects. They are connected

to corresponding assets and eventsindoorAssetManagement:ProcessInfo 42

Fig 18: Objects related to a process execution 43

Fig 19: Operator hierarchy: representing people and groups 43

Fig 20: Example implementation of responsibilities subsystem 44

Fig 21: Model of the assets of Hyde Park 45

Fig 22: The AssetType structure that describes the structure of a generic 45

Fig 23: Exampleof a second park model-based on “Park: AssetType” 45

Fig 24: The roles structure of Hyde Park, which is connected with the operators of the example

(Person type) 46




Fig 25: Database Versioning 48

Fig 26: Oracle CM SDK types of objects 49

Fig 27: Identity Identifier Service 51

Fig 28: i-locate middleware components 54

Fig 29: Ontology like view of identity and identifiers 55

Fig 30: The three primary roles in the common IdM thematic model 56

Fig 31: SAML approach to IdM and authentication. Source: Wikipedia [14]. 56

Fig 32: Overall architecture of the routing system including the proxy and the two sub-component for

indoor and outdoor routing. 72

Fig 33: the overall approach used for the architecture of the geofencing module 78

Fig 34: the overall structure of the asset management service. 84

Fig 35: a screenshot of the backend interface developed by Trilogis and that will be interfaced to the

backend module of i-locate. 85

Fig 36: a screenshot of the frontend interface developed by Trilogis and that will be interfaced to the

frontend module of i-locate. 86

Fig 37: Overall building blocks of the backend of the Asset Management module. 87

Fig 38: class diagram of back-end module 88

Fig 39: overall architecture of the frontend of the Asset Management module. 96

Fig 40: upload service 102

Fig 41: download service 103

Fig 42: Communication Bus 104

Fig 43: Functional block diagram of the camera surveillance subsyste 106

Fig 44: General Overview of the system architecture 113

Fig 45: Mobile Application Architecture 117

Fig 45: Application Layer - General Approach 118

Fig 46: Application Layer main interactions 119

Fig 47: Mobile Application Architecture 120

Fig 49: Mobile App - Communication module 121

Fig 49: Web application workflows 124

Fig 50: Portal Infrastructure Architecture Diagram 125

Fig 51: The different modules of the portal 126

Fig 52: Guest view map Screen 127




6 Introduction

6.1 Scope

This document aims at the definition of the details of the architecture for the i-locate system for -

"Indoor/outdoor LOCation and Asset management Through open gEodata". This is the final

deliverable for the first work package (WP) and a fundamental component for all the other technical

WPs.

The different requirements collected throughout WP1, and formalized within previous deliverables

D1.1 “Use cases description and Privacy Threat Vulnerability and Risk” [1] and D1.3 “Pilot scope

description and system requirements” [2], have been used as a basis to define the system

architecture. The approach followed within this section builds on top of the Use Case modelling,

which has been tightly integrated with the user requirements which are immediately reflected by the

design of the final users’ applications planned for i-locate.

The document will cover all the aspects related to the structure and behaviour of the i-locate toolkit

from the data level up to the application level, including also the full set of details of the i-locate portal

infrastructure. This structure has been intended as the shared reference point for development

activities required for the correct accomplishment of the project.

This document is the result of several revisions and updates as a consequence of the discussions

done during the analysis of the available resources, of the pilot and user cases, their requirements,

(including specific requirements emerging from some of the pilot sites), of privacy requirements and

legal compliance.

This document has been meant to provide a general framework to the project and to define, to the

greatest possible degree, the high level functionalities envisaged at this stage. However, it is

important to mention that some of the software interfaces may change at development stage, albeit

to a minor extent. Nevertheless this document is essential to define a common shared view of the

entire framework.

As visible in Fig 1, from a software architecture standpoint, i-locate will deliver two main results:

A ready-to-be-deployed "toolkit" based on interoperable services for indoor and outdoor

location, routing and asset management that use open GI. This development will also be

complemented by a set of Apps for smartphones and tablets that can use the services made

available by the toolkit, providing access to location, routing functionalities of the toolkit and

allowing crowdsourcing of information regarding indoor spaces. This infrastructure, will

strongly rely on open source software, including use of PostGIS/PostGRES at the database

level. This will ensure maximum take-up of the core of the toolkit due to absence of licensing

costs.

A public portal for indoor open GI (Geographic Information) which can be regarded as the

indoor counterpart of OpenStreetMap. This will be essential to help users upload, manage

and share indoor mapping data as open data. The public portal, at the database level, will

rely on an Oracle database in order to ensure maximum scalability and performances as well

as to benefit from a range of features available within the Oracle suite.

It is important to highlight that, the choice of relying on Oracle for the portal will not infer with the

impact and takeover of the toolkit within the wide community since it will be represent a one-off setup




and infrastructure (referred to as “virtual hub”) that will be made available to the public to provide

access to indoor GI as open data.

Portal

Database

(PostGIS)

Portal

Database

(ORACLE)

DataLevel

MiddlewareLevel

i-locate middleware Portal Services

Applications Web pagesApplication

Level

i-locate toolkit i-locate portal

Fig 1: the overall approach followed for the architecture of i-locate

6.2 Organization of the Document

The deliverable is organized as follows: after this first (section 7) introductory chapter, which provides

the overall approach of the design of the i-locate project, first providing an introduction of how the

final applications (whose technical details will be then presented later in the document within section

12) will behave in order to immediately provide the reader with a view of the system starting from the

components that will be used by the users. This approach reflects the user-centric approach that has

been followed within the definition of the project and its architecture.

The document then presents the various levels of the service oriented architecture of i-locate. The

analysis starts from the lower data level (section 8) and then moves to the middleware layer (section

9). Section 10 provides an example of further specialisation of the toolkit, detailing a module required

for video surveillance applications, which extends the functionalities of the toolkit to respond to

specific user requirements (see use case of the pilot in the Municipality of Tremosine, Italy [1]).

Eventually a dynamic view of the overall toolkit is introduced in Section 11 followed by a detailed

description of the highest logical level of the toolkit, the application level, which is detailed within

section 12.

The last chapter eventually defines the details of the portal, which represents –as illustrated in Fig

1- an independent logical stack from the toolkit, yet closely interrelated in that it will ensure public

provision of indoor GI as open data.




7 Introduction to Overall Features Available to the Users

Since the reminder of the document describes the service oriented architecture of i-locate starting

from the lowest logical levels and moving up to the Application level, it has been decided to provide

an initial section where the overall functionalities at the (highest) application level are introduced

upfront. This choice has been made in order to help the reader build, right from the beginning of the

document, a mental picture of the final user-centric use of the system. This way the reader will be

able to better appreciate the features detailed in the following sections without having to wait for the

document to logically move up to the last layer (describing the application) to appreciate the final

use of the system.

As mentioned already in earlier sections of this document, the final applications will be deployed as

web pages or as mobile applications (or App, as it will be referred to in the reminder of the document),

suitable for smartphones and tablets. Further developments, could easily enlarge the scope and use

of the Apps by providing support for smart watches or smart glasses (such as the popular Google

Glasses solution).

To help readers appreciate Several mock-ups have been included in this section to help the reader

better appreciate the most important features envisaged for the Graphical User Interface in the

various scenarios addressed by the project. However, it is essential to highlight that these are only

simplified functional mock-up that are meant to facilitate comprehension by the reader by

providing a graphical exemplary representation of the most important features that will be available.

These mock-ups therefore do not show the full set of features that the user will have access to

nor they do represent the final graphical style of the applications.

It is worth noting that providing a detailed presentation of the aesthetic aspects of the Graphical User

Interfaces is beyond the scope this document. During the development activities the development

team will identify, with active support of the final users involved in the pilot sites, the graphical

appearance of the interfaces in order to ensure a pleasant user experience while providing high

degree of usability. Wherever possible, the interaction language developed for the final interfaces

will follow the most well-known interaction paradigms adopted for websites and Apps.

7.1 Selected Applications

7.1.1 The “Core” App

The i-locate “core” mobile application will include all the common features needed by the different

use cases. This App will be further extended with additional features to respond to particular

requirements of specific users or use cases, as detailed in the following sections.

The App will be developed for Android and iOS operating systems (OS) and will be designed to run

both working on phones and tablets. The App will consist of three main components:

The core and Graphical User Interface (GUI), presenting information of relevance to the

user including, but not limited to, current position, destination, route, directions, Expected

Time of Arrival (ETA) and so on. The GUI will provide access to server-side features such as

searching for indoor positions (e.g. “meeting room at second floor”) of Points of Interest

(POIs) inside or outside a buildings. Further functionalities made available by the core include

map downloading capabilities to enable users to download maps for offline use as detailed

in section 9.14. Fig 2, provides a first mock-up of the GUI that shows how, through a set of




ComboBoxes or similar GUI components, it will be possible for the user to perform searches

by address, or by outdoor / indoor POI.

The GUI will also ensure let the user configure routing preference and other configuration

options that may be required by the specific use case.

Within the GUI a central role will be paid by the map, routing and display GUI component.

This will be essential to show a map (indoor and outdoor), the positions the user, to displays

the route and to provide directions on how to get to the selected destination. A functional

mock-up of the GUI of this component has been provided in Fig 2.

A location service, used to collect the position-related information made available from the

user from different data source (e.g. GPS receiver, location retrieved by Wi-Fi location based

application or by reading a QRCode of known position etc.).

A communication module, to ensure communication with the i-locate services.

Starting from M12 we will decide on the specific technology to be used for implementing the

mobile application. This is strongly linked with the i-locate exploitation strategy, and in particular

with the target audience for the app. If it is about sharing with the public location-based contents

(including maps etc.) both a mobile web approach and a mobile application could be appropriate.

If the target is the community of mobile developers, we could potentially create an open source

mobile application framework providing all the basic features for creating mobile applications for

the most popular platforms, and connect them to the i-locate middleware. All such options will be

evaluated and assessed in the definition of the project-level exploitation strategy. The specific

technology for designing and realising the mobile application will be chosen on the basis of the

outcomes of such evaluation




Fig 2: Top: the functional mock-up of the POI searching interface. Centre: the mock-up of the map searching interface. Bottom: the mock-up of the interface used for mapping and

navigation.




7.1.2 Interfaces for Supporting Staff

The “core” App detailed in the previous section, will be extended with additional features necessary

to various types of supporting staff, involved in the various pilot site, who include, for instance, public

officers and administrative staff (in pilots dealing with public officers), nurses or clinical engineers (in

case of pilots dealing with hospitals), or employees of a museum.

In addition, specific functionalities may be also provided through an ad-hoc web application, which

will enable operators to perform daily tasks in more efficient way. Typical tasks that the interface will

be designed for include, for instance, pre-authorization features, performing check-in, facilities to

locate assets or specific persons. Specific attention will be paid to queue management features

including, for instance, those to be used at public offices or within clinics, and to facilities that can be

used to inform visitors about possible delays of key personnel (e.g. doctors).

The web applications will also be tailored to provide configuration of specific alerts, depending of the

specific use case, for instance in case of unauthorized access by users in some restricted areas or

in case users or assets are leaving the premises.

A functional mock-up of the interface for hospital pilot site is illustrated in Fig 3.

Fig 3: functional mock-up of the interface for the supporting staff




7.1.3 Interfaces for Specialists

A specialised App, which will be an extension of the core App (see section 7.1.1), will be needed to

cover all the use cases addressed by the various pilots. The App will have to respond to specific

requirements of specialists (e.g. doctors, guides, experts in public authorities), who will have to be

able to notify weather they are on/off duty, to receive the list of expected visitors/patients, to be

informed about cancellation or delays.

A specific web-based interface will be developed for the particular case of operational managers,

who are in charge of maintaining assets within their facilities (e.g. hospitals, museums, etc.). The

interface will feature a map-based environment integrated with existing asset management features

available through the existing asset management system, called Box3, developed by Trilogis1.

Through this interface, operational managers will be able to create users, associate users and assets

to tags, perform asset management tasks and generate analytics reports. A functional mock-up of

the App for specialists is illustrated in Fig 4.

Fig 4: functional mock-up of the interface for operational purposes

7.1.4 Interface for Lay Users

Due to the various lay users foreseen by the different use cases (i.e. patients, visitors, customers

etc.) the project will also develop a number of customised interfaces on top of the “core App” detailed

in the previous section 7.1.1. These Apps, for instance, will allow cancelling or rescheduling

meetings/appointments or notifying of late arrival by the user or –likewise- to receive notifications in

case of cancelation or delay by other parties.

From a technical point of view, these Apps will simply be an extension of the core App and therefore

they will inherit the same technology. The most significant difference will be in terms of specific

graphical user interface components and functionalities required to accomplish tasks required by the

1 The Box3 system will be provided as pre-existing “background” to the project’s pilot users by Trilogis and does not represent a result of the project. It is important to highlight that, in order to ensure adoption of other asset management platform, the existing Box3 solution will be integrated with the i-locate toolkit through well-defined set of software interfaces as detailed within later sections of this document. This abstract layer will allow connecting –through a web-service interface- any other asset management solution without creating any specific dependence from any proprietary solutions.




specific use cases they have to respond to. A functional mock-up of the App for specialists is

illustrated in Fig 5.

Fig 5 : an example of functional mock-up of the application for lay people. In this case the mock-up depicts the typical features needed for the management of health bookings.




8 Data Layer

The i-locate toolkit has been engineered as a classic multi-tier SOA. This section starts illustrating

the lower data level which higher levels being detailed within the following sections of this deliverable.

8.1 Overall Approach

The data layer has been engineered to deal with both existing open GI repositories (e.g. road network

available as open data from OpenStreetMap) and indoor data which are directly collected or

processed by i-locate. These data include those made available via the portal (the “virtual hub”) as

detailed in the last part of this document.

Due to the spatial nature of i-locate, beside other standard alphanumeric information, the data layer

will be responsible for storing geographical data. This will be done according to different strategies:

As files: for example raster data can be stored in raster files formats (such as JPEG, TIFF

or GeoTIFF), while vector data can be stored in various formats such as ESRI Shapefile,

MapInfo, DXF, etc.

Within a database: this is managed through a spatial database management system. As

already highlighted in Fig 1, two stacks have been planned, one based on Oracle Spatial and

Graph and the second based on the open source solution Postgres/Postgis. Both Spatial

Databases (or GeoDBs), are used for higher data volumes or when data must be accessed

and updated by many users, when security policy is required, when complex spatial and non-

spatial operation must be performed on the database and when the data must be integrated

with non-spatial data.

In i-locate, the data level consists of all the different datasets (alphanumeric, spatial, harmonized

and not) made available within the network by the different content providers. Basically, the data

stored at this logical level can be divided in two main categories:

Geographical data: datasets provided for i-locate pilots including road networks, indoor and

outdoor mapping data etc.

Support i-locate IT data: dataset necessary to meets i-locate functionality and services, for

instance asset management data etc.

It should be noted that, from a deployment perspective, the various data repositories may be

physically managed by different DBMS.

8.2 Data Level Unified Architecture

The purpose of this sub-section detail the set of components of the data level, which is the lowest

level of the Service Oriented Architecture, which is further detailed in Fig 6. Each of the data

repositories in Fig 6 will be used to store information used by the modules/technologies belonging to

the middleware layer. This data will be mostly stored through the use of Spatial Databases.




Fig 6: architectural representation of the data level

8.3 Vast Support for Standards

Due to the specific nature of i-locate, which stresses the importance of interoperability and support

for open standards, particular attention has been paid to the adoption of relevant standards for the

key features of the toolkit.

This strategy has been followed to ensure:

High extensibility, in that support for standards allows future connection of further

technologies provided they are compliant.

Better marketing value, since support for standard maximises commercial impact and

industrial interest of the solution.

Lower technology dependence, since, through wide support for well acknowledged

standards, it becomes possible to use technologies from a variety of different vendors (or

open source).

In particular, most of the aforementioned geographical repositories2 will be accessed by the toolkit

via interoperable standards from the Open Geospatial Consortium (OGC) specifically as WMS (Web

Map Service) and WFS (Web Feature Service) standard. This will ensure easy connection to other

available open data repositories such as OpenStreetMap, or to other data sources available through

other open data initiatives at local, regional or national level. This includes data made available

through INSPIRE3 or projects within Copernicus (formerly GMES) that provide open GI that can be

used to better react to emergencies, to improve health community support to better assess people

at risk.

2 A detailed analysis of the repositories available to the pilots is provided within the deliverable D.2.1 [3] 3 European Directive 2007/2/EC INSPIRE “Infrastructure for Spatial Information in Europe” (inspire.ec.europa.eu/)

Routing & Navigation

Camera Surveillance

DB

User data &

Configuration DB

Asset

Management DB

Geographical

Data Warehouse DB

Analytics DB

Pilot Data DB (.shp, .dxf)

Repositories

(File, PostGIS, Oracle Spatial)

External sources(WMS, WFS)

Data layer Overview




Besides well-established open standards from the Open Geospatial Consortium - OGC, whose

adoption is detailed in the corresponding sections of this document, i-locate has embraced, at the

overall system architecture level, support for IndoorGML as the emerging standard for indoor LBS

[9]. IndoorGML “is a common information model and XML-based encoding for the representation,

storage, and exchange of virtual 3D city and landscape models” [11].

It should be noted that ensuring support of IndoorGML has a strategic relevance, in that it will make

i-locate become the first implementation of a reference standard within a very promising market,

therefore ensuring significantly higher market potential and business take-up of the results of the

project. A specific section introducing IndoorGML has been included in this document for the

particularly relevant role that the adoption of this standard will play within i-locate.

Attention to relevant emerging standards has been paid when designing new features or extension

of existing standards. This is the example of the data model adopted for asset management, detailed

in section 9.10, which follows the guidelines of standard ISO 55000-1-2 on Asset management [5]

[6] [7] to propose a new module of IndoorGML for asset management.

Further, with regard to location data, the toolkit has been designed to ensure support for simple

positioning data as ISO 19111 [15] and for the full set of relevant information related to real-time

locating systems data as ISO/IEC 24730-1:2014 standard on “Information technology - Real-time

locating systems (RTLS)” [4], as detailed in section 9.4.3.

Last, but not least, whenever needed, support for dates and times, essential for the location features,

will be based on ISO 8601:2004 [8].

8.3.1 i-locate as the First Implementation of IndoorGML

Although providing a detailed description of the IndoorGML is not within the scope of this document,

however, due to the novelty and peculiar features of IndoorGML, it is appropriate to provide a short

introduction of the most important features of this emerging standard, limitedly to those concepts

necessary to facilitate understanding of the approach and software components designed for the

overall software architecture of i-locate. For additional details we recommend referring to the most

recent specifications of the standard published by OGC4.

IndoorGML, whose version 1.0 is due to be released over the second part of 2014, specifically targets

the need of indoor location based services (LBS). In particular, the standard accounts for significant

differences with outdoor domain that emerge whenever indoor location is required. These include,

different navigation constraints such as steps, stairs, doors and several other features that are not

found within classical outdoor navigation scenarios.

In addition, classical navigation metaphors (e.g. “after 200 meters turn right”) may not be entirely

appropriate within indoor navigation scenarios where diversity and complexity is, to a certain extent,

higher than in outdoor navigation scenarios. This scenario is further complicated by the fact that,

within indoor contexts, the degrees of freedom of the user (e.g. a person walking inside a building)

are significantly higher than in outdoor navigation scenarios where vehicles are supposed to be

driven only along streets. Instead, people can walk freely, with often no restriction on directions flows,

across different floors, use different transportation modes such lifts, escalators etc.

4 Open Geospatial Consortium Inc. (2014). OGC® IndoorGML v.0.9.0 (OGC reference number OGC 14-005r1)




It is worth noting that IndoorGML does not describe architectural features (when this is required it

allows referring to CityGML or Industry Foundation Classes - IFC [12] data models) but indoor

spaces and their relationships.

Within IndoorGML, indoor spaces are defined as collection of non-overlapping cells, each with a

unique identifier which can be used to define their position (this can also be done with standard

coordinates). Each cell can be further qualified through semantic or geometric characterisation.

Semantic description is used to qualify the “type” of space, for instance to define that a cell is a

“waiting lounge” or a “ticket desk”. Semantic descriptions can be also associated to the concept of

aggregation, for instance to define sub-cells. This is particularly useful in case of large spaces such

as check-in areas at an airport that could be further subdivided into small cells, each corresponding

to a check-in desk, which could be used as “last-mile” representation for high-precision routing.

In addition, spaces are qualified semantically through an explicit definition of non-navigable spaces

(e.g. a wall) and navigable spaces (e.g. a room), which in turn is further specialised by classes such

as general spaces, transition spaces, connection spaces, as illustrated in Fig 7.

Fig 7: The different semantic differences among spaces. Source: IndoorGML v.0.9.0 [10].

An additional topology, based on use of anchor nodes and anchor spaces, can be used to represent

the entry point of a building (there must be at least one within each model of building) and it ensures

connection with outdoor data structure allowing for a clear separation between the indoor and

outdoor domain. The anchor node, which can contain reference to the outdoor graph, contains

additional information that may be used, for instance, for conversion between indoor and outdoor

Coordinate Reference Systems (CRS), allowing convenient use of relative coordinate systems when

indoor.




As mentioned earlier, geometrical description may be provided as regular ISO 19107 [13]

geometrical features within IndoorGML or, preferably, by referring –through links- to other external

ISO 19107, CityGML or IFC classes. It should be noted that geometrical description may not be even

provided within an IndoorGML model with the overall model being perfectly valid.

In addition, IndoorGML leverages on the semantic qualification of indoor spaces to create a network-

based representation that can be used, similarly to road networks in the outdoor domain, to create

indoor navigation systems. This network-based representation is formalised through a Node-

Relation Graph (NRG) which can be used to represent adjacency or connectivity relationships

between nodes.

More specifically, as visible in Fig 8, these graphs are created leveraging on the so-called Poincaré

duality whereby traditional spaces (such as rooms of a building), which are represented by 3D or 2D

features (within what is referred to as the “primal” space), are mapped to nodes of a graph (which is

a zero-dimensional objects). The nodes of the graphs are called “states”. In addition, the Poincaré

duality can be used to map 2D surfaces (for instance a wall separating two adjacent rooms if

represented in 3D) or 1D lines (for instance representing the same wall within a 2D representation

of the room) to edges of a graph (one-dimensional objects). The connections of the graphs are called

“transitions”.

Fig 8: A representation of Poincaré duality

A more detailed example is shown in Fig 9 which is quoted from the official documentation of

IndoorGML standard [10]. The figure shows, on the left, a topological space where two adjoining

rooms, each represented in IndoorGML with a cell, (R1 and R2) are sharing a wall (named B2) and

connected by a door (D1). The different nature of this relations is shown in the graph in the centre of

Fig 9 whereby simple adjacency relationships are represented by dashed lines while connectivity

relationships are represented by a continuous line.

It should be noted that both rooms share an adjacency relationship with the outdoor space and

therefore, as depicted in the graph in the centre, both nodes R1 and R2 are connected to a further

node EXT, which represents the outdoor space, respectively through wall B1 (for cell R1) and walls

RoomA RoomB

wall

RoomA RoomB

Primal3Dspace

Primal2Dspace

Dualspace

wall




B3 and B4 (for cell R2). In addition, cell R2 is directly connected to the external space through a door

(D3) as visible by the continuous line connection within the graph.

Fig 9: A view of the topographic space (left), of the adjacency graph in dual space (centre) and connectivity graph in dual space (right). Source: IndoorGML v.0.9.0 [10].

If we isolate the connection relationships, we end up with a connectivity graph (see Fig 9 on the right)

that can be used for navigation purposes. A similar, albeit more complicated graph, can be derived

when we consider walls with their thickness (and not just as thin lines). For a full description we

recommend referring to the specifications of the IndoorGML standard [10].

It is important to highlight that there can be different connectivity graphs at the same time. One, for

instance, could be created for walking users, a second for wheelchair users. In this case, for instance,

adjacent rooms connected by a door whose width, is lower than 80 cm would be not considered as

“connected” as the wheelchair could not possibly pass through the door.

In addition, the representation of indoor spaces is based on a so-called multi-layered space

approach. The indoor space in fact can be represented in many different and totally arbitrary ways.

For instance, if seen from a topographical point of view, then the space is made of rooms, corridors,

stairs etc. whose connectivity can be represented through a graph in dual space.

If instead we consider the indoor space from a location service point of view, we can just divide it

into areas of coverage of each antenna. In this case “rooms” are replaced by portions of space which

represent the area covered by each antenna. Similarly to the previous case, we can define a dual

graph that represents their connectivity. More detailed examples are provided within the official

IndoorGML standard specifications [10]. It should be noted that “there are other possible

interpretations, and the number of layers is generally unbounded and any definition for space (e.g.,

security space, movement space, activity space, visual space etc.) can be given for a semantic

modelling of indoor space, where each of them is defined in its own layer” [10].

As mentioned already, IndoorGML allows for sub-spacing of large rooms (e.g. a check-in area may

be divided in check-in desks), which are represented in dual space by sub-graphs, i.e. graphs that

are created starting from a node that represent, for instance, connectivity at the sub-cell level.

The multiple space representation is done through different logical “layers”, each considering a

different representation of cells, and connected through inter-layer relationships. This model referred

to as MLS (Multiple Layered Space representation). Fig 10 depicts the standard data model for the

IndoorGML core module based on the multi-layered space model.




Fig 10: UML diagram of Multi-Layered Space representation. Source: IndoorGML v.0.9.0 [10].

The non-overlapping nature of cells ensures that “an object is at any given time exactly in one cell

(named state) in each layer simultaneously. This overall state is thereby denoted by the combination

of active states from all space layers” [10].

In addition to MLS, IndoorGML provides an additional model called Structured Space Model which

“defines the general layout of each space layer independently from the specific space model which

it represents. Each layer is systematically subdivided into four segments” [10] which include four

elements:

The geometry, either 3D or 2D, to which a geometric NRG corresponds in dual space.

Its induced topology in 3D or 2D space, to which a logical NRG corresponds in dual space.

The combination of different layers (within an MLS), each of which has a Structured Space Model

representation, yields the so-called MLSM (Multi-Layered Space Model) which allows for significant

flexibility in terms of indoor location based services. The different graphs which are stored within the

various layers can be connected by further inter-layer connections, called joint edges, yielding a

multi-layered graph.

Since cells are built on the principle that each of them does not have any overlapping area, an item

or person being tracked can only be in one cell (a node of the graph) at time. In the MLSM model,

this means that it is possible that, at each given time, the object or person being tracked is within

different states (at most one for each layer) at the same time.

Last, but not least, the entire standard has been designed with modularity in mind, through the

development of a core standard data model with the possibility to extend it through modules.




8.3.2 Binding to OSM

The second important cornerstone of data structure of i-locate will be the integration with

OpenStreetMap (OSM). This is particular important in light of a possible integration of the i-locate

portal with the overall OpenStreetMap portal infrastructure. For this reason particular attention has

been paid to defining a data model that could, in addition to providing support for IndoorGML,

facilitate convergence with OSM. For this reason, as illustrated in Fig 11, the design has been

oriented to try to identify, wherever possible, a common data structure, bridging across OSM and

IndoorGML, that can be used to let users define data of relevance for indoor location based services.

Fig 11: i-locate data model as partial bridge between OSM and IndoorGML

In fact, thanks to the design of its data structure, i-locate will ensure a partial bridge between those

three most important elements of the two data models which are necessary for the creation of

location based services, namely for:

Definition of indoor spaces.

Semantic classification of those spaces through standardised tagging.

Definition of connectivity between indoor spaces.

It is important to highlight that, although it could be possible, at least in principle, to provide a

conceptual mapping (as well as transformation tools) between the way the geometry of the building

is defined in OSM and how this is done in IndoorGML (also through referencing of IFC or CityGML

classes), this would be outside the scope of this first version of i-locate which aims at providing

support for harmonised indoor location based services and not harmonised indoor space

representation.

Providing a data model that bridges the two data models (at least limitedly to those element

necessary for location based services) is the first step to the development of automatic

transformation systems between key elements of OSM (which heavily relies on tags5) and

IndoorGML, which will be made available through the i-locate portal. This approach would allow, in

principle, users to operate –during the data curation process- in either of the two data models while

the system caters for automatic translation to the other.

5 It is worth noting that in OSM the classification is based on name=value tag with the optional description ref=value.

IndoorLBS




As for the previous section on IndoorGML, providing a detailed description of OSM data model is

beyond the scope of this document (the reader can refer to the online documentation from

http://wiki.openstreetmap.org). Nevertheless, it is worth highlighting a few aspects of its data model

that are of relevance for indoor services and that can be beneficial for i-locate, highlighting how this

relates to IndoorGML. In order to avoid misunderstanding, within this section, the definition of each

OSM or IndoorGML element will be preceded by the corresponding official namespace, that is:

IndoorGML objects will have “indoorCore” namespace while OSM tags with be preceded by the

“indoor” namespace.

Definition of indoor spaces.

In particular, OSM indoor structures can be modelled through the specific tag indoor:area. The

concept of indoor:area corresponds to the indoorCore:CellSpace concept in IndoorGML. The

indoor:area tag can take the value “yes” to indicate the area being within an indoor space, or it could

be used to define (semantically) the function of a space.

Semantic classification of those spaces through standardised tagging

Such semantic qualification, although it could be totally arbitrary, in i-locate will be based on a well-

structured classification which is based on an existing standard model, called Omniclass™, which is

detailed within the following section6. It should be noted that the very same classification structure

can be provided for semantic description of indoor spaces in IndoorGML when defining the properties

of a indoorCore: CellSpace, thus ensuring high degree of mapping between the two data models.

It should be noted that, while in OSM the characteristics of an indoor:area make it very similar to the

concept of indoorCore:CellSpace (or indoorCore:State in dual space), its complementary

representation of the boundary of the space, which in IndoorGML are defined as

indoorCore:CellSpaceBoundary, can be mapped with a indoor:wall tag, with particular similitudes

when dealing with IndoorGML “thick wall models”.

Definition of connectivity between indoor spaces

In terms of connectivity, indoor:area can be connected through indoor:highway=<footway / Steps /

ramp / elevator / service /pedestrian_street>. In addition, indoor:highway can be also used to

describe specific constraints such as opening hours or restriction of access, something that in

IndoorGML can be achieved through use of indoorCore:MultiLayeredGraph.

It should be noted that OSM connections provided through indoor:highway are based on connection

points tagged as indoor:door=<value> which could be mapped to indoorCore :ConnectionSpace or

nodes of the IndoorGML NRG. In addition, the OSM concept of indoor:entrance corresponds to the

concept of “anchor” in IndoorGML which maps to the indoorCore :AnchorSpace class.

6 From a practical point of view, this will be achieved through the portal infrastructure that will allow selecting

a classification of an indoor space, based on the existing i-locate specialisation of OmniClass™ [17] as detailed

within Appendix 1 to this document.

http://wiki.openstreetmap.org/




Fig 12: the OSM structure where indoor:area (the border of the rooms in red) are linked through an indoor:highway (the blue graph connecting the rooms) which connects

indoor:door(s) (black circles representing the doors) or to entrance(s) of the building (black diamonds representing the two entrance points at the bottom and top of the figure. Figure

courtesy of Elektrobit Automotive GmbH.

Details of such mapping will be defined in detail during the first phase of development, tested and

used to create translation mechanism that can allow transformation between the different modes.

8.4 i-locate Extended Data Model

The overall data model defined in i-locate is a collection of different models, each responding to the

specific requirements of a feature of the system, namely:

Positioning data model.

Indoor graph and location based services data model.

Asset management data model.

The following sections provide, for each of these data model, the full set of details in terms of data

exchanged, formalism adopted and reference to standards supported.

8.4.1 Positioning data model data model

Positioning information will include both positioning information, such as location update, as well as

information related to the specific localization system being used to localize the asset or the persons.

The overall data model is represented in the following figure.




Fig 13: Overall Positioning data model

Location

The Location data object, models a Location update received through one of the many localization

systems integrated into the i-locate platform. The Location data model includes the following

attributes:

point: coordinates of the location update [mandatory].

localizationSystem: ID of the localization system used [mandatory].

device: ID of the device reporting the location update [mandatory].

Accuracy: accuracy of the position included in the location update [mandatory].

Timestamp: timestamp of the location update [mandatory].

Device

The Device models a device reporting a location update. Example of devices are, e.g., TAGs,

smartphones. The Device data model includes the following attributes:

id: the ID of the device being tracked [mandatory].

name: the name of the device being tracked [optional].

description: description of the device being tracked [optional].

class: Classification is a unique representation of a tag population based on a common set

of attributes associated with the function of the tags or the assets they are attached to. This

field is useful when an application needs to treat asset classes differently, or when the data

collection device needs to apply special logic to a tag based on its type [mandatory].

batteryLevel: battery level of the device [optional].

Positioning:Device

- id: string

- name: string- lastSeen: simestamp- type: string

Gml:PoinPositioning:Location

- accuracy: double- timestamp: timestamp

Positioning:Antenna

- name: string- description: string

Positioning:LocalizationSystem

- name: string- description: string

- type: string




lastSeen: timestamp of when the device was last seen [mandatory].

localizationSystem: the localization system used to track the device [mandatory].

LocalizationSystem

The LocalizationSystem models a localization system integrated into the i-locate platform. Example

of localization systems are, e.g., Quuppa, Zigpos, Wi-Fi-based, etc.. The LocalizationSystem data

model includes the following attributes:

Name: this is the name of the localization system [mandatory].

Description: this is the description of the localization system [mandatory].

Type: this provides a taxonomy of the localization technologies being used [optional].

Antenna

The Antenna models an antenna deployed as part of a localization infrastructure. Example of

antennas are, e.g., Wi-Fi APs, anchors, locators. The Antenna data model includes the following

attributes:

Name: this is the name of the localization system [mandatory].

Description: this is the description of the localization system [mandatory].

8.4.2 Indoor graph and location based services

As mentioned already in section 8.3.1, i-locate will build on top of the IndoorGML open data model.

i-locate will leverage on IndoorGML application schema for exchanging information related to indoor

navigation. IndoorGML can be used for i-locate applications because it supports modelling of a space

which includes components such as rooms and corridors, and constraints such as doors. The

schema also supports all CityGML (and IndoorGML) features.

The first version of IndoorGML addresses standardization demands of indoor LBS and routing

services. Further versions may focus also on other more specific requirements, including indoor

facility management (section 8.4.3). To this extent, in fact, i-locate will contribute to the extension of

the current standard by proposing an additional model for asset management which could extend

the core standard by using concepts of ISO 55000 series on asset management.

The IndoorGML model will be ultimately functional to the definition of indoor navigation graphs which

will be generated starting from the mapping data of the indoor environment through the various

features made available from the portal, as detailed in section 12. To this end, a complete pipeline

for generating graphs, in a semi-automatic way, based on indoor mapping data will be developed as

part of the set of tools integrated within the portal and detailed in section 13.2.4.1.

The persistence layer for IndoorGML (hence XML) data will be ensured through the 3DCityDB SQL

schema, which describes, in great details, a wide variety of objects found in an indoor area, ranging

from the building area itself to doors found within each pilot.

In parallel, urban data management field requires extensive and high-quality geographic data

sources for spatial analysis or application. In the last couple of years the VGI (Volunteered

Geographic Information) has become more attractive to professionals in the geo-information

industry. One of the very strong and active VGI communities is the OpenStreetMap (OSM). OSM




provides very detailed information about the landscape and the street network, allowing users to

contribute and collaboratively edit spatial data.

However, most of the current mapping activities are related to the outdoor environments, and there

is hardly any information available about indoor environments. Therefore, an extension is needed to

the indoor environment for bringing VGI to the next level. In general, people are seeking and even

expecting their well-known outdoor application being adapted to the Indoor context. Indoor

applications require maps on top of each other to deal with floors, zones (security, communication),

as well as the semantic of the indoor environment.

IndoorGML takes into account the last mentioned aspects of the indoor conceptual model.

IndoorGML is used to formalize the indoor graphs and the location infrastructure. In other words,

IndoorGML is just a way to make sure that the information about indoor routes is stored properly.

The routing system can then “read” the graphs, generate the right route (as IndoorGML class) and

then expose this as routing service (based on the OpenLS standard), which has been presented in

section 9.6.

Outdoor graphs

To take into account time tables of public transport, the so-called time dependent approach is used.

In this approach, arrival and departure times at nodes are compared to time tables of public transport

in a path search process. In fact, as detailed later in section 9.6.2, a door-to-door routing request is

broken down into an outdoor-routing part and an indoor-routing part where the building entrance

node defines the cut-off-point. Both the indoor and outdoor routing systems read graph and attribute

data in standard formats and compute routes and associated turn-by-turn directions based on an

internal network file compiled based on this data. Associated to node and links are attributes that

allow the routing system to handle possible routing preferences and constraints imposed by a user.

The routing system for the outdoor environment reads graph data of the multimodal transport

network in OpenStreetMap (OSM) format (road network data) and GTFS (public transport data)

format as input. OpenStreetMap is crowdsourced database of geographic information. It contains

location data from a variety of sources gathered by users. Later, the location data can be edited,

reviewed, and corrected as necessary by others. The OpenStreetMap data contains many geometric

features in the raw OSM dataset that can be saved into a database using different formats as, for

example: PostGIS/PostgreSQL, Microsoft SQL Server Spatial, Oracle Spatial, SpatiaLite/SqLite.

OpenStreetMap uses a topological data structure, with four core elements (also known as data

primitives7):

Nodes are points with a geographic position, stored as coordinates (pairs of a latitude and a

longitude). Outside of their usage in ways, they are used to represent map features without

a size, such as points of interest or mountain peaks.

Ways are ordered lists of nodes, representing a polyline, or possibly a polygon if they form a

closed loop. They are used both for representing linear features such as streets and rivers,

and areas, like forests, parks, parking areas and lakes.

Relations are ordered lists of nodes, ways and relations (together called "members"), where

each member can optionally have a "role" (a string). Relations are used for representing the

relationship of existing nodes and ways. Examples include turn restrictions on roads, routes

7 Source: http://en.wikipedia.org/wiki/OpenStreetMap




that span several existing ways (for instance, a long-distance motorway), and areas with

holes.

Tags are key-value pairs (both arbitrary strings). They are used to store metadata about the

map objects (such as their type, their name and their physical properties). Tags are not free-

standing, but are always attached to an object: to a node, a way, a relation, or to a member

of a relation.

GTFS is for the static exchange of public transport stop and schedule data. It allows public transit

agencies to publish their transit data and developers to write applications that use that data in an

interoperable way. The schedule data is sent as a set of Comma Separated Values (CSV) table,

which is saved into the database. Using the GTFS format, the routes of public transport are defined

in terms of sequence of stops and corresponding time tables. Timetables define arrival and departure

times at stops for regular (weekdays) and non-regular services (Saturdays, Sundays and holidays).

The time table data are stored at nodes using the so-called time dependent approach.

Indoor graphs

The routing system for the indoor environment, detailed in section 9.6.1, reads graph data of the

indoor environment in IndoorGML format. The graph defines the nodes and links representing

locations (rooms, halls, etc.) and transport connections between locations. Stairs and elevators are

special links that interconnect different floors in a building (vertical transport). For indoor

environments the coordinates defining the geographic position of a location (a node) is extended to

also include a Z coordinate (in addition to a X and Y coordinate).

Just as in the outdoor case, the turn-by-turn directions associated with a route plan are specified as

text strings and geographic positions when text strings are to be displayed (e.g., in 5 meter before a

turn go to the right or left). The contents of the text strings, i.e. the way the directions are formulated,

are adapted to the indoor environment: instruction protocols that may work well for outdoor

environments may not work well for indoor environments and vice versa. However, the structure of

the turn-by-turn directions is the same.

Associated to node and link objects are attribute data. Two sets of attributes are assumed – one for

nodes and one for links. The attribute data should allow the routing system to evaluate preferences

and constraints for routes. In terms of preferences the user may wish to minimize travel distance

(shortest route), minimize the travel time (fastest route) or minimize inconvenience (penalties for

slopes and for stairs).

In terms of constraints, the user may demand to avoid certain features such as stairs. When in a

wheel chair certain features may need to be avoided as well namely those features that prohibit the

use of wheel chair (such as slopes and stairs). Thus, to take into account all possible preferences

and constraints, the attribute data for links should include as a minimum set: type of link (stair,

elevator, ordinary way); slope; length (distance); travel speed by mode and accessibility by mode.

For this the system will leverage on the intrinsic semantics of IndoorGML which allow definition of

transition spaces which can be architectural features such as stairs etc.

Anchor Nodes

As detailed in section 9.6, the routing system supports integrated indoor-outdoor routing based on a

component for indoor and a component for outdoor routing. Internally, a routing request is broken

down into an outdoor and an indoor routing part divided by the entrance point of the building. The




routing responses generated for the two parts are re-integrated at this point in order to present a

single overall door-to-door route plan to the user.

However, connecting indoor and out spaces is an important aspect of the indoor spatial information.

In general, every indoor space contains at least one entrance, and it can be used to connect indoor

and outdoor spaces. IndoorGML offers a concept to connect indoor and outdoor spaces called

anchor node. The anchor node may include additional information for converting indoor coordinate

reference system (CRS) to outdoor absolute CRS.

Figure 12 shows an anchor node that is connected to the ground transportation network. The anchor

nodes are not only defined within IndoorGML data but also accessible from external data. In order

to link the indoor space with the outdoor space some conversion parameters need to be defined. In

many cases, a relative CRS is applied to an indoor space and it is necessary to convert the

coordinates of each point of indoor geometry according to the absolute outdoor CRS. If the indoor

CRS is relative, the anchor node may contain the following parameters for transformation between

spaces:

1 rotation origin point (x0, y0, z0).

Rotation angle (a, b, g, along x, y, and z-axis).

Rescaling factor (sx, sy, sz).

Translation vector (tx, ty, tz). In case the indoor CRS is absolute, the conversion parameters are not necessary. However, even

in this case the anchor nodes are still needed. The connectivity between the indoor spaces and

outdoor spaces has to be represented. Also, using anchors we can facilitate seamless services

between outdoor radio map and indoor positioning.

Fig 14: Anchor Node Connecting Indoor and Outdoor Networks. Source: [10].

8.4.3 Asset management data model

A specific data model has been defined for asset management purposes. It should be noted that, in

order to maximise references to existing concepts and data, and to ensure maximum flexibility yet




leaving to the bare minimum the creation of new classes, the model explicitly refers to concepts from

the following standards:

CityGML [9].

IndoorGML [10].

ISO 55000:2014, Asset management - Overview, principles and terminology [5].

ISO 55001:2014, Asset management - Management systems – Requirements [6].

ISO 55002:2014, Asset management - Management systems – Guidelines for the application

of ISO 55001 [7].

ISO 8601:2004, Data elements and interchange formats – Information interchange –

Representation of dates and times [8].

ISO 19111, for simple positioning data [15].

In particular, the asset management data model has been defined as possible further module of

IndoorGML within a specific namespace “indoorAssetManagement” and it comprises the following

main classes:

indoorAssetManagement:Asset,

indoorAssetManagement:AssetType,

indoorAssetManagement:Process,

indoorAssetManagement:ProcessInfo,

indoorAssetManagement:ProcessTime,

indoorAssetManagement:Activity,

indoorAssetManagement:ActivityInfo,

indoorAssetManagement:Event,

indoorAssetManagement:Operator,

indoorAssetManagement:Person.

Each of the following sections details, for each of the aforementioned classes, their meaning, typical

use and properties.

indoorAssetManagement:Asset and indoorAssetManagement:AssetType

From a logical point of view, one of the most important components of the model is the concept of

“Asset”. Here the concept of asset follows the formal definition given by the ISO 55000 standard

according to which an “asset is items, thing or entity that has potential or actual value to an

organization” [5]. According to the very same ISO 55000 standard an asset has a lifetime, which

becomes an attribute of the asset.

Within the i-locate data model, assets are represented as generic hierarchical structures, as assets

may be (and often are) composed by components and sub-components that in turn need to be

maintained. In addition, the structure needs to be generic because attributes are specific for every

type of asset.




Fig 15: UML class diagram of Asset Management data model proposed in i-locate

In order to better support a generic data model an AssetType class has been defined, providing

support for attributes such as names and types. Hierarchical structuring of AssetType classes allows

for great deal of flexibility in the definition of types of objects to be subject to asset management




tasks. The hierarchical approach is illustrated in the following image, hierarchical use of Asset and

AssetType objects introduces significant degree of flexibility, allowing for modelling of logical

relationships (in terms of asset types) as well as physical relationships (such as part/sub-part

relationship).

It should be noted that assets can be intrinsically very different, ranging from small portable items,

that can be abstracted with a simple position in space, to very complex and articulated assets such

as complex HVAC facilities with a large footprint or volume. For this reason each asset can rely on

GML Geometries (either a point, curve, surface or solid) or simply use the concept of Cell ID within

IndoorGML to relate the position of the asset within the building.

Fig 16: Example of a composite asset. AssetType and Asset objects are instantiated

indoorAssetManagement:Process

The ISO 55000-1-2 series also introduces the concepts of processes and activities. It should be

noted that ISO 55000-1-2 does not define how a process should be modelled instead, it rather

describes what to consider in order to create high quality processes.

Starting from this principle, i-locate has defined a data structures to manage processes and activities

based on the two concepts of Process and Activity.

A Process defines all the most important aspects of an overall maintenance process (e.g. “winter

check”) which, in turn, relies upon a variety of different Activity objects (see following section). In

particular, a Process can be used to list the set of Activity objects, it allows defining the events that

trigger the asset management activities and it provides references to the operator(s) in charge of

processes. It should be noted that the class Process does not contain any information about the

executions of the project per se, being this intrinsically different for each maintenance activity, while

instead its structure defines only how the activity has to be performed.

The mandatory attributes of Process are:

AssetType: PumpType

AssetType: InverterType

AssetType: PowerSupplyType

AssetType: BatteryType

AssetType:

CableType

AssetType: Pump1 (PumpType)

AssetType: Inverter (InverterType)

AssetType: PowerSupply (PowerSupplyType)

AssetType: BatteryType (BatteryType)

AssetType: CableType (Cable Type)




ProcessTime: the date when the process is due. This is defined as xs:dateTime according

to ISO 8601 [8].

Operator: the operator in charge of the management of the process;

A sorted list of objects of type Activity as detailed in the following section. It should be noted

that more complex workflow-like approaches could be implemented in the future in extension

to regular ordered lists of actions. Although this is currently outside the scope of i-locate, this

would allow definition of much more articulated conditional workflows (e.g. when action A is

completed then perform action B).

indoorAssetManagement:Activity

The class Activity provides a definition of a corresponding asset management activity, i.e. a specific

procedure to be carried out (e.g. “replace air filter”), together with other ones (e.g. “check oil

pressure”), in the context of a Process (e.g. “winter check”).

The attributes identified are:

Name: the name of the activity, for instance “Replace electric engine”.

EstimatedDuration: Estimated duration in minutes.

ExecutionState: an integer (from 1-4) which defines a set of different states (completed,

pending, to be re-executed, closed).

Description: a brief text-based description of the activity.

Full Description: an external link (as URI) of the resource providing a full description of the

activity.

indoorAssetManagement:Event

The Event defines the condition that triggers a maintenance process. For instance, this could be the

expiring date of the battery installed within a portable medical device, which being replaced every

24 months. The most important properties of this class are:

Name: the name of the event.

StartTime: the time when the event is scheduled. This is defined as ISO 8601 xs:dateTime.

indoorAssetManagement:Event can be then subclassed by PeriodicEvent, which has an additional

attribute, that is Periodicity, that is the duration of the interval within two recurring events (e.g. 100

days).

The example in the figure below will help understand the relationships between different classes.

The two Process object represented in the graph include two Activity objects; they are connected to

operators (see class IndoorAssetManagement:Operator detailed in section 9.10) who have specific

responsibilities. Processes are connected to Events that can trigger processes.

indoorAssetManagement:ActivityInfo

For each Activity it is possible to specific additional information regarding the specific execution of

an activity through the ActivityInfo class which includes the following attributes:

Operator: the person who has executed the activity (refer to section 9.10 for additional

information).




Activity: the corresponding object (of type IndoorAssetManagement:Activity).

Asset: the related asset (of type IndoorAssetManagement:Asset) subject of the asset

management activity.

Notes: a list of ancillary information related to the Activity expressed as JSON.

Fig 17: The objects representing two IndoorAssetManagement:Process objects. They are connected

to corresponding assets and eventsindoorAssetManagement:ProcessInfo

This object includes information related to a specific occurrence of an event. This includes

information such as:

Operator: the person who notified the malfunction requiring a new Process.

Process: the corresponding IndoorAssetManagement:Process.

Asset: the related asset subject of the Process.

Notes: a list of ancillary information related to the Activity expressed as JSON.

Role: Worker

Event: PeriodicBatteryCheckProcess: PeriodicBatteryCheckAsset: Battery1

Activity: CheckState Activity: SubstituteAsset Activity: TestBattery Activity: TestPowerSupply

Process: BrokenPSAsset: PowerSupply1

Operator: Mike

Event:

BrokenPowerSupply




Fig 18: Objects related to a process execution

The previous figure shows an example of the aforementioned model. A ProcessInfo object holds a

references to an ActivityInfo object for each of the operations which constitute the process

indoorAssetManagement:Operator

The ISO 55000 standard on Asset Management highlights the importance of establishing a

framework for management of responsibilities. A strong management structure with clear roles is

essential to ensure control over complex organizational processes. The data model proposed allows

definition permissions to manage both responsibilities assigned to specific persons or groups.

Every process has an appointed person or role that will take account of the whole execution of the

process.

Fig 19: Operator hierarchy: representing people and groups

indoorAssetManagement:Role

This object allows a convenient way to group people by the tasks they are responsible for. The

structure of a role is hierarchical, so is it possible to compose roles to create new ones. Roles at

higher layers include the capabilities of roles at lower layers. This object includes the an attributes,

called Description, which provides a brief description of the role.

indoorAssetManagement:Person

This object refers to a physical person, who is identified through a unique identification code for the

whole organization. The identification code may be retrieved by an existing system in case of

integration with other software systems. This object includes the following attributes:

Process: PeriodicBatteryCheckProcessInfo

Timestamp : int

ActivityInfo1

-notes

ActivityInfo2

-notes

ActivityInfo3

-notes

Activity: CheckState Activity: SubstituteAsset Activity: TestBattery




ID: the unique identification code used within the company.

FirstName: the first name of the person.

LastName: the surname of the person.

Fig 20: Example implementation of responsibilities subsystem

This example show how to create a hierarchical structure of roles. It is worth noting that, thanks to

this structure, it is possible for a person to play more than one role at the same time. In this

implementation, for instance, Mike has the authorization to perform all the processes assigned to

Intern role, but not the processes assigned directly to John.

Example of use case

Richard Flynn is leader of the maintenance-team of the west area of Hyde Park and he has to look

after at the management/works of 13 gardeners. The tasks of the team is ranging from the pruning

of plants and placement of new flowers/plants to the configuration and control of irrigation systems.

One of the tasks of the West Hyde Park Crew is the planting of tulips in various areas of the park.

The process describes all the activities necessary to complete the task. The first activity concerns

the retrieval of the plants type to be planted; the activity defines the amount of plants, the quality and

the vivarium in which get them. The subsequent activities define the areas where the tulips should

be planted: every activity defines a specific area of the park for tulips. The spatial properties of the

activities are used to indicate the areas.

The park is divided logically in “west” and “east”; Both are divided into zones according to the needs

of the maintenance of the park. The western part is divided into 4 sub-zones; the activities of the

preceding paragraph refer to these logical areas.

Inside the structure that represents the park (Asset), there are also other different information: the

irrigation system and the fountains of the park.

In the object “Hyde Park Asset” data are structured according to the class Park (AssetType). It

defines an object “Park” that can be divided into sub-areas with different hierarchical levels including

fountains, enclosed areas for dogs, benches and tables.




Fig 21: Model of the assets of Hyde Park

Fig 22: The AssetType structure that describes the structure of a generic

Fig 23: Exampleof a second park model-based on “Park: AssetType”




At the beginning of the process an instance “ProcessInfo” is created. This stores information about

the person/responsible that has to carry out the process, Richard Flynn, and the date/ start time of

the performance. In addition to this basic information the various colleagues of Richard who will work

on the same process.

The activities carried on leave a trace: Richard can select the outcome of each activity, and, if there

will be any issue within the specific event, he will provide the necessary information (using objects

ActivityData) to describe the problem.

Meanwhile, Peter Lloyd, a colleague of Richard operating in the West side of the park, performs the

reconfiguration of the irrigation system of the area, in order to adapt it to current season and the new

flora. The reconfiguration process can be made using the only action Reconfigure Irrigation System.

Richard and Peter have different responsibilities and duties: Richard is part of the “West Hyde Park

Crew” and he is the Leader of the Team (so has two roles: “West Hyde Park Crew” and “Crew

Leader”). Peter is a simple gardener of the same crew (so he has the only role “West Hyde Park

Crew”). The role of “Crew Leader” gives access to processes and information of the other teams, in

order to facilitate coordination. The processes/works regarding the west area are associated to the

role “West Hyde Park Crew”, so that other teams can run the relative processes. The roles up in the

hierarchical structure are qualified to carry out the processes. In this case the “Support Crew 1” can

carry out maintenance of the entire Hyde Park and Green Park.

Fig 24: The roles structure of Hyde Park, which is connected with the operators of the example (Person type)

The system takes care about the generation of events related to the plants, to be placed depending

on the configuration defined in the back end. The events that concern “pruning” are periodic; the

events that concern the positioning of the flowers are instead configured from time to time because

they are subject to many other various factors.

8.5 Semantic description of indoor spaces

In order to provide a standardised way to describe, from a semantic standpoint, indoor spaces, i-

locate will use a well structured classification by function: the OmniClass™ Construction

Classification System (known as OmniClass™ or OCCS, http://www.omniclass.org/). This is a

(Simple Knowledge Organization System) SKOS-based classification system for the construction

industry, which will be used in i-locate project as the knowledge base to classify and label spaces of




the buildings for indoor localization and guidance. This classification will be used for the users to

select the classification of indoor spaces from a list of pre-set options.

Few concepts not necessary in the scope of i-locate have been removed from the original OmniClass

classification table. The proposed classification has mainly kept those elements required to guide

citizens and professionals inside public buildings (hospitals, municipalities, universities). For

example, the concepts Space Planning Types, Void Areas, Wall spaces (and their sub-concepts)

are concepts of interest for the construction industry, and not for the indoor navigation and therefore

have been removed. The full classification, due to its extensive length, has been included within a

separate Appendix 1 to this document.

On the other hand, the proposed classification has retained not only concepts directly related to the

use case of the project, but also to the concepts that could be useful when the implementation of

concepts will be extended in other indoor environments. Within this approach, two concepts, missing

in the OmniClass classification (Stairlift and Cafeteria) have been added. Since OmniClass assigns

a unique code to each space, two custom codes, prefixed by the literals “c-“, have been created.

As a further step, from the OmniClass classification of spaces by function, a taxonomy in SKOS

(Simple Knowledge Organization System), was created. This is a common data model for sharing

and linking knowledge organization systems via the Web for representation of thesauri, classification

schemes, taxonomies, subject-heading systems, or any other type of structured controlled

vocabulary. The advantage of having a SKOS taxonomy can be to allow automatic classification,

space labelling or reasoning systems in i-locate. In SKOS Concepts can be organized in hierarchies

using broader-narrower relationships, or linked by non-hierarchical (associative) relationships.

Starting from this a taxonomy was defined as an OWL ontology using Protègé 4.3.x, with the

following object properties, data properties and annotations according to the semantics of SKOS.

Essentially:

Each concept of OmniClass is an individual instance of the Concept class (direct child of

Thing) in OWL;

A SKOS concept A narrower than another concept B is modeled by the object property

narrower linking the individual B to the individual A (B narrower A). In the asserted ontology,

we did not state explicitly that B is broader than A. Since narrower and broader are defined

as inverse properties, a reasoner (HermiT) automatically infers that the narrower individual

is linked to the broader one by the property broader (A broader B);

The definition of an OmniClass concept is modelled in OWL as the value of the annotation

property definition;

The code of an OmniClass concept is modelled in OWL as the value of the data property

notation.

Lastly, the OWL-SKOS inferred taxonomy (without definitions) was exported in text format for human

readability. The full text has been included within Appendix 1.

8.6 Versioning

Versioning is the capability of the system to track history of changes to mapping data based on

facilities provided at database level. The fact that the i-locate portal has been designed as an open

data portal based on crowdsourced data, similar to OpenStreetMap for indoor data, will require the




system to support versioning of mapping data to ensure that, in case of introduction of wrong

mapping information overriding existing correct one, the latter can be recovered at later stage.

Versioning will provide a way to create and manage different versions of a resource within the i-

locate databases. i-locate will therefore have to support versioning because, otherwise, after a

resource (e.g. table, column) will be updated, its previous contents and properties will be lost.

Fig 25: Database Versioning

8.6.1 ORACLE CM SDK

It should be noted that, as already illustrated in Fig 1, while the toolkit will rely on open source

DB, the portal will rely, at the data level, on an ORACLE database with the “Spatial and Graph”

extension. Specifically, i-locate will leverage on the ORACLE versioning functionalities which allow

application developers and DBAs to version topologies in the Oracle Spatial topology data model.

The Oracle Spatial topology data model manages data about points (nodes in our case), edges (links

in our case), and faces (boundary areas in our case – e.g. buildings, rooms) in a topology.

Topological relationships include such relationships as contains, inside, covers, covered by, touch,

and overlap with intersecting boundaries. Topological relationships remain constant when features

are edited or the coordinate space is deformed, such as by twisting or stretching.

Topologies are useful when there is a high degree of feature editing and a strong requirement for

data integrity across maps and map layers which is a mandatory aspect for i-locate. Additionally,

topology-based queries typically perform faster for queries involving relationships such as

adjacency, connectivity, and containment.

In terms of the technology used, Oracle CM SDK provides a flexible versioning model capable of

supporting a wide variety of processes for authoring and publishing information. Most PublicObjects

can be versioned. PublicObjects are objects that Oracle CM SDK users can access, such as

User 1 User 2

Versioning

Database Release v.1

Database

Release

Database Release v.2




documents and folders. These objects descend from PublicObject in the Oracle Content

Management (CM) SDK class hierarchy.

The four main versioning classes in Oracle CM SDK are Family, VersionSeries, VersionDescription,

and Document. A non-versioned document in the repository is represented as an instance of the

Document class, or a custom class that extends Document. The instance possesses structured

information describing the document, such as Name, Owner, and CreationDate. These are

represented as attributes on the Document class. Documents also possess unstructured content

represented as an instance of ContentObject referenced by the ContentObject attribute on the

Document class.

When a document is versioned, Oracle CM SDK creates three additional types of objects to manage

all of the versions created during the document's life cycle: a Family, VersionSeries, and

VersionDescription, illustrated in the following figure.

Fig 26: Oracle CM SDK types of objects

Family: When a Document is versioned, the Family Object represents the document,

collecting all the versions created for the document.

VersionSeries: The Family groups the versions into VersionSeries, which represent a series

of sequential changes made to the document. Each version in a VersionSeries represents

the state of the document at a particular point in time. The order of the versions in the

VersionSeries represents the order in which changes were made to the document.

VersionDescription: Within a VersionSeries, each version of the document is represented

by a VersionDescription describing the context of the version within the series, such as its

sequence number (such as 1, 2, 3). Each VersionDescription references the instance of

Document that contains the attributes and content for that particular version of the document.

The Oracle CM SDK can provide versioning functionality in a custom application and can create a

new version of a document in few simple steps. To this end, the versioning application uses the

following API calls:

The application calls the reserveNext() method on the document's VersionSeries object to

prevent other users from making changes at the same time. The application sets the




Reservor, ReservationDate, ReservationComments, and WorkPath attributes on the

VersionSeries to provide users with information about who, why, and when it was reserved.

When the user edits the document, the changes are to be stored as a new version of the

document. The application creates a new instance of the Document class to store the

modified content and attributes. Then, the application calls the newVersion() method to

create a new VersionDescription and set the values for the new version's VersionLabel,

RevisionComments, and PublicObject. It sets the PublicObject attribute on the new

VersionDescription to reference the new Document instance.

8.7 Security and authentication

The data layer is secured by the native capabilities of the database engine and by provision of access

controls through the middleware layer using a combination of SAML (Security Assertion Markup

Language), XACML (eXtensible Access Control Markup Language) and digest based authentication

for users through the web-interface (refer to later sections of this document). Data access for read

only operations shall be offered as the default condition. Data transfers to the middleware shall be

through secured tunnels (IP Security - IPsec tunnels, Transport Layer Security - TLS tunnels or any

compliant Virtual Private Network - VPN technology) that offer the following capabilities:

Source authentication (by source identifier, so IP address for IPsec, module name for TLS)

Payload integrity proof and verification;

Payload confidentiality (e.g. for IPsec by use of the Encapsulating Security Payload - ESP

tunnel mode)




Fig 27: Identity Identifier Service




9 Middleware Layer

9.1 Introduction

Within the i-locate architecture, the middleware layer will provide a set of services needed for

enabling location-based services and other ancillary features as defined within the use cases of i-

locate [1]. The focus will therefore be on accessibility to location services (both indoor and outdoor),

complemented by advanced functionalities for building richer and more effective applications. This

includes features for facilitating the design and development of services based on location data, such

as, e.g., geo-fencing or location analytics.

9.2 Overall approach

At the high level, the middleware layer will include a number of interoperating components, working

coherently to provide application developers with the necessary functions to quickly and easily build

location-based services.

The overall architecture of the middleware layer is depicted in i-locate middleware componentsFig

28. Components can be clustered in three logical levels.

The first level provides the core localization services for both indoor and outdoor environment. It

includes:

Outdoor localization: this component provides positioning information for outdoor

environments. It comprises connectors to a GNSS localization module which will be based

on the Galileo service and -if it not available- on the GPS with additional EGNOS

enhancement.

Indoor localization: this component will provide positioning information for indoor

environments. It will provide connectors to various indoor localization technologies. Within

the scope of i-locate the platform will support:

- 802.15.4-based eeRTLS technology by ZigPos.

- BLE-based HAIP technology by Quuppa.

- Commercial Wi-Fi-based technologies.

- Eye3 camera-based tracking system developed by Trilogis8.

For each supported technology a connecting module will be provided.

Monitoring: this component provides the system administrator with a suitable interface for

controlling the state of the system (e.g., tags running out of battery, locators not functioning

etc.).

Configuration: provides configuration handlers for the indoor localization subsystems,

including, e.g., setting and getting the local reference point coordinates.

8 It is worth noting that camera-based tracking system called Eye3 represents a “background” and not a “foreground” of i-locate, which is owned by Trilogis and that will be licensed free of charge to the pilot sites for the whole duration of the project.




Location Resolver: the location resolver will provide a high level abstraction of the

localization technologies integrated into the platform. Further, it will implement a minimal level

of persistence for storing the data retrieved through the various localization technologies

integrated into the infrastructure. Such level of persistence will be used to maintain an active

state of all the objects being track and for a fast response. Further, it might not always be

possible to query the location of objects. It is then necessary to store such information

whenever available

The second level provides a number of location-based services enablers. This level includes

services providing features such as:

Routing: this component provides services for seamless routing i-locate end users

regardless if they move within outdoor or indoor environments.

Identity management: this components provides services for supporting federated identity

management of people and object IDs in the context of the i-locate systems. Identity

management: provides services related to identification of objects and users (including

authentication and authorization). This would be for instance used to associate, from a logical

point of view, the position of a user to a mobile device (e.g. the smartphone with GPS receiver

he uses) and to a smart badge with indoor location technology. Both items (and the

information they generate) would be logically associate to the same person and used to

augment each other’s precision.

Geofencing: this component provides geo-fencing support both to applications as well as to

other i-locate internal components. This will be essential, for instance, to receive alerts

whenever a user (or an object) leaves or enters a given space.

Location analytics: this component provides some basic analytics functionalities for location

data. It can be used, e.g., for tracking an object and compute statistics about its behaviour.

The third level finally provides a number of value-added services, which can be readily deployed,

including:

Asset management: this component provides services for localization of devices/assets in

indoor environments for management and optimization purposes.

Crowdsourcing: this component connects to the CivicFlow crowdsourcing platform. It will

provide appropriate handlers to crowd-source geographical information from i-locate services

users.




Fig 28: i-locate middleware components

Each component is further detailed in the following subsections, where interfaces are detailed. In

general, components expose a REST API; web technologies and protocol (HTTP/HTTPS) are used

for accessibility and connecting the various components.

Asset Management Croudsourcing

Sp

ec

ific

LB

S

En

ab

les

Ge

ne

ric

LB

S

En

ab

les

Routing

Identity Management

Geofencing Location Analytics

Co

re

loc

ali

za

tio

n

se

rvic

es

Spatial Solver

Configuration

Monitoring

Da

ta S

tora

geService Bus

CIV

ICF

LO

W

i-locate middleware services

Outdoor Localization

Ga

lile

o

Ca

me

ras

GP

S/E

GN

OS

ISO 244130 Compliant Localization

Indoor Localization

Qu

up

pa

Ca

me

ras

ee

RT

LS

Wi-

Fi

Upload/

Download

OGC Spatial

Proxy




9.3 Identity Management

Identity management is the name given to the methods of allowing a relying party to identify the

principal and determine if service is to be offered. The overall architecture of identity management

is intrinsically complex and can be represented in a number of ways. The UML class diagram in the

following figure illustrates some of this complexity using an ontology like representation.

Fig 29: Ontology like view of identity and identifiers

This can be further mapped to the more “code” like model given in Error! Reference source not

found. where the thing being identified is the Principal and the entity requiring it to be identified is

the Relying party.

Principal – in SAML and similar SSO protocols also referred to as User or User-Agent.Often

synonymous with the end-user or an electronic agent of the end-user.

Identity Provider (IdP). The organization generally required to authenticate the Principal and

to provide an assertion of this authentication to the Relying Party.

Relying Party (RP) – in SAML and similar SSO protocols also known as the Service Provider.

An organization providing a service to the Principal. The Principal may authenticate to the

RP but, the RP is also willing to rely on an assertion provided by the IdP.

Class IdentityIdentifier Service

IdentityProvider

Identifier Credential

Authentication

SystemElement

ServiceUser

UserProfile

Person

Issues Verifies

IsAuthenticatedUsing

Requires

HasA

Is accessed viaIsAliasOf

ExpressesPreferenceIn

CustomisesProvisionOf




Fig 30: The three primary roles in the common IdM thematic model

The identity provider in i-locate may take the form of an external (3rd party) or be an internal software

role.

Each service in i-locate offering service to an identified object that requires to identify that object

shall be considered a relying party.

Each user or service in i-locate that is using the service of any object or service in i-locate shall be

considered as the principal.

Fig 31: SAML approach to IdM and authentication. Source: Wikipedia [14].

From the point of view of the backend services, the middleware shall be considered a trusted party

while, from the point of view of the user, the middleware shall be considered as a trusted party.




9.4 Localization services

9.4.1 Outdoor localization

The outdoor location service of i-

locate will essentially rely on three

very high level types of location

technologies:

GNSS (e.g. Galileo EGNOS,

GPS, GLONASS).

Wi-Fi.

Cell Tower.

EPSGR will develop a Galileo

compliant service, which will achieve,

access to more accurate positioning

information along with integrity

information to smart devices through

a simple API. i-locate will

encapsulate the upcoming Galileo SDK core and will operate as a proxy between it and the user

application in order to leverage on the Galileo technology with far better accuracy, in terms of

positioning, if compared to GPS.

Galileo is a Global Navigation Satellite System (GNSS) which will provide a high-precision

positioning system independently from the Russian (GLONASS), US (GPS) and Chinese

(Compass) systems.

For outdoor localization i-locate application will use Galileo service when the source code will be

publicly available. The first release of the i-locate application will support the EGNOS - European

Geostationary Navigation Overlay System. EGNOS service provides various features, including an

enhanced accuracy and integrity/availability module, management of the data received from the GPS

receiver and computation algorithms for calculations of position correction.

EGNOS currently offers two choices, when it comes to ready to use toolkits:

EGNOS SDK: The EGNOS SDK (Software Development Kit) applies the full theory of

EGNOS and GPS starting from the raw data provided by a GNSS chipset, on a broad set of

platforms (iPhone, Android, Blackberry and Windows Phone). The caveat is that as, so far,

GPS chips inside smartphones are "blackboxes", the only way to retrieve the GPS raw data

needed to apply EGNOS corrections is to rely on an external GNSS receiver connected to

the smartphone by Bluetooth.

SIGNATURE toolkit: this provides EGNOS corrections for Android phones, by applying

correction data received via the SISNeT (Signal in Space through the Internet) internet

services to the GPS position calculated by the phone's internal GNSS chipset.

Additionally, in case the external receiver is not Galileo capable or is out of view of Galileo satellites,

the GPS or EGNOS Data Access Service (EDAS) will be used to deliver the required positioning

information.


Sp

ec

ific

LB

S

En

ab

les

Ge

ne

ric

LB

S

En

ab

les

Routing

Identity Management


Co

re

loc

ali

za

tio

n

se

rvic

es

Spatial Solver

Configuration

Monitoring

Da

ta S

tora

geService Bus

CIV

ICF

LO

W


Ga

lile

o

Ca

me

ras

GP

S/E

GN

OS


Indoor Localization

Qu

up

pa

Ca

me

ras

ee

RT

LS

Wi-

Fi

Upload/

Download

OGC Spatial

Proxy




However, it is important to highlight that the release of the full set of aforementioned features will

depend upon availability of Galileo service together with the Galileo library source code.

9.4.1.1 APIs

In terms of APIs the following call has been designed to ensure access outdoor location data. The

service will produce, as a result, a JSON response which will include the fields as detailed in the

following table.

getOutdoorLocation

REQUEST

Item Type Short description

dgnssType_id string this field identifies the Global Navigation Satellite System to be used by users’ smart device (e.g. GPS, EGNOS-GPS, and Galileo)

station_id: integer The id of the GPS/Galileo reference receiver.

RESPONSE

dgnssType_id string -

Station_id integer -

datum_name: String standard name e.g. ETRS89_ETRC_LCC

dx Real x in meters

dy Real y in meters

dz Real z in meters

hAccuracy Real in meters horizontal accuracy

vAccuracy Real in meters vertical accuracy

9.4.2 Indoor localization

The goal of the indoor localization component is to provide location information relative to i-locate

object(s), specified by a given unique ID.

The key functionality provided by this module is to return the position of a given object; this is offered

in both push and pull mode.

In push mode data is pushed from the localization subsystem to the data layer, where it is stored.

In pull mode the data can be requested by an external entity to the localization subsystem. Ability of

working in push mode requires the deployment of an appropriate agent within the relevant

localization subsystem to ensure that data gets consistently delivered to i-locate.

Positioning information can be provided as relative data (x,y,z triple with respect to an indoor

reference point) or absolute. A function able to return an estimate of the current position of the object

(based on the last available information) is also included.

Another functionality provided is to return information on a specific object. This includes control

information exposed by the specific localization subsystem being used.




It should be noted that the approach followed is totally hardware independent and scalable. This

allow connecting a variety of different technologies in a seamless way. However, for the sake of

practical use within the pilot sites, the indoor localization component will be initially extended to

provide support to a few existing positioning technologies needed for the pilot use cases. In

particular, it will support:

802.15.4-based eeRTLS technology by ZigPos.

BLE-based HAIP technology by Quuppa.

Commercial Wi-Fi-based technologies.

Camera-based location system through computer vision techniques.

Each indoor localization technology will be connected through an appropriate “plugin”. The APIs

have been designed to be reusable and extendible, with the aim of providing vendors with an

interface easy to implement for their own localization technology, which could be then used

seamlessly in i-locate applications.

Four modes (three pull and one push mode) APIs have been planned as detailed in the following

sections.

9.4.2.1 1st mode API - pull

The first pull mode allows an application to get the current (or last seen) location of a given object.

The request shall specify the localization technology to be used (e.g., Wi-Fi or eeRLTS) and an

optional field with the maximum age of the data. The response is a JSON file including the positioning

information of the object (absolute position), timing information (when such position was measured)

plus a number of additional (optional) fields that can be used by the application to optimize the usage

of the position information. The following table shows a syntax of the typical request and response.

getIndoorLocation

REQUEST

localizationSystem_id String mandatory, it identifies the localization system to be used. At the moment the following values are supported: ‘eertls’, ‘quuppa’, ‘gnss’, ‘gps’, ‘wifi’

obj_id optional, if this parameter is specified, only information associated to the requested object is returned. If this parameter is not specified, information on all objects being tracked are returned.

positionType Real optional, defines whether the positioning information should be returned as absolute or relative to the local reference point. Values supported: ‘absolute’, ‘relative’. When the parameter is not specified, ‘absolute’ is used as default value.

maxAge Real optional, defines the maximum age in millisecond for a stored information to be considered valid. If no information that satisfies this constraint is available, then an empty result is returned.




responseTimestampEpoch

timestamp when this response was generated as ISO 8601:1988 (E) format (Optional, can be used at the application level).

RESPONSE

obj_id Integer unique object id.

localizationSystem_id String id of the localization system used.

positionTimestampEpoch

timestamp of the last measured position expressed in ISO 8601 : 1988 (E) format

positionType Real ‘absolute’ or ‘relative’, defines how to interpret the data in the position field.

position Real estimated position of the object according to ISO 19111 format (if positionType is ‘absolute’) or (x,y,z) expressed in meters (if positionType is ‘relative’).

positionAccuracy (optional)

Integer estimated accuracy in meters of the position fix. In 2D, this field describes the radius of a circle cantered at the given (X, Y) coordinates. In 3D positioning, accuracy refers to the radius of a sphere. If it set to 0, it means that this feature is not supported by the given localization subsystem.

9.4.2.2 2nd mode API - pull

The second pull mode API is used to obtain additional information about a given object. This can be

used, for instance, to get information about a locator/antenna deployed as well as to get additional

information about an object being tracked. The response is a JSON file including a number of fields

provided by the specific localization subsystem indicated in the request, plus a number of mandatory

fields including the last position measured and the corresponding timestamp.

For ‘static’ objects (e.g., locators/antennas) the timestamp field is set to 0.

getObjectParameters

REQUEST

localizationSystem_id string mandatory, identifies the localization system to be used. At the moment the following values are supported: ‘eertls’, ‘quuppa’, ‘gnss’, ‘gps’, ‘wifi’

obj_id integer mandatory, only information associated to the requested object is returned. If this parameter is not specified, information on all objects being tracked are returned.

positionType real optional, defines whether the positioning information should be returned as absolute or relative to the local reference point. Values supported: ‘absolute’, ‘relative’. When the parameter is not specified, ‘absolute’ is used as default value.

RESPONSE

obj_id integer unique object id.




positionType string ‘absolute’ or ‘relative’, it defines how to interpret the data in the lastPosition field.

position real estimated position of the object according to ISO 19111 format (if positionType is ‘absolute’) or (x,y,z) expressed in meters (if positionType is ‘relative’).

positionTimestampEpoch

timestamp of the last measured position expressed in ISO 8601 : 1988 (E) format. If ‘0’ is returned, the data corresponds to a static object (typically a locator/antenna).

Additional parameters (system-dependent)

string This may include, e.g., firmware version, battery status, serial number, date of installation etc.

9.4.2.3 3rd mode API - pull

The third pull mode API can be used to obtain an estimate of the current position of an object. It uses

the last available position data and, using forecasting methods, it returns an estimate of the current

location. This method does not require to specify the indoor localization subsystem to be used, but

leaves the choice to the middleware.

getINDOOREstimatedLocation

REQUEST

obj_id integer mandatory, if this parameter is specified, only information associated to the requested object is returned. If this parameter is not specified, information on all objects being tracked are returned.

positionType String optional, defines whether the positioning information should be returned as absolute or relative to the local reference point. Values supported: ‘absolute’, ‘relative’. When the parameter is not specified, ‘absolute’ is used as default value

RESPONSE


positionType string ‘absolute’ or ‘relative’, defines how to interpret the data in the lastPosition field.

position estimated position of the object according to ISO 19111 format (if positionType is ‘absolute’) or (x,y,z) expressed in meters (if positionType is ‘relative’).


real estimated accuracy in meters. This depends on a number of factors, including:

9.4.2.4 4th mode API - push

The push mode APIs are used to create a stream of location information about a given object. Two

functions are provided, to register and unregister the stream, respectively. A callback endpoint

should be specified when registering the stream. The syntaxes of the two functions are:




registerINDOORLocation & unregisterINDOORLocation

REQUEST

pushEndPoint_id mandatory, it identifies the end point where the data has to be pushed.

pushRegistrationID_id mandatory, it is used to indicate to the target of the push notifications.

localizationSystem_id string mandatory, it identifies the localization system to be used. At the moment the following values are supported: ‘eertls’, ‘quuppa’, ‘gnss’, ‘gps’, ‘wifi’.

obj_id mandatory, if this parameter is specified, only information associated to the requested object is returned. If this parameter is not specified, information on all objects being tracked are returned.

timePeriod real optional, it defines the period (in milliseconds) among successive pushes of information.

REQUEST

result integer 0 if the registration / un-registration was successful, -1 otherwise

This functional block is a wrapper for the indoor localization subsystem APIs. It provides the best

estimate of the current position of an object, checking across all localization subsystems available

and using a predictive mechanism based on the last available information.

9.4.3 ISO 24730 compliant localisation

In addition to the APIs defined before, the platform will provide also supporting APIs for exposing the

data through the Real-time Locating Systems (RTLS) standard BS ISO/IEC 24730-1:2014 (more

information can be read from [4]) . This will ensure maximum interoperability, albeit in this case at

the expenses of performances.

This will regard only location updates delivered to third-party applications registering to the i-locate

middleware. Conversely, communication among internal components in i-locate will not follow such

standard in order not to introduce an unnecessary overhead. The API will be exposed through a

WebSocket connection, over which the flow of location updates will be delivered to a client

registering to the platform.

We report in the following an example of the message flow send by the system when establishing

an RTLS connection to i-locate:

MyAppl,SLMF,1.0,Welcome to the RTLS Text Stream interface.<CR><LF>

-----------------------------------------------------------------------------------------------

---------------------------------------------

FieldDefinition,Source,String<CR><LF>

FieldDefinition,Format,String<CR><LF>




FieldDefinition,Tag_ID_Format,HexBinary<CR><LF>

FieldDefinition,Tag_ID,HexBinary<CR><LF>

FieldDefinition,X,Double<CR><LF>

FieldDefinition,Y,Double<CR><LF>

FieldDefinition,Z,Double<CR><LF>

FieldDefinition,Battery,HexBinary<CR><LF>

FieldDefinition,Timestamp,DateTime<CR><LF>

FieldDefinition,Algorithm,String<CR><LF>

FieldDefinition,Data,HexBinary<CR><LF>

FieldDefinition,A,Double<CR><LF>

FieldDefinition,B,Double<CR><LF>

FieldDefinition,C,Double<CR><LF>

-----------------------------------------------------------------------------------------------

---------------------------------------------

LocateMessageDefinition,MySourceA,DFT,Tag_ID_Format,Tag_ID,X,Y,Z,Battery,Timestamp<CR><LF>

LocateMessageDefinition,MySourceA,S,Tag_ID_Format,Tag_ID,X,Y,Z,Battery,Timestamp,Algorithm<CR><

LF>

LocateMessageDefinition,MySourceA,T,Tag_ID_Format,Tag_ID,X,Y,Z,Battery,Timestamp,Algorithm,Data

<CR><LF>

LocateMessageDefinition,MySourceC,SP,Tag_ID_Format,Tag_ID,X,Y,Z,Battery,Timestamp,Algorithm,Dat

a,A,B,C<CR><LF>

KeepAlive,30<CR><LF>

-----------------------------------------------------------------------------------------------

---------------------------------------------

MySourceA,DFT,01,000100BC614E,100,150,8,1,2010-11-24T09:07:04-08:00<CR><LF>

MySourceA,S,01,000100BC614E,100,150,8,0,2010-11-24T09:07:04-08:00,2D<CR><LF>

MySourceA,S,01,000100BC614E,100,150,8,0,2010-11-24T09:07:04-08:00,L<CR><LF>

MySourceA,T,01,000100BC614E,100,150,8,0,2010-11-24T09:07:04-08:00,2D,0A46E137<CR><LF>

MySourceA,S,01,000100BC614E,100,150,8,0,2010-11-24T09:07:04-08:00,P<CR><LF>

MySourceC,SP,01,000100BC614E,100,150,8,0,2010-11-24T09:07:04-

08:00,3D,B7F349,3.14,0.785,0.0<CR><LF>

The message flow is divided into the following 4 sections:

The first one is a welcome message, and it provides some basic information on the versions

of the RTLS and localization system used.

The second one provides a definition of the fields used in the reminder of the message. This

part is specific to the various localization technologies used and allows to properly interpret




the following part. Each localization technology, when returned through RTLS, will need to

define its own fields.

The third one defines the format to the messages. Also this part is specific to the various

localization technologies being use, and each localization sub-system will handle the proper

messaging formatting

The fourth part is used to deliver the actual location updates. This is aligned with the previous 2

steps and is specific to each localization sub-system




9.5 Spatial Solver Service

The spatial solver practically

represents the spatial query interface,

i.e. a middleware component that can

serve to application developer or

middleware services, some spatial

utilities already bundled. The functions

planned within the API are introduced

below.

9.5.1 APIs

Buffer given a position

bufferPoint?pos=<position>&resultType=<resultType>&radius=<radius>

This feature allows to receive a list of POI (assets, object areas and others) that are fully or partially

within a certain distance to the given point. This functionality takes the point and creates a circular

area around it using the given radius.

Position: the position used for the buffer.

resultType: the result type needed (combination of POIs, roads, areas).

radius: the radius (in meters) to be used for the creation of the circular sourrounding of the

position.

Buffer given a route

bufferRoute?route=<route>&resultType=<resultType>&radius=<radius>

This feature is almost the same as BufferPoint, except that the input is a “linestring” compliant feature

i.e. a route, and the radius is used to enlarge the route width. The resulting buffer area will not be

circular, but will be an enlargement of the provided line.

Buffer given an area (rooms, buildings…)

bufferArea?area=<area>&resultType=<resultType>&radius=<radius>

The third buffer function acts as the other two, except for the input data that requires a polygon

describing an area. The buffer area will be a resulting area obtained by expanding the input with the

radius value.

Check object inclusion

checkInclusion?obj=<obj>&area=<area>

The inclusion function will simply check if an object is within (partially or fully) inside a specific area

and returns the result of the inclusion as true/false.


Sp

ec

ific

LB

S

En

ab

les

Ge

ne

ric

LB

S

En

ab

les

Routing

Identity Management


Co

re

loc

ali

za

tio

n

se

rvic

es

Spatial Solver

Configuration

Monitoring

Da

ta S

tora

geService Bus

CIV

ICF

LO

W


Ga

lile

o

Ca

me

ras

GP

S/E

GN

OS


Indoor Localization

Qu

up

pa

Ca

me

ras

ee

RT

LS

Wi-

Fi

Upload/

Download

OGC Spatial

Proxy




area: the area where check the inclusion

obj: the object to check against the inclusion

Get area(s) containing object

getContainingArea?obj=<obj>

This feature will return one or more areas where the given object resides. This is typically the case

when one wants to know where a particular asset is. This function can be used to retrieve the areas

where the object is located.

Get included object (given area):

getObjectsWithin?area=<area>

Whenever is needed to know which objects (either assets or other) is inside a particular area, this

function will can be invoked and retrieves a list of them. If no objects are within the area, the return

value is just an empty list.

Distance within objects (or areas)

getDistanceWithin?object1=<objectId>&object2=<objectId>&type1=<type>&type2=<type>

This function provides the minimum distance between the provided objects/areas or combination of

the two. The distance is linear distance and does not take care of routing. The two type parameters

are for specifying if the Ids are referred to objects or areas

Type1: the type of the object one id, either “object” or “area”

Type2: the type of the object two id, either “object” or “area”

Two pull-mode APIs have been envisaged as detailed in the reminder of the section.

1st mode API - pull

getLocation

REQUEST

obj_id integer optional, if this parameter is specified, only information associated to the requested object is returned. If this parameter is not specified, information on all objects being tracked are returned.

positionType string optional, it defines whether the positioning information should be returned as absolute or relative to the local reference point. Values supported: ‘absolute’, ‘relative’. When the parameter is not specified, ‘absolute’ is used as default value.

RESPONSE


positionType string ‘absolute’ or ‘relative’, defines how to interpret the data in the position field




position estimated position of the object according to ISO 19111 format (if positionType is ‘absolute’) or (x,y,z) expressed in meters (if positionType is ‘relative’).

referencePointPosition (only present if positionType is ‘relative’)

absolute position of the reference point, in ISO 19111 format.

rotation (only present if positionType is ‘relative’)

real angle of rotation of the relative coordinate system about the z axis of the absolute coordinate system


real estimated accuracy in meters. This depends on a number of factors, including;

The localization subsystem(s) used for estimating the position.

The age of the last available location information.

In 2D, this field describes the radius of a circle centred at the given (X,Y)-coordinates. In 3D positioning, accuracy refers to the radius of a sphere

localizationSystemID (optional):

string identifier of the localization system used in order to compute the provided estimation.

2nd mode API - pull

The second APIs is based on the following syntax:

getLastSeenLocation

REQUEST

obj_id integer if this parameter is specified, only information associated to the requested object is returned. If this parameter is missing or invalid an error is returned. If it is not set, information about all objects being tracked is returned.

positionType string optional, it defines whether the positioning information should be returned as absolute or relative to the local reference point. Values supported: ‘absolute’, ‘relative’. When the parameter is not specified, ‘absolute’ is used as default value.

RESPONSE


positionType string ‘absolute’ or ‘relative’, defines how to interpret the data in the position field.

position last measured position of the object according to ISO 19111 format (if positionType is ‘absolute’) or (x,y,z) expressed in meters (if positionType is ‘relative’).




referencePointPosition (only present if positionType is ‘relative’)

the absolute position of the reference point, in ISO 19111 format.

rotation (only present if positionType is ‘relative’)

the angle of rotation of the relative coordinate system about the z axis of the absolute coordinate system.


estimated accuracy in meters. This depends on a number of factors, including

The localization subsystem(s) used for estimating the position.

The age of the last available location information.

In 2D, this field describes the radius of a circle centred at the given (X,Y)-coordinates. In 3D positioning, accuracy refers to the radius of a sphere.

localizationSystemID (optional)

the identifier of the localization system used in order to provide the position data




9.6 Routing service

The routing service will generate a

route plan and corresponding turn-

by-turn directions for a trip with

given origin and destination

location. The routing system that

will be integrated in i-locate, which

will extend already available

technology form TU/e, will have

the following features:

Support for integrated

indoor-outdoor routing;

Support for multimodal

routing (allowing that

multiple transport modes

are combined in the same

trip);

Supports for multiple

possible routing preferences (such as fastest, shortest, most bicycle friendly, etc.);

Support for possible routing constraints such as avoiding certain features such as particular

road types, stairs, etc.).

The entrance of the building will be the node where the (multimodal) network for the outdoor

environment and the network for the indoor environment are interconnected. To take into account

time tables of public transport, the so-called time dependent approach will be used. In this approach,

arrival and departure times at nodes are compared to time tables of public transport in a path search

process.

The door-to-door routing request will be broken down into an outdoor-routing part and an indoor-

routing part where the building entrance node defines the cut-off-point. After having found a route

for each part, the two routes will be integrated into an overall door-to-door route by reconnecting the

two parts at the point where they were broken apart (the entrance of the building). Both the indoor

and outdoor routing systems will read graph and attribute data in standard formats and compute

routes and associated turn-by-turn directions based on an internal network file, compiled based on

this data.

When there will be a real-time update of the network (for example, an elevator being temporarily out

of order) the database will be updated accordingly and the routing system will receive a message of

the event upon which it implements the required update of the internal network in real-time.

Furthermore, when a user will deviate from the route plan, the routing system will receive a re-routing

request. The request and response format for re-routing will be not different from the request and

response format of an initial routing request.

The detection of a deviation from the route will be handled at the client side. Origin and destination

locations in a routing request/response will be specified in terms of their X,Y (and Z) coordinates.

This means that geocoding (translating an address into X,Y coordinates) and reverse geocoding


Sp

ec

ific

LB

S

En

ab

les

Ge

ne

ric

LB

S

En

ab

les

Routing

Identity Management


Co

re

loc

ali

za

tio

n

se

rvic

es

Spatial Solver

Configuration

Monitoring

Da

ta S

tora

geService Bus

CIV

ICF

LO

W


Ga

lile

o

Ca

me

ras

GP

S/E

GN

OS


Indoor LocalizationQ

uu

pp

a

Ca

me

ras

ee

RT

LS

Wi-

Fi

Upload/

Download

OGC Spatial

Proxy




(translating X,Y coordinates back to an address) will be dealt with by a separate service (is not part

of the routing service).

Although routing from outdoor to indoor (or vice versa) is the typical case, the routing system will be

also able to handle requests for outdoor routing only and requests for indoor routing only. In other

words, all the way outdoor routing and all the way indoor routing will be just special cases for the

routing system.

Apart from the route plan and turn-by-turn directions, the routing system will provide relevant

summary information about the trip, including expected travel time and expected arrival time.

Updates of expected travel time and arrival time and alerts to the user when the expected arrival

time is later than a scheduled time, will be taken care of at the client side.

9.6.1 Indoor routing

The routing system for the indoor-environment will read graph data of the indoor environment in

IndoorGML format (refer to section 8.2 for further information on IndoorGML data model). The graph

data defines the nodes and links representing locations (rooms, halls, etc.) and transport connections

between locations. Stairs and elevators are special links that interconnect different floors in a building

(vertical transport). Also, building entrances are special nodes representing the locations where the

outdoor and indoor networks are interconnected.

For indoor environments, the coordinates defining the geographic position of a location (a node) will

be extended to also include a Z coordinate (in addition to a X and Y coordinate). The Z-coordinate

will define the floor level of the location. So, for example, two locations that are on different floors at

the same X,Y position will be differentiated by the Z-coordinate.

Just as in the outdoor case, the turn-by-turn directions associated with a route plan will be specified

as text strings and geographic positions when text strings will have to be displayed (e.g., in 5 meter

before a turn go to the right or left). The contents of the text strings, i.e. the way the directions are

formulated, will be adapted to the indoor environment since instruction protocols that may work well

for outdoor environments may not work well for indoor environments and vice versa. However, the

overall structure of the turn-by-turn directions will be the same. Approaches, such based on

semantics of indoor spaces, which can leverage on information available through IndoorGML, will

be followed to provide more customised forms of guidance (e.g. “exit the room, turn right and follow

the corridor…”)

Associated to node and link objects there will be attribute data. Two sets of attributes will be assumed

– one for nodes and one for links. The attribute data will allow the routing system to evaluate

preferences and constraints for routes. In terms of preferences the user will be able to minimize

travel distance (shortest route), minimize the travel time (fastest route) or minimize inconvenience

(penalties for slopes and for stairs).

In terms of constraints, the user will be able to demand avoiding certain features such as stairs.

When in a wheelchair or when the user is blind, certain features may need to be avoided as well

namely those features that prohibit the use of wheel chair (such as slopes and stairs). Thus, to take

into account all possible preferences and constraints, the attribute data for links will include as a

minimum set:

type of link (stair, elevator, ordinary way);

slope;




length (distance);

travel speed by mode and accessibility by mode.

9.6.2 Outdoor routing

The routing system for the outdoor environment will read graph data of the multimodal transport

network in OpenStreetMap format (road network data) and GTFS (public transport data) format as

input. Just as in the indoor case, the graph data will define the nodes and links representing locations

and transport connections. Locations will be either entry points (where one can enter the network),

exit points (where one can leave the network), turns (where one can change direction) and

stations/stops/parking-places where one can transfer between transport modes or change vehicle of

public transport (e.g., change train or bus).

Transport connections will not only denote infrastructure for physical travel (on the road, railway etc.)

but also for transfers (at stations or stops) and boarding and alighting. In the outdoor case, the

geographic position of locations will be defined by an X and Y coordinate only (there is no Z

dimension).

Using the GTFS format, the routes of public transport will be defined in terms of sequence of stops

and corresponding time tables. Time tables will define arrival and departure times at stops for regular

(weekdays) and non-regular services (Saturdays, Sundays and holidays). The time table data will

be stored at nodes using the so-called time dependent approach.

Turn-by-turn directions will be provided with each generated route plan. As in the indoor case, the

directions will be specified as text strings to be displayed at specified geographic positions on the

route. The directions will be adapted to public transport and private transport travel modes, but will

have the same structure for all modes.

Associated to node and links there will be the attribute data that allow the routing system to handle

possible routing preferences and constraints imposed by a user. In terms of routing preferences, a

user will be able to minimize a travel distance (shortest route), minimize travel time (fastest route) or

to follow the safest route (e.g., bicycle friendly route). Furthermore, a user will be able to put an extra

penalty on transfers (to avoid them). In terms of constraints, a user will be able to exclude certain

transport modes (e.g., allow only car), certain features of travel connections (e.g., avoid highways)

or impose an extra minimum time for a transfer.

To take into account possible preferences constraints, attribute data for each link will have to include

at least:

type of link (e.g., type of road);

length (travel distance);

travel speed by mode and accessibility by mode.

9.6.3 Routing proxy

As said, the routing system will support integrated indoor-outdoor routing based on a component for

indoor and a component for outdoor routing. Internally, a routing request will be broken down into an

outdoor and an indoor routing part divided by the entrance point of the building. The routing

responses generated for the two parts will be re-integrated at this point in order to present a single

overall door-to-door route plan to the user.




Fig 32: Overall architecture of the routing system including the proxy and the two sub-component for indoor and outdoor routing.

As illustrated in figure Fig 32, a proxy will be developed to perform this internal decoupling and

recoupling so that from the point of the user the routing system will be able to perform integrated

indoor-outdoor routing seamlessly.

Although door-to-door planning stretching over indoor and outdoor space is the general case, it is

recognized that routing requests for indoor only (e.g., routing a patient or a doctor from the nursery

ward to an operating room) and for outdoor only may be relevant as well. Therefore, the routing

system will handle all types of routing requests -integrated indoor-outdoor, outdoor only and indoor

only through three separate APIs (defined next).

9.6.4 Routing APIs

For outdoor routing, i-locate will use the OpenTripPlanner (OTP) software. OTP is an open-source

software which provides multimodal routing services based on OpenStreetMap and GTFS data. The

software will be extended with an indoor routing package.

The following sections describe the parameters regarding the requests on client side and responses

on the server side. Three cases are considered: outdoor only, indoor only and integrated outdoor-

indoor.

9.6.4.1 API for outdoor routing only

getOutdoorRoutin

REQUEST

fromPlace Longitude, latitude Start place of the journey

toPlace Longitude, latitude End place of the journey

date Date Start date of the journey

time Time Time of the journey

Routing

Request

Type

Routing

Outdoor Routing Indoor Routing

Routing

Response




Available modes WALK, BICYCLE, CAR, TRAM, SUBWAY, RAIL, BUS, FERRY, CABLE_CAR, UNICULAR

The transport mode(s) user selected

optimize FASTEST, SHORTEST, FLATTEST

Routing preference – the definition of the preferred route

maxWalkDistance

Maximum allowed walking distance on the route

ExtraTransferTime

optional Requirement of extra time for transfers. For example one may wish to have extra time of 5 minutes for convenience (Integer; Default = 0)

AvoidList optional The types of features to avoid when determining the route, such as Highway, Tollway, Staircase, etc. (Enumeration type)

RESPONSE


from LocationType Start place of the journey

to LocationType End place of the journey

Itineraries List of Itinerary Alternative routes for the journey

getLocationType

REQUEST

name optional Name of the street or node

lon Longitude

lat Latitude

getItinerary

duration Total duration of the journey

startTime Start time of the journey

endTime End time of the journey

walkTime Total walking time

transitTime Total public transport time

waitingTime Total waiting time




walkDistance Total walking distance

transfers Number of transfers

legs List of Leg The legs of the journey (a leg is a segment of the route done by a same transport mode)

tooSloped True or False Exceeds tolerance for elevation

getLeg

REQUEST

startTime Start time of the leg

endTime End time of the leg

departureDelay Delay at departure

arrivalDelay Delay at arrival

distance Distance of the leg

from LocationType to LocationType legGeometry Geometry of the leg

transitLeg mode steps List of Step The links of the leg

rentedBike True or false Bicycle was rented for the leg

duration Duration of the leg

getLegGeometry

REQUEST

Points List of points Shape points of the route

levels List of levels length Length of the leg in meters




getStep

REQUEST

distance Distance of the link

relativeDirection LEFT, RIGHT

streetName Name of the street

absoluteDirection

NORTH, SOUTH, EAST, WEST

Lon Longitude of the end node

Lat Latitude of the end node

Elevation Slope

9.6.4.2 API for indoor only

getIndoorRouting

REQUEST

fromPlace Longitude, latitude, floor level Start place of the journey in Building

toPlace Longitude, latitude, floor level End place of the journey in Building

date Date Start date of the journey in Building

time Time Time of the journey in Building

Mode WALK, WHEELCHAIR, USESTAIR, USEELEVATOR

The transport mode user selected (excluded modes are deselected here)

optimize FASTEST, SHORTEST, FLATTEST

Routing preference – the definition of the preferred route

AvoidList optional The types of features to avoid when determining the route, such as staircase, etc. (Enumeration type)

RESPONSE




Itinerary Specification of the route for the journey

getLocationType

REQUEST

name optional Name of the location

lon Longitude position in Building




lat Latitude position in the Building

levelFloor Floor level in the building

getItinerary

REQUEST

duration Total duration of the journey

startTime Start time of the journey

endTime End time of the journey

legs List of Leg The legs of the journey (a leg is segment of the route done by a same mode)

tooSloped True or False Exceeds tolerance for elevation

getLEG

REQUEST

startTime Start time of the leg

endTime End time of the leg

distance Distance of the leg

from LocationType

to LocationType

legGeometry Geometry of the leg

mode

steps List of Step The steps of the leg (a step is a single link in the network)

duration Duration of the leg

getLegGeometry

REQUEST

Points List of points Shape points of the route

levels List of levels

length Length of the leg in meters

getStep

REQUEST




distance Distance of the link

relativeDirection LEFT, RIGHT

streetName Name of the street

absoluteDirection NORTH, SOUTH, EAST, WEST

Lon Longitude of the end node

Lat Latitude of the end node

Elevation Slope

9.6.4.3 APIs for integrated indoor-outdoor

getIndoorOutdoorRouting

Request

fromPlace Longitude, latitude, levelFloor Start place of the journey

toPlace Longitude, latitude, levelFloor End place of the journey


time Time Time of the journey

indoorRequest Table of outdoor request parameters

outdoorRequest Table of outdoor request parameters

RESPONSE




outdoorItineraries List of Itinerary (Outdoor case) Specification of the route from origin to Building entrance to destination

indoorItinerary Itinerary (Indoor case) Specification of the route from Building entrance to destination




9.7 Geofencing Service

The geofencing module will play an

important role whenever there will

be the need to be notified when a

particular geographic position is

reached by someone (or

something). Examples of use of the

geofencing module include:

Being notified when an entity

(objects or persons) enters a

given space (e.g. a given

room).


leaves a given space.


gets in the vicinity of another

entity (e.g. a moving person

getting close to another

moving person).

This functionality will heavily rely on localization features and will require the specific identifier (as

defined in section 8.7) to be available for each person/object to be involved in the geofencing

process. It should be noted that there is very limited state of the art on how to create a geofencing

engine. In the specific case of i-locate, the project will develop a common APIs that will enable

heterogeneous engines to perform the geofencing through a consistent “universal” interface.

Such an interface, the geofencing proxy, as detailed in Fig 33, will expose APIs to access geofencing

features through a standard interface. The features themselves will be then performed by an

independent component in charge of true computation. As illustrated in the following figure, this

approach will allow replacement of the geofencing engine (the actual implementation) without

interfering with the overall system.

Fig 33: the overall approach used for the architecture of the geofencing module

The most important features that the geofencing module will provide will be:

Items IDs or Items references.

Items position.


Sp

ec

ific

LB

S

En

ab

les

Ge

ne

ric

LB

S

En

ab

les

Routing

Identity Management


Co

re

loc

ali

za

tio

n

se

rvic

es

Spatial Solver

Configuration

Monitoring

Da

ta S

tora

geService Bus

CIV

ICF

LO

W


Ga

lile

o

Ca

me

ras

GP

S/E

GN

OS


Indoor LocalizationQ

uu

pp

a

Ca

me

ras

ee

RT

LS

Wi-

Fi

Upload/

Download

OGC Spatial

Proxy




Fencing areas, i.e. areas where the Geofencing will be enabled.

Direction of fencing, inbound, outbound, both.

Callback (or service) to which notify the geofence event.

In the context of i-locate the items IDs (or reference) and the items position will be already managed

by the core system as detailed in section Error! Reference source not found.. The geofencing API

will complement the i-locate core features with those necessary for creation of the areas, the

capability to choose the fencing direction and how to set the callback/service for receiving geofencing

events.

It is important to highlight that, differently from other services, the geofencing features are only

available through communication via the bus and not as standard web-service call.

9.7.1 APIs

The geofencing APIs that will be used both by the geofencing engine (in the reminder of this section

it will be simply referred to “engine”) and the clients, which logically represent all the possible

components invoking the geofencing engine. The clients, in particular, will either use the API for

configuring fencing or receiving notifications.

The following set of specifications are the smallest set of APIs that each specific implementation of

a Geofencing engine will have to support in order to ensure it can be integrated in the i-Locate

system. It should be noted that it will be very possible to add later extensions of the engine to allow

for collection of additional data from the middleware layer and to make statistic evaluation,

predictions or many other functionalities. However, all these features are outside the scope of the

pure geofencing engine and therefore are not discussed here.

The APIs specified below represents the body of the messages that will be sent via a bus (see

section 9.15) and that that the engine is able to read/manage. Due to the behaviour of the bus, there

will be no request/response flow, the request will be just sent by the client and it will just receive the

confirmation of the message sent. To receive a specific response, the geofencing engine will just

need to send a specific message to a particular topic on the bus. Additional information on the bus

are provided in section 9.15

The following subsections detail the use of the API for a number of different actions.

Register an object to the geofencing engine

In order to register an asset to the geofencing engine (in order for the asset to be considered for

fencing events) the following formalism will have to be followed, when sending the message via the

bus.

{

"Id":123432432,

"Position":{

"x":10.0,

"y":45.0,

"z":1.0

},

"Name":"InfusionPump01"

}




Update Item Position

In order to make the geofencing engine to work on positions and fencing, it will need to be fed about

items positions. There will be a quasi “Pull” mode from the engine to the i-locate context, but the

main use case will be to work on “push” mode, so the engine will be fed by the middleware

components.

{

"ItemId":123432432,

"Position":{

"x":10.0,

"y":45.0,

"z":1.0

}

}

Create Fencing Area (with direction and Callback)

The engine with items alone, does not fire events until at least one Fencing area is created. This API

allows an area to be created and used for fencing events. It is possible also to specify the direction

for which receive the events (INBOUND,OUTBOUND or BOTH) and a callback where notify fired

events, if callback is not set, a default callback stored in the engine configuration is called.

{

"GeofenceId":1451487,

"GeoArea":{

"Name":"Paint of Viviani",

"Height":2,

"Coords":[

{"x":10.00,"y":45.00,"z":1.0},

{"x":10.01,"y":45.04,"z":1.0},

{"x":10.02,"y":45.02,"z":0.9}

]

},

"Items": [123432432, 223432124, 54124432],

"Direction”:”INBOUND”,

"Callback”:”https://ilocatemiddleware.org/geofencing/1451487”

}

Notification (from Geofencing)

The Geofencing engine will send a notification when a fencing alert is fired. The notification will be

sent either on the specified callback, or to the default endpoint otherwise. The content of the

notification will be as follows:

{

"GeofenceId":1451487,

"ItemId":12343243,

"EventFiredTime":1403042400000,

"GeoFenceDirection":"INBOUND"

}




9.8 Monitoring service

The monitoring component will

implement appropriate interfaces for

the deployment of localization

infrastructure management and

control functionalities. The provided

API will provide a basic functionality

for querying the status of the objects

managed by a localization sub-

system. The interpretation of the

data is left to the specific localization

sub-system, as this can vary

significantly depending on the

localization technology being used

(e.g., TAGs vs. Wi-Fi).

9.8.1 APIs

The service features a single API,

allowing to retrieve the current status of a given object. In this case:

getStatus

REQUEST

obj_id optional, if this parameter is specified, only information associated to the requested object is returned. If this parameter is not specified, information on all objects being tracked are returned.

The response is provided in the form of a JSON file. The fields depend on the specific type of object

for which status information is requested.


Sp

ec

ific

LB

S

En

ab

les

Ge

ne

ric

LB

S

En

ab

les

Routing

Identity Management


Co

re

loc

ali

za

tio

n

se

rvic

es

Spatial Solver

Configuration

Monitoring

Da

ta S

tora

geService Bus

CIV

ICF

LO

W


Ga

lile

o

Ca

me

ras

GP

S/E

GN

OS


Indoor Localization

Qu

up

pa

Ca

me

ras

ee

RT

LS

Wi-

Fi

Upload/

Download

OGC Spatial

Proxy




9.9 Location Analytics

The location analytics component

exposes statistics about movement

patterns of objects, at the level of

single object or aggregated across

all objects being tracked. Such

statistics are aggregated to the level

of specific areas being monitored

and will rely on the geo-fencing

component for receiving specific

notifications. The Location Analytics

will provide 3 main metrics:

Visitors: number of assets

entering a given area.

DwellTime: time spent by

assets in a given area.

Flow Analysis: flows of

assets between to pre-defined areas.

9.9.1 APIs

Number of visitors

The syntax of the request for this service is the following:

getVisitors

REQUEST

area this provides the information necessary to model a given area

dateFrom Date this specifies the beginning of the time interval

dateTo date this specifies the end of the time interval

The response is in the form of a JSON object, containing the number of visitors entering a given area

in the specified period of time.

Dwelling time

The syntax to retrieve the dwelling time is as follows:

getDwellTime

REQUEST

area this provides the information necessary to model a given area.

dateFrom date this specifies the beginning of the time interval


Sp

ec

ific

LB

S

En

ab

les

Ge

ne

ric

LB

S

En

ab

les

Routing

Identity Management


Co

re

loc

ali

za

tio

n

se

rvic

es

Spatial Solver

Configuration

Monitoring

Da

ta S

tora

geService Bus

CIV

ICF

LO

W


Ga

lile

o

Ca

me

ras

GP

S/E

GN

OS


Indoor Localization

Qu

up

pa

Ca

me

ras

ee

RT

LS

Wi-

Fi

Upload/

Download

OGC Spatial

Proxy




dateTo date this specifies the end of the time interval

The response is in the form of a JSON object, containing the dwell time for a given area in the

specified period of time.

Flow analysis

The last request, regarding the flow analysis, can be invoked through the following request syntax:

getFlow

REQUEST

Obj_id optional, if this parameter is specified, only information associated to the requested object is returned. If this parameter is not specified, information on all objects being tracked are returned.

dateFrom date this specifies the beginning of the time interval.

dateTo date this specifies the end of the time interval.

The response is in the form of a JSON array, containing various statistics about the flow of the

object(s) in the specified period of time.




9.10 Asset Management

The objective of the asset management module is to

create an abstract interface that can be used to

decouple general asset management tasks from the

actual implementation of the software used to support

to asset management.

There is a clear duality between design of this module,

as detailed in the following sections, and the asset

management data model which is detailed within this

document within section 9.10.1.3.

As illustrated in figure Fig 34, the asset management

module is divided in two parts following a client (top)

and server (bottom) fashion. In addition, the client part is further articulated into a back-end module

and a front-end module, in order to allow a clear separation between two functional areas.

Fig 34: the overall structure of the asset management service.

It should be noted that both backend and frontend will be designed as general abstract interfaces to

ensure abstraction over different system. For the specific purposes of i-locate and its pilots, the

backend and frontend will be interfaced with the corresponding components of BOX3, the existing

asset maintenance solution developed by Trilogis that will be used for the use cases planned at the

pilot sites9.

9 It is worth noting that BOX3 represents a “background” and not a “foreground” of i-locate, which is owned by Trilogis and that will be licensed free of charge to the pilot sites for the whole duration of the project.

Assets

- Creation

- Modification

- Deletion

Processes

- Creation

- Modification

- Deletion

Role definition

History

- human readable

- structured data

System DB

Client DB

View fired

events

Fire events

Synchronizati

on

Client <->

Server

View

processes

Perform asset

management

process

Server

Backend Frontend

Events

- Creation

- Modification

- Deletion

Events


Sp

ec

ific

LB

S

En

ab

les

Ge

ne

ric

LB

S

En

ab

les

Routing

Identity Management


Co

re

loc

ali

za

tio

n

se

rvic

es

Spatial Solver

Configuration

Monitoring

Da

ta S

tora

geService Bus

CIV

ICF

LO

W


Ga

lile

o

Ca

me

ras

GP

S/E

GN

OS


Indoor Localization

Qu

up

pa

Ca

me

ras

ee

RT

LS

Wi-

Fi

Upload/

Download

OGC Spatial

Proxy




As described in figure Fig 34, and as already introduced earlier in this section, the asset management

module is divided into server and client components. The server component in practice only includes

the database, which is structured according to the data model detailed in section 8.4.3.

The backend part (see figure Fig 35) is used to define the data maintenance model. In other words,

the back-end is used to define the assets, the maintenance processes and their related activities as

well as roles, as detailed in section 9.10.1. The backend can also be also used to create the

instances of the objects –as defined within the data model- used to represent the real world context

subject of the asset management processes.

Fig 35: a screenshot of the backend interface developed by Trilogis and that will be interfaced to the backend module of i-locate.

The frontend part (see figure Fig 36) will instead be used to carry on all the maintenance activities

according to the instances and attributes defined within the backend system. Integration with the

system data layer will allow binding entities of the Asset Management module to spatial properties,

in order to provide features such as routing to the place where an asset is located or to accurately

represent the asset management processes. The frontend module will make it possible to bind

spatial properties to assets, events or data collected during maintenance activities.

Both frontend and backend will presented in detail in the following sections which will provide also a

detailed description of the API defined for each of the modules.




Fig 36: a screenshot of the frontend interface developed by Trilogis and that will be interfaced to the frontend module of i-locate.

9.10.1 Backend module

The backend module will allow defining the maintenance model of the domain subject of the asset

management activities. The overall approach relies on four main concepts, described within section

8.4.3., and briefly introduced in the table below for the sake of convenience. The concepts build on

top of the concepts and methodologies defined within the family of standards ISO 55000 – Asset

Management [5].

Concept Explanation

Asset Every resource that produces value for the organization.

Can be a pump, a pipe or a garden.

Event The event that trigger the necessity to perform some maintain operations on assets

Process A structured and defined list of maintain operations; moreover it defines and conditions needed to conduct maintain operations (i.e. events)

Role Roles are used to represent responsibilities and capabilities into the system.

All the data structures corresponding to the four aforementioned concepts are defined by a user with

a system or data administrator role who often is the only operator with the privileges to configure the

asset management system, and the properties of the asset managed by it, within an organization.

The following section illustrates the APIs that have been designed for the various functional blocks

as detailed in Fig 37. Method calls have been defined through self-declaratory names and therefore




do not need a further description to illustrate their meaning. To facilitate reading they have been

separated in logical groups, each included in a different table as follows.

Fig 37: Overall building blocks of the backend of the Asset Management module.

Assets

- Creation

- Modification

- Deletion

Processes

- Creation

- Modification

- Deletion

Role definition

History

- human readable

- structured data

Backend

Events

- Creation

- Modification

- Deletion




Fig 38: class diagram of back-end module




9.10.1.1 Asset management features

The concept of an asset, which is detailed within section 8.4.3., is coupled – in terms of system

architecture - to a corresponding functional block which provides core features for assets

manipulation. The following list of methods details the functions planned for the APIs.

Due to the very diversified nature of actions needed by this service, the standard tables used to

define the APIs have not been adopted and replaced with a more compact representation which

groups service calls within different functional groups, as detailed in the following tables.

GENERAL ASSET-LEVEL SERVICE CALLS

Return type Service call Parameters

long newAsset Long parentId, String name, String description

String getAssetName long id

String getAssetDescription long id

List<String> getAttributesNames long assetId

void updateAssetParent long id, Long parentId

void updateAssetName long id, String name

void updateAssetDescription long id, String description

void void deleteAsset long id

SERVICE CALLS TO MANAGE ATTRIBUTES


void newAttribute long idAsset, String name, AttrType type, String description

AttrType getAttributeType long idAsset, String attrName

String getAttributeDescription long idAsset, String attrName

void updateAttributeType long idAsset, String attrName, AttrType type

void updateAttributeDescription long idAsset, String attrName, String description

void deleteAttribute long idAsset, String name

9.10.1.2 Event management mechanism

Events are simple objects that represent the cause for the execution of a maintenance process.

Events can be unique or recurring. Additional details are provided in section 8.4.3. The following list

of service calls, details the functions planned for the APIs.

SERVICE CALLS TO MANAGE EVENTS


void newEvent long idProcess, String name, String description




void newPeriodicEvent long idProcess, String name, String description, long start, long periodicity

Long getStartTimestamp long idProcess, String name

Long getPeriodicity long idProcess, String name

void updateEvent long idProcess, String name, long Id

void updateEventDescription long idProcess, String name, String description

void updatePeriodicEvent long idProcess, String name, long start, long periodicity

void deleteEvent long idProcess, String name

The asset management subsystem shall provide events registration features handled through a

subscription design pattern. The following list of service calls details the functions planned for the

APIs.

SERVICE CALLS FOR REGISTRATION TO EVENTS


void registerToEvents long Id, SignalCallback callback

void registerToAssetEvents void registerToAssetEvents (long assetId, SignalCallback callback

void registerToProcessEvents long processId, SignalCallback callback

void signalEvent long processId, long assetId, long timestamp

9.10.1.3 Management of “asset management” processes

Processes define all the aspects of maintenance flows as detailed within section 8.4.3. The following

tables detail the various group of service calls planned for the APIs.

SERVICE CALLS TO MANAGE PROCESSES


long createProcess String name, String description, long eventId

String getProcessName long id

String getProcessDescription long id

long getProcessEventId long id

List<long> getActivitiesTypes long processId

void updateProcessName long id, String name

void updateProcessDescription long id, String description

void updateProcessEvent long id, long eventId

void updateProcess long id, long id

void deleteProcess long id

SERVICE CALLS TO CONNECT PROCESSES TO ASSETS





void assignProcessToAsset long processId, long assetId

void removeProcessToAsset long processId, long assetId

SERVICE CALLS TO MANAGE ACTIVITIES


long newActivityType String description, Long estimatedDuration

String getActivityTypeDescription long id

Long getActivityTypeStimatedDuration long id

Set<String> getActivityTypeAttributes long id

void updateActivityTypeDescription long id, String description

void updateActivityTypeStimatedDuration long id, long stimatedDuration

void deleteActivity long id

SERVICE CALLS TO MANAGE ATTRIBUTES


void newActivityTypeAttribute long activityTypeId, String name, AttrType type, String description

AttrType getActivityTypeAttributeType long activityTypeId, String name

String getActivityTypeAttributeDescription

long activityTypeId, String name

void deleteActivityTypeAttribute long activityTypeId, String name

SERVICE CALLS TO CONNECT ACTIVITIES TO PROCESSES


void assignActivityTypeToProcess long activityTypeId, long processId

List<long> getProcessActivitiesTypes long processId

void changeActivitiesOrder long processId, int oldIndex, int newIndex

void removeActivityTypeToProcess long activityTypeId, long processId

9.10.1.4 Role management

Through management of roles it will be possible to abstract the concept of a person and to ensure

sufficient flexibility to handle different roles. It should be noted that, according to recommendations

within ISO 55000 [5] a process must have a person in charge to manage maintenance operations.

Since in the most case it will not be possible to assign a process directly to a person, the system will




allow relying on roles (e.g. engineer, project manager etc.). As detailed in section 8.4.3., each

operator or person will be able to play zero or more roles.

The following tables detail the various group of methods planned for the APIs.

SERVICE CALLS FOR ROLE MANAGEMENT


boolean isRoleId long id

boolean isPersonId long id

long long newRole String name, String description, Long parentId

String getRoleName long id

String getRoleDescription long id

Long getRoleParent long id

void updateRoleName long id, String name

void updateRoleDescription long id, String description

void updateRoleParent long id, long parentId

void deleteRole long id

long newPerson String name

String getPersonName long id

void updatePersonName long id, String name

void deletePerson long id

SERVICE CALLS TO ASSOCIATE PERSON TO PROCESS


void assignOperatorToProcess long appointedId, long processId

9.10.1.5 Management of historical data

This component will ensure management of historical data related to maintenance activities. It should

be noted that this functional component provides access to historical data in a way that may be

similar to that described within the section dealing with versioning (see section 8.6). However, it

should be noted that the two of them will be significantly different in that the role of this functional

component is not to provide access to historical positioning or geographically-relevant information

but, more specifically, access to data related to execution of asset management processes.

Since processes will be completely configurable, the system is on the structure of the data adopted

for each specific assent and its related management processes. In fact, each maintenance process

is composed by different activities, and each activity could require a different number of attributes of

different types, with different constraints.




As detailed in section 8.4.3, the structure of ProcessInfo will provide access to information related to

the execution of a process. The following table illustrates the relevant methods available through the

API.

SERVICE CALLS TO ACCESS INFORMATION RELATED TO PROCESS EXECUTION


long newProcessInfo long processId, long timestampTriggedEvent

List<long> getProcessInfo long processId

void setOperatorInCharge long ProcessInfoId, long personId

long getProcessInfoTimestamp long ProcessInfoId

long getProcessId long ProcessInfoId

long getOperatorInCharge long ProcessInfoId

void updateProcessInfoTimestamp long ProcessInfoId, long timestampTriggedEvent

void updateProcessInfoOperatorInCharge long ProcessInfoId, long personId

void deleteProcessInfo long ProcessInfoId

SERVICE CALLS TO CONNECT ACTIVITIES TO PROCESSES


long newActivityInfo long activityTypeId, long ProcessInfoId, long assetId

long getActivityInfoOperatorInCharge long ProcessInfoId

long getActivityInfoDuration long ProcessInfoId

long getActivityInfoTimestamp long ProcessInfoId

void updateActivityInfoOperatorInCharge long ActivityInfoId, long personId

void updateActivityInfoDuration long ProcessInfoId, long duration

void updateActivityInfoTimestamp long ProcessInfoId, long timestamp

void deleteActivityInfo long id

void newActivityInfoAttribute long ActivityInfoId, String name, Object value

Object getActivityInfoAttributeValue long ActivityInfoId, String name

void updateActivityInfoAttributeValue long ActivityInfoId, String name, Object value

void deleteActivityInfoAttribute long ActivityInfoId, String name




9.10.2 Frontend module

The frontend will be the functional model that will be used by the final user (e.g. maintenance

engineer) to perform asset management of which he/she is in charge. Through the frontend the

operator can:

view the processes that are due to be executes,

notify that a process is due to be executes,

execute them and

introduce all required data about the process execution within the system.

The following tables illustrates the relevant methods that will be available through the API.

SERVICE CALLS TO VIEW PROCESSES THAT ARE DUE TO BE EXECUTED


List<long processId, long assetId>

getToPerformProcesses long startEventId, long assetId, long operatorId

SERVICE CALLS TO SIGNAL PROCESSES THAT ARE DUE TO BE EXECUTED

Return type

Service call Parameters

List<long> getEvents

Long getStartTimestamp long idProcess, String name

Long getPeriodicity long idProcess, String name

Void fireEvent long id, long assetId

SERVICE CALLS TO EXECUTE THE PROCESSES


String getAssetName long id

String getAssetDescription long id

List<String> getAttributesNames long assetId

AttrType getAttributeType long idAsset, String attrName

String getAttributeDescription long idAsset, String attrName

String getProcessName long id

String getProcessDescription long id

long getProcessEventId long id

List<long> getActivitiesTypes long processId

AttrType getActivityTypeAttributeType long activityTypeId, String name




String getActivityTypeAttributeDescription long activityTypeId, String name

SERVICE CALLS TO REPORT INFORMATION ABOUT THE PROCESSES EXECUTION

Return type

Service call Parameters

long startProcessExecution long processId, long assetId, long personId

void modifyProcessInfo long processInfoId, String notes

long performActivity long processInfoId, long activityTypeId, long personId, String notes

void modifyActivityInfo long activityInfoId, String notes

9.10.3 Integration with the server component

As mentioned before within this document, in order to integrate the backend and frontend

subsystems to the sever component, which indeed contains the data layer, the approach proposed

will bind the spatial properties of the system to elements of Asset Management subsystem as defined

in section 8.4.3.

9.10.4 Synchronization

Since the asset management activities are often carried on onsite it cannot be assumed that frontend

and server components are always connected online. For this reason, a specific feature of the

system will be introduced to provide a synchronization system, to:

keep the list of processes updated and to be able to generate events whenever a asset

management process is to be triggered;

deliver to the server the data collected onsite during the execution of asset management

process, transferring and synchronising the content of a local database (within the frontend

application) and the server backend.

Moreover, a push notification system shall inform – when connectivity is available – about new

events.

The synchronization will be performed automatically, however user will have a mechanism to force

a synchronisation on demand. It is worth noting that manual synchronization is useful in case of

limited connectivity. Following the synchronisation, the user shall have an immediate feedback on

the state of the update to keep control over data stored within the frontend.




Fig 39: overall architecture of the frontend of the Asset Management module.

Client DB

View fired

events

Fire events

Synchronizati

on

Client <->

Server

View

processes

Perform asset

management

process

FrontendEvents




9.11 Crowdsourcing module

The crowdsourcing component will

allow applications to rapidly deploy

campaigns aimed at:

collecting from users data

relevant for the i-locate

services

performing collective data

curation for crowdsourced

data

obtain insight into

interpretation of collected

data.

This will be achieved by providing an

interface for connecting to the

crowdsourcing engines, and in

particular supporting interface with

the CIVICFLOW platform [16].

One generic API is foreseen, allowing the posting of tasks, a task being defined as an action to be

carried out by an i-locate user. This can include, e.g., answering to questionnaires about the correct

positioning of objects on a map, taking photos of a given object/location, annotating a given object

etc. Tasks will be geo-localized, so that the user will receive the task (pushed through the i-locate

mobile app GUI) only when within a given area (the target area is specified as part of the task

description). The crowdsourcing component will make use of the geo-fencing APIs for triggering the

push of notifications. The request shall include a callback end point to return the outcomes of the

task action.

9.11.1 APIs

The following single command and parameters has been designed:

postTask

REQUEST

taskDescription: JSON array including a description of the task to be carried out

callbackEndPoint_id mandatory, identifies the end point where the response has to be sent.

callbackRegistrationID_id mandatory, used to identify the target of the response notifications.

The response will be 0 if the task was successfully registered, -1 otherwise


Sp

ec

ific

LB

S

En

ab

les

Ge

ne

ric

LB

S

En

ab

les

Routing

Identity Management


Co

re

loc

ali

za

tio

n

se

rvic

es

Spatial Solver

Configuration

Monitoring

Da

ta S

tora

geService Bus

CIV

ICF

LO

W


Ga

lile

o

Ca

me

ras

GP

S/E

GN

OS


Indoor Localization

Qu

up

pa

Ca

me

ras

ee

RT

LS

Wi-

Fi

Upload/

Download

OGC Spatial

Proxy




9.12 Configuration

The configuration component will be

required for the deployment of web-

based configuration interfaces. This

will be required when setting up the

localization subsystem. Data to be

stored in the configuration

component include, e.g., the

position of the local reference point

(for allowing conversion from

relative to absolute coordinates), the

direction of reference axes, version

of the system being installed, date of

installation etc.

9.12.1 APIs

Three APIs foreseen, are two

generic ones for storing and reading

configuration information and one for retrieving the reference local coordinate system. The response

is provided in the form of a JSON array with a number of system-dependent fields.

Configuration retrieval

The following interface and parameters has been planned for retrieval of configurations:

getConfigurationData

REQUEST

localizationSystem_id string mandatory, it identifies the localization system to be used. The following values will be supported: ‘eertls’, ‘quuppa’, ‘gnss’, ‘gps’, ‘wifi’

RESPONSE

position absolute position of the reference point for the specified indoor localization subsystem, in ISO 19111 format.

rotation real angle of rotation of the relative coordinate system about the z axis of the absolute coordinate system.

Configuration storing

The following interface and parameters has been planned for storing of configurations:

setConfigurationData

REQUEST

localizationSystem_id string mandatory, it identifies the localization system to be used. The following values will supported: ‘eertls’, ‘quuppa’, ‘gnss’, ‘gps’, ‘wifi’


Sp

ec

ific

LB

S

En

ab

les

Ge

ne

ric

LB

S

En

ab

les

Routing

Identity Management


Co

re

loc

ali

za

tio

n

se

rvic

es

Spatial Solver

Configuration

Monitoring

Da

ta S

tora

geService Bus

CIV

ICF

LO

W


Ga

lile

o

Ca

me

ras

GP

S/E

GN

OS


Indoor Localization

Qu

up

pa

Ca

me

ras

ee

RT

LS

Wi-

Fi

Upload/

Download

OGC Spatial

Proxy




configData JSON array including configuration data, defined in a way suitable for the specific localization system

The response will be 0 if the operation was successful, -1 otherwise.

Configuration storing

The following interface and parameters has been planned for retrieval of the reference system used

for indoor:

getINDOORReferenceSystem

REQUEST

localizationSystem_id string mandatory, it identifies the localization system to be used. The following values will be supported: ‘eertls’, ‘quuppa’, ‘gnss’, ‘gps’, ‘wifi’

RESPONSE

position absolute position of the reference point for the specified indoor localization subsystem, ISO 19111 format

rotation real angle of rotation of the relative coordinate system about the z axis of the absolute coordinate system.




9.13 Spatial Services

Within i-Locate context, the Spatial

Services will be vital because they

will allow users to connect to remote

data stores and extract vector (e.g.

.shp, .gml, .dxf) and/or raster (e.g.

floor maps) data for visualization

and manipulating spatially related

data and/or graphical representation

of them. Mainly the following classes

of Spatial Services are undertaken

within i-locate project:

Moving Features [18].

WMS – Web Map Service

[19].

WFS – Web Feature Service

[20].

9.13.1 API based on standard web-services by OGC

The following specifications are introduced at the high level (therefore with no high detail of each

service call) since they simply use service calls as defined by the respective OGC standard. For

additional detail on each standard the reader should refer to the corresponding official specifications.

Moving Features

Moving Feature is an OGC standard for web-based Applications using moving feature data. The

volume of such data (Vehicles, pedestrians, airplanes and ships), has begun growing at a very high

rate along with the growth in location - aware mobile devices. The standard allows a very simple,

CSV (Coma Separated Value) type of data access. This very simple approach provide convenient

access to updated positions of points and features.

WMS

A Web Map Service (WMS) is a web interface that allows publishing and deploying geographical

maps over the internet. The WMS in an official specification from OGC® and ISO that defines - a set

of interface specifications that provide uniform access by web clients to maps rendered by map

server on the internet. A web map service produces maps of geo-referenced data. The WMS

specification standardized the way client request a map and the way servers describe their data

holdings. Thus, WMS is a service interface specification that:

Enables dynamic construction of a map as a picture, as a series of graphical elements, or as

a package set of geographic feature data.

Answers to basic queries about the content of a map.

Informs other programs about the maps it can produce and it provides metadata about the

data being served.


Sp

ec

ific

LB

S

En

ab

les

Ge

ne

ric

LB

S

En

ab

les

Routing

Identity Management


Co

re

loc

ali

za

tio

n

se

rvic

es

Spatial Solver

Configuration

Monitoring

Da

ta S

tora

geService Bus

CIV

ICF

LO

W


Ga

lile

o

Ca

me

ras

GP

S/E

GN

OS


Indoor Localization

Qu

up

pa

Ca

me

ras

ee

RT

LS

Wi-

Fi

Upload/

Download

OGC Spatial

Proxy




WMS will be deployed in such a way that one will be able to query the server and retrieve certain

information about the data or the capabilities of the service. The following operations are valid

requests to be issued by a client-side application via WMS:

GetCapabilities: to retrieve the capabilities of the server through service-level metadata. This

is a description of the WMS information content and it includes a list of data layers provided

by the service, their extent and coordinate reference system.

GetMap: to retrieve the map (as raster data or image file) whose geographic and dimensional

parameters should be defined by the data service provider.

GetFeatureInfo: to retrieve information about a particular feature shown on the image or

raster file.

WFS

The Web Feature Service is an official specification from the OGC® which provides an interface for

describing data manipulation operations (create, delete, update and get feature) on geographical

feature stored in a database, using HTTP as the distributed computing platform.

The WFS interface exposes the data in these repositories as Geography Mark-up Language (GML).

A WFS request consists of a description of query, or data transformation operations that are to be

applied to one or more features. The request is generated on the client and it is posted to a web

feature server using HTTP. The web feature server then reads and executes the request. A WFS-

compliant OGC® specification can be implemented in either its basic version, or in the so-called

―Transactional version.

Basic WFS are read-only web feature servers while transactional web feature servers (WFS-T) can

additionally support transactional operations. Transactional WFS allows multiple users to perform a

variety of manual operations, such as to create/update/delete data or to make requests

simultaneously on the same geographic feature. However, if a WFS implementation allows clients

to manipulate features, then it must ensure that the client has the authority to perform the

manipulation. It is up to the site that implements the WFS service to manage user-access controls

to upload new or edited features. This would likely be implemented using a user authentication

mechanism that would verify the identity and the role of the user.

There are many advantages of using WFS; most notably it enables raw data to be served to any

client in a vendor neutral format. The raw data can contain the geometric description of a feature as

well as other accompanying information about it. Depending on the data policy issues and the WFS

implementation, access to data through WFS may be prohibited or provided only upon authorization

and therefore allow only visualization functions (similarly to WMS).




9.14 Upload/Download

Service

An small upload service with a

graphical user interface for the

upload of input data (e.g. for .dxf

files, Shapefiles, indoorGML files)

has to be developed (see section

7.1.1). This component deals with

the procedures to open a

communication channel between

the local file system and a remote

repository or processing service.

The user can upload or download a

file to a data store for future usage

or processing purposes. From a

technical perspective we can

implement Multi part Resolver which

can handle file upload. Actually, it

uses the Apache commons upload library in order to handle the file and in our case the data upload.

Below the figure depicts a general diagram of the upload service:

Fig 40: upload service

For the download service we can implement a Spring MVS application which can support the

download functionality. The figure below depicts a workflow for the download service:

Internet

Execute Data Upload

-Temporary storage-

Geographical Data

Warehouse DB

Import


Sp

ec

ific

LB

S

En

ab

les

Ge

ne

ric

LB

S

En

ab

les

Routing

Identity Management


Co

re

loc

ali

za

tio

n

se

rvic

es

Spatial Solver

Configuration

Monitoring

Da

ta S

tora

geService Bus

CIV

ICF

LO

W


Ga

lile

o

Ca

me

ras

GP

S/E

GN

OS


Indoor Localization

Qu

up

pa

Ca

me

ras

ee

RT

LS

Wi-

Fi

Upload/

Download

OGC Spatial

Proxy




Fig 41: download service

Client

click

Download link/data request

Data on

server

Controller

read

response




9.15 Communication Bus

The communication bus is the

software architecture model in

charge of connecting all the i-locate

middleware components providing

agility and flexibility with respect to

the mutual intercommunication

between components. With this

approach it is possible to separate

services and software components

in order to deploy and manage them

independently.

The particular technology used in i-

locate middleware is called

Enterprise Service Bus (ESB) which

is a common pattern for service

oriented architectures and follows

the same design as the World Wide

Web. The ESB functions can range from the monitor and control of message exchange for

connecting services, to manage versioning (route the request to the correct version of the service),

transform data and manage message (or event) queues in case of network traffic. Although it is a

complex and big component, it can easily serve various and heterogeneous atomic services by using

some simple connectors. An ESB can work with different technologies and services, provided that

they are using the proper connector.

Fig 42: Communication Bus

The architecture of the bus itself allows the components to be easily plugged and unplugged or

replaced without big impact or shutdown to the message routing system which besides inside the

ESB itself. Approaching the i-locate architecture with an enterprise service bus, can lead to a huge


Sp

ec

ific

LB

S

En

ab

les

Ge

ne

ric

LB

S

En

ab

les

Routing

Identity Management


Co

re

loc

ali

za

tio

n

se

rvic

es

Spatial Solver

Configuration

Monitoring

Da

ta S

tora

geService Bus

CIV

ICF

LO

W


Ga

lile

o

Ca

me

ras

GP

S/E

GN

OS


Indoor Localization

Qu

up

pa

Ca

me

ras

ee

RT

LS

Wi-

Fi

Upload/

Download

OGC Spatial

Proxy




drop of point-to-point connections and allows a set of interactions to be one-to-many i.e. the location

updates for an object can be sent simultaneously to the database for storing the event and to the

GeoFencing engine.

The adoption of a service bus as loose-coupling technique allows it to be used also as a logger and

filter, in fact it can be used to redirect and block particular messages, delay them until the receiver

is available (think at the user inside a tunnel or in a non-covered area) or check security policies.

One of the main features of the ESB that can improve i-locate middleware functions is the message

queueing and redirection. The message queue is particularly helpful when users are requiring hybrid

routing coming from different services which could not be synchronized, or in case of location

updates, where different technologies and different services could need the information and process

it in different ways (data storage, statistics, geofencing, routing, switchover mechanism and many

others).

Despite all the advantages of the service bus, there are also some drawbacks that needs to be

considered; using an ESB as the main (or unique) connection point to all the services means that

there will be a single node that in case of failure can stop all the communication, and in order to

avoid this, service replication and redundancy must be considered. The second problem is that the

ESB heavily relies to a standard set of messages that can be transferred; in case of a non-standard

message there must be a software adapter that can transform and mediate the flowing messages.

This can turn to be an advance for i-locate system since adapters and transformers are needed for

wrapping custom systems and to allow easy communication between components, hence they can

be re-used for ESB.

There are many good commercial and non-commercial implementations of ESBs and in i-locate

middleware we will consider Oracle ESB (as part of Oracle Fusion Middleware) as commercial

solution and Apache Service Mix or Mule ESB as open source solutions.




10 Camera Surveillance subsystem

The Camera Surveillance Subsystem will be a high-level system component of i-Locate that will build

on top of the toolkit to provide a first example of high-level services which will operate on top of the

camera tracking module as detailed in section 9.9. The component will collect and process data

received from the video cameras, according to the overall approach and –as output- will be able to

generate high-level events and alerts, as illustrated in the following figure, and described below.

The component will be strictly coupled to the camera tracking module of which, to some extent, it

will provide additional extensions regarding to specific computer vision-related features and high-

level logics, as detailed below.

Fig 43: Functional block diagram of the camera surveillance subsystem

10.1 APIs

The architecture of this subsystem will be articulated into the following main macro components:

The plugin-based module.

The message filter.

The context reasoner.

The logical reasoner.

The database.

The services container.

The plugin-based module will be the component dedicated to the interconnection with the

hardware, in this case the video cameras. To this extent this module will logically represent a

dedicated communication to the hardware (parallel to standard communication channel provided by

the “regular” middleware messages), which can be required to provide access to specialised features

that will be specific to camera-based features and therefore will not be available through the i-locate

toolkit (e.g. to grab an image from a camera).

Each plug-in, which will represent a different feature to be tracked (e.g. a person, a vehicle), will

expose, through an API based on HTTP protocol, access to specific features as services to enable

PUSH and PULL requests to and from cameras. These include for instance retrieving an image

Camera surveillance subsystem

Message Filter

Context reasoner

DatabaseLogical reasoner

Service

Container

Connector

Plugin




captured from the cameras or specific information on object detected (e.g. if it is a vehicle or a

person, something not contemplated by the standard communication channel).

In some specific case, PUSH mode may not be recommended, for instance when accessing video

frames, because of high data transfer required between the camera and the rest of the system (the

best solution is to grab a frame only upon a request from the user). Other features available could

be access to specific patter-recognition related camera settings (i.e. sensitivity, selection of

processing areas).

When operating in PUSH mode, the plug-in module will continuously send messages containing data

regarding the elements recognised by the system (i.e. persons or vehicles) which can be related (via

unique ID) to their position retrieved via standard middleware. Such a decoupling will allow for

instance to use cameras for both tracking and reasoning or to mix tracking (e.g. based on use of

tags) and reasoning (e.g. to understand if it is a person or a car) based on use of cameras.

Once that a message will be delivered it will be processed by the system to have it filtered by asset

type (i.e. people or cars) or for other purposes (e.g. to updates statistics i.e. average car speed and

counters). All ancillary data will be then stored to the database.

The aforementioned filtering job will be done, at higher logical level, by the context reasoner that is

the component in charge of analysing whenever a specific situation occurs. In practice, the context

reasoner will be the component inside the Camera Surveillance Subsystem that will deal with the

organization of rough data coming from cameras. Its mission will be to forward, based on the type of

message received from the camera, information to the database in a unique format. Data will be

classified into different categories, depending on the various plugins developed for each pattern to

be recognised, including for instance:

People,

Cars,

Other objects of know aspect.

For every entry it will be possible to retrieve the associated geographic position and timestamp by

means of the unique ID as received by the i-toolkit toolkit.

This component, similar to the previous models, will be able operate in PUSH or PULL mode (the

latter occurring through explicit requests made by the model). Whenever a condition will be met an

“Alert” message can be sent out.

An example may help out understanding the full process. Let us assume there is a use case which

requires use of tracking technologies to locate people. i-locate could retrieve position of a set of

people based on use of tags (e.g. attached to a badge) or through camera based tracking. Their

position of each person is handled by the system. At the same time, the Camera Surveillance

Subsystem can use video flow from the cameras (that may or may not be used for tracking of user’s

position) to detect if a person has fallen down. This could be very relevant in a retirement house.

Once the context reasoner detects a person falling from the images, the alert message is fired

together with information about position, which is retrieved via the unique ID associated to the person

(being one of the “items” being tracked by the camera tracking module). The message is then

redirected it to the correct end-user upon request through the service container.




A further module, the logical reasoner, will extract data from the database to infer information such

as: mean speed and counter of object being tracked (e.g. number of people or vehicle, queue status,

etc.) and sends it to the users via the service container.

It should be noted that the logical reasoner, by interpolating data stored on the database and the

one acquired directly from the camera component, could also “infer” potentially dangerous patterns

(of statistical relevance). Also in this case, an alert will be generated and it will be sent to the

subscribed users via the service container.

In particular, the service container, will be able to expose three different services: resource service,

detection service, settings service which are detailed in the reminder of this document.

Resource service

The resource service will be the component that will connect the statistics stored in the database

with users’ requests through the following methods.

Method Description Parameters Response

getResource() It returns the value of the requested resource ID.

cameraSystem_id: mandatory, identifies which system to query

camera_id: mandatory, identifies a single video camera

resource_id: mandatory, identifies which resource to get. Currently supported: ‘speed’, ‘counter’, ‘people’

fromTime/toTime: mandatory, timestamps, they define the time slot for the analysis

Value (int)

getFrame() It returns the image captured by the selected camera.


camera_id: mandatory, identifies a single video camera

Image (*.png/*.jpg)

Detection service

The detection service will be the component that deals with alerts. Alerts will identify specific

dangerous situations such as car crashes, traffic jams, people walking within dangerous places or

objects on the street. The methods contained are listed in the following table.


subscribe() It can be used by users to subscribe to specific events10.


camera_id: mandatory, identifies the camera to be used

Bool (true if successful)

10 This could be used, for example, whenever a police office wants to receive an alert whenever a car crash occurs or whenever a tourist wants to receive notifications in case of traffic jams.




pushEndPoint_id : mandatory, identifies the end point where the data has to be pushed

pushRegistrationID_id: mandatory, used to indicate to the target of the push notifications

detection_id: mandatory, only information associated to the requested type of detection is returned. If this parameter is missing or invalid an error is returned. Supported values are ‘crash’, ‘peopleonroad’, ‘rocks’, ‘queue’, ‘illumination’

timePeriod: optional, defines the period (in milliseconds) among successive pushes of information

unsubscribe() It gives users the opportunity to unsubscribe to the alert system.

Same as for “subscribe” Bool (true if successful)

Settings service

Lastly the settings service will enable the connection between the user and the camera. This

service will expose methods to modify the parameters related to cameras and/or the Logical

Reasoner such as the sensitivity of the system or the areas in which enable the image processing.

The methods contained are listed in the next Table.


addNewProcArea() It adds a new area in which the image processing is carried on. It returns the ID of the new area if successfully added, -1 if an error occurred.



geometry: mandatory, defines the area

geometry_dscp: optional, string to give a very short description to the new area

Value (int)

deleteProcArea() It removes a previously saved area.



geometry_id: mandatory, identifies the area to be removed


setCameraOptions() It gives access to cameras’ options such as brightness or frame size.







options_id: mandatory, identifies which option to modify

value: optional, identifies the new value. When left blank the system is set to default

setSensitivity() It changes the threshold value at which alerts are generated.



detection_id: mandatory, only the threshold value of the requested type of detection is modified. If this parameter is missing or invalid an error is returned. Supported values are ‘crash’, ‘peopleonroad’, ‘rocks’, ‘queue’, ‘illumination’

threshold: mandatory, values can be ‘low’, ‘med’, ‘high’





11 Dynamic View

This section will summarize what has been thoroughly presented into the Middleware Layer of i-

locate. Namely, a short description of each technology that will be used within the scope of the

project.

It is important to mention that all the above mentioned components have been chosen after taken

into account the different requirements collected throughout WP1, and formalized within the

documents D.1.3. The approach pursued builds on top of Use case modelling which has been tightly

integrated with the user requirements.

This process has been carried out incrementally with involvement of the partners, final pilot users

and of key members of i-locate advisory board. In fact i-locate strongly depends on the requirements

received from the pilot users, and from the use cases and the needs derived from them. This

approach makes the design and later development process, problem-driven.

The one single underpinning of i-locate has been to provide indoor navigation and asset

management services through open GeoData, most importantly, processing functionalities in an

interoperable and scalable way through a federated software infrastructure. Below, the figure Fig 44:

General Overview of the system architecture Fig 44




Da

ta L

aye

r

Mid

dle

war

e La

yer

Communication Bus

Spat

ial S

olv

er

Pro

xySp

atia

l Qu

ery

inte

rfac

e

Ind

oo

r G

eoco

de

/

Rev

erse

Ge

oco

de

Ou

tdo

or

Geo

code

/ R

eve

rse

G

eoco

de

Loca

liza

tio

n S

erv

ice

Ind

oo

r

Gu

up

pa

Zi

gpo

s

Wi-

Fi

QR

C

ame

ra

Ou

tdo

or

G

PS/

EGN

OS

G

alil

eo

Cam

era

In

mem

ory

per

sist

enc

y

Cro

wd

sou

rcin

gG

eo

fen

cin

gRu

le

DB

Ro

uti

ng O

pen

LS p

roxy

Ou

tdoo

rIn

do

or

Cam

era

Su

rve

illan

ce

Trai

nin

g se

ts D

B

Ge

og

rap

hic

al

Da

ta

Wa

reh

ou

se

DB

Co

nfi

gura

tio

n

Us

er

Pro

file

&

Co

nfi

gu

rati

on

DB

Spa

tial

Se

rvic

e

WM

S

Mov

ing

Fe

atu

re

WFS

Ex

tern

al

Ge

og

rap

hic

al

Op

en

Da

ta (

We

b s

erv

ice

s

– O

SM

- G

TF

S)

Iden

tity

Man

age

me

nt

Ph

ysic

al E

nti

ty

Tra

cka

ble

En

tity

Loca

tio

n

An

aly

tics

An

aly

tic

s D

B

Mo

nit

ori

ng

As

se

t

Ma

na

ge

me

nt

DBA

sse

t M

an

age

me

nt

Ap

plic

atio

n L

aye

r




Fig 44: General Overview of the system architecture

The following part will give a general description and scope of each component/service (Fig 44)

Identity Management

This components ensures that users can authenticate using their credential yet in a privacy sound way.

Localization Services

Localization Service contains the indoor and outdoor localization technologies that will be used within i-locate. For outdoor GPS/EGNOS/Galileo, Wi-Fi, Cell Tower location technologies will be used and for the indoor eeRTLS, HAIP, Wi-Fi, cell Tower and QRCodes.

Monitoring Service

Monitoring Service will be a useful tool for the pilot staff in order to manage the status of different objects. Monitoring service will be strongly related to the asset management component and also the asset management repository.

Location Analytics

Spatial Solver

Spatial Solver will be the spatial query interface and it will rely on the Location service and it will communicate with the Geofencing service

Routing service

Routing service will be responsible for the indoor and outdoor guidance of the users. Basically for the indoor environment it will use the IndoorGML data and for the outdoor environment it will use external data repositories (e.g. OSM, GTFS)

Geofencing Service

Geofencing will be an important service for i-locate because it affects a lot of middleware components. Specifically, it is related with the Spatial Solver, Crowdsourcing, Location Analytics, Camera Surveillance. The reason why we use this service is for the need to be notified when a particular geographical position is reached by anything and/or someone.




Location Analytics is a component which will be expose statistics about movement patterns of object and will be inextricably connected with the geofencing component for receiving notifications.

Asset Management

Asset Management will implement an interface that can be used for asset management tasks from the actual implementation of the software used to support to asset management. This will allow definition of asset management processes, the related activities as well as the different operators involved (togheter with their roles) in the asset management tasks.

Crowdsourcing Module

Crowdsourcing module will help i-locate to create open GI related to indoor spaces, enabling users to feed with geographical data. Namely, users will be able to upload relevant data (e.g. .shp, .dxf, .gml) by using CIVCFLOW platform which will communicate with the i-locate data repository.

Configuration

The configuration component will be used for storing and reading various information, such as position of the local reference point; direction of reference axes; version of the system and date of installation. All this information will be stored into the user profile and configuration database

Spatial Services

Spatial Services will be responsible for the connectivity between remote data stores; extract vector and in addition it will be vital for other i-locate services such as the localization service and routing service.

Upload/Download Service

Upload/Download service will give the capability to the user to upload and download data and maps from/to the i-locate database

Communication Bus

Communication bus will ensure access to all the functions required to deploy LBS based on indoor and outdoor positioning.

From the conceptual point of view the final i-Locate toolkit will develop a set of service components,

to be run from one (e.g. pilot i-Locate servers) or more servers (TRILOGIS, external OSM, GTFS),




which will be made accessible via a client available both as standalone program and through the

network JavaTM web technology.

Since the set of services to be deployed will be implemented according to open standards it will be

possible for other stakeholders to access and extend them (e.g. for instance to develop specific

routing services customised for disabled people).




12 Application Layer

12.1 The Mobile Application

The i-locate mobile application will be available for Android and iOS, both working on phones and

tablets. As already mentioned earlier in this document the application will consist of 3 base

components:

The core and GUI – Graphical User Interface. The latter shows the relevant information to

the user including current position, destination, route, directions and so on.

The location module, which is responsible for getting the coordinates for the user.

The communication module, whose role is to ensure communication with the i-locate

services within the application.

The following figure shows how the three main component realate each other and how thei interface

with the middeware.

Core and GUI – Graphical User Interface

As already presented in the first part of this document, the GUI will feature the common interfaces

that will be used to show maps, routes and other information. The interface will display outdoor

(OSM) and indoor (IndoorGML) information, depending on the location. It will let users select their

destination (at the room level for indoor locations and street address level for outdoor locations). In

addition, the GUI will show users the current location (including floor level for indoor).

It should be noted that, while outdoor map will use already existing technologies (e.g. 3D mapping

solutions or 3D viewers such as NASA World Wind), the indoor map visualisation component, for its

specific requirements, will have to be implemented anew. Keeping the two components separated

will ease development and will maximise re-use of existing technologies.

For this reason, particular attention will be paid when shifting from outdoor to indoor maps. This will

be performed through a fadeout of the outdoor details and a fade-in of the indoor map details inside

the building (and viceversa). For indoor routing, level changes will be marked through a fadeout of

the previous level and a fade-in of the new (current) level. When leaving indoor spaces, the process

will be reversed, with the client fading out the indoor map and fading-in the outdoor map.

The GUI of the final application will contain the following modules:

Search module.

Map download module.

Settings module.

Map and routing display module.

The search module, which will provide options for searching addresses and Points of Interest

(POIs), both inside and outside buildings. Outdoor searches will allow selecting Country, City, Street

and Street Number or Intersecting Street. Outdoor POI search will allow both searching for POIs

near current user’s position on route or near a given address or destination.




Indoor search will allow searching for indoor POIs inside the current building or inside a selected

building. A dedicated graphical user interface will be used to show available buildings for the user to

select from.

The map download module will enable users to use online maps or download maps for offline

usage. The module will connect to the i-locate toolkit, present a list of maps available for download.

It will also display a list of selected maps and available updates.

The settings module will be used for local configurations of the app. This includes routing options,

plug-in installation and configuration options, as well as graphical features (e.g. themes and display

options).

The map, routing and display module will show the map (indoor and outdoor), the positions the

user on its current location, it will display the route and it will provide directions on how to reach their

destination. The interface will enable users to zoom in and out, access information about location,

coordinates, signal strength, and so on.

Location module

The location module is in charge of locating the user, including making aware weather the user is

outdoor or indoor. This can be performed in several ways. The location service can use the device’s

own location systems (Wi-Fi or GPS or others) or can acquire location from other services or

technologies (e.g. external Bluetooth tags).

Switching from indoor to outdoor modes can be performed in several ways, depending on available

technologies and hardware options. The location service interacts with the GUI presenting the

information on the user’s current position adjusting accordingly when he/she is indoor or outdoor.

The location service will be solely responsible of determining the position and conditions

(indoor/outdoor) and to inform the GUI which mode to use.

Fig 45: Mobile Application Architecture

The figure above shows the logical connections between the different components. In particular, the

Outdoor Positioning Module will be responsible of receiving outdoor location from outdoor location

sensors such as GPS, Galileo, or other i-locate outdoor positioning systems using specific

positioning and location datasets. The Indoor Positioning Module will do the same using indoor




positioning services for indoor location. The Indoor/outdoor switch positioning module identifies

the location and informs the GUI about the map to use and display. The Positioning

acknowledgement module will transmit location to the GUI which will interpret and display it

according to the information received from the indoor/outdoor switch.

Fig 46: Application Layer - General Approach

Positioning system

Outdoor GPS

Outdoor Map display

User interface actions

Outdoor map high detailBuilding no

detail

Indoor Map display

Outdoor GPS signall loss

No indoor Map display

Entering location

Indor positioning

start

Outdoor map low detail

Entrance level Map display

based on entry point

Outdoor details

fadeout

Indoor detail fadein

Level change

Previous level details

fadeout

New level details fadein

New level map displayed

Record entry point

Record exit point

Leaving premises

Outdoor map high detailBuilding no

detail

Outdoor details fadein

Indoor detail fadeout

No indoor Map display




A list of modules which will be used – A diagram for each module – and an explanation should be

provided (e.g. navigation instructions)

Fig 47: Application Layer main interactions

Communication module

Lastly the communication module will be in charge of transmitting data between the application

and the middleware. Two scenarios have emerged concerning the communication module:

Internet access is available: In this case the application connects to the i-locate services

for navigation, routing and map download.

Internet access is unavailable. This can occur where the pilot or beneficiary of i-locate

does not wish to provide its customers with internet connectivity. In this scenario, we provide

a local network replica of the i-locate cloud services. The local network will be configured

to route the domain used for i-locate services (e.g. cloud.i-locate.eu) to a local server. The

communication module will communicate with this replica, download maps and routing

information from it.

User

Interaction

GUI

Communication

moduleLocation Module

Send

Route, Maps, Info

Show position

Inform if indoor/outdoor

Request

Route, Maps, Info

Send location

i-locate middleware

Positioning systems

(GPS, Galileo, Wi-Fi,

Cell Tower)

Acquire location information

Communicate current position

Request routingProvide routing




Fig 48: Mobile Application Architecture




Fig 49: Mobile App - Communication module

The communication module will also receive routing information from the i-locate middleware and

forward it to the GUI.

12.2 The Web Application

As illustrated in previous sections, several web interface will be customised for use by the different

user groups involved in the different pilot sites, including nurses, receptionists, engineers etc.

These interface will be developed following the principles of ergonomics and user friendliness. It will

work in any web browser. It will enable different functionalities for each user type, such as:

Local network and local middleware

user

Connect local wi-fi

i-locate app

middleware

Internet available

Connect to www.i-locatemidleware.eu

Local router – redirect www.i-locatemiddleware.eu to local ip for local i-locate server

YES

NO

Emulate i-locate cloud

Map downloadRouting system

Www.ilocatemiddleware.eu

Navigation, routing...




Staff :

Pre-authorization features (Requirement - connection to Wi-Fi)

Check in (list of the people has checked in)

Queue management (for emergency)

Queue management by doctor/clinic

Expected Time of Arrival (ETA) of doctors

Position of Asset

People leaving premises

Asset leaving premises

Entering non authorization area

Rescheduling/Cancelling

Expected late arrival alert

Guidance in a specific condition

Operational

Simple Map

Re-associate Doctors/Staff

Asset Management

Analytics

Patient/Visitors

ID Card Number

Name

Surname

Routing Preferences (Patients/visitors)

Notification of change of schedule

Cancel appointment

Expected late arrival alert

Specialists

On Duty / off Duty

List of expecting Patients

Patient checked in or changed for their clinic

Facility to inform of cancellation/delay

The workflows for the web application are described as follows:




i-locate Middleware

Web interface actions

Query Doctor

Locate Doctor Provide ETA

Doctor Located, ETA

provided

Doctor / Staff ETA

i-locate Middleware


Querry Asset /Person

Locate Asset /Person

Provice Location

Asset/Person Located

Person/Asset Location

i-locate Middleware


Asset/Person Monitoring

Notify Staff

Asset/Person leaving

premises/enter unauthorized

area

Unauthorized access

i-locate Middleware


Person check-in

Notify Staff

Queue Management

Check in and Queue Management




Fig 50: Web application workflows

The web application will interact with the location services in the middleware in order to obtain the

location of assets and people.

12.3 Communication

The communication between middleware and application layer will be also based on open

standards by the OGC to ensure maximum interoperability and scalability.

Mobile App

i-locate Middleware


Rescheduling, expected late

arival notification

Notify staff, doctor

Rescheduling, if possible

Notification staff/doctors

Rescheduling Expected Late Arrival

Mobile App

i-locate Middleware


Queue Management

Notify Staff, Doctor, Visitor

Notification staff/doctors

Notification Visitor/Doctors

Queue Management




13 Portal Infrastructure

The portal will allow visualisation of indoor maps and creation of new ones by users. This subsection

details the details of the portal and conversion tool, and then the architecture by which these will be

accomplished. It should be noted that these functionalities have been defined to respond of a

specific set of use cases which have been included in Appendix 2 to this document.

These use cases have not been included in the i-locate deliverable D1.1 – Use cases description

and Privacy Threat Vulnerability and Risk (Available online from: http://www.i-locate.eu/public-

deliverables/) because of they are not related to pilot-related use cases, but rather to functional

aspects of the portal as part of the i-locate infrastructure. Their importance for the definition of the

features required by the portal during the design stage, has justified their detailed definition and

inclusion within the D.1.4 as appendix.

The portal and its related conversion tools will have to address the use cases detained in the

following sections. For the portal, two types of users will exist. The ‘’basic user’ is typically a lay-

person, e.g. a citizen, a patient of an hospital, the visitor of a museum, or a taxpayer. This lay user

can only see the information available within the portal, that is indoor maps, which can be

interactively accessed or downloaded as open data. A second type of user will be instead an

‘advanced user’, that is someone from an institution that wishes to enrol in the i-locate portal.

Typically this user would be a IT manager or an IT specialist. This user profile will have the privileges

and tools to create and edit maps, in order to make them available to the large community of end

users.

Fig 51: Portal Infrastructure Architecture Diagram

Web Browser

OpenLayersJavascript library

Geoserver

Outdoor Map Service

Base Map Service

OpenStreetMap Connector

Other Connectors

Map Editing Service

Map Upload Service

TopologicalChecker

User Service

Geospatial Indoor Data

Auxiliary / Meta Data

Open Street Map

Site Service

i-locate portal web application

Page Controllers

HTMLJavascript

User ShapefileUpload

Map Export Service

Map

Oracle SQL Database with Spatial and Graph Extension

Other Geospatial Repositories






Fig 52: The different modules of the portal

13.1 Web Browser Layer

The portal web application will have several panels necessary to accomplish the scenarios listed.

These are: a guest view map screen, with search and guidance tabs, and for admins a log-in screen,

a staging map preview screen, a site status and operations screen, and a special map view screen.

All web application pages will have a header with the i-locate project name, a log-in or log-out link

(depending on whether there is a currently logged in user), and a language selection list.

Each web application page will interact on the server with a corresponding page controller. In general

each page will describe the look, layout and functionality in the browser, while the server-side

functionality will be provided by the page controller.

Map ConverterAnd Editor

Shapefile Loader Shapefile Model

Map Renderer

Shapefile from GeoDB

IndoorGML Model

IndoorGML Renderer

IndoorGML Editor

IndoorGML to GeoDB

IndoorGML from GeoDB

Oracle Spatial and Graph

SHP Files

Shapefile to GeoDB

Space Partitioner

Validation Suite




13.1.1 Guest view map screen

This will be the main screen of the application. On this screen, an end user will be able to search for

a location and display its map. The user will be able to pan / zoom the map, and change level (floor)

if several levels are available.

On the top of the screen, a link leads to the log-in screen for an admin. On the left side, two tabs

offer search and guidance functions. The search tab displays a search text field, and a search button.

After entering text and clicking the search button, a list of results is displayed – a list of found

locations. Clicking on a location in the results list will navigate the map to that location. The guidance

tab displays two text fields, for guidance start and destination, and a ‘show route’ button. A checkbox

allows requesting a route for wheelchair access. Filling in the source and destination and clicking on

the ‘show route’ button will display a list of routing instructions. The route will also be displayed on

the map.

Fig 53: Guest view map Screen

On the right side of the screen there will be a map, which will be navigable by zoom / pan, and which

will respond to actions on the left side – search for places and guidance.

13.1.2 Login screen

After clicking “Log In” from the guest view map screen, a user will be taken to the log in screen. This

allows admin users to authenticate to the system using a username and password. After a successful

login, the admin user will be taken to the site status and operations screen.




13.1.3 Site status and operations screen

The site status and operations screen will display the maps currently available for the site

administered by the logged in user. There will be a list with the maps in staging, and a list with the

maps in production. There will be a button that allows pushing all the maps currently in staging in

production mode, replacing those already in production. There will be a possibility to remove maps

from staging, and to upload a new map or a new version of an already existing map.

13.1.4 Staging map preview screen

This page allows the admin user to see a preview of the maps, in staging mode, as they will appear

in production once promoted. This screen will show the staging maps for the current site, with the

navigation graph overlaid. (Note, if the user moves the map to see a different site, she will see the

production maps. The staging maps are only visible for the user’s own site.)

13.1.5 Special map view screen

This page shows the map with some special overlay. A drop down menu on the left side allows

selecting from the special overlays available for this site. This is meant to be used for things like

asset management, or visitor statistics. On the right side, the map will be shown with the selected

overlay.

13.1.6 Map control implementation

The implementation of a map control in a HTML page will be implemented with the OpenLayers

JavaScript library, which supports standards such as OGC WMS. This allows combining data from

i-Locate, Open Street Maps and other sources. The map control will obtain the map data to display

from two sources: the map server (Geoserver) and the portal web server. Geoserver is an open-

source java web application, which runs in a container servlet (e.g. tomcat), and has the capability

to read geospatial data from a multitude of sources and offer standard services, such as OGC WMS.

The Geoserver will provide map data, while the portal web app server will provide overlay data, such

as the location of indoor mapped sites, or IndoorGML graph when editing. Additional detail on

Geoserver are included in the following pages.

13.2 Web Server Layer

13.2.1 Introduction

The web server layer of the portal will consist of two java web applications, running in a servlet

container, for example Tomcat. One of the applications will provide the map services, which will be

done by Geoserver, with proper configuration to obtain data from the database, and connectors to

external open data repositories. These will provide data to the OpenLayers library in the browser.

The other application will contain the actual web pages implementing the portal and all the other

services. This section of the web layer will handle users, security, auxiliary data (such as pilot sites

names, descriptions, maps names), crowdsourcing, map editing, etc.




13.2.2 Geoserver

The map services in this section will be provided through Geoserver. It will be configured to read

data from the geospatial SQL database.

Geoserver follows the WMS, WFS and WCS specifications to the letter, and forms the platform to

develop GIS applications based on these specifications. Additionally, GeoServer reads data in a

wide variety of formats from PostGIS, Oracle Spatial, ArcSDE to shapefiles and Geotiff. It can also

produce KML, GML, Shapefiles, GeoRSS, GeoJSOn and multitudes of other formats.

GeoServer database communication is based on GeoTools which is an open source (LGPL) Java

code library which provides standards compliant methods for the manipulation of geospatial data.

13.2.3 Outdoor Map Service

This service will provide the basic tiles for the outdoor map for the whole world, through a connector

to an external source, like Open Street Map. This should implement the OGC WMS standard.

According to the standard, the operations exposed by this service are:

Operation Get Capabilities

Inputs None

Results returns parameters about the WMS (such as map image format and WMS version compatibility) and the available layers (map bounding box, coordinate reference systems, URI of the data and whether the layer is mostly opaque or not).

Operation Get Map

Inputs Layers – list of map layers to retrieve, Styles – list of rendering styles, one per layer, CRS – Coordinate Reference System, BBOX – bounding box coordinates in CRS units, Width – width in pixels, Height – height in pixels, Format – the image format to return.

Results An image in the specified format, which contains a tile of the map, according to the parameters.

13.2.3.1 Base Map Service

This service will provide the basic tiles for the map, for a given site, floor and so on. This should

implement the OGC WMS standard.

According to the standard, the operations exposed by this service are:

Operation Get Capabilities

Inputs None

Results returns parameters about the WMS (such as map image format and WMS version compatibility) and the available layers (map bounding box, coordinate reference systems, URI of the data and whether the layer is mostly opaque or not).




Operation Get Map

Inputs Layers – list of map layers to retrieve, Styles – list of rendering styles, one per layer, CRS – Coordinate Reference System, BBOX – bounding box coordinates in CRS units, Width – width in pixels, Height – height in pixels, Format – the image format to return.

Results An image in the specified format, which contains a tile of the map, according to the parameters.

13.2.3.2 OSM connector

The Open Street Map servers provide a OGC WMS standard service. Because it is standard

compliant, it can be used in Geoserver with just some configuration. The connector to OSM is

therefore reduced to the appropriate configuration in Geoserver.

13.2.3.3 Other Connectors

Connectors to other geospatial data repositories will be developed, depending on which repositories

are identified in Task T2.3.1. Depending on the data formats and APIs available for these, the

connectors may range in complexity from configuration settings for Geoserver to software

components that interface with the map server and/or OpenLayers. The connectors will be

developed in such a way that the map server can offer their data through a standard WMS service.

13.2.4 Web application

13.2.4.1 Map Editing Service

The map editing service will provide all necessary operations to implement a map editor in the

browser using the OpenLayers JavaScript library.

Operation Create Layer

Inputs Site name – name of the site that contains the map, Map name – name of the map that the layer will be created into, Layer Type – the layer type to be created. Site, map and layer type must exist.

Results A layer of the specified type is created. A layer identifier is returned.

Operation Delete Layer

Inputs Site name – name of the site that contains the map, Map name – name of the map that the layer will be deleted from, Layer Identifier – the layer type to be deleted. Site, map and layer type must exist. A layer of the specified type must exist.

Results The layer of the specified type is deleted

Operation Copy Layer

Inputs Site name – name of the site that contains the map, Map name – name of the map that the layer will be created into, Source Layer Identifier – the layer to copy




data from, Destination Layer Type – the layer type to be created and populated with copied data . Site, map and destination layer types must exist. The source layer must exist.

Results The information in the source layer is copied in the destination layer. A layer identifier for the destination layer is returned.

Operation Create Graph Node

Inputs Site name – name of the site that contains the map, Layer Identifier – identifier of the layer that the node will be created into, Node Position – the position at which to create the node. Site and layer must exist. A node must not exist at the same exact position as the new one.

Results A new node is created in the specified layer at the specified position. A node identifier is returned.

Operation Delete Graph Node

Inputs Site name – name of the site that contains the map, Node Identifier – identifier of the node to be deleted. Site and node must exist.

Results he node with the specified identifier is deleted, along with all edges connected to it.

Operation Set Graph Node Property

Inputs Site name – name of the site that contains the map, Node Identifier – the node for which a property should be set, Property Name – the property to set, Property Value – the property value to set. Site and node must exist.

Results The specified node will have the specified property set with the specified value

Operation Read Graph Node Properties

Inputs Site name – name of the site that contains the map, Node Identifier – the node for which a property should be set. Site and node must exist.

Results A collection of name-value pairs will be returned, which are the properties of the node.

Operation Create Graph Edge

Inputs Site name – name of the site that contains the map, First Node Identifier – the starting node for the edge, Second Node Identifier – the finishing node for the edge. Site and both nodes must exist. An edge must not exist between the first to the second node.

Results An edge is created between the first to the second node. An identifier is returned for the created edge.




Operation Delete Graph Edge

Inputs Site name – name of the site that contains the map, Edge Identifier – identifier of the edge to be deleted. Site and edge must exist.

Results The edge with the specified identifier is deleted. The nodes that the edge connected will remain.

Operation Set Graph Edge Property

Inputs Site name – name of the site that contains the map, Edge Identifier – the edge for which a property should be set, Property Name – the property to set, Property Value – the property value to set. Site and edge must exist.

Results The specified edge will have the specified property set with the specified value.

Operation Read Graph Edge Properties

Inputs Site name – name of the site that contains the map, Edge Identifier – the edge for which a property should be set. Site and edge must exist.

Results A collection of name-value pairs will be returned, which are the properties of the edge.

13.2.4.2 Page Controllers

The portal web application will contain a series of controllers that manage the html pages and the

forms in them (e.g. login form, user registration form, new site, new map). Page controllers will

interact where necessary with the other services in the system.

13.2.4.3 Map Overlay

The map overlay service will provide additional map data which is not appropriate for the map

service. This is for instance a set of points that display the location of all indoor map sites, for a

zoomed out world map, or map data that is currently being edited. The data will be provided in a

format convenient for use in OpenLayers, probably as JSON.

13.2.4.4 Map Upload Service

This service will allow the uploading of new map data to the portal. This will also permit invocation

of the conversion tool and the GTMC (topological checker).

Operation Upload Map

Inputs Site name – name of the site for which this map is uploaded, Map name – name of the map that is uploaded, so it can be referenced later, Map Data – the actual map data. The map will consist of either shapefile data, used for rendering, or IndoorGML data, used for navigation.

Results The map is uploaded in the database, but not yet made available on staging. It must first be validated by the topological checker.




Operation Check Map

Inputs Site name – name of the site for which a map will be checked, Map name – a map to be checked. The map must be uploaded but not checked yet.

Results Either a success response, indicating that the check found no problems, or a list of errors found in the map. If the check is successful, the map will be entered into the staging area.

13.2.4.5 Map Export Service

This service will allow the downloading of map data from portal.

Operation Download Map

Inputs Site name – name of the site that contains the map, Map name – name of the map that will be downloaded, Data Type – which kind of data to download: shapefile or IndoorGML.

Results The map data is returned, in an appropriate file format, depending on data type

13.2.4.6 Site Service

A ‘Site’ is a collection of maps for an institution, or a location, e.g a map for each floor, several

buildings, etc. This service will deal with things like create a new site, list available sites, list maps

available for a site, change site from staging mode to production mode. This service will be called

by the web layer.

Notes on ‘Staging’: A site may have more or less maps in staging than in production, and different

versions of the same map i.e. the same floor of the same building may look different in staging than

in production. The purpose of this arrangement is to allow proposed maps to be previewed and

checked for correctness before making them available to the end users.

The following operations are exposed by the site service:

Operation New Site

Inputs Name – the name of the site to be created; Admin user – the user that will have modification rights for this site.

Results A new site will be created with the given name, and the specified user will have modification rights for this site.

Operation List Sites

Inputs None

Results A list of all available sites in the system.

Operation List Site Maps




Inputs Site name – the name of the site for which maps should be listed. Mode – an argument specifying whether to return the staging maps or the production maps for the site.

Results A list of available maps for the given site.

Operation Promote to production

Inputs Site Name – the name of the site to promote to production.

Results All the current maps that this site has in staging mode are copied to production mode.

13.2.4.7 User Service

This service will provide user authentication and user access rights. Only Admin users need to be

authenticated, end users can access the portal without any authentication.

Operation Authenticate user

Inputs User name – user name, Password – password with which user attempts authentication.

Results Either a success response, indicating that the user exists and this is the correct password, or an error indicating either the user does not exist or the password is incorrect. A data structure is returned including user details and the name of the site for which this user has admin rights.

13.2.4.8 Geographical and Topological Model Checker

This service will be responsible for providing control, against a pre-set model (e.g. an XML), of a

given set of rules which will be defined within a configuration file. The Geographical and Topological

Model Checker will extend the existing component from Trilogis which will be integrated, as a service,

within the i-locate infrastructure. The system not only will allow invoking of validation of a dataset

against a set of rules but, most importantly, it will produce –as output- the result of the operation,

including possible break of rules or formal errors.

13.2.5 Geospatial Data

The web application will be fed by a big number of geospatial data. Actually it depends on each pilot

case and especially about the availability of the data. Specifically, after the collection of the various

data of each pilot, a single geodatabase will be created for each pilot. All this geospatial data will be

available for the web application. Additionally, the database will allow the user to create/edit/upload

new data, make spatial queries and retrieve data. As mentioned in section 8.2 this data will be mostly

stored through the use of Spatial Databases.

Date post:	06-Aug-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times