WODAR – Web Open Data Augmented Reality

(1)

Studente/i

Bertacco Davide

Relatore

Sommaruga Lorenzo

Correlatore

Catenazzi Nadia

Committente

Sommaruga Lorenzo

Corso di laurea

Ingegneria Informatica

Modulo

Progetto di diploma

Anno

2018-2019

Data

(2)

(3)

Indice

1 Introduzione 3

2 Progetto assegnato 5

3 Analisi dei requisiti 7

3.1 Definire punto di interesse . . . 7

3.2 Backend per la costruzione dei wPOI . . . 8

3.3 Esporre wPOI attraverso un server . . . 8

3.4 Client web in realtà aumentata . . . 9

4 Tecnologie e metodologie utilizzate 11 4.1 Back-end . . . 11

4.2 Front-end . . . 11

4.3 GitLab & Continuos Integration . . . 12

4.4 Librerie . . . 12

4.5 Metodologia di lavoro . . . 13

4.5.1 Organizzazione del lavoro . . . 13

5 Implementazione e funzionamento 15 5.1 Raccolta dati . . . 15 5.1.1 SimpleGeo . . . 16 5.1.1.1 Paesi contenuti: . . . 16 5.1.1.2 Implementazione . . . 17 5.1.2 API . . . 17 5.1.2.1 Implementazione . . . 19 5.1.3 Sparql query . . . 19 5.1.3.1 Implementazione . . . 21

5.2 Mapping dati ritornati . . . 22

5.3 Merge dei dati . . . 25

5.4 Esposizione dati con API . . . 26

(4)

ii INDICE

5.4.1.1 Conclusione . . . 29

5.5 Client AR . . . 30

5.5.1 Implementazione . . . 30

5.6 Test . . . 31

5.6.1 Test sul modello . . . 31

5.6.2 Test interazione database . . . 31

6 Guida all’utilizzo del client 33 7 Sviluppo futuro 37 8 Conclusione 39 8.1 Obiettivi raggiunti . . . 39

8.2 Competenze sviluppate . . . 39

(5)

Elenco delle figure

1.1 Schema del lavoro svolto . . . 4

3.1 Libreria usata per l’esposizione dei wPOI . . . 8

3.2 Framework AR considerati . . . 9

5.1 Interfaccia gestione API . . . 18

5.2 Interfaccia gestione query sparql . . . 19

5.3 Confronto mapping API - query sparql . . . 22

5.4 Algoritmo creazione dataset preprocessamento . . . 27

5.5 Algoritmo creazione dataset intersezione . . . 28

5.6 Algoritmo creazione dataset tangenza . . . 28

5.7 Algoritmo creazione dataset immagine dimostrativa . . . 29

6.1 Interfaccia client (lungolago Lugano) . . . 33

6.2 Interfaccia client (lungolago Lugano) . . . 34

6.3 Interfaccia client (Piazza Riforma Lugano) . . . 34

6.7 Interfaccia client (Parco Ciani Lugano) . . . 35

7.1 Interfaccia client problema scaling (Parco Ciani Lugano) . . . 38

(6)

(7)

Abstract

WODAR è un progetto sperimentale con lo scopo di realizzare un’applicazione dimostrativa che utilizzi e visualizzi dati aperti esistenti, sfruttando i benefici dell’integrazione delle tec-nologie web di realtà aumentata (AR) e di Linked Open Data (LOD).

In particolare, questo progetto, e composto da tre blocchi principali.

1. Il primo blocco rappresenta lo sviluppo di un meccanismo di raccolta e di aggregazione dei dati LOD disponibili sul web attraverso API o query sparql. Le fonti dati, rappre-sentate da API o da query sparql, risultano ampiamente personalizzabili attraverso un interfaccia che permette l’aggiunta, la modifica e la rimozione delle stesse e il mapping delle risorse ritornate con la struttura dati sottostante, definita sottoforma di wPOI in campo applicativo turistico.

2. Il secondo blocco è rappresentato dall’esposizione dei dati sopra generati attraverso un’API. Essa è resa parametrizzabile dal fatto che in background sfrutta l’endpoint sparql generato dal software d2rq, il quale permette all’API di comportarsi come una query sparql con endpoint predefinito.

3. Il terzo blocco è la parte che va a visualizzare i dati resi disponibili dall’API. Questa parte è composta da una pagina web che sfrutta la realtà aumentata, basandosi sul framework AR.js, per renderizzare dei marker virtuali sopra le immagini catturate dalla telecamera del dispositivo in uso.

(8)

(9)

Capitolo 1

Introduzione

Il progetto presentato prevede l’implementazione di un sistema composto da una parte ser-ver di esposizione e pre-processamento di dati aperti e da una parte client di “consumo” mediante una web app in AR.

Le principali funzionalità di cui è richiesta l’implementazione iniziano con lo sviluppo di un algoritmo di parsing-matching dei dati aperti, raccolti attraverso API o query sparql configu-rabili dall’utente. Continuano con l’aggiunta di un servizio per l’esposizione dei dati raccolti nel database attraverso un endpoint sparql realizzato con software opensource disponibili in rete. Finiscono con l’aggiunta di un client in realtà aumentata che permetta di visualizzare i dati ritornati dall’endpoint sparql nel mondo reale attraverso una Web Application. Per svolgere le parti sopra descritte si sfrutta la struttura dati del wPOI definita apposita-mente per il progetto e fissata in campo applicativo turistico.

Tra i compiti da svolgere rientrano ovviamente anche la pianificazione per lo sviluppo del progetto, quindi l’analisi dei bisogni, dei vincoli e delle funzionalità richieste per il comple-tamento del sistema. Questa parte svoltasi in collaborazione con il relatore del progetto ha portato a frequenti mutamenti della pianificazione iniziale con l’inserimento e la modifica di features per adattarsi ai nuovi requisiti. Dal punto di vista dell’implementazione questo si trasforma nell’aumento dei tempi di sviluppo e di refactoring necessari per l’aggiunta delle nuove funzionalità.

(10)

4 Introduzione

(11)

Capitolo 2

Progetto assegnato

Web Open Data AR - WODAR

Persone coinvolte

