Web Open Data Augmented Reality - WODAR Bertacco Davide Sommaruga Lorenzo - in SUPSI Tesi
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Web Open Data Augmented Reality -
WODAR
Studente/i Relatore
Bertacco Davide Sommaruga Lorenzo
Correlatore
Catenazzi Nadia
Committente
Sommaruga Lorenzo
Corso di laurea Modulo
Ingegneria Informatica Progetto di diploma
Anno
2018-2019
Data
6 settembre 2019
i
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
5.4.1 Algoritmo creazione dataset . . . . . . . . . . . . . . . . . . . . . . . 26
Web Open Data Augmented Reality - WODAR
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
A Sprint del Progetto 43
Web Open Data Augmented Reality - WODAR
iii
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.4 Interfaccia client (Piazza Riforma Lugano) . . . . . . . . . . . . . . . . . . . 34
6.5 Interfaccia client (Piazza Riforma Lugano) . . . . . . . . . . . . . . . . . . . 35
6.6 Interfaccia client (Piazza Riforma Lugano) . . . . . . . . . . . . . . . . . . . 35
6.7 Interfaccia client (Parco Ciani Lugano) . . . . . . . . . . . . . . . . . . . . . 35
7.1 Interfaccia client problema scaling (Parco Ciani Lugano) . . . . . . . . . . . 38
7.2 Interfaccia client problema altitudine (Corrido) . . . . . . . . . . . . . . . . . 38
Web Open Data Augmented Reality - WODAR
iv ELENCO DELLE FIGURE Web Open Data Augmented Reality - WODAR
1
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.
Web Open Data Augmented Reality - WODAR
2 ELENCO DELLE FIGURE Web Open Data Augmented Reality - WODAR
3
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à.
Web Open Data Augmented Reality - WODAR
4 Introduzione
Figura 1.1: Schema del lavoro svolto
Web Open Data Augmented Reality - WODAR5
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.
Web Open Data Augmented Reality - WODAR6 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
- Gestione DB, sql
Web Open Data Augmented Reality - WODAR7
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, ...).
Web Open Data Augmented Reality - WODAR8 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 esposizione 2 , 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 d2rq 3 , 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
Inclusi username e password
Web Open Data Augmented Reality - WODAR9
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.js 6 , 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/
Web Open Data Augmented Reality - WODAR10 Analisi dei requisiti Web Open Data Augmented Reality - WODAR
11
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
[2] https://github.com/jeromeetienne/AR.js
Web Open Data Augmented Reality - WODAR12 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:
• d2rq 4 : è 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/
Web Open Data Augmented Reality - WODAR13
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 terzi 9 ), 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
funziona utilizzando alcuni formati di oggetti
Web Open Data Augmented Reality - WODAR14 Tecnologie e metodologie utilizzate Web Open Data Augmented Reality - WODAR
15
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, 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
[10] https://archive.org/details/2011-08-SimpleGeo-CC0-Public-Spaces
Web Open Data Augmented Reality - WODAR16 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 ISO 2 , 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 • FI: Finlandia • LT: Lituania
• AF: Afghanistan • FR: Francia • LU: Lussemburgo
• AR: Argentina • GB: Inghilterra • LV: Lettonia
• AT: Austria • GR: Grecia • MX: Messico
• AU: Australia • HK: Hong Kong • MY: Singapore
• BD: Bangladesh • HR: Croazia • NL: Paesi Bassi
• BE: Belgio • HU: Ungheria • NO: Norvegia
• BG: Bulgaria • ID: Indonesia • NZ: Nuova Zelanda
• BR: Brasile • IE: Irlanda • OM: Oman
• CA: Canada • IL: Israele • PA: Panamà
• CH: Svizzera • IN: India • PE: Perù
• CL: Cile • IS: Islanda • PH: Filippine
• CN: Cina • IT: Italia • PK: Pakistan
• CZ: Reppublica Ceca • JM: Giamaica • PL: Polonia
• DE: Germania • JP: Giappone • PR: Portorico
• DK: Danimarca • KR: Corea del Sud • PT: Portogallo
• EE: Estonia • LI: Liechtenstein • RU: Russia
• ES: Spagna • LK: Sri Lanka • SA: Arabia Saudita
2
https://it.wikipedia.org/wiki/ISO_3166-1_alpha-2
Web Open Data Augmented Reality - WODAR17
• SE: Svezia • TH: Thailandia • US: Stati Uniti
• TR: Turchia
• SG: Singapore • UY: Uruguay
• UM: Isole minori ester-
• SI: Slovenia ne degli Stati Uniti • 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 " ,
" distance " :" 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
funzionare richiede un’iscrizione
Web Open Data Augmented Reality - WODAR18 Implementazione e funzionamento
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.
Web Open Data Augmented Reality - WODAR19
5.1.2.1 Implementazione
L’implementazione delle API, a lato server, è abbastanza semplice. Si inizia con la sostituzio-
ne delle parole chiave 5 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
§lat§, §lon§, §range§
Web Open Data Augmented Reality - WODAR20 Implementazione e funzionamento
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:
PREFIX onto:
PREFIX dbo:
PREFIX rdfs:
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.
Web Open Data Augmented Reality - WODAR21
5.1.3.1 Implementazione
Anche l’implementazione delle query sparql, a lato server, è abbastanza semplice. Come
prima, si inzia con la sostituzione delle variabili 6 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
?myLat, ?myLon, ?range
Web Open Data Augmented Reality - WODAR22 Implementazione e funzionamento
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.
Web Open Data Augmented Reality - WODAR23
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 :
{
" batchcomplete " : " " ,
" query " :{
" geosearch " : [
{
" pageid " :82976 ,
" ns " : 0 ,
" t i t l e " : " Taj Mahal " ,
" lat " :27.175 ,
" lon " :78.041944444444 ,
" dist " :0 ,
" primary " :" "
},
{
" pageid " :13325558 ,
" ns " : 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 Taj Mahal " ,
" lat " :27.175 ,
" lon " :78.0422 ,
" dist " :25.3 ,
" primary " :" "
}
]
}
}
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 punto 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
&gsradius=100
Web Open Data Augmented Reality - WODAR24 Implementazione e funzionamento
Per l’accesso a un singolo elemento è sufficente aggiungere dopo il nome dell’array la posizio-
ne 8 dell’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
Iniziando a contare da 0
Web Open Data Augmented Reality - WODAR25
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
Valore scelto dopo aver svolto alcune prove sulla città di Como
Web Open Data Augmented Reality - WODAR26 Implementazione e funzionamento
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 argomenti 11 :
https://gioconda.supsi.ch/wodar/api_request?query=PREFIX 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
La parte di URL della query deve essere codificata
Web Open Data Augmented Reality - WODAR27
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
Devono avere comunque un raggio maggiore di 100m altrimenti non vengono generati
Web Open Data Augmented Reality - WODAR28 Implementazione e funzionamento
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.
Figura 5.6: Algoritmo creazione dataset tangenza
Web Open Data Augmented Reality - WODAR29
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 interessata 13 .
Figura 5.7: Algoritmo creazione dataset immagine dimostrativa
13
In questo particolare caso Piazza della Riforma e Parco Ciani a Lugano
Web Open Data Augmented Reality - WODAR30 Implementazione e funzionamento
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.js 14 .
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 input 15 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
Giroscopio, bussola, ...
Web Open Data Augmented Reality - WODAR31
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 16 si è 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
É il componente di Spring che si occupa dell’interazione con il database.
Web Open Data Augmented Reality - WODAR32 Implementazione e funzionamento Web Open Data Augmented Reality - WODAR
33
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
dalle fonti
Web Open Data Augmented Reality - WODAR34 Guida all’utilizzo del client
Figura 6.2: Interfaccia client (lungolago Lugano)
Figura 6.3: Interfaccia client (Piazza Riforma Lugano)
Figura 6.4: Interfaccia client (Piazza Riforma Lugano)
Web Open Data Augmented Reality - WODAR35
Figura 6.5: Interfaccia client (Piazza Riforma Lugano)
Figura 6.6: Interfaccia client (Piazza Riforma Lugano)
Figura 6.7: Interfaccia client (Parco Ciani Lugano)
Web Open Data Augmented Reality - WODAR36 Guida all’utilizzo del client Web Open Data Augmented Reality - WODAR
37
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-Frame 1 , 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
Si intende l’edificio/monumento
Web Open Data Augmented Reality - WODAR38 Sviluppo futuro
Figura 7.1: Interfaccia client problema scaling (Parco Ciani Lugano)
Figura 7.2: Interfaccia client problema altitudine (Corrido)
Web Open Data Augmented Reality - WODAR39
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.
Web Open Data Augmented Reality - WODAR40 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,
all’utilizzo del linguaggio di query sparql e all’utilizzo di librerie per la realtà aumentata.
Web Open Data Augmented Reality - WODAR41
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
Web Open Data Augmented Reality - WODAR42 BIBLIOGRAFIA Web Open Data Augmented Reality - WODAR
43
Appendice A
Sprint del Progetto
Web Open Data Augmented Reality - WODAR44 Sprint del Progetto Web Open Data Augmented Reality - WODAR
45 Web Open Data Augmented Reality - WODAR
46 Sprint del Progetto Web Open Data Augmented Reality - WODAR
47 Web Open Data Augmented Reality - WODAR
Puoi anche leggere
