RICERCA ITALIANA     

Programma di ricerca

Interoperabilità e gestione cooperativa di dati geografici dinamici multidimensionali e distribuiti con strumenti GIS liberi e Open Source

Università di riferimento

Università degli Studi di CAGLIARI - INGEGNERIA STRUTTURALE - ()

Responsabile dell'Unità di ricerca

Giuseppina Vacca

Descrizione

Il progetto di ricerca si colloca nell’ambito dei servizi noti come LBS (Location Based Services) e in particolare lo studio vuole affrontare le problematiche legate alle diverse componenti di cui sono costituiti e alla standardizzazione ed interoperabilità di un servizio di questo tipo. Come detto precedentemente sia a livello di ISOTC/211 sia di Open Geospatial Consortium (OGC) sono state emanate direttive e standard per i servizi LBS. Nel primo caso le norme specifiche sono le 19132 (Location based services possible standard), 19133 (Location based services tracking and navigation) e la 19134 (Multimodal location based services for routing and navigation), mentre nel secondo caso il documento di riferimento è l’OGC 05-016.
L’OGC, attraverso i suoi documenti, implementa le specifiche per la realizzazione di una piattaforma aperta chiamata OpenLS. Tali specifiche descrivono i servizi base di un GeoMobilityService ovvero: directory service, gateway service, location utility service, presentation service, route service (che verranno descritte più avanti), le sue funzionalità di base, la comunicazione tra client e server, la struttura dei dati e le relazioni dell’OpenLS rispetto alle specifiche e agli standard. Il documento OGC 05-016 consiste di un set di specifiche per l’interfaccia attraverso uno schema XML, il quale determina l’accesso ai servizi base e definisce la comunicazione tra il server e il client, descrivendone gli schemi per la richiesta del client e per la risposta del server. Vengono definiti inoltre il formato nel quale devo essere trasferiti i dati (XML e GML).
Per quanto riguarda i servizi di base definiti nella specifica OpenLS , questi sono divisi in cinque tipologie.
- Directory Service:: Questo è il servizio che fornisce agli utenti un indirizzario online in cui trovare uno specifico (o il più vicino) luogo, prodotto o servizio.
? Esempio: “Dov’è il ristorante cinese ‘Il Drago Rosso’?”
- Servizio Gateway: Questa è l’interfaccia fra il GeoMobility Server e il Location Server appartenente al fornitore della rete mobile, attraverso la quale i servizi OpenLS possono ottenere i dati di posizione dei terminali mobili. È utilizzato per richiedere la posizione attuale di un dispositivo mobile con diverse modalità (p. es. terminale singolo o multiplo, posizione immediata o periodica).
- Location Utility Service (Geocode / Reverse Geocode): Questo servizio effettua un’operazione di “geocodifica”, determinando una posizione geografica dato un indirizzo, nome del luogo o codice postale. Può compiere anche l’operazione inversa, cioè determinare un indirizzo completo (o codice postale, o nome di località) in base a una posizione geografica.
? Esempio: Dato un indirizzo, trovare una posizione.
- Presentation Service: Questo servizio converte l’informazione geografica in una rappresentazione visualizzabile su un mobile device. Un’applicazione OpenLS può richiamare questo servizio per ottenere la cartografia di un’area desiderata, con o senza sovrapposizione della geometria delle strade, punti di interesse, aree di interesse, localizzazione, posizione, e/o indirizzo.
? Esempio: L’utente vuole vedere dove si trova la sua casa su una carta.
- Route service: Questo servizio determina un percorso o rotta per un utente. Il richiedente deve indicare il punto di partenza (solitamente la posizione acquisita attraverso il Gateway Service, ma può trattarsi anche di una posizione specificata, ad esempio la propria casa per il progetto di un viaggio) e la destinazione (qualsiasi locazione, come ad esempio un luogo di cui possiede solo il numero telefonico o indirizzo, o un luogo determinato tramite una ricerca in un Directory Service). L’utente può opzionalmente specificare dei punti intermedi, il tipo di rotta preferito (più veloce, più breve, minor traffico, più panoramica, ecc.) e il mezzo di trasporto preferito. L’informazione restituita può essere testuale (con la descrizione di svolte e distanze) o geometrica (rappresentabile su una mappa).
Il linguaggio utilizzato nell’OpenLS è l’XML, in particolare le specifiche indicano l’XLS per il Location Services e il GML per i dati geografici.
Il progetto dell’Unità di ricerca di Cagliari si vuole inserire in questo contesto studiando le problematiche presentate, fino ad arrivare alla realizzazione di un prototipo basato sugli standard e le specifiche OGC utilizzando ed integrando software di tipo FOSS.
Nello specifico il lavoro dell’unità di Cagliari si articolerà nelle seguenti fasi:
1. Studio sui Location Based Services e loro architettura
2. Studio degli standard ISO e OGC sugli LBS
3. Ricerca di software Free e OS lato client e lato server
4. Studio e realizzazione di un prototipo di LBS secondo gli standard OGC e ISO
5. Test su un’area campione
Fase 1: Studio sui servizi Location Based Services e loro architettura.
La prima fase del lavoro sarà caratterizzata dallo studio dei servizi Location Based Services e della loro architettura. In particolare saranno studiati i diversi elementi che concorrono a formare un servizio LBS ovvero: i mobile device, la rete di comunicazione , la componente per il posizionamento , i provider dei servizi e delle applicazioni e infine, i provider dei dati.
a. Mobile device, sono strumenti che l’utente usa per accedere al servizio LBS, può essere un telefono cellulare, un PDA, un notebook, ma può essere anche un unità navigazionale per auto.
Si possono classificare in due categorie: Single purpose device e Multi purpose device. Alla prima categoria appartengono quegli strumenti che nascono per un servizio ben specifico e non possono assolverne degli altri (ad esempio il TomTom). Alla seconda categoria, appartengono, invece, quegli strumenti che possono essere utilizzati anche per scopi diversi dall’applicazione LBS, quali telefoni cellulari, notebook, PDA ecc.
Lo studio interesserà soprattutto la categoria di mobile device di tipo Multi-purpose e in particolare telefoni cellulari e PDA. Si analizzeranno le caratteristiche e le funzionalità che possono influenzare un’applicazione LBS ovvero: memoria e capacità di calcolo, autonomia delle batterie, caratteristiche degli schermi utilizzati, connessione alla rete Internet ecc. In particolare proprio i limiti di calcolo di questi apparati precludono la possibilità di effettuare, all’interno del mobile device, operazioni di tipo spaziale e di processamento delle informazioni. Ciò significa che molte delle operazioni che potrebbero essere fatte all’interno del mobile device, devono essere fatte all’interno del server provider, il quale dovrà inviare all’utente, esclusivamente il risultato finale. Alla fine dei questa fase verranno indicate le caratteristiche e le funzionalità che ottimizzano il loro uso all’interno di un LBS.
b. rete di comunicazione, è la rete che ha il compito di trasferire le richieste dell’utente dal mobile device al server provider e di rimandare la risposta di quest’ultimo all’utente. La rete può essere una Wireless Wide Area Network (WWAN) come ad esempio la rete GSM e UMTS, una Wireless Local Area Network (WLAN) come ad esempio l’IEEE 802.11 o una Wireless Personal Area Network (WPAN) come ad esempio il Bluetooth. Lo studio si focalizzerà soprattutto sulla rete UMTS, GPRS, EDGE verificandone le potenzialità e la copertura.
c. componente di posizionamento, è utilizzata per la localizzazione del mobile device. La posizione dell’utente può essere ottenuta utilizzando la rete di comunicazione mobile (ad esempio triangolando le celle) oppure attraverso un ricevitore GPS. Il nostro studio si focalizzerà soprattutto sui ricevitori GPS utilizzati ai fini di un servizio LBS. In particolare saranno testati ricevitori di tipo HGPS e AGPS in riferimento ai seguenti parametri:
- disponibilità del segnale
- accuratezza della posizione
- affidabilità e integrità del sistema
- continuità del servizio
- tempo di attesa per la posizione (Time To First Fix TTFIX)
d. provider dei servizi e delle applicazioni, è la componente principale del servizio. E’ responsabile dell’intero processo di elaborazione dei dati per l’applicazione e può essere proprietario dei dati su cui si basa il servizio oppure a sua volta avvalersi di un provider proprietario dei dati e dei contenuti utili al Location Based Service. I tipi di dati coinvolti in una qualsiasi applicazione LBS possono essere: dati geografici (cartografie, immagini satellitari georeferenziate, modelli digitali del terreno ecc..) e/o banche dati alfanumeriche (pagine gialle, informazioni turistiche, informazioni meteo, guida ai ristoranti e agli hotel ecc). In questa fase saranno di supporto le ricerche effettuate dai gruppi di ricerca del Politecnico di Milano e dell’Università di Trento sui web-server e sui DBMS.
Fase 2: Studio degli standard ISO e OGC sugli LBS
In questa fase saranno studiati gli standard e le specifiche emanate dall’ISO/TC211 e dall’OGC. Importante sarà verificare le architetture proposte per tali servizi e i linguaggi utilizzati (soprattutto GML, Geographic Markup Language, e XLS, XML for Location Services). Andrà approfondita in particolare l’architettura della piattaforma “GeoMobility Server”, definita nel già citato standard OGC 05-016 (http://www.opengeospatial.org/standards/olscore).
Tale studio sarà la base per la successiva fase 3 sui client/server di tipo FOSS dedicati agli LBS. Chiaramente, a questo stadio della ricerca non sono disponibili informazioni più approfondite.
Fase 3: Ricerca di software Free e OS lato client e lato server
La fase 3 riguarderà la ricerca di client e server FOSS finalizzati ad un servizio LBS. La ricerca sarà focalizzata esclusivamente su quei software che implementano gli standard e le specifiche dell’OGC e dell’ISO/TC211. Da tale ricerca saranno scelti quelli che più rispondono ai requisiti di standard del punto 2 per poi essere utilizzati nella fase 4, ovvero per la creazione di un servizio LBS con software di tipo FOSS.
Al momento sono già stati individuati alcuni software su cui è possibile concentrarsi: gvSIG della Generalitat Valenciana - Conselleria de Infraestructuras y Transporte (http://www.gvsig.gva.es/) per il lato client, e GeoServer (http://geoserver.org/) per il lato server. Tali software seguono le specifiche OGC, ma al momento non hanno funzionalità specifiche degli LBS; potrebbe quindi essere necessario scrivere del plug-in appositi sfruttando la natura open-source dei software.
Tuttavia, è anche possibile che questa fase consenta di individuare dei software specifici più adatti allo scopo.
Fase 4: Studio di un prototipo di LBS secondo gli standard OGC e ISO
L’ultima fase della ricerca sarà dedicata alla predisposizione di un servizio LBS secondo le specifiche OGC e ISO. In particolare saranno utilizzati e testati i software individuati nella fase 3. Sulla base dei risultati delle ricerche delle unità di Trento (DBMS) e di Milano, si cercherà di predisporre un servizio LBS finalizzato a scopi turistici. La scelta è ricaduta sul mercato del turismo, in quanto questo è una risorsa per l’Italia in continua espansione e l’esigenza di avere strumenti che ti offrono la possibilità di visitare luoghi non familiari o sconosciuti, con una continua assistenza online in termini d’informazioni turistiche sul sito o luogo che si sta visitando o in termini d’informazioni logistiche relative alle zone visitate (ristoranti, alberghi, banche ecc) è di notevole importanza.
Il prototipo LBS di Infoturismo che si vuole proporre in questo progetto è un servizio attivabile in un sito di interesse storico, archeologico, culturale a supporto della visita all’interno di esso da parte di un turista. Il servizio sarà usufruibile da un qualsiasi cellulare o palmare con collegamento a Internet e dispositivo di localizzazione GPS (di tipo AGPS, HGPS o integrato con correzioni differenziali in tempo reale DGPS).
L’architettura del sistema sarà costituita da un mobile device con GPS integrato e connessione ad Internet, da un server web di tipo FOSS quali MapServer o GeoServer dove saranno archiviate le mappe geografiche e i DB realizzati secondo gli standard OGC e ISO.
Il lato client del servizio sarà costituito da un mobile device con integrato un GPS. Tramite la connessione ad Internet la posizione GPS verrà inviata continuamente al server del provider non appena si accede al servizio tramite il client. Il server, sulla base della posizione (orientamento e posizione) del mobile device, invierà le informazioni relative al sito visitato e in particolare al singolo bene di importanza culturale in prossimità dell’utente. Le informazioni inviate dal server provider saranno:
- mappe della zona intorno al mobile device con la possibilità per il mobile device di effettuare zoom e pan all’interno della cartografia;
- informazioni del bene visitato
- hyperlink su foto e documenti del bene
Dal lato server l’architettura del sistema prevede l’installazione di MapServer o GeoServer per la gestione delle banche dati geografiche. Saranno implementate una serie di routine per la gestione delle informazioni del posizionamento e dell’orientamento dell’utente provenienti dal mobile device, per la generalizzazione delle mappe, per l’invio delle informazioni turistiche.
Fase 5: Test su un’area campione
L’ultima fase riguarderà esclusivamente i test e le prove da effettuarsi nell’area campione. Verranno testate le diverse componenti del servizio LBS evidenziandone i limiti e le problematiche.