Proponente Sommaruga Lorenzo Relatore Sommaruga Lorenzo Correlatore Catenazzi Nadia Studente Bertacco Davide

Dati generali

Codice C10089

Anno accademico 2018/2019 Semestre Semestre estivo

Corso di laurea Ingegneria informatica (Informatica TP) Opzione Nessuna opzione

Tipologia del progetto diploma Stato in corso Confidenziale NO Pubblicabile SI

Descrizione

Le tecnologie web per lo sviluppo di smart applications stanno raggiungendo un livello di ma-turità che permette di sperimentare lo sviluppo di interessanti applicazioni web cross-browser e platform.

(12)

6 Progetto assegnato

Nell’ambito di un progetto Interreg sui Linked Open Data (LOD) per favorire l’ egovernance, questo progetto mira a sviluppare un’applicazione dimostrativa che utilizzi e visualizzi dati aperti esistenti sfruttando i benefici dell’integrazione delle tecnologie web, di realtà aumen-tata (AR) e di LOD.

Si prenderà in considerazione l’intero processo di creazione di una applicazione LOD, dalla produzione dei dati, a un loro eventuale pre-processamento, alla loro esposizione tramite API e standard, al loro consumo all’interno di una web app innovativa di AR. Si prevede di sfruttare dati provenienti da DBpedia o Wikidata.

Compiti

- Analisi dello stato attuale della soluzione: bisogni, vincoli, funzionalità richieste per il completamento del sistema

- Implementazione di un sistema composto da una parte server di esposizione e prepro-cessamento di dati aperti e da una parte client di “consumo” mediante una web app in AR

- Testing e valutazione dei risultati

- Interazione e collaborazione con il team di progetto e tutte le altre possibili persone coinvolte

- Descrizione e presentazione finale del lavoro svolto

Obbiettivi

Sviluppo completo di un progetto

Realizzazione di una applicazione web in AR con dati aperti

Tecnologie

- Tecnologie per sviluppo AR in web lib e framework per riconoscimento di patterns AR, AR.js, ARcore

- Tecnologie e formati standard per l’esposizione di dati aperti (e.g. Sparql endpoint) - Tecnologie per sviluppo web app e CI/CD

(13)

Capitolo 3

Analisi dei requisiti

Come già accennato nell’introduzione, a inizio progetto sono stati definiti con il relatore i requisiti del progetto (in questo caso, le funzionalità prioritarie su cui focalizzare il progetto):

• Definire la struttura di un punto di interesse (wPOI) • Sviluppare un backend che costruisca i wPOI

• Esporre i wPOI su un server

• Mostrare i wPOI in realtà aumentata su una pagina web

Il livello di dettaglio e la comprensione dei requisiti sono andati a mano a mano migliorando con l’avanzare del progetto: la migliore confidenza con il codice già prodotto e gli incontri settimanali con il committente/relatore sono serviti a dettagliare le richieste più importanti e a circoscrivere le diverse situazioni di utilizzo delle nuove funzionalità dell’applicazione.

3.1 Definire punto di interesse

Per la definizione del punto di interesse (wPOI) sono state prese in considerazione varie ontologie o dizionari già esistenti. Tra quelle considerate risultano quella di SimpleGeo, che è stata quasi subito scartata a causa della mancanza di molti attributi tra i quali una chiave per indicare l’altitudine, quella di Factual, che anche se più completa rispetto a quella di SimpleGeo presentava la stessa mancanza, quella di OpenStreetMap, la quale è una delle due prese maggiormente in considerazione ma che risponde con modelli leggermente diversi in base alla richiesta che viene esseguita 1, e in fine quella di DBpedia, la quale unita con quella di OpenStreetMap è stata usata per la definizione del nostro wPOI.

1

Ad esempio se si fa una richiesta per un singolo wPOI l’address viene descritto come un oggetto indipen-dente all’interno dell’oggetto wPOI, mentre se si fa una richiesta che ritorna una lista di wPOI i componenti dell’address sono espressi con il namespace addr (addr:city, addr:country, ...).

(14)

8 Analisi dei requisiti

3.2 Backend per la costruzione dei wPOI

La scelta del backend per la costruzione dei wPOI è, come descritto nel capito successivo, caduta su Java. Questa decisione è stata presa a causa delle potenzialità offerte da questo linguaggio quali: la velocità di sviluppo, la grande disponibilità di librerie, l’alta integrazione con il web e la compatibilità multipiattaforma.

3.3 Esporre wPOI attraverso un server

Per l’esposizione dei dati sul server, la scelta iniziale non è quella che poi è stata portata avanti fino allo sviluppo finale. Infatti, come prima idea, si voleva sfruttare un servizio per esposizione dei dati quale Apache Jena Fuseki o graphDB, i quali necessitano entrambi di una precedente conversione del database relazionale in un file rdf. Per la conversione del DB in rdf si era scelto di utilizzare il programma xsltproc, che prendendo come argomenti il risultato di una query sql e un file di mapping restituiva come risultato il file rdf. Il problema di questo approccio si situava proprio nella fase di conversione del database relazionale. Infatti da questa conversione si otteneva correttamente un file rdf che però era sprovvisto di un dizionario delle classi e quindi il server di esposizione2, pur servendo correttamente i wPOI, non consentiva l’utilizzo delle query sparql.

Da questo punto in poi la scelta si è spostata a un server in grado di comunicare direttamente con il database, ed è stato scelto d2rq3, il quale anche se con aggiornamenti non recenti delle lib software era in grado di svolgere tutte le necessità richieste dal progetto. In particolare questo software, per svolgere il suo compito, necessita di un file di mapping che definisce il database con il quale comunicare 4, la struttura dei dati in esso contenuti e il modo in cui questi dati devono essere strutturati per la fase di esposizione.

Figura 3.1: Libreria usata per l’esposizione dei wPOI

2

Apache Jena Fuseki (scelto perchè già presente sul server di destinazione del progetto)

3_{[1] http://d2rq.org/} 4

(15)

3.4 Client web in realtà aumentata

Per la scelta del framework di realtà aumentata sono state valutate alcune alternative. La prima è stata AR.js 5, la quale è stata poi utilizzata nel progetto ma che inizialmente era stata accantonata a causa della mancanza dell’utilizzo delle coordinate per il posizionamento degli oggetti. La seconda è stata Argon.js6, la quale sembrava la più idonea alle necessità del progetto, visto che permette il posizionamento degli oggetti in base alle coordinate, ma che poi si è rivelata inutile visto che non è stato possibile farla funzionare e non funziona nemmeno il loro browser Argon4 7 che sfrutta quel framework. La terza opzione è stata WebXR 8, anchessa molto promettente ma ancora in via sperimentale e quindi non disponibile su tutti i browser. L’ ultima opzione è stata awe.js 9 che pur essendo molto interessante per essere utilizzata necessita della piattaforma awe.media 10 che è a pagamento.

Figura 3.2: Framework AR considerati

5 [2] https://github.com/jeromeetienne/AR.js 6 [3] https://www.argonjs.io/ 7_{[4] https://app.argonjs.io/} 8 [5] https://webxr.io/ 9_{[6] https://github.com/awe-media/awe.js} 10 [7] https://awe.media/

(16)

(17)

Capitolo 4

Tecnologie e metodologie utilizzate

In questo capitolo si vanno ad elencare le tecnologie e metodologie utilizzate per lo sviluppo dei componenti mostrati nello schema dell’immagine 1.1 subito dopo l’introduzione.

4.1 Back-end

Il back-end dell’applicazione è stato sviluppato in Java con Spring MVC. Il framework fornisce tecnologie per la gestione della sicurezza e della connessione con il database, oltre che naturalmente la possibilità di servire richieste HTTP.

Per la gestione del database, Spring è stato affiancato da un ORM, JPA, per la gestione della struttura e del contenuto delle tabelle.

Per quanto riguarda invece il deploy dell’applicazione, è stato scelto Apache Tomcat per la Web Application WODAR e Jetty per d2rq 1.

4.2 Front-end

Il front-end, la parte con cui interagisce l’utente, è stato implementato utilizzando HTML e CSS (in particolare Bootstrap) per la creazione di pagine e template con Thymeleaf, per ottenere delle pagine costruite dinamicamente dal server. Per la gestione dell’interazione con l’utente e per la comunicazione asincrona con il server sono stati usati, rispettivamente,

JavaScript (con anche il framework JQuery) e AJAX. Inoltre per quanto riguarda la

visua-lizzazione della mappa è stata sfruttata la libreria Leaflet 2, mentre per quanto riguarda il client è stata usata AR.js 3_{, descritta nel paragrafo delle Librerie.}

1

[1] http://d2rq.org/

2_{[8] https://leafletjs.com/} 3

(18)

12 Tecnologie e metodologie utilizzate

4.3 GitLab & Continuos Integration

Il codice dell’applicazione web è ospitato sulla piattaforma GitLab SUPSI-DTI ISIN, motivo per il quale Git è stato utilizzato come sistema di versioning per la condivisione del codice. Potendo disporre della piattaforma GitLab, nella seconda parte del progetto abbiamo sfruttato anche le possibilità di continuos integration offerte da questa: raggiunta la giusta maturità delle funzionalità implementate, esse sono state aggiunte in modo continuo all’applicazione e messe direttamente in produzione. E’ ora disponibile un ambiente di sviluppo del progetto che permette facilità di aggiornamento e di messa in produzione per poter continuare negli sviluppi sperimentali del sistema.

4.4 Librerie

Per rendere il lavoro più agevole, è stato necessario ricercare e includere alcune librerie esterne per poter eseguire specifici compiti.

In particolare, le principali librerie sono:

• d2rq4_{: è una libreria Java che permette di accedere ai database relazionali come grafici}

RDF virtuali di sola lettura. Offre accesso basato su RDF al contenuto dei database relazionali senza doverlo replicare in un archivio RDF.

A causa del fatto che questa libreria è un pò obsoleta, visto che l’ultima release risale al 2012, per farla funzionare è stato necessario aggiornare il connettore mysql a una versione più recente in modo da farlo funzionare sia con la versione 5 di mysql che con la 8 5. Questo aggiornamento è stato anche pubblicato sul software open source in GitHub contribuendo allo sviluppo del progetto. Inoltre per linux è stato anche necessario creare uno script bash per avviare il programma che altrimenti necessitava di recarsi nella cartella del programma e avviarlo manualmente.

• AR.js 6_{: si tratta di una libreria Javascript che permette di dotare le pagine web di}

una funzionalità di realtà aumentata. Questa libreria è stata realizzata sfruttando il framework web per la realtà virtuale A-Frame 7 che permette di creare scene 3D al-l’interno del browser utilizzando un linguaggio di markup. Ar.js estende le potenzialità di questo framework introducendo ulteriori tag che consentono di identificare i marker utilizzati per l’esperienza di realtà aumentata.

Questa libreria avendo la mancanza del posizionamento degli oggetti in base alle

coor-4_{[1] http://d2rq.org/} 5 https://github.com/Bertak25/d2rq/tree/change-mysql-connector 6_{[2] https://github.com/jeromeetienne/AR.js} 7 [9] https://aframe.io/

(19)

dinate ha richiesto la ricerca e l’aggiunta di una soluzione, rappresentata da un file Javascript estrapolato dal lavoro di nanofuxion 8, la quale con opportune aggiunte, per esempio la comunicazione con il server, ha permesso di adattarla alle esigenze del progetto.

4.5 Metodologia di lavoro

Per poter pianificare al meglio il lavoro e poterne gestire l’avanzamento è stata applicata la metodologia agile SCRUM. I requisiti da portare a termine e le funzionalità da implementare sono state inizialmente segnate e discusse insieme al relatore e ad esse è stata data una priorità. A questo punto sono state suddivise in più sprint (della durata ciascuno di una settimana, per un totale iniziale di 10 sprint che è stato portato a 12 a causa di una leggera sottovalutazione dei problemi derivanti dall’utilizzo di librerie di terzi9), mantenendo il fuoco su ciò che è stato ritenuto più urgente dal committente. Durante il proseguo del progetto, sono stati aggiunti ulteriori requisiti, a cui è seguita una riassegnazione delle priorità.

4.5.1 Organizzazione del lavoro

Come citato sopra, il lavoro è stato suddiviso in sprint della durata di 1 settimana ciascuno, per un totale di 12 sprint. Per ogni sprint è stato sempre fissato un incontro con il relatore per l’aggiunta di nuovi requisiti e per verificare l’avanzamento dei lavori e la corrispondenza del prodotto con quanto richiesto dai requisiti.

Per poter tenere traccia del lavoro svolto e organizzare gli sprint, sono state usate le issue di GitLab che hanno consentito di organizzare e pianificare al meglio le attività e i progetti. É stata creata una issue per ogni sprint, come mostrato nell’appendice A, e ogni issue contiene le attività che devono essere portate a termine durante quella settimana. Per spostamenti o nuove aggiunte sono state create delle sezioni dedicate denominate con old o new.

8

https://github.com/nanofuxion/GPS-based-AR

9_{É stato perso molto tempo sia per capire il funzionamento di d2rq che quello di AR.js, il quale non}

(20)

(21)

Capitolo 5

Implementazione e funzionamento

Per ognuno dei requisiti implementati, vengono presentate le soluzioni fornite, ponendo anche l’attenzione sulle scelte implementative.

Definizioni preliminari

• wPOI: Un wPOI rappresenta un punto di interesse turistico di diversa tipologia (al-loggio/hotel, ristorante, monumento, etc.). Esso è identificato univocamente da un insieme di tre attributi lat, lon, scope, dove l’unico che può essere vuoto è scope. Gli altri attributi che compongono un wPOI sono: alt, name, description, country,

city, street, house_number, opening_hours, phone e website.

• Dataset: Un dataset è un oggetto fittizio utilizzato unicamente dalle API o dalle query sparql per definire il luogo dove esse devono svolgere la ricerca dei wPOI. Esso è composto dagli attributi: name, lat, lon e radius.

5.1 Raccolta dati

La raccolta dei dati può avvenire da più fonti contemporaneamente. Queste fonti, che pos-sono essere personalizzate dagli utenti attraverso un’interfaccia dedicata, pos-sono rappresentate da API o da query sparql. Oltre a queste, nel backend, viene anche aggiunta SimpleGeo 1, la quale si differenzia dalle altre a causa del fatto che essa è rappresentata da un gruppo di file, salvati localmente, in formato geojson.

1

(22)

16 Implementazione e funzionamento

5.1.1 SimpleGeo

Come indicato sopra, la collezione di wPOI di SimpleGeo è contenuta in un gruppo di file in formato geojson. In totale i file sono 63, dove ognuno di essi va a rappresentare una nazione del mondo identificata con codice ISO2, e i wPOI contenuti in essi sono più di 23 milioni. I dati presentano licenza CC0 (Creative Commons) quindi sono di pubblico dominio.

Per poter usare i wPOI forniti da SimpleGeo è necessario che il nome che viene fornito al dataset contenga la parola SimpleGeo senza nessuna differenza tra caratteri maiuscoli o minuscoli.

5.1.1.1 Paesi contenuti:

• AE: Emirati Arabi Uniti • AF: Afghanistan • AR: Argentina • AT: Austria • AU: Australia • BD: Bangladesh • BE: Belgio • BG: Bulgaria • BR: Brasile • CA: Canada • CH: Svizzera • CL: Cile • CN: Cina • CZ: Reppublica Ceca • DE: Germania • DK: Danimarca • EE: Estonia • ES: Spagna • FI: Finlandia • FR: Francia • GB: Inghilterra • GR: Grecia • HK: Hong Kong • HR: Croazia • HU: Ungheria • ID: Indonesia • IE: Irlanda • IL: Israele • IN: India • IS: Islanda • IT: Italia • JM: Giamaica • JP: Giappone • KR: Corea del Sud • LI: Liechtenstein • LK: Sri Lanka • LT: Lituania • LU: Lussemburgo • LV: Lettonia • MX: Messico • MY: Singapore • NL: Paesi Bassi • NO: Norvegia • NZ: Nuova Zelanda • OM: Oman • PA: Panamà • PE: Perù • PH: Filippine • PK: Pakistan • PL: Polonia • PR: Portorico • PT: Portogallo • RU: Russia

• SA: Arabia Saudita

2

(23)

• SE: Svezia • SG: Singapore • SI: Slovenia

• TH: Thailandia • TR: Turchia

• UM: Isole minori ester-ne degli Stati Uniti

• US: Stati Uniti • UY: Uruguay • ZA: Sud Africa

5.1.1.2 Implementazione

Siccome SimpleGeo è strutturato in file, per decidere quello corretto da esaminare si sfrutta l’utilizzo di una chiamata API, la quale in base alle coordinate passate come parametro 3, restituisce il codice ISO del paese a cui appartengono.

La chiamata in questione è la seguente 4_:

http://api.geonames.org/countryCodeJSON?lat=46&lng=9&username=wodar

e fornisce come risposta il seguente json:

{ " l a n g u a g e s ": " de - CH, f r - CH, i t - CH, rm ", " d i s t a n c e ": " 0 ", " c o u n t r y C o d e ": " CH", " countryName ": " S w i t z e r l a n d " }

Dopo aver esaminato il json e ottenuto il valore di countryCode, si va a leggere il file della nazione corrispondente con tutti i relativi wPOI. A questo punto i valori di ogni wPOI vengono accoppiati con la struttura del nostro wPOI che verrà successivamente salvato su database.

5.1.2 API

La sezione delle API così come quella delle query sparql presenta un’interfaccia di gestione che permette la configurazione e la personalizzazione delle fonti dati e del mapping in base alle preferenze dell’utente. Per personalizzazione si intende la possibilità di aggiunta, modifica e rimozione delle fonti API con relativo mapping delle informazioni che verrà spiegato nel dettaglio nella sezione 5.2.

In questa sezione ci limiteremo a definire i componenti dell’API, gli stessi riportati nella tabella dell’interfaccia, e analizzeremo in breve la sua inplementazione.

3

Coordinate del Dataset

4_{Il fatto che necessiti come argomento anche un username è perchè, anche se è un’API gratuita, per}

(24)

Figura 5.1: Interfaccia gestione API

Come si può notare dall’immagine sovrastante l’interfaccia dell’API presenta una tabella modificabile con le seguenti colonne:

• URL: rappresenta l’interfaccia e i parametri utilizzati per la richiesta. Esso può prendere in input tre parametri che sono latitudine, longitudine e raggio di ricerca.

Per poter utilizzare i parametri citati sopra bisogna inserire nell’URL le seguenti stringhe

§lat§, §lon§, §range§ al posto dei numeri come mostrato nell’esempio sottostante: http://places.cit.api.here.com/places/v1/browse?in=§lat§,§lon§;r=§range§

• License: rappresenta la licenza dei dati ritornati.

• POI keys: rappresenta la colonna dedicata al mapping dei dati ritornati con gli attributi del wPOI definito nel backend.

• Build: rappresentata da una checkbox questa colonna definisce se l’API in questione ritorna una lista di wPOI o meno.

(25)

L’implementazione delle API, a lato server, è abbastanza semplice. Si inizia con la sostituzio-ne delle parole chiave5 dichiarate nel paragrafo precedente con i valori effettivi del dataset o dei wPOI ai quali si vogliono aggiungere ulteriori informazioni. Si continua con l’esecuzione della chiamata e la lettura di tutto lo streaming di risposta. E si conclude con l’esecuzione del parsing del json di risposta, in base al mapping che è stato definito nella colonna POI

keys del client, e il salvataggio dei wPOI.

5.1.3 Sparql query

Come già citato nella sezione delle API, anche la parte delle query sparql presenta un in-terfaccia di gestione che permette l’aggiunta, la modifica e la rimozione delle fonti dati rappresentate dalle query. Inoltre, come avviene con le API, anche qui è presente una parte dedicata al mapping dei dati che analizzeremo nella sezione 5.2.

Quindi in questa sezione definiremo i componenti della query sparql e analizzeremo in breve la sua implementazione.

Figura 5.2: Interfaccia gestione query sparql

5

(26)

Come si può notare dall’immagine alla pagina precedente, l’interfaccia della query sparql presenta una tabella modificabile con le seguenti colonne:

• Query: rappresenta la query sparql da eseguire. Essa, come avviene per le API, può prendere in input tre parametri che sono latitudine, longitudine e raggio di ricerca. Questa volta per poter utilizzare i parametri citati sopra bisogna inserire nella query le seguenti variabili ?myLat, ?myLon, ?range al posto dei numeri come mostrato nell’esempio sottostante che utilizza come fonte dati un endpoint sparql di DBpedia:

PREFIX geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> PREFIX onto: <http://dbpedia.org/ontology/>

PREFIX dbo: <http://dbpedia.org/ontology/>

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> SELECT * WHERE {

?s a onto:Place . ?s geo:lat ?lat . ?s geo:long ?lon .

OPTIONAL {?s dbo:elevation ?alt} . OPTIONAL {?s dbo:abstract ?abs} . OPTIONAL {?s dbo:city ?city} . OPTIONAL {?s rdfs:label ?label} .

FILTER (?lat > ?myLat - ?range && ?lat < ?myLat + ?range && ?lon > ?myLon - ?range && ?lon < ?myLon + ?range) . }

Come è possibile notare dalla query sovrastante è importante anche inserire i PREFIX necessari per l’esecuzione della stessa.

• Sparql endpoint: rappresenta l’endpoint del server al quale verrà richiesta la query. • License: rappresenta la licenza dei dati ritornati.

• POI keys: rappresenta la colonna dedicata al mapping delle variabili della query con gli attributi del wPOI definito nel backend.

• Build: rappresentata da una checkbox questa colonna definisce se la query in questione ritorna una lista di wPOI o meno.

(27)

Anche l’implementazione delle query sparql, a lato server, è abbastanza semplice. Come prima, si inzia con la sostituzione delle variabili6 dichiarate nella query con i valori effettivi del dataset o dei wPOI ai quali si vogliono aggiungere ulteriori informazioni. Si continua con l’esecuzione della query al server endpoint ottenendo in risposta i dati sottoforma di una tabella. E si conclude con l’esecuzione del parsing di ogni riga della tabella di risposta, in base al mapping che è stato definito nella colonna POI keys del client, e il salvataggio dei wPOI.

6

(28)

5.2 Mapping dati ritornati

Il mapping dei dati ritornati dalle API o dalle query sparql, come si può notare dall’immagine sottostante, presenta la stessa interfaccia di gestione ma richiede un inserimento dei para-metri differente. Questa differenza è dovuta al fatto che nel backend vengo sfruttati due parser indipendenti che richiedono diversi formati. Un’altra cosa molto importante è che nel mapping, quindi anche in entrambe le risposte, devono essere presenti sia la lat che la lon a causa del merge dei dati spiegato nella sezione 5.3.

Figura 5.3: Confronto mapping API - query sparql

Per quanto riguarda il mapping della parte della query sparql la situazione è molto semplice visto che basta associare le variabili dalla query con gli attributi della struttura del wPOI sottostante. La situazione cambia per quanto riguarda la parte delle API visto che la struttura che è necessario associare è quella del json ritornato dal server dell’API.

(29)

Per definire la struttura del json è stata presa ispirazione da linguaggi di programmazione ad oggetti come Java, quindi ogni blocco racchiuso tra parentesi graffe rappresenta un oggetto, mentre ogni blocco racchiuso tra parentesi quadre rappresenta un array.

Per rendere più chiare le cose vediamo un piccolo esempio 7:

{ " b a t c h c o m p l e t e ": " ", " q u e r y ": { " g e o s e a r c h ": [ { " p a g e i d ": 8 2 9 7 6 , " n s ": 0 , " t i t l e ": " T a j Mahal ", " l a t ": 2 7 . 1 7 5 , " l o n ": 7 8 . 0 4 1 9 4 4 4 4 4 4 4 4 , " d i s t ": 0 , " p r i m a r y ": " " } , { " p a g e i d ": 1 3 3 2 5 5 5 8 , " n s ": 0 , " t i t l e ": " O r i g i n s and a r c h i t e c t u r e o f t h e T a j Mahal ", " l a t ": 2 7 . 1 7 5 , " l o n ": 7 8 . 0 4 2 2 , " d i s t ": 2 5 . 3 , " p r i m a r y ": " " } ] } }

Analizzando il json sovrastante possiamo subito notare che abbiamo un oggetto principale che contiene un attributo "batchcomplete" e un oggetto "query". Partendo dal presuppo-sto di essere già nell’oggetto principale, perchè stabilito di default, possiamo direttamente accedere sia all’attributo che all’oggetto mettendo nel mapping la parola batchcomplete, per l’attributo, o la parola query, per l’oggetto.

Da qui in poi per quanto riguarda l’attributo abbiamo finito, ma per quanto riguarda l’ogget-to potremmo voler accedere al suo interno e per fare ciò basta mettere un punl’ogget-to dopo il nome dell’oggetto, che poi verrà seguito dal nome degli attributi contenuti in esso, quindi

que-ry.geosearch. A questo punto ci troviamo in presenza di un array e abbiamo l’opportunità

di accedere a un singolo elemento o di accedere a tutti attraverso un iteratore implementato nel backend.

7_{https://en.wikipedia.org/w/api.php?action=query&list=geosearch&format=json&gscoord=27.175|78.041944}

(30)

Per l’accesso a un singolo elemento è sufficente aggiungere dopo il nome dell’array la posizio-ne8dell’elemento al quale si vuole accedere tra parentesi quadre, quindi query.geosearch[0], questo però implica che si deve avere la certezza che quell’elemento sia presente. Per ovviare a questo problema si può sfruttare l’iteratore sopra citato, che viene eseguito solo se l’array non è vuoto. Per fare ciò è sufficente sostituire il numero della posizione dell’elemento con il simbolo del punto di domanda, quindi query.geosearch[?].

Ora, per accere agli attributi contenuti negli oggetti dell’array, riprendiamo la logica vista qualche riga sopra andando a sfruttare nuovamente il punto, quindi con query.geosearch[?].lat andiamo a ottenere l’attributo "lat".

8

(31)

5.3 Merge dei dati

Siccome si possono avere più fonti dati e alcune di esse potrebbero ritornare gli stessi wPOI con valori uguali o leggermente diversi, è stato necessario implementare un sistema che permettesse il merge delle informazioni.

Questo sistema funziona attraverso la creazione di una chiave costituita dagli attributi lat,

lon e scope, dove l’unico che può essere vuoto è lo scope. Gli altri due devono per forza

essere presenti visto che sono utilizzati per il calcolo della distanza tra le coordinate di tutti i wPOI e se questa distanza è minore di 2m 9 i due wPOI, se hanno stesso scope o uno dei due è vuoto, vengono uniti in un unico wPOI.

L’ultima parte inerente al merge delle informazioni riguarda al sistema di salvataggio dei dati. Esso avviene attraverso l’utilizzo di hashset i quali permettono il salvataggio univoco dei dati evitando le duplicazioni che potrebbero derivare dalla presenza di più fonti.

9

(32)

5.4 Esposizione dati con API

L’API presente nel progetto, esposta all’URI https://gioconda.supsi.ch/wodar/api_request, è un semplice endpoint che rende possibile l’acceso e la creazione dei wPOI da un punto esterno all’app di configurazione. L’API può prendere da uno a tre argomenti in ordine sparso e in base ad essi va a svolgere diverse mansioni. Gli argomenti che vengono accettati sono

query, lat e lon e permettono di svolgere le seguenti operazioni:

• Con solo l’argomento query è possibile inviare una query sparql completa di PREFIX, che verrà eseguita sul database esposto da d2rq 10 e permette di accedere a tutti i wPOI già presenti nel sistema.

• Con gli argomenti lat e lon è possibile popolare i dataset per coprire la zona con centro le coordinate passate come argomenti e con raggio 1000m attraverso l’algoritmo spiegato nella sezione successiva.

• Con tutti e tre gli argomenti viene prima eseguito il popolamento dei dataset e poi viene eseguita la query.

Esempio richiesta API con tre argomenti11:

https://gioconda.supsi.ch/wodar/api_request?query=PREFIX vocab:

<http://localhost:2020/resource/vocab/> SELECT * WHERE { ?s a vocab:poi . ?s vocab:poi_id 160 . ?s vocab:poi_name ?name . }&lat=46.0481516&lon=9.1369806

5.4.1 Algoritmo creazione dataset

L’algoritmo di creazione dei dataset sfrutta la geometria analitica per evetiare una eccessiva sovrapposizione dei dataset, ma dato che la terra è una sfera e non un piano la sua precisione non è molto accurata. Questo imprecisione comunque non va a influire in alcun modo sul corretto funzionamento dell’algoritmo dato che pochi metri di errore su un chilometro risultano completamente trascurabili.

Iniziamo suddividendo il problema in tre casi:

• primo caso: il nuovo dataset è completamente contenuto in un dataset già presente. • secondo caso: le coordinate del centro del nuovo dataset non sono contenute in nessun

altro dataset.

• terzo caso: le coordinate del centro del nuovo dataset sono contenute in uno o più dataset preesistenti.

10_{[1] http://d2rq.org/} 11

(33)

Nel primi due casi la situazione si risolve molto semplicemente perchè, siccome vogliamo la certezza che il punto in cui si trova l’utente sia contenuto in un dataset, o non facciamo nulla o andiamo a creare un nuovo dataset con raggio 1000m e centro nelle sue coordinate. Nel terzo caso la situazione si complica perchè è in questo momento che si inizia a sfruttare la geometria. Come primo passaggio abbiamo un preprocessamento nel caso in cui il nuovo dataset ha un unico dataset preesistente. Questo preprocessamento consiste nella creazione di un nuovo dataset (blu) all’esterno del dataset preesistente (nero) in modo da contenere parte dei punti del nuovo dataset (rosso) che fuoriescono da quello già presente.

Figura 5.4: Algoritmo creazione dataset preprocessamento

Il preprocessamento inizia creando un retta (verde) passante per i punti A e B. Successiva-mente vengono cercati i punti di intersezione tra la retta e la circonferenza del nuovo dataset (rosso) e viene scelto il più lontano dal punto A, quindi il punto C. In questo punto viene creato il dataset esterno (blu) con raggio 1000m.

Dopo il preprocessamento si passa alla parte più complessa dell’algoritmo. Questa parte si occupa della creazione dei dataset di dimensioni minori 12 _{che devono coprire le parti del}

nuovo dataset che fuoriescono dai dataset preesistenti. Per fare ciò questa volta si sfruttano i punti di intersezione tra i dataset. Di questi punti si scelgono quelli contenuti nel nuovo dataset e di essi si prendono solo quelli che non sono contenuti in altri dataset. Questo secondo controllo ci permette di identificare i punti esterni, cioè quei punti oltre i quali non è presente nessun dataset, quindi è una zona inesplorata.

12

(34)

Figura 5.5: Algoritmo creazione dataset intersezione

Partendo dal risultato della seconda immagine del preprocessamento otteniamo una situa-zione in cui abbiamo due dataset preesistenti (neri). Di questi dataset troviamo i punti di intersezione E e D e notiamo che oltre a essere contenuti nel nuovo dataset (rosso) sono anche punti esterni. A questo punto creiamo la retta (verde) passante per i due punti e calcoliamo i punti di intersezione tra la retta e il nuovo dataset, quindi F e G. Siccome sia D che E sono punti esterni andremo a creare due nuovi dataset (blu), uno con centro in F e raggio la distanza tra F e D e l’altro con centro in G e raggio la distanza tra G e E.

(35)

In questo secondo esempio ci troviamo in una situazione un pò più complessa con la presenza di tre dataset preesistenti (neri), due dei quali sono anche tangenti (quello con centro in A e quello con centro in B). Per quanto riguarda questi ultimi due l’algoritmo va a creare una retta (viola) passante per i punti A e B e calcola la retta (viola) ad essa perpendicolare passante per il punto D. Con la retta perpendicolare si calcolano i punti di intersezione con il nuovo dataset (rosso), quindi I e K. Con questi due punti e quelli calcolati con il sistema mostrato nell’esempio precedente andiamo a creare il dataset con centro in I e raggio la distanza tra I e D e il dataset con centro in J e raggio la distanza tra J e G. I punti K e F vengano scartati o perchè non punti esterni o perchè non contenuti nel nuovo dataset.

5.4.1.1 Conclusione

In conclusione questo algoritmo, che se è stato creato per permettere l’utilizzo del client in qualunque parte del mondo senza la preventiva creazione del dataset, ha dimostrato una buona efficacia nella creazione automatica degli stessi che, come si può notare nell’immagine sottostante, vanno a coprire completamnte la zona interessata13.

Figura 5.7: Algoritmo creazione dataset immagine dimostrativa

13

(36)

5.5 Client AR

Il client AR non è altro che una pagina statica in html resa dinamica da una grande quantità di JavaScript fornito principalmente dalla libreria AR.js14.

5.5.1 Implementazione

La pagina html oltre a contenere la sidebar laterale, la quale sfrutta molto lo stile fornito dai css di Bootstrap, presenta solamente altri tre elementi:

• a-scene: la scena è l’oggetto radice globale e tutte le entità sono contenute all’interno della scena.

• a-camera: il componente della telecamera, contenuto nell’ a-scene, definisce da quale prospettiva l’utente visualizza la scena. La fotocamera è abbinata a componenti di controllo che consentono ai dispositivi di input15 di spostare e ruotare la fotocamera. • a-cursor: il componente cursore ascolta gli eventi di mousedown, mouseup, mouseen-ter, mouseleave e click. Il cursore, essendo un figlio di a-camera, è fisssato al centro dello schermo, indipendentemente dalla direzione in cui guardiamo.

A questo punto risalta molto l’assenza dei marker, i quali vengono aggiunti successivamente attraverso il JavaScript e presentano il seguente codice:

Dal codice sovrastante non si può fare a meno di notare che non si tratta effettivamente di un marker ma è un cono rovesciato con sopra una sfera. Questo stratagemma è stato necessario perchè tutti i marker 3D presenti sul Web, almeno quelli che sono riuscito a trovare, risualtavano a pagamento.

Il JavaScript che va inserire i marker dopo la richiesta iniziale prima di inviarne un altra aspetta che l’utente si sia spostato di almeno 100m oppure abbia cambiato il valore del raggio di ricerca attraverso lo slider.

14_{[2] https://github.com/jeromeetienne/AR.js} 15

(37)

5.6 Test

Siccome si è partiti con un progetto nuovo si è deciso di procedere con la scrittura di alcuni test in modo da dare un template per il testing ai prossimi sviluppatori che potranno così partire da una base già funzionante e adatta a sviluppi futuri del progetto.

In particolare, l’attenzione si è concentrata su due fronti: • Test sulle classi che costituiscono il modello • Test che coinvolgono l’interazione con il database

5.6.1 Test sul modello

Nelle classi che costituiscono il model dell’applicazione sono stati implementati i test necessari a garantire che i pochi metodi implementati (specialmente getter e setter) assolvano i propri compiti. I test scritti non sono complicati ma garantiscono la mancanza di errori negli attributi settati o ottenuti (anche di errori accidentali da parte dei programmatori).

5.6.2 Test interazione database

Questo tipo di test è sicuramente quello più interessante tra quelli implementati: essi fanno infatti riferimento all’interazione dell’applicazione con il database e quindi riguardano il cor-retto inserimento di nuove informazioni e la modifica di queste.

Per poter testare il funzionamento di alcuni metodi del service 16si è deciso di implementare un database in memoria RAM della macchina durante l’esecuzione di questi test: in questo modo l’ambiente di test rimane isolato da quello di produzione, permettendo di inserire o cancellare dei dati senza toccare il database di produzione.

16

(38)

(39)

Capitolo 6

Guida all’utilizzo del client

Come si piò notare dall’immagine sottostante, l’interfaccia client presenta una sidebar laterale che può essere nascosta premendo la X nell’angolo in alto a destra. Al suo interno la sidebar contiene due bottoni uno per aprire il fullscreen e uno per chiuderlo, uno slider per regolare il raggio di ricerca e due label che indicano la latitudine e la longitudine in cui si trova l’utente.

Figura 6.1: Interfaccia client (lungolago Lugano)

Non appena vengono prese le coordinate viene chiamata l’API, spiegata nella sezione 5.4, che va a ritornare la lista di wPOI presenti in zona che vengono subito renderizzati sottoforma di marker. Questi marker hanno una dimensione che va a diminuire più il wPOI è distante e vengono rappresentati nelle coordinate in cui si trova il punto di interesse nel mondo reale 1. Una volta renderizzati i marker l’utente può prendere la mira attraverso il cerchio blu al centro dello schermo e facendo click su un punto qualsiasi dello schermo va a visualizzare nel dettaglio le informazioni inerenti al poi del marker da lui scelto.

1_{La precisione del posizionamento del marker dipende anche dalla correttezza dei dati che vengono ritornati}

(40)

34 Guida all’utilizzo del client

Figura 6.2: Interfaccia client (lungolago Lugano)

(41)

Figura 6.5: Interfaccia client (Piazza Riforma Lugano)

(42)

(43)

Capitolo 7

Sviluppo futuro

Durante lo sviluppo del progetto sono state analizzate delle funzionalità che si è pensato sarebbero state utili, ma che non sono state implementate o per un’elevata complessità o perchè si è preferito concentrarsi su altre parti del progetto di maggiore rilevanza. Queste parti non sono andate perse ma sono entrate a far parte della lista delle future da implementare in futuro. Di questa lista fanno parte le seguenti voci:

• Migliorare il marge dei dati all’interno dei wPOI dando magari la possibilita all’utente di risolvere i conflitti. Questa funzionalità necessita dell’implementazione di una pa-gina dedicata esclusivamente al merge dei conflitti, ma oltre a questo bisognerebbe anche cercare un sistema per risolvere più conflitti simili in più wPOI nello stesso mo-mento. Questo secondo punto risulta molto importante perchè se un dataset contiene molti wPOI e l’utente deve risolvere un conflitto alla volta va a perdere moltissimo tempo, mentre con la modifica multipla il tempo che va a risparmiare potrebbe essere dedicandolo ad altre attività più importanti.

• Migliorare lo scaling dei marker in base alla distanza. Questo punto è per risolvere il problema dovuto al fatto che A-Frame1, il framework usato da AR.js 2 per il disegno dei marker sopra l’immagine della fotocamera, utilizza una matrice prospettica per il rendering del mondo virtuale che va a restringere eccessivamnte i marker più lontani impedendo all’utente di premerci sopra per visualizzare i dettagli del wPOI.

• Aggiungere l’altitudine alla visualizzazione dei poi. Questo punto è necessario per risol-ve il problema di quando l’utente si trova in una posizione o sopraelevata o sottoelevata rispetto alla posizione in cui si trova il punto di interesse 3. Infatti se si trova in una posizione sopraelevata i marker vengono visualizzati alla sua stessa altitudine quindi molto sopra al punto di interesse, mentre se si trova in una posizione sottoelevata si troveranno sotto al punto di interesse.

1

[9] https://aframe.io/

2_{[2] https://github.com/jeromeetienne/AR.js} 3

(44)

38 Sviluppo futuro

Figura 7.1: Interfaccia client problema scaling (Parco Ciani Lugano)

(45)

Capitolo 8

Conclusione

Al termine delle dodici settimane di lavoro, è stata svolta un’analisi del lavoro svolto durante il progetto, come previsto dalla metodologia di lavoro, in modo da identificare gli obiettivi raggiunti, le criticità riscontrate e definire le features future.

8.1 Obiettivi raggiunti

Si può sostenere che gli obiettivi principali del progetto siano stati raggiunti con successo: • Definire la struttura di un punto di interesse (wPOI): il wPOI è stato definito già nelle

prime settimane.

• Sviluppare un backend che costruisca i wPOI: l’algoritmo è già in utilizzo con le specifiche descritte nel capitolo 5.

• Esporre i wPOI su un server: il sistema è attualmente funzionante e in produzione attraverso l’API spiegata nella sezione 5.4, all’URI https://gioconda.supsi.ch/wodar/. • Mostrare i wPOI in realtà aumentata su una pagina web: il client è funzionante e mostra

correttamente i marker dei wPOI, all’URI https://gioconda.supsi.ch/wodar/client.

8.2 Competenze sviluppate

Il lavoro di diploma rappresenta un punto importante del percorso di studi perché consente di applicare nella pratica quanto imparato durante le lezioni.

In particolare, in questo progetto le competenze maggiormente accresciute sono:

• Applicazione dei principi di lavoro propri delle metodologie agili: dall’organizzazione del lavoro in sprint fino alle pratiche di Continuos Integration.

(46)

40 Conclusione

• Applicazione delle conoscenze di sviluppo relative alle applicazioni web, sia backend che frontend, e sul deploy di un’applicazione su server pubblico.

• Lavoro a contatto con il committente: adattarsi alle richieste del committente e ai frequenti cambi di idea riguardo a funzionalità e priorità di implementazione.

• Analisi e progettazione di una soluzione software+hardware completa e successiva installazione.

• Pubblicazione di un aggiornamento a un software open source presente su GitHub . • Accrescimento delle competenze realtive alla creazione di una un endpoint sparql,

(47)

Bibliografia

[1] d2rq. http://d2rq.org/. 8, 11, 12, 26 [2] Ar.js. https://github.com/jeromeetienne/AR.js. 9, 11, 12, 30, 37 [3] Argon.js. https://www.argonjs.io/. 9 [4] Argon4. https://app.argonjs.io/. 9 [5] Webxr. https://webxr.io/. 9 [6] Awe.js. https://github.com/awe-media/awe.js. 9 [7] Awe-media. https://awe.media/. 9 [8] Leaflet. https://leafletjs.com/. 11 [9] A-frame. https://aframe.io/. 12, 37 [10] Simplegeo. https://archive.org/details/2011-08-SimpleGeo-CC0-Public-Spaces. 15

(48)

(49)

Appendice A

(50)

(51)

(52)

(53)