Tracking di dispositivi mobili in ambienti WebGIS

annuncio pubblicitario

UNIVERSITÀ DEGLI STUDI DEL SANNIO
Facoltà di Ingegneria
Corso di Laurea in Ingegneria Informatica
Tesi di Laurea
in
Fondamenti di Informatica
Tracking di dispositivi mobili in ambienti
WebGIS
Relatore:
Candidato:
Ch.mo Prof. Michele Ceccarelli
Francesco Cioffi
Matricola: 195 / 000014
Correlatore:
Dott. Michele Di Capua
ANNO ACCADEMICO 2005/2006
Ai miei genitori, che mi hanno sostenuto lungo
il difficile percorso di studi che si conclude con la laurea.
A mia madre in particolare che mi è sempre stata vicino
specie nei momenti più difficili.
Ed a mio padre che ha sempre fatto dei miei studi la priorità maggiore
A Michele, mio fratello, che è la persona a cui voglio più bene al mondo.
Un ringraziamento particolare va al professore Michele Ceccarelli,
che, in questi ultimi mesi, ha contribuito alla mia formazione professionale.
Mi ha assistito durante il periodo del tirocinio e la redazione della dissertazione
dimostrandosi una persona davvero disponibile e comprensiva.
Dandomi la massima fiducia e mettendosi a disposizione per ogni difficoltà.
Ringrazio il mio correlatore, il Dott. Michele Di Capua
per la pazienza e il fondamentale supporto datomi durante il periodo del tirocinio.
Una figura professionale che non si è mai posta come supervisore, piuttosto come amico.
Ringrazio anche tutto il gruppo della Unlimited Software s.r.l., che mi ha accolto
fra loro permettondomi di lavorare in un ambiente sereno e professionale.
Ulteriori parole di ringraziamento rivolte al relatore e al correlatore
non sarebbero sufficienti a rendere l’idea di ciò che penso di loro e
quanto abbiano contribuito a fare di questo capitolo della mia carriera universitaria
il più bello e il più sereno nonostante l’impegno costante e le lunghe giornate di lavoro.
Grazie per avermi fatto VIVERE questa esperienza,
e ancora grazie ai miei genitori per avermi dato la possibilità di studiare!
Alla mia famiglia:
mio padre Roberto Cioffi
mia madre Maria Rosaria Bevilacqua
mio fratello Michele Cioffi
Indice
I
WebGIS
3
1 Cartografia e GIS
4
1.1
Cartografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2
Sistemi informativi geografici . . . . . . . . . . . . . . . . . . . . . .
4
1.2.1
GIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2.2
Modello dei dati . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2.3
Tipologia di dati geografici . . . . . . . . . . . . . . . . . . . .
6
1.2.4
Funzionalità . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
Rappresentazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.3.1
Proiezione cartografica . . . . . . . . . . . . . . . . . . . . . .
8
1.3.2
Coordinate geografiche . . . . . . . . . . . . . . . . . . . . . .
8
1.3.3
WGS84 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.3
2 WebGIS
2.1
10
WebGIS software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1
MapServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2
ArcView Internet Map Server (AVIMS) . . . . . . . . . . . . . 12
2.1.3
Autodesk MapGuide 4.0 . . . . . . . . . . . . . . . . . . . . . 14
2.1.4
MapXtreme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
iii
2.1.5
GeoMedia Web Map . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.6
Perché Alov / TimeMap?
3 Shapefile
3.1
20
Organizzazione del file principale . . . . . . . . . . . . . . . . . . . . 21
3.1.1
3.2
. . . . . . . . . . . . . . . . . . . . 18
Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Protocollo NMEA
23
4.1
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3
“Frasi” NMEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4
Decodifica di una “frase” . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 Infomobilità
5.1
5.2
27
Sistema di rilevamento satellitare della posizione . . . . . . . . . . . . 27
5.1.1
Principio di funzionamento . . . . . . . . . . . . . . . . . . . . 28
5.1.2
Tipo di modulazione e frequenze . . . . . . . . . . . . . . . . . 29
5.1.3
Grado di precisione del rilievo . . . . . . . . . . . . . . . . . . 29
5.1.4
Ricevitore GPS . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.5
Principio di funzionamento . . . . . . . . . . . . . . . . . . . . 30
5.1.6
Accesso telematico . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1.7
Telesorveglianza . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1.8
GLONASS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Galileo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.1
Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2.2
Principio di funzionamento . . . . . . . . . . . . . . . . . . . . 35
5.3
II
Applicazioni reali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.1
Navigatore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.2
Tracking Server . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.3
Tracking di flotte . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.4
Utilizzi del tracking . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.5
Telesorveglianza . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Applicazione web
6 Introduzione
40
41
6.1
Premessa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2
Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.3
Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.4
Conversioni delle coordinate . . . . . . . . . . . . . . . . . . . . . . . 44
6.5
Filosofia di sviluppo
7 TimeMap
. . . . . . . . . . . . . . . . . . . . . . . . . . . 44
46
7.1
Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.2
Client / Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.3
File di layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.3.1
Oggetti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.3.2
Dimensioni ed allineamento . . . . . . . . . . . . . . . . . . . 50
7.3.3
Bottoni e toolbar . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.3.4
Pannelli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.3.5
Colori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.3.6
Collegamento alla mappa . . . . . . . . . . . . . . . . . . . . . 51
7.4
File di progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.4.1
Database Clearinghouse . . . . . . . . . . . . . . . . . . . . . 51
7.4.2
Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.5
Applet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.6
Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8 Architettura
8.1
Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.1.1
8.2
8.3
8.4
Aggiunta di un nuovo dispositivo . . . . . . . . . . . . . . . . 55
Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
8.2.1
Comunicazione con i dispositivi GPS . . . . . . . . . . . . . . 56
8.2.2
Registrazione di un dispositivo GPS . . . . . . . . . . . . . . . 57
8.2.3
Comunicazione con l’applet . . . . . . . . . . . . . . . . . . . 58
Applet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.3.1
Scheda dettagli . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.3.2
Pannello di controllo per il tracking . . . . . . . . . . . . . . . 60
8.3.3
Registrazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
MIDLet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
8.4.1
Configurazione dei parametri di connessione . . . . . . . . . . 61
8.4.2
Comunicazione Bluetooth . . . . . . . . . . . . . . . . . . . . 61
8.4.3
Invio della propria posizione . . . . . . . . . . . . . . . . . . . 61
9 Funzionamento
9.1
54
62
Oggetti mobili . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
9.1.1
I dispositivi GPS . . . . . . . . . . . . . . . . . . . . . . . . . 62
9.1.2
La classe “GPSDevice” . . . . . . . . . . . . . . . . . . . . . . 64
9.2
9.3
9.4
Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
9.2.1
Comunicazione con la MIDlet . . . . . . . . . . . . . . . . . . 65
9.2.2
Memorizzazione delle posizioni . . . . . . . . . . . . . . . . . . 66
9.2.3
Comunicazione con l’applet . . . . . . . . . . . . . . . . . . . 67
Applet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
9.3.1
Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
9.3.2
Scheda dettagli . . . . . . . . . . . . . . . . . . . . . . . . . . 67
9.3.3
Pannello di Tracking . . . . . . . . . . . . . . . . . . . . . . . 70
MIDLet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
9.4.1
Ricerca Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . 78
9.4.2
Opzioni di connessione . . . . . . . . . . . . . . . . . . . . . . 79
9.4.3
Verifica della connessione . . . . . . . . . . . . . . . . . . . . . 81
9.4.4
Invio della propria posizione al server . . . . . . . . . . . . . . 81
10 Codice sorgente
84
10.1 Modifiche apportate ai sorgenti originali . . . . . . . . . . . . . . . . 84
10.1.1 Classe Carte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
10.1.2 Classe UploadServlet . . . . . . . . . . . . . . . . . . . . . . . 85
10.1.3 Costanti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
10.2 Classi sviluppate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
10.2.1 Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
10.2.2 Applet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
10.2.3 Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
10.2.4 MIDlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
11 Installazione e configurazione
98
11.1 Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
11.2 Caricamento dei dati geografici . . . . . . . . . . . . . . . . . . . . . 99
11.2.1 Caricamento delle mappe . . . . . . . . . . . . . . . . . . . . . 99
11.2.2 Gestione oggetti mobili . . . . . . . . . . . . . . . . . . . . . . 100
11.3 Impostazione dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
12 Sviluppi futuri
103
12.1 Espandibilità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
12.2 MIDlet per cellulari con antenna GPS integrata . . . . . . . . . . . . 103
12.3 Visualizzazione di informazioni sul cellulare
. . . . . . . . . . . . . . 104
12.4 Gestione del formato SVG sul cellulare . . . . . . . . . . . . . . . . . 104
12.5 Configurazione dei dispositivi da monitorare . . . . . . . . . . . . . . 105
12.6 Sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
12.7 Gestione di eventi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
12.8 Modifica mappe dal cellulare . . . . . . . . . . . . . . . . . . . . . . . 105
12.9 Analisi del territorio . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
III
Appendice
13 Software
107
108
13.1 Software e linguggio di programmazione . . . . . . . . . . . . . . . . 108
13.2 MIDP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
13.3 Sun Java Wireless Toolkit 2.3 Beta . . . . . . . . . . . . . . . . . . . 109
13.4 Tomcat 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
13.5 MySQL 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
13.6 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
13.6.1 Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Bibliografia
111
Elenco delle figure
115
Elenco delle tabelle
116
14 Ulteriori informazioni
117
14.1 Infrastruttura utilizzata . . . . . . . . . . . . . . . . . . . . . . . . . 117
14.2 Telefoni con ricevitori GPS . . . . . . . . . . . . . . . . . . . . . . . . 117
14.3 Questo documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
14.4 Sistema operativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
14.5 Browser web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Introduzione e scopo del lavoro
Scopo della tesi è descrivere il sistema di “Tracking di dispositivi mobili” sviluppato “in ambiente WebGIS”, attività svolta durante il periodo di tirocinio e durante
il perodo di tesi.
È stato sviluppato un software in grado di monitorare, tramite un browser
web, dispositivi mobili (eg. cellulare dotato di ricevitore GPS), visualizzandone
dinamicamente la posizione su una mappa GIS, da una console centralizzata.
La prima fase del lavoro è consistita in un’analisi delle tecnologie esistenti nell’ambito del WebGIS. Acquisite le nozioni teoriche fondamentali riguardo la cartografia e il GIS, sono stati successivamente analizzati i principali software esistenti.
Dopo un’attento studio di tali software è stato scelto Alov / TimeMap, una
combinazione di un server di mappe e di un’applet Java che ha soddisfatto subito i
requisiti fondamentali, dettagliati nei capitoli succesivi.
Il sistema presentato, ne eredita le funzionalità di base, ed aggiunge la possibilità
di tenere traccia in tempo reale della posizione di dispositivi mobili.
L’attività principale è quindi consistita nello sviluppo di componenti aggiuntive
sulle tre aree interessate (client, server, mobile), in grado di estendere e innovare
alcune delle funzionalità presenti sul sistema di origine.
Parte I
WebGIS
Capitolo 1
Cartografia e GIS
1.1
Cartografia
La cartografia è l’insieme di conoscenze scientifiche, tecniche ed artistiche finalizzate
alla rappresentazione simbolica ma veritiera di informazioni geografiche1 su supporti
piani (carte geografiche) o sferici (globi).
Gli studi cartografici e le relative applicazioni nei diversi campi applicativi sono
stati rivoluzionati dallo sviluppo e dalla diffusione dei GIS[1] (“Geographic Information System”, Sistemi Informativi Geografici).
1.2
Sistemi informativi geografici
Un GIS è un sistema informativo computerizzato che consente l’acquisizione, la
registrazione, l’analisi, la visualizzazione e la restituzione di informazioni derivanti
da dati geografici (georeferenziati).
1
o statistiche, demografiche, economiche, politiche, culturali, ma comunque in relazione al luogo
geografico nel quale si realizzano
1.2 Sistemi informativi geografici
1.2.1
5
GIS
Il GIS è l’inseime di una potente serie di strumenti per acquisire, memorizzare,
estrarre, trasformare e visualizzare dati spaziali dal mondo reale.
Si tratta di un sistema informatico in grado di analizzare dati spaziali associando
a ciascun elemento rappresentato un database informativo (anche noto come dato
non spaziale).
Il GIS può essere visto come una forma di DBMS (Database Management System), in grado di gestire dati geografici.
1.2.2
Modello dei dati
Per la rappresentazione dei dati in un sistema informatico occorre formalizzare un
modello rappresentativo flessibile che si adatti ai fenomeni reali. Nel GIS abbiamo
tre tipologie di informazioni:
Informazioni Geometriche relative alla rappresentazione cartografica degli oggetti rappresentati: forma (punto, linea poligono), la dimensione e la posizione
geografica,
Topologiche riferite alle relazioni reciproche tra gli oggetti: connessione, adiacenza, inclusione etc. ,
Informative riguardanti i dati (numerici, testuali etc.) associati ad ogni oggetto.
Il GIS prevede la gestione di queste informazioni in un database relazionale.
L’aspetto che caratterizza il GIS è quello geometrico: esso memorizza la posizione
del dato impiegando un sistema di proiezione reale che definisce la posizione geografica dell’oggetto. Inoltre il GIS gestisce contemporaneamente i dati provenienti da
diversi sistemi di proiezione e riferimento.
1.2 Sistemi informativi geografici
6
A differenza della cartografia su carta, la scala, in un GIS, è un parametro di qualità del dato e non di visualizzazione. Il valore della scala, esprime le cifre significative
che devono essere considerate valide rispetto alle coordinate di georiferimento.
1.2.3
Tipologia di dati geografici
Il mondo reale può essere rappresentato in un GIS attraverso due tipologie principali
di dato: il dato vettoriale e il dato raster.
I dati vettoriali sono costituiti da elementi semplici quali punti, linee e poligoni,
codificati e memorizzati sulla base delle loro coordinate. Un punto viene individuato
attraverso le sue coordinate reali (x1, y1); una linea o un poligono attraverso la
posizione dei sui nodi (x1, y1; x2, y2; ...). A ciascun elemento è associato un record
del database informativo che contiene tutti gli attributi dell’oggetto rappresentato.
Il dato raster permette di rappresentare il mondo reale attraverso una matrice
di celle, generalmente di forma quadrata o rettangolare, dette pixel. A ciascun pixel
sono associate le informazione relative a ciò che esso rappresenta sul territorio. La
dimensione del pixel (detta anche pixel size), generalmente espressa nell’unità di
misura della carta (metri, chilometri etc.), è strettamente relazionata alla precisione
del dato.
I dati vettoriali e i dati raster si adattano ad usi diversi. La cartografia vettoriale
è particolarmente adatta alla rappresentazione di dati che variano in modo discreto
(eg. la rappresentazione delle strade, l’ubicazione dei cassonetti dei rifiuti di una
città o una carta dell’uso del suolo), la cartografia raster è più adatta alla rappresentazione di dati con variabilità continua (eg. un modello digitale di elevazione o
una carta di acclività del versante).
1.3 Rappresentazione
1.2.4
7
Funzionalità
Il GIS consente di mettere in relazione tra di loro dati diversi, sulla base del loro
comune riferimento geografico in modo da creare nuove informazioni a partire dai
dati esistenti. Il GIS offre ampie possibilità di interazione con l’utente ed un insieme
di strumenti che ne facilitano la personalizzazione e l’adattamento alle specifiche
problematiche.
I GIS presentano normalmente delle funzionalità di analisi spaziale ovvero di
trasformazione ed elaborazione degli elementi geografici degli attributi. Esempi di
queste elaborazioni sono elencate di seguito.
L’overlay topologico Si effettua una sovrapposizione tra gli elementi di due temi
per creare un nuovo tematismo (eg. si sovrappone il tema dei confini di un
parco con i confini dei comuni, per determinare le zone di competenza di ogni
amministrazione o la percentuale di area comunale protetta).
Le query spaziali Interrogazioni di basi di dati a partire da criteri spaziali (vicinanza, inclusione, sovrapposizione etc.).
La Network Analysis Algoritmi che da una rete di elementi lineari rappresentata
mediante dati geografici (eg. rete stradale), determinano i percorsi minimi tra
insiemi di punti.
1.3
Rappresentazione
Le tecniche geometriche o matematiche che trasformano i punti espressi in coordinate geografiche in punti espressi in coordinate cartesiane si chiamano proiezioni
cartografiche.
1.3 Rappresentazione
1.3.1
8
Proiezione cartografica
Una proiezione cartografica è il risultato di trasformazioni geometriche, matematiche
o empiriche, di punti geografici espressi in coordinate geografiche, in punti espressi
in coordinate cartesiane.
Le proiezioni vengono usate in cartografia per rappresentare su di un piano2 un
fenomeno che nella realtà esiste sulla superficie della sfera.
Essendo impossibile evitare deformazioni3 , le proiezioni vengono scelte sulla base delle loro caratteristiche, vale a dire sulla base dei loro inevitabili difetti (la
deformazione) ed i loro auspicabili pregi.
1.3.2
Coordinate geografiche
Le coordinate geografiche servono ad identificare la posizione di un punto sulla
superficie terrestre.
La latitudine è la distanza angolare dall’equatore e la longitudine è la distanza
angolare lungo il parallelo del luogo da un arbitrario meridiano di riferimento. La
latitudine e la longitudine sono espresse in gradi, minuti e secondi. Attualmente
viene utilizzato il meridiano di Greenwich che passa per l’omonimo osservatorio.
In Italia era costume (non del tutto scomparso) utilizzare come meridiano di riferimento quello passante per l’osservatorio di Monte Mario (a Roma, 12 gradi, 27.2
primi a Est di Greenwich). Tale sistema di coordinate venne adoperato dall’Istituto
Geografico Militare (IGM) per aggiornare i dati allo standard World Geodetic System 1984 (WGS84), su cui si basa anche il Global Positioning System (GPS). Lo
2
3
le carte geografiche
In realtà l’unica rappresentazione esente da deformazioni è la sfera
1.3 Rappresentazione
9
standard WGS84 si basa su un modello geodetico della Terra standard, l’EGM96,
definito da un sistema di armoniche sferiche.
1.3.3
WGS84
WGS84[2] è l’acronimo di World Geodetic System 1984 e definisce il sistema come
geodetico, mondiale, riferito al 1984.
Esso costituisce un modello matematico del globo da un punto di vista geometrico, geodetico e gravitazionale, costruito sulla base delle misure e delle conoscenze
scientifiche e tecnologiche disponibili al 1984.
A questo scopo si utilizzano degli ellissoidi di riferimento, ovvero i datum geodetici. Un datum è un ellissoide con dei parametri assegnati, orientato in modo
opportuno rispetto alla terra.
I datum della geodesia classica, che possono essere definiti locali o regionali,
approssimano bene il geoide solo in un intorno del punto di emanazione, mentre il
datum globale WGS84 utilizza lo standard EGM96, che approssima il geoide nel suo
complesso ed è valido per tutto il mondo.
Dal 2000 è obbligatorio l’utilizzo del WGS84 come standard per la navigazione
aerea. In Italia tuttavia è tuttora in corso la conversione dei dati aeronautici dell’ENAV dai vecchi standard ED50 e MM40 al WGS84, mentre l’Aeronautica Militare
Italiana ha terminato la conversione nel 2002.
Il sistema sviluppato adotta lo standard presentato, in quanto attualmente è
quello maggiormente diffuso sul mercato.
Capitolo 2
WebGIS
Al giorno d’oggi la cartografia sta subendo un’evoluzione senza precedenti a causa
dello sviluppo nei campi dell’informatica e delle telecomunicazioni. Tali cambiamenti
si presentano fondamentalmente sotto tre aspetti:
• produzione cartografica,
• comunicazione,
• conoscenza ed analisi.
La visualizzazione cartografica è la combinazione dei su detti aspetti.
2.1
WebGIS software
I software WebGIS sono una nuova gamma di prodotti per la cartografia. Essi
permettono di comunicare informazioni geografiche in formato visuale tramite il
web.
Tecnicamente il WEBGIS è un GIS distribuito all’interno di una rete di computer, per integrare e distribuire informazioni geografiche in formato visuale nel World
2.1 WebGIS software
11
Figura 2.1: Architettura di un software WebGIS
Wide Web. Dal punto di vista dell’analisi dei processi GIS, la struttura è simile
ad un’architettura Client-Server (vedi fig. 2.1): l’analisi dei dati geografici avviene lato server mentre lato client, gli utenti accedono tramite un browser web o un
programma software proprietario.
Tipicamente il client è un browser web ed il server è un server web su cui è
installato un application server fornito dal software WebGIS. Il client effettua tramite
il web, le richieste in termini di mappe o analisi di dati geografici ad un server. Il
server soddisfa le richieste inoltrandole al software WebGIS. Il software restituisce
i risultati delle richieste al server web che le traduce in una forma comprensibile al
client prima di inoltrarle al browser web. Il client ha delle funzionalità aggiuntive
che permettono l’interpretazione dei risultati: un plugin o un applet.
Di seguito saranno analizzati alcuni software maggiormente affermati sul mercato
basati sulla tecnologia webgis.
2.1.1
MapServer
MapServer1 è un ambiente di sviluppo OpenSource, di applicazioni internet orientate
alla gestione di dati spaziali.
1
http://mapserver.gis.umn.edu/
2.1 WebGIS software
12
Può essere compilato sulla maggior parte dei sistemi Unix-like ed eseguito sui
sistemi Windows e su piattaforme Linux/Apache. Dato che viene installato come
applicazione CGI sul server HTTP, è possibile estenderne le funzionalità accedendo
all’API dell’applicazione.
L’architettura di MapServer è costituita da tre componenti di base: i Mapfile,
i file di template l’insieme dei dati GIS. I Mapfile definiscono i dati che sono usati
nell’applicazione e sono costituiti da parametri di configurazione dell’applicazione.
Permettono di definire informazioni riguardo l’interpretazione dei risultati delle richieste inoltrate al server. I file di template definiscono invece il layout grafico della
legenda e della mappa, impostando quindi l’interfaccia che viene mostrata a video.
MapServer utilizza, per gestire i dati geografici, il formato ESRI2 shapefile come
formato vettoriale di default. I dati in formato raster sono gestiti in diversi formati
a seconda dei parametri impostati in fase di compilazione dell’applicazione.
2.1.2
ArcView Internet Map Server (AVIMS)
AVIMS nasce come un’estensione per il software GIS “ArcView GIS”3 . Per aggiungere la funzionalità di Webmapping, un wizard guida l’utente durante l’installazione
dei vari componenti.
All’interno di ArcView esiste un’estensione IMS (Internet Map Server) che permette ad ArcView GIS di comunicare con un Web Server, e un’estensione, la ESRIMap Web Server che si installa sul web server stesso. Quest’ultima permette al
server web di comunicare con una o più sessioni di ArcView GIS in esecuzione su
una o più piattaforme di sviluppo, gestendo le connessioni e bilanciando il carico di
2
3
http://www.esriitalia.it
http://www.esriitalia.it/arcgis
2.1 WebGIS software
13
lavoro del server fra le varie sessioni. L’estensione per il Web Server è compatibile
sia con i Web server Microsoft che Netscape.
Dato che il web non è in grado di leggere direttamente il formato vettoriale, ArcView gestisce lato server i dati geografici (mappe in formato vettoriale), mentre lato
client vengono visualizzati i dati raster, ossia immagini GIF o JPEG. Le immagini
raster sono particolarmente adatte alle applicazioni Webmapping per visualizzare i
risultati delle operazioni GIS in quanto su un’immagine è possibile applicare effetti
grafici come ombreggiatura o colorare determinati elementi, effetti che rendono più
chiara e fruibile la mappa. A livello prestazionale la comunicazione è resa più performante dal basso carico di informazioni da trasferire, in quanto le immagini GIF
e JPEG sono formati nativamente compressi.
Queste mappe in formato raster vengono gestite in una applicazione atta al
Webmapping, l’applet MapCafè. Essa mette a disposizione gli strumenti grafici per
visualizzare le mappe in un browser web. L’applet, depositata sul server, viene
scaricata automaticamente dal browser web per essere interpretata dalla JVM (Java
Virtual Machine) presente sul computer client. L’utente non ha pertanto necessità
di installare nulla sulla propria macchina per utilizzare l’applicazione accessibile
tramite la rete internet.
Per pubblicare le mappe sul web bisogna aggiungere l’estensione IMS ad un
progetto di ArcView. AVIMS quindi metterà a disposizione, nel menu file, i comandi
per configurare, avviare e bloccare il server, per la configurazione delle pagine web
e per la configurazione dell’applet MapCafè. Per quanto riguarda la configurazione
dell’applet è possibile scegliere quali componenti far apparire nell’interfaccia. Il
pannello di configurazione relativo alle pagine web permette di creare ed editare
documenti HTML. Per far partire il server bisogna configurarlo impostando il tipo
2.1 WebGIS software
14
e l’indirizzo IP del web server in cui si è installata l’estensione “ESRIMap Web
Server”. All’avvio del server la finestra del progetto cambia aspetto indicando che
ci si trova nella modalità di funzionamento server.
2.1.3
Autodesk MapGuide 4.0
Un altro software WebGIS per generare applicazioni orientate al Webmapping è
Autodesk MapGuide 4.0, un software per la pubblicazione di mappe web che vanno
dalle semplici mappe tematiche a complesse mappe multimediali. La suite consiste
di un Server, un Author e di un Viewer.
Il server gestisce le comunicazioni riguardo le mappe e i dati, rispettivamente,
per il Viewer e per l’Author. L’Author è la parte che permette la creazione e
la pubblicazione di mappe in accordo alle specifiche di visualizzazione iniziali. Il
Viewer è un plugin per la visualizzazione delle mappe e per l’esecuzione di alcune
operazioni lato client.
Prima di poter eseguire l’applicazione, tutti i dati geospaziali devono essere convertiti nel formato SDF (Spatial Data File4 ) nativo di MapGuide. Nell’installazione
è compreso un convertitore da tutti i maggiori formati utilizzati per la rappresentazione di mappe. L’utilizzo di un formato proprietario permette agli sviluppatori di
usare un sistema di referenza nativo.
Lato server è necessario configurare la sorgente dei dati e i parametri per l’acceso
al database.
L’interfaccia dell’Author è intuitiva e basata su un approccio WYSIWYG5 . Lo
sviluppo delle mappe per il web è reso possibile grazie al MWF (Map Window
File) incluso nell’applicazione, ossia la finestra per i file delle mappe. Sono incluse
4
5
http://www.spatial-data.com
What you see, is what you get.
2.1 WebGIS software
15
funzioni quali la personalizzazione e l’impostazione di simboli o di menu pop-up, il
salvataggio di “segnalibri” o la possibilità di inserire link. Alcune funzionalità offerte
dall’Author permettono l’applicazione di effetti di trasparenza su immagini raster e
la stampa delle mappe. L’Author è un ambiente di sviluppo per le mappe web che
permette di creare dinamicamente delle mappe lato server che saranno visualizzate
lato client.
Il Viewer è molto semplice da utilizzare, è eseguito lato client ed è fornito sotto
forma di plugin per il browser web. L’utente può gestire i layer e personalizzare la
grafica a seconda delle proprie esigenze, può effettuare l’analisi dei dati pubblicati e
sottoporre query in base a dati geografici salvando i risultati sotto forma di report.
2.1.4
MapXtreme
MapXtreme è uno strumento per la creazione di documenti web in cui è anche possibile processare mappe web tramite le rete internet o una rete intranet. Il cuore
della funzione relativa al Webmapping è MapX, un componente della MapInfo Corporation6 . Sfrutta i controlli ActiveX lato server per sistemi operativi compatibili,
quali Windows.
Il software integra nel web server la possibilità di processare mappe web. Il
software di installazione è diviso in due parti: la parte relativa allo sviluppo e la parte
relativa al server. La parte di sviluppo comprende gli strumenti atti allo sviluppo
di scripts: un IDE, esempi e librerie. La parte relativa al server, invece, include i
controlli MapX ActiveX, dati MapXtreme, il Remote Geocoder, uno strumento di
amministrazione del server, e uno strumento per l’amministrazione dei dati geografici
(Geoset manager). Il Remote Geocoder permette agli amministratori del sito web di
6
http://www.mapinfo.com
2.1 WebGIS software
16
processare i dati geografici che sono alla base delle mappe. Il tool di amministrazione
lato server permette di testare e configurare il server dopo l’installazione. Il Geoset
Manager permette di creare nuove mappe e modificare quelle esistenti, aggiungere
e rimuovere layers, impostare i livelli di zoom, aggiungere proprietà ed etichette ed
alterare le impostazioni riguardanti i layers.
Gli script creati tramite i tool di sviluppo vengono installati sul web server e
saranno mandati in esecuzione per rispondere a determinate richieste effettuate lato
client. Quando uno script va in esecuzione viene istanziato un oggetto e vengono
utilizzati le proprietà e i metodi, messi a disposizione da questo. Quindi lo script,
interagisce con i dati che descrivono la mappa ed effettuano la costruzione di un’immagine, cioè di una mappa in formato raster. L’immagine viene inviata al client
e inclusa nel documento HTML. Si possono generare immagini in vari formati. I
web browser meno innovativi7 supportano nativamente solo i formati GIF, JPEG e
PNG. Svolgendo le operazioni per la creazione delle mappe lato server, e generando
immagini supportate dal browser, MapX lavora solo lato server e non è necessario
installare nessun plugin sul client.
2.1.5
GeoMedia Web Map
Intergraph GeoMedia Web Map8 (GWM) permette la distribuzione delle informazioni geografiche su più sorgenti di dati e l’utilizzo del sistema all’interno della rete
internet o intranet. Il software permette di lavorare su dati geografici usando un
sistema operativo e un browser web standard.
Nel 1997 la Intergraph introdusse GWM per pubblicare dati geospaziali sul web
7
Mozilla Firefox 1.5 ha introdotto la funzionalità di visualizzare immagini in formato SVG ossia
immagini in formato vettoriale.
8
http://www.intergraph.com/gmwm
2.1 WebGIS software
17
come un’estensione delle tradizionali applicazioni GIS. Questo software permette
di creare dinamicamente mappe web in base allo stato dei dati GIS presenti sul
database in un determinato momento, e quindi di distribuire dati e informazioni in
tempo reale.
GWM non abbraccia la filosofia che si basa sulla produzione di immagini, ossia
di mappe in formato raster. Utilizzando una tecnologia di terze parti, interCAP
Graphics System, Inc.9 , crea delle mappe in formato vettoriale prelevando i dati
direttamente dal database di dati GIS. In particolare le mappe sono prodotte in
formato ActiveCGM10 (ACGM), un formato compatto e personalizzabile, sviluppato
per far viaggiare dati vettoriali in internet. In questo modo lato client dovranno
essere interpretati dati in formato vettoriale.
Il software della Intergraph accede contemporaneamente a vari tipi di database ed integra i dati risultanti dalla richiesta in una singola mappa. Un’ulteriore
funzionalità offerta da GeoMedia Web Map è la possibilità di inserire etichette e
collegamenti interattivi all’interno della mappa.
L’applicazione è accessibile lato client tramite un browser web su cui sia installato il plugin o il controllo ActiveX per interagire con le mappe web. La mappa
viene ricreata ogni volta che le informazioni vengono modificate sul server in modo
da mostrare sempre informazioni aggiornate. GeoMedia permette anche di creare
mappe web sottoforma di SVG (formato vettoriale) o JPEG (formato raster).
9
10
http://www.intergraph.com
http://www.design-drawing.com/smartsketch/activeCGM.htm
2.1 WebGIS software
2.1.6
18
Perché Alov / TimeMap?
Alov / TimeMap11 consiste in un’applet Java ed un’applicazione lato server sviluppata nello stesso linguaggio di programmazione.
È possibile utilizzarlo sia in modalità standalone che client / server. La modalità
standalone permette, tramite l’utilizzo dell’applet di visualizzare direttamente in un
web browser le mappe in formato vettoriale.
Quando il web browser tenta di interpretare la pagina HTML in cui si fa riferimento all’applet, essa entra in esecuzione ed interpreta direttamente file in formato
“shape”12 , elencati in un file XML13 .
La modalità di funzionamento client / server permette inoltre, di caricare le
mappe in un database a cui accederà la parte server dell’applicazione. Quando
l’applet viene caricata, in base allo stesso file XML, fa richiesta al server dei dati
necessari per disegnare la mappa. Il server preleva tali dati dal database e li invia
all’applet che disegna la mappa e la mostra a video.
Sono supportati svariati tipi di motori di database e la stessa applicazione lato
server fornisce un’interfaccia per il caricamento delle mappe. La comunicazione fra
client e server avviene tramite richieste HTTP. Lato client, non è necessario installare
nulla, ma basta collegarsi con un browser web che supporti le applet Java14 , all’url
del server. A questo punto il browser provvederà a scaricare l’applet lato client15 ed
a mandarla in esecuzione.
L’applet fornisce gli strumenti per navigare la mappa, selezionare o escludere
layers, per effettuare lo zoom e per inserire etichette o collegamenti.
11
http://www.alov.org - http://www.timemap.net
formato analizzato nel capitolo successivo
13
http://www.w3c.org
14
http://www.java.sun.com
15
In base al funzionamento delle applet Java
12
2.1 WebGIS software
19
L’immagine che viene mostrata nel browser è il risultato dell’elaborazione diretta
di dati contenuti nello shapefile originale16 e quindi mantiene, tramite oggetti, la
stessa struttura di uno shapefile: record e shape.
Il vantaggio di questo approccio sta nel fatto che anche lato client si ha a disposizione la struttura di un shapefile, quindi una mappa in formato vettoriale. Sulla
mappa si possono quindi effettuare operazioni di zoom conservando la stessa qualità
dell’immagine originale.
L’applicazione è largamente configurabile tramite file XML. Il file “layout.xml”
permette di impostare il layout grafico dell’applicazione ed il file “project.xml”
permette di impostare i layers, la sorgente dei dati, eventuali etichette e collegamenti.
In quanto appena detto riguardo il formato delle mappe utilizzato e l’enorme
flessibilità offerta, emergono le motivazioni della scelta di Alov. C’è da aggiungere
la potenza offerta da un linguaggio di programmazione ormai affermato e robusto
quale Java di Sun MicroSystem.
Da considerare inoltre che questo sistema è OpenSource, e la disponibilità dei
sorgenti offre notevoli vantaggi allo sviluppo e all’integrazione di funzionalità in
un’applicazione.
16
a prescindere dal fatto che sia stata caricata dal database o meno
Capitolo 3
Shapefile
Come introdotto nel capitolo precedente, il formato delle mappe utilizzato dall’applicazione sviluppata è il formato “shape”1 . Di seguito saranno descritte la struttura
e le principali caratteristiche di questo formato [10].
Uno “shapefile” memorizza informazioni geometriche non topologiche, per funzionalità spaziali in un insieme di dati. Le informazioni geometriche sono scritte
all’interno del file come un insieme di coordinate vettoriali, mentre attributi sui dati
sono memorizzati in un file di database.
Dato che i file non contengono informazioni riguardanti la struttura dati topologica, offrono il vantaggio di una veloce rappresentazione e modifica.
Gli shapefile supportano punti, linee e forme chiuse nonché poligoni ed i relativi
attributi hanno una relazione diretta (ovvero uno ad uno) con i record.
Uno shapefile ESRI è composto da un file principale (name.shp), un file di indice
(index.shx) e una tabella dBase (dbase.dbf). Il file principale è ad accesso diretto ed
ha una struttura di record a lunghezza variabile. Ogni record descrive una forma
con una lista di vertici. Nel file di indice, ogni record contiene l’offset corrispondente
1
http://www.esriitalia.com
3.1 Organizzazione del file principale
21
nel file principale dall’inizio alla posizione in cui è memorizzato quel record. Il file
dBase contiene gli attributi dei record, uno per volta. La relazione uno a uno tra la
geometria e gli attributi è basata sul numero dei record nel file principale.
3.1
Organizzazione del file principale
Il file principale è formato da un’intestazione di lunghezza fissa seguita dall’elenco dei
record di lunghezza variabile. Ogni record è composto a sua volta da un’intestazione
di lunghezza fissa e da un contenuto a lunghezza variabile.
Tutto il contenuto del file principale può essere suddiviso in due categorie:
• Dati
Contenuto dei record del file principale
Intestazione
• Gestione dei file
File e lunghezza dei record
Offset dei record
L’intestazione del file principale è lunga 100 bytes e contiene informazioni riguardo la lunghezza, la versione, il tipo di figura (shape) utilizzato e informazioni
spaziali riguardo il massimo e il minimo offset.
L’intestazione del singolo record è lunga 8 bytes e contiene il numero del record
e la sua lunghezza.
3.2 Figure
3.1.1
22
Records
Il contenuto dei records consiste nei dati geometrici della figura a seconda del tipo
(eg. punto, poligono etc.). La lunghezza dipende dal numero di parti e vertici della
figura.
3.2
Figure
Tra le forme disponibili si possono annoverare:
• figura nulla senza informazioni geometriche (shape di tipo “null”). Questo
tipo di figura è utilizzato in fase di creazione,
• un punto (coppia di coordinate, nell’ordine X,Y, a doppia precisione.
• punti multipli,
• linee.
Sono rappresentabili inoltre altri tipi di figure più complesse quali poligoni, oppure figure simili alle precedenti con informazioni aggiuntive sulla misura, oppure
figure posizionate secondo le tre dimensioni spaziali.
A seconda dei dati che si vogliono rappresentare si utilizzano delle forme anziché
altre. Uno shapefile è composto da dati omogenei e quindi i record al suo interno
sono sempre dello stesso tipo.
Capitolo 4
Protocollo NMEA
La NMEA (National Marine Electronics Association) ha sviluppato una specifica che
definisce un’interfaccia per le varie apparecchiature elettroniche della marina[3] (una
copia dello standard è disponibile per scopi didattici sul sito web: http://www.nmea.com).
Il sistema sviluppato utilizza questo protocollo.
4.1
Introduzione
Molti software che prevedono la comprensione di informazioni sulla posizione in tempo reale sono in grando di comprendere dati in formato NMEA. Tali dati includono
la soluzione completa PVT (“Position, velocity, time”, posizione, tempo, velocità)
fornita da un ricevitore GPS.
L’idea del protocollo è di inviare un insieme di dati suddiviso in frasi1 . Ogni
frase comprende tutte le informazioni necessarie ed è quindi indipendente dalle altre
frasi. Ci sono frasi per ogni categoria di dispositivi e c’è la possibilità di definire
frasi proprietarie per scopi individuali.
1
Stringhe, dall’inglese “sentences”
4.2 Hardware
24
Ogni frase inizia con il simbolo “$” e finisce con carattere di a capo2 e non può
essere più lunga di 80 caratteri di testo visibile. I dati contenuti nella linea sono
separati dalla virgola3 e sono costituiti solo caratteri ASCII. Alla fine di ogni frase,
dopo un asterisco viene posto un checksum che è calcolato come la funzione XOR a
8 bit di tutti i caratteri che la compongono.
4.2
Hardware
Le interfacce di connessione hardware sono ideate per soddisfare i requisiti NMEA.
Queste sono compatibili con le porte seriali le quali usano il prtocollo “RS232”[4].
Ad ogni modo NMEA raccomanda il rispetto del “EIA-422”[5].
La velocità può variare in base agli apparecchi ma lo standard è 4800 baud con 8
bits di dati, nessuna parità e un bit di stop. Tutte le apparecchiature che supportano
NMEA dovrebbero supportare questa velocità.
4.3
“Frasi” NMEA
Le stringhe NMEA sono composte da parole separate da virgole. La prima parola è
quella che definisce il tipo e quindi in base ad essa si dovrà interpretare il resto della
frase. Lo standard NMEA prevede molti tipi di frasi, in base al tipo di dispositivo
utlizzato nell’ambiente marino.
Lo standard prevede che la stringa inizi con due lettere che identificano la cate2
3
“Carriage return/line”
“commas”
4.4 Decodifica di una “frase”
25
goria di dispositivi che utilizzano tale stringa4 . Le successive tre lettere definiscono
il contenuto della frase.
Invece le stringhe definite da aziende per scopi individuali devono iniziare con
la lettera “P” e le successive tre lettere identificano l’azienda che ha introdotto tale
stringa.
La frase non ha lunghezza fissa in quanto in alcuni casi alcuni campi possono
mancare, ma anche se un valore manca le virgole che lo delimitano vengono inserite.
4.4
Decodifica di una “frase”
La più completa frase NMEA, fra quelle che riguardano il rilevamento della posizione
geografica del localizzatore, è quella che inizia con “$GPRMC”. Infatti il prefisso
inizia con “GP” che sta per “dispositivo GPS” e continua con “RMC” che sta per
“Raccomanded Minimium specific GPS/TRANSIT data”.
Un esempio di stringa NMEA è il seguente:
$GPRMC,140005.242,A,4717.1126,N,00833.7862,E,0.02,79.58,010201,,*36
in cui i campi hanno il seguente significato:
HHMMSS.SSS Ora UTC-GPS (Universal Coordinated Time)
X Stato A=Attivo (Active); V=Nullo (Void)
XXXX.XXXX Latitudine della posizione attuale
X Emisfero della posizione attuale: N=Nord (North); S=Sud (South)
XXXX.XXXX Langitudine della posizione attuale
4
e.g. “GP” per i GPS
4.4 Decodifica di una “frase”
X Verso della posizione attuale: E=Est (East); W=Ovest (West)
X.XX Velocità al suolo in nodi
XX.XX Direzione di movimento, in gradi reali (Track Mode Good)
GGMMAA Data
X.X Variazione / declinazione magnetica in gradi
X Verso della variazione / declinazione magnetica
X Tipo di rilevazione:
[A] Automatica (Autonomous)
[D] Differenziale (Differential)
[E] Stimata (Estimated)
[N] Dati non validi (Non valid data)
26
Capitolo 5
Infomobilità
Dopo un’analisi degli standard e delle tecnologie utilizzate al momento, verranno
presentate le caratteristiche del sistema di rilevamento satellitare della posizione che
è alla base del funzionamento del sistema sviluppato [6], [7].
5.1
GPS
Il sistema GPS (Global Positioning System) avviato dagli U.S.A. a partire dagli anni
’70, e completato nel 1993, è stato realizzato per motivi principalmente militari,
per rispondere all’esigenza del Ministero della Difesa degli Stati Uniti di seguire
il percorso di mezzi militari sulla terraferma ed in mare in modo da localizzarne
la posizione in ogni momento e consentirne eventuali operazioni di supporto e di
salvataggio.
Il GPS è un sistema di individuazione della posizione che utilizza 24 satelliti
artificiali (vedi fig. 5.1), divisi in gruppi di quattro che ruotano attorno alla terra
alla quota di circa 20.200 Km in orbite distanti fra loro di un angolo di 60 gradi, in
5.1 Sistema di rilevamento satellitare della posizione
28
modo da ricoprire tutto il globo terrestre, e formanti un angolo di 55 gradi rispetto
al piano equatoriale.
Figura 5.1: Disposizione dei satelliti
Di questi satelliti, 21 sono attivi, mentre tre sono di scorta, cioè sono in attesa
di entrare in funzione quando qualcuno dei 21 cesserà di essere attivo. I satelliti
artificiali, infatti, hanno una vita media che, per quelli di questa serie, è di circa
dieci anni.
È previsto anche un piano di espansione futura che prevede il lancio di altri
satelliti, per sostituire quelli che man mano esauriranno le loro capacità ed andranno
fuori servizio.
5.1.1
Principio di funzionamento
Il sistema GPS consente di determinare la propria posizione sulla superficie terrestre,
e la quota, ed è attivo oggi in qualunque punto della terra.
È necessario disporre di un ricevitore GPS il quale intercetta a terra il segnale a
microonde generato dai satelliti in orbita che, a turno, passano sopra di noi.
Infatti, visto il numero, l’orbita ed il periodo di rotazione dei satelliti, di cui si è
5.1 Sistema di rilevamento satellitare della posizione
29
già parlato, risulta che in ogni istante sono sopra di noi in media da cinque ad otto
satelliti che si alternano in quota.
5.1.2
Tipo di modulazione e frequenze
I satelliti GPS generano due diversi segnali di tipo numerico, che vengono chiamati
L1 ed L2, alle frequenze rispettivamente di 1,5 e 1,2 GHz circa, modulati in P.S.K.1
dei quali il primo serve per la localizzazione grossolana, quella di tipo civile, e l’altro
per la localizzazione più precisa, di tipo militare.
5.1.3
Grado di precisione del rilievo
Il primo segnale consente la determinazione della propria posizione con la precisione
di circa 300 metri, il secondo invece, con la precisione di 50 cm.
Mentre il primo segnale è trasmesso in chiaro, il secondo, invece, è trasmesso in
codice segreto e non è accessibile se non al Ministero della Difesa degli Stati Uniti
che lo utilizza esclusivamente per la propria sicurezza e non lo rende noto a tutti per
evitare che possa essere utilizzato contro gli interessi degli Stati Uniti da criminali
o da stati nemici.
Ogni satellite trasmette dei segnali ad alta frequenza verso terra che vengono
ricevuti da un apposito apparecchio ricevitore dalle dimensioni ridottissime di un
comune cellulare.
5.1.4
Ricevitore GPS
I ricevitori GPS commerciali, oggi dal costo molto contenuto, consentono di sintonizzarsi automaticamente sulle frequenze dei satelliti suddetti e, dopo un tempo di
1
http://it.wikipedia.org/wiki/PSK
5.1 Sistema di rilevamento satellitare della posizione
30
ricerca e di elaborazione dei dati ricevuti, dell’ordine di pochi secondi, sono in grado, individuando la distanza da almeno quattro satelliti, di determinare la propria
posizione geografica sulla terra in termini di latitudine e longitudine, e quota.
Alcuni tipi di ricevitori, sono in grado di mostrare la propria posizione all’interno
di una cartina geografica anche di un’intera nazione, che può essere ingrandita fino
a diventare una vera e propria cartina topografica.
5.1.5
Principio di funzionamento
I satelliti, dotati di orologi atomici al cesio di grandissima precisione, che vengono
sincronizzati dalla stazione americana di Colorado Spring ogni qual volta vi passano sopra, trasmettono in continuazione dati numerici che comprendono le proprie
coordinate X, Y, Z, e l’istante esatto T di trasmissione.
Questi dati vengono elaborati a terra dal ricevitore il quale, confrontandoli con il
proprio tempo locale, in quanto anche il ricevitore è dotato di orologio al quarzo, e
conoscendo la velocità delle onde elettromagnetiche, deduce a che distanza si trova
da ognuno dei satelliti di cui sta ricevendo il segnale.
Infatti, noto l’istante T1 trasmesso dal satellite in cui è partito il segnale, e
l’istante T2, indicato dall’orologio locale, in cui il segnale è stato ricevuto a terra,
si conosce il tempo impiegato a percorrere la distanza dal satellite al ricevitore, ed
essendo la velocità della luce c, nota, la distanza D del satellite dal ricevitore risulta:
D = c (T2 - T1)
La conoscenza della distanza da un solo satellite è un dato del tutto insufficiente
per determinare la propria posizione, in quanto non è nota la posizione azimutale
né quella zenitale dello stesso, analogamente non è sufficiente conoscere la distanza
5.1 Sistema di rilevamento satellitare della posizione
31
Figura 5.2: Intersezione di tre sfere di raggio noto
da due satelliti; infatti, l’intersezione di due sfere di raggio noto, cioè le distanze
calcolate, dà luogo ad un cerchio e non ad un punto.
L’intersezione di tre sfere di raggio noto (vedi fig. 5.2), invece, determina due
punti, dei quali uno è di norma inaccettabile in quanto si trova ad altissima quota
e risulta anche muoversi ad altissima velocità.
Soltanto l’intersezione di quattro sfere di raggio noto, invece, consente con certezza, di determinare una posizione univoca nello spazio, il che spiega perché è
necessario aspettare del tempo, anche se si tratta di frazioni di secondo, per elaborare i dati, in quanto bisogna aspettare il passaggio di almeno quattro satelliti ed
avere anche il tempo di effettuare numerosi calcoli ed approssimazioni successive.
I dati del quarto satellite, infatti, oltre a rendere univoca la soluzione al sistema
di quattro equazioni in quattro incognite, consentono di correggere il valore del
tempo proprio del ricevitore per mezzo dei tempi dei quattro satelliti.
Le quattro incognite da determinare sono X, Y, Z, T, cioè le tre coordinate
indicanti la posizione geografica dell’utente fornito di ricevitore, più il tempo proprio
5.1 Sistema di rilevamento satellitare della posizione
32
che è indispensabile per determinare con grande precisione le distanze dei satelliti,
distanze che costituiscono i dati di partenza.
La X rappresenta la longitudine, la Y rappresenta la latitudine, la Z, la quota sul
livello del mare, e T il tempo proprio, corretto dagli orologi ad altissima precisione
che orbitano sui satelliti.
5.1.6
Accesso telematico
L’accesso telematico al satellite è del tipo CDMA.2 (Code Division Multiplexing
Access).
La CDMA è la tecnica più moderna e più complessa di accesso telematico ai
satelliti perché, essendo in linea di principio la fusione della divisione di tempo e della
divisione di frequenza, consente di trasmettere i dati multiplandoli sia in frequenza
che in tempo, e permette l’accesso da terra soltanto utilizzando un particolare codice
che può essere noto o segreto.
5.1.7
Telesorveglianza
Il sistema GPS è oggi molto usato per la telesorveglianza degli autoveicoli e la loro
protezione dai furti.
L’autoveicolo è dotato di un ricevitore satellitare del tipo G.P.S. accuratamente
nascosto che viaggia con lui e che ne determina istante per istante la posizione con
la precisione del centinaio di metri ritrasmettendola continuamente alla centrale che
gestisce il sistema antirapina a mezzo di frequenze usate dai cellulari che garantiscono
un’ottima copertura su tutto il territorio nazionale.
2
http://it.wikipedia.org/wiki/Cdma
5.2 Galileo
5.1.8
33
GLONASS
Il GLONASS[8] (GLObal NAvigation Satellite System) è un sistema satellitare di
individuazione della posizione prodotto dall’U.R.S.S. circa nello stesso periodo del
GPS americano e che ha caratteristiche molto simili, solo che non è criptato bensı̀
totalmente in chiaro.
Questo sistema è dotato di 24 satelliti, suddivisi in tre orbite distanti 120 gradi
fra loro ad una quota leggermente maggiore di quella dei satelliti GPS. La frequenza
è determinata in base ad un fattore variabile ed il tempo non corrisponde a quello
di Colorado Spring.
Nonostante le considerevoli differenze tecniche fra i due sistemi, esistono alcuni
fra i migliori ricevitori GPS che possono ricevere sia l’uno che l’altro sistema ed
ottenere una precisione complessiva simile a quella del sistema codificato militare
americano, cioè di quasi mezzo metro.
5.2
Galileo
Galileo[9] è un giovane sistema di posizionamento satellitare indipendente da quello
GPS del Dipartimento della Difesa degli USA e, al contrario di questo, prevalentemente dedicato ad usi civili. La sua entrata in funzione, che prevede il lancio in
orbita di una costellazione di 30 satelliti, è stata fissata per il 2008.
La creazione di una rete europea di localizzazione satellitare, darà impulso ad
una serie di servizi georeferenziati che andranno ad incidere positivamente in tutti i
settori della vita quotidiana, e non solo in quello della mobilità.
Quest’ultimo sarà però senza dubbio il mercato più importante, in particolare il
settore delle applicazioni per il settore automobilistico, ricordando che nei prossimi
5.2 Galileo
34
Figura 5.3: Satelliti in orbita
anni in Europa almeno il 10% dei veicoli, potrà essere on-line, con enormi vantaggi
non solo per gli automobilisti ma anche per i singoli stati, che disporranno cosı̀ di
efficaci strumenti di gestione e monitoraggio della mobilità, tali da sopperire alle
carenze infrastrutturali.
Con Galileo, l’Europa mira ad incrementare la sicurezza e l’efficienza dei trasporti nei settori aeronautico, marittimo e terrestre, grazie alla distribuzione di un
segnale certificato per l’aviazione civile e all’integrazione con i futuri sistemi di comunicazione mobile di uso pubblico. Accanto a questo, il “GPS all’europea” potrà
essere utilizzato per i sistemi antifurto, i mezzi di soccorso e molti altri servizi, pubblici e privati, che oggi devono fare completo affidamento sul servizio gestito dal
Dipartimento della Difesa degli USA.
Il fatto che gli USA considerino il sistema GPS un servizio ancora prevalentemente militare, porta con sé alcune conseguenze non trascurabili, fra cui una copertura
del servizio limitata alle nazioni militarmente allineate e la degradazione del segnale
destinato ad usi civili.
A differenza del GPS, con cui è comunque compatibile e interoperabile, Galileo
trasmetterà i segnali ad almeno due diverse frequenze: in questo modo, secondo
5.2 Galileo
35
gli esperti, i ricevitori terrestri possono correggere con più accuratezza i disturbi
atmosferici e calcolare la posizione con una precisione di circa 1 metro, contro i
10-20 metri del GPS.
5.2.1
Servizi
Sono quattro i servizi che Galileo offrirà:
• L’OS (Open Service) sarà accessibile a chiunque. I ricevitori consentiranno
un’accuratezza inferiore ai 4 metri orizzontalmente e 8 metri verticalmente;
• Il CS (Commercial Service), criptato, consentirà, dietro pagamento, di avere
un’accuratezza inferiore al metro. Il CS potrà essere completato da stazioni a
terra per portare l’accuratezza inferiore ai 10 cm.
• Il PRS (Public Regulated Service) e il SoL (Safety of Life Service) criptati
offriranno un’accuratezza comparabile con il servizio Open Service. Il loro
scopo principale è la robustezza contro disturbi e il rilevamento affidabile dei
problemi entro 10 secondi. Sono specificatamente progettati, rispettivamente,
per operatori di sicurezza (polizia, militari, ecc) e applicazioni per la sicurezza
nei trasporti (air-traffic control, atterraggio automatizzato di velivoli, ecc).
5.2.2
Principio di funzionamento
Galileo è basato su una costellazione di 30 satelliti (vedi fig. 5.4). Le stazioni di
ricezione sulla terra, insieme ad alcuni centri di controllo, forniscono informazioni
relative alla posizione degli utenti. Ad esempio nell’ambito dei trasporti, essi forniscono servizi per la posizione, la ricerca di strade, il controllo della velocità, sistema
di guida etc.
5.2 Galileo
36
Figura 5.4: Architettura di Galileo
Il principio operativo principale è semplice. I satelliti nella costellazione sono
equipaggiati di un orologio atomico che misura il tempo in modo molto accurato. I
satelliti emettono segnali personalizzati che stanno ad indicare il preciso istante in
cui il segnale stesso parte dal satellite. Le antenne riceventi, incorporate per esempio
in un telefono cellulare, hanno in memoria il dettaglio preciso dell’orbita di tutti i
satelliti nella costellazione. Interpretando il segnale in ingresso, il chip integrato nel
dispositivo ricevente, riconosce il satellite che l’ha inviato, e in base al tempo che ha
impiegato per viaggiare dal satellite ad esso calcola la distanza dal satellite. Ogni
ricevitore ha bisogno contemporaneamente, dei segnali di almeno quattro satelliti
per calcolare l’esatta posizione.
5.3 Applicazioni reali
5.3
37
Applicazioni reali
Ad oggi le possibili applicazioni del WebGIS sono molteplici e man mano che la
tecnologia diviene più accessibile e perfezionata nascono nuovi campi d’interesse.
5.3.1
Navigatore
Ad esempio, negli ultimi tempi, si sta diffondendo sempre più l’utilizzo di navigatori
satellitari installati a bordo di veicoli. Un navigatore permette di visualizzare, all’interno di una mappa la propria posizione, e inserendo una destinazione, di guidare
l’utente tramite una voce ed indicazioni grafiche su un display (di un palmare o di
un comune cellulare).
La configurazione che sta prendendo sempre più piede negli ultimi mesi è quella di
un telefono cellulare con un sistema operativo Symbian, su cui è possibile installare
una versione di navigatore. Il telefono cellulare deve essere fornito di interfaccia di
comunicazione bluetooth, e di un ricevitore GPS bluetooth.
5.3.2
Tracking Server
Un’ulteriore possibile applicazione di questa tecnologia è il cosı̀ detto “Tracking
Server”. Esso consiste nel tenere traccia della posizione di un oggetto nel tempo e
memorizzarla su una base di dati.
Utilizzando la rete GPRS3 o l’ormai affermata UMTS4 , dei gestori di telefonia
mobile è possibile comunicare con un server accessibile in internet tramite un telefono
cellulare. Tramite bluetooth5 il cellulare può comunicare con un ricevitore GPS e
3
http://it.wikipedia.org/wiki/GPRS
http://it.wikipedia.org/wiki/UMTS
5
http://it.wikipedia.org/wiki/Bluetooth
4
5.3 Applicazioni reali
38
inviare al server le coordinate della propria posizione. Un’applicazione in esecuzione
sul telefono cellulare può leggere le informazioni dal ricevitore GPS ed inviarle al
server.
Una configurazione simile è del tutto accessibile al giorno d’oggi, infatti tutti i cellulari di ultima generazione supportano la tecnologia UMTS, forniscono l’interfaccia
di comunicazione bluetooth e consentono di installare ed eseguire applicazioni software. Infatti questa generazione di cellulari ha installata una Java Virtual Machine
in versione Microedition, è quindi possibile lo sviluppo di un programma software
che effettui le operazioni descritte.
Tenendo conto che alcune case produttrici di telefoni cellulari iniziano a costruire
cellulari con il ricevitore GPS incorporato si può immaginare un apparecchio atto
ad eseguire solo le operazioni di cui si ha bisogno per il “Tracking Server”.
5.3.3
Tracking di flotte
Il “Tracking di flotte” è un’estensione del “Tracking Server” appena descritto. Esso consiste nel tenere costantemente traccia su un monitor o su un display della
posizione di un certo numero di oggetti in tempo reale.
Se i dati sulle posizioni vengono costantemente registrati su un database, nulla
vieta a un’ulteriore applicazione, di prelevare tali informazioni e renderle disponibili
in forma visuale.
Di applicazioni orientate al WebGIS ne esistono già molte, esse rendono disponibili dati geografici memorizzati su un database o su dei file. È possibile integrare
in esse la funzionalità di visualizzare ulteriori oggetti su una mappa prelevando le
informazioni da un database simile. Per analizzare lo spostamento degli oggetti mobili è sufficiente interrogare costantemente il server che raccoglie i dati sulle relative
5.3 Applicazioni reali
39
posizioni.
5.3.4
Utilizzi del tracking
Il meccanismo del tracking permette quindi una varietà di utilizzi. Basti pensare,
ad esempio, ad una ditta che fitta automobili, a un’impresa di trasporti, o ad una
ditta con dei tecnici sparsi sul territorio.
Una ditta con dei tecnici sparsi sul territorio potrebbe avere sempre sotto controllo la situazione in tempo reale, conoscere esattemente la posizione dei propri
tecnici e quindi soddisfare eventuali chiamate dei clienti contattando ed inviando il
tecnico più vicino.
Una ditta di trasporti o una che fitta automobili, avrebbero la possibilità di conoscere in tempo reale la posizione dei propri mezzi sul territorio e di visualizzarla su
di una mappa. Tramite un database potrebbero memorizzare gli eventuali percorsi
e riproporli successivamente.
5.3.5
Telesorveglianza
Ulteriori applicazioni reali sono quelle orientate alla telesorveglianza. Piazzando
degli appositi dispositivi in un edificio se ne potrebbe riportare la posizione su di
uno schermo. Allo scatenarsi di determinati eventi potrebbero essere mostrati degli
avvisi a video; oppure si potrebbe pensare di controllare in tempo reale la posizione
delle sentinelle all’interno dello stabile e conoscendone la posizione contattare la
sentinella più vicina in caso di eventuali problemi.
Parte II
USAlov
Capitolo 6
Introduzione
Il sistema sviluppato è stato chiamato “USAlov”. Si tratta di un’applicazione Client
/ Server per la visualizzazione ed il tracking di dispositivi GPS, collegati ad un
telefono cellulare1 , su una mappa.
6.1
Premessa
L’applicazione si basa su Alov TimeMap2 un’applicazione Java, quindi indipendente
dalla piattaforma, per la pubblicazione di mappe in formato vettoriale su Inernet e
la visualizzazione interattiva in un browser web.
6.2
Architettura
L’applicazione è composta principalmente da un’applet (lato client) e da una servlet
lato server. La servlet accede ad un database (nel nostro caso MySql3 5), su cui
1
tramite bluetooth nel caso in esame
http://www.timemap.net - http://www.alov.org
3
http://www.mysql.org
2
6.3 Tracking
42
Figura 6.1: Screenshot
sono stati caricati preventivamente i dati relativi le mappe, e li invia, su richiesta, a
quest’ultima.
6.3
Tracking
Tale architettura è stata integrata con funzionalità atte al tracking di flotte.
Lato server è stata sviluppata una struttura che permette di dialogare tramite
richeste HTTP con l’applet, e tramite la rete GPRS o UMTS con i dispositivi mobili.
La struttura client / server esistente in Alov / TimeMap, prevede la possibilità
di mostrare mappe GIS su una macchina client facendone richiesta ad un server. Il
6.3 Tracking
43
Figura 6.2: Struttura sviluppata
server preleva le mappe da una base di dati (clearinghouse). USAlov aggiunge un
server di tracking e un’ulteriore base di dati per la memorizzazione delle informazioni
riguardo gli oggetti mobili. Inoltre integra lato client le infrastrutture necessarie per
visualizzare tali dispositivi sulla mappa e per effettuarne la richesta della posizione
in tempo reale. Il pannello di tracking permette all’utente di interagire con il client
impostando gli oggetti mobili da tracciare o seguire. Nuove funzionalità lato client
effettuano le richieste al server di tracking per la comunicazione delle informazioni
riguado gli oggetto mobili. In tabella 6.1 un riassunto delle funzionalità.
Applet
Client
M
Server delle mappe
Server
O
Pannello e funzioni di tracking
Client
N
Server di tracking
Server
N
6.4 Conversioni delle coordinate
44
MIDlet per l’invio della posizione
Mobile
N
Interfaccia di caricamento delle mappe
Server
M
Tabella 6.1: Funzionalità: I = Modificata e rivista, O =
Originale, N = Nuova
I dispositivi GPS comunicano con il cellulare tramite bluetooth e il cellulare utilizza la rete GPRS per comunicare con il server tramite richieste HTTP. In tal modo
aggiornano la loro posizione al server. L’applet comunica con il server effettuando
un polling su richiesta dell’utente, al quale il server risponde con le informazioni
richieste.
6.4
Conversioni delle coordinate
Per effettaure le conversioni delle coordinate relative alla posizione sono state utilizzate le librerie Java fornite da GeoTransform[13].
Queste permettono di trasformare coordinate quali latitudine e langitudine in
coordinate compatibili con la proiezione cartografica con cui è stata costruita la
mappa.
6.5
Filosofia di sviluppo
La filosofia di sviluppo è stata quella di modificare il meno possibile i sorgenti di
Alov sfruttando le possibilità di estensione messe a disposizione dall’applicazione
originale.
Sono stati gentilemte messi a disposizione i sorgenti dell’applicazione TimeMap
6.5 Filosofia di sviluppo
45
dall’Uiniversità di Sydney (Australia). Essi sono stati molto utili in fase di debbugging e studio anche se l’applicazione originale fornisce già di per se un’ampia
possibilità di personalizzazione e configurazione.
Si è cercato quindi di sfruttare tale estendibilità modificando i sorgenti originali
in minima parte. Le innovazioni più rilevanti sono state sviluppate e progettate in
moduli esterni.
Le modifiche effettuate e le classi implementate sono descritte in maniera dettagliata nel capitolo relativo al codice sorgente.
Capitolo 7
TimeMap
Figura 7.1: Logo di TimeMap
7.1
Database
TimeMap, per memorizzare su database i dati geografici relativi le mappe utilizza,
tra le altre, le seguenti tabelle:
TM INSTANCE Questa tabella contiene i dati necessari per accedere alla tabella
in cui vengono caricati i dati al momento dell’upload della mappa.
TM DATASETS Questa tabella contiene i dati peculiari della mappa caricata,
e viene popolata all’atto della registrazione di una mappa precedentemente
caricata.
7.1 Database
47
Figura 7.2: Database di TimeMap
Quando si carica una mappa viene creata un’ulteriore tabella per memorizzare
le informazioni geografiche. Ad esempio se si carica una mappa con le strade di New
York, il sistema crea una tabella con “n” tuple, quanti sono i record dello shapefile,
ed “m” campi, quanti sono gli attributi. Inoltre la tabella conterrà ulteriori campi
contenenti le informazioni shape sui singoli record. Dalle indagini fatte si è evinto che
se lo shape è di tipo punto, vengono aggiunti due campi a doppia precisione (double)
per le coordinate, altrimenti il sistema utilizza un campo di tipo “GEOBLOB” per
inserire le informazioni relative lo shape.
Ad esempio, lo shapefile contenente le strade di una città viene tradotto in tabella
come mostrato nella figura 7.1
7.2 Client / Server
48
Figura 7.3: Tabella generata per la memorizzazione di uno shapefile contenente le
strade di una città
7.2
Client / Server
TimeMap in origine prevedeva due possibili modalità di funzionamento: standalone
e client / server. Per sviluppare USAlov si è partiti dalla modalità client / server.
In questo modo le mappe GIS, tramite la procedura di upload fornita dall’applicazione, vengono caricate sul database. Quindi la macchina server ospiterà l’applet1 ,
alla quale comunicherà le informazioni di cui ha bisogno (vedi fig. 6.1).
Client La connessione al sistema si basa su un browser web. Quando un client
si collega al sito internet, su cui è ospitata l’applet, il browser scaricherà l’applet2
la quale inizierà il proprio ciclo di vita sulla macchina client. All’avvio del sistema,
il client leggerà alcuni file XML presenti sul server in cui sono specificati il layout
1
Per motivi di sicurezza un’applet non può comunicare con altri host all’infuori dell’host da cui
è stata scaricata.
2
Componente attivo lato client
7.3 File di layout
49
grafico e le mappe da visualizzare. In base a tale file l’applet, comunicherà con il
server il quale fornirà i dati da mostare a video.
Il server fa da tramite tra l’applet e il database, leggendo le richieste dell’applet
e rispondendo con i dati prelevati dal database.
Questa descritta è l’architettura base di TimeMap che, seppur molto più complessa, è stata illustrata in maniera sintetica. La documentazione ufficiale è disponibile
on-line all’indirizzo “http://www.timemap.net”.
Nei prossimi paragrafi di questo capitolo sarà illustrato in dettaglio il funzionamento dell’applicazione.
7.3
File di layout
Il file “layout.xml” specifica i componenti disponibili all’interfaccia client ed il loro
layout nella finestra dell’applet.
Il percorso del file deve essere specificato nel file HTML che carica l’applet e
deve essere passato come parametro “layout” a questa, altrimenti sarà cercato nella
directory di default dell’applicazione al di sotto della direcotry specificata dal parametro “codebase” dell’applet. Se il file ha una struttura XML non valida esso sarà
ignorato e l’applicazione caricherà il layout di default.
7.3.1
Oggetti
Gli oggetti sono specificati con il tag “<object>”3 . Oggetti con funzionalità specifiche sono identificati da uno dei seguenti attributi:
3
vedi standard XML
7.3 File di layout
50
name per componenti quali toolbar, bottoni e controlli,
type per gli altri tipi di componenti.
È anche possibile definire oggetti senza alcun attributo il cui unico scopo è quello
di raggruppare altri oggetti.
7.3.2
Dimensioni ed allineamento
Tutti gli oggetti possono specificare la loro posizione, dimensione ed allineamento.
tramite l’utlizzo dei tag “align”, “bounds” e “size”.
7.3.3
Bottoni e toolbar
I bottoni sono identificati dall’attributo “type” inserito nel tag “<object>”. È
possibile quindi specificarne dimensione ed allineamento.
Per una corretta configurazione grafica si consiglia la creazione di una toolbar
associata alla mappa contenente tutti i bottoni.
7.3.4
Pannelli
Gli oggetti “panel” possono essere utilizzati per contenere altri oggetti eccetto
bottoni.
7.3.5
Colori
Il formato utilizzato per specificare i colori é “R:G:B”, dove R, G e B sono valori da 0
a 255. È inoltre possibile specificare un quarto parametro per definire la trasparenza
(alpha), il quale dovrà assumere anch’esso valori da 0 (trasparente) a 255 (opaco).
7.4 File di progetto
7.3.6
51
Collegamento alla mappa
Tutti gli oggetti sono collegati con la mappa di default, ma nel caso sia prevista
la visualizzazione di due o più mappe, è anche possibile collegare i vari oggetti alla
relativa mappa, grazie all’attributo “map=name-of-map”.
7.4
File di progetto
Il file di progetto “project.xml”4 è un documento XML che descrive la struttura di
una mappa. Contiene la lista dei layers, specifica i simboli, le opzioni e la sorgente
dei dati.
7.4.1
Database Clearinghouse
Usare un database (detto Clearinghouse) è la via più corretta per la memorizzazione
e l’amministrazione dell’insieme dei dati: “dataset”. Un dataset descrive e registra
in un database Clearinghouse i layer che possono essere utilizzati in più progetti.
Per l’amministrazione del Clearinghouse vedere il capitolo sulla configurazione.
7.4.2
Layers
Il file di progetto specifica, sempre avvalendosi dello standard XML, i layers da
visualizzare e la sorgente dei relativi dati. Un layer può essere identificato come un
insieme di oggetti omogenei.
4
Chiamato da TimeMap “mapspace file”
7.5 Applet
7.5
52
Applet
Per essere caricata in un browser web l’applet deve essere richiamata in una pagina
HTML che funge da vettore di dati. Di seguito ne viene illustrato un esempio.
Figura 7.4: Screenshot dell’applet
<applet codebase=“/usalov”
code=“org.alov.viewer.SarApplet”
archive=“alov.jar”
width=“640”
height=“480”
align=“center”>
7.6 Server
53
<param name=“pid”
value=“USAlovResources/project-bmwin.xml”>
<param name=“layout”
value=“USAlovResources/layout.xml”>
</applet>
In questo modo quando si accede con un browser web alla pagina HTML contenente il codice appena illustrato, il browser scaricherà l’applet dal server a cui si
è effettuato l’accesso cercandola nel path indicato dal parametro “codebase” con il
nome indicato dal parametro “archive”.
Una volta scaricata sul client l’applet inizia il proprio ciclo di vita caricando la
classe principale indicata dal paramtero “code”.
L’aspetto grafico sarà impostato secondo il file di layout, mentre i dati da
richedere al server sono indicati nel file di progetto.
In questo caso la classe responsabile dell’avvio è la classe “SarApplet” contenuta
nel package “org.alov.viewer”.
7.6
Server
Lato server il servizio principale è realizzato dalla Servlet “MapServlet” contenuta
nel package “org.alov.serv”.
“MapServlet” è la Servlet principale utilizzata per interagire con l’applet tramite
il protocollo HTTP.
Questo servizio si occupa del recuupero delle informazioni da inviare al client.
Capitolo 8
Architettura
USAlov estende le funzionalità di TimeMap sotto vari aspetti. Esso si propone di
integrare alle funzionalità di base già esistenti la possibilità di effettuare il tracking
di dispositivi mobili.
8.1
Database
Ai fini di storicizzazione dei dati, cioè per il salvataggio dei percorsi effetuati dagli oggetti mobili e dei dati dei dispositivi registrati, sono state introdotte alcune ulteriori
tabelle. Per non interferire con il database dell’applicazione originaria, si è scelto di
creare un nuovo database in cui inserire le tabelle necessarie all’applicazione.
In particolare sono state inserite dua tabelle di base. La tabella “register” consente la memorizzazione dei dispositivi registrati: essa conterrà l’identificativo e il
tipo di ogni oggetto mobile registrato sul sistema. La tabella “history”, invece, contiene i dati relativi il percorso dei dispositivi mobili: contiene quindi l’identificativo
del dispositivo, le coordinate relative la posizione è l’orario della comunicazione.
8.1 Database
55
Tabella 8.1: Struttura della tabella history
Field
Type
Null
id
varchar(255)
Yes
x
double
Yes
0
y
double
Yes
0
timestamp
Yes
0000-00-00 00:00:00
time
Default
Tabella 8.2: Struttura della tabella registered
Field
8.1.1
Type
Null Default
id
varchar(255)
Yes
type
varchar(20)
Yes
Aggiunta di un nuovo dispositivo
Per gestire una particolare categoria di dispositivi mobili, bisogna inserire un’ulteriore tabella. In essa si memorizzeranno i dati peculiari dell’oggetto. Ad esempio
se si vuole gestire la categoria di oggetti mobili “Autobus”, con le caratteristiche
targa, posti e numero, la tabella da creare sarà, per l’appunto, “Autobus” e conterrà
i campi su elencati.
Quando un utente effettua la registrazione di un nuovo dispositivo di tipo “Autobus”, sul sistema, dovrà inserire i valori relativi i campi della tabella. Il sistema
quindi provvederà a popolare la tabella “register” con il tipo di dispositivo e l’identificativo e la tabella “Autobus” con l’identificativo e i dati peculiari dell’oggetto.
trattato.
8.2 Servlet
56
Tabella 8.3: Structure of table autobus
Field
Null Default
id
varchar(255)
Yes
targa
varchar(10)
Yes
posti
int(11)
Yes
varchar(50)
Yes
numero
8.2
Type
Servlet
L’esigenza di dover inserire a runtime oggetti sulla mappa ha condotto all’integrazione, nell’interfaccia di caricamento dei dati, della funzionalità di creazione di mappe
vuote che poi ospiteranno a runtime oggetti mobili (vedi fig. 8.2).
Inoltre è stata sviluppata un’ulteriore servlet che fa da tramite tra i dispositivi
GPS e l’applet. Essa è centrale per il modulo di comunicazione in quanto tutte le
comunicazioni (richieste HTTP) avvengono tramite essa.
8.2.1
Comunicazione con i dispositivi GPS
La servlet riceve la posizione dei dispositivi GPS, la memorizza su un database,
e controlla ad intervalli regolari quali sono quelli che non comunicano la propria
posizione da più di un intervallo di tempo (configurabile).
Per tenere traccia degli spostamenti utilizza due strutture dati: un database in
cui vengono memorizzate tutte le posizioni comunicate dai dispositivi mobili e una
struttura in memoria in cui tiene traccia dei dispositivi attivi.
Le coordinate relative alla posizione, prima di essere memorizzate sul database,
8.2 Servlet
57
Figura 8.1: Interfaccia di caricamento delle mappe
vengono trasoformate in coordinate compatibili con la proiezione cartografica della
mappa.
8.2.2
Registrazione di un dispositivo GPS
La servlet registra nuovi oggetti GPS memorizzandone i dati inviati a seconda del
tipo di oggetto. In questo modo le successive comunicazioni avverranno solo tramite
un identificativo del dispositivo. Inoltre sarà possibile permettere le comunicazioni
solo per i dispositivi preventivamente registrati.
8.2 Servlet
8.2.3
58
Comunicazione con l’applet
Anche la comunicazione con l’Applet avviene rispondendo oppurtunamente ad eventuali richieste HTTP della stessa.
Tracking
Come detto in precedenza, il server tiene traccia dei dispositivi attivi in un determinato momento, eliminando dalla struttura dati quelli che non aggiornano la loro
posizione da più di un intervallo di tempo.
Quindi un opportuno processo in backgound controlla tutta la struttura dati ed
elimina le voci inerenti i dispositivi il cui ultimo aggiornamento della posizione non
è recente.
Quando l’applet effettua un’opportuna richiesta HTTP il server risponde con
l’ultima posizione di ogni dispositivo attivo.
Identificativi:
la servlet distingue i dispositivi in base al tipo e comunica le
ultime posizioni dei dispositivi richesti qualora essi siano presenti nella struttura
dati dei dispositivi attivi. Ad esempio se un oggetto “X” aggiorna la sua posizione
al server alle 14.00 e l’intervallo di tempo massimo di aggiornamento è impostato a
1 minuto, “X” alle 14.01 sarà rimosso dalla struttura dati dei dispositivi attivi.
Una delle nuove funzionalità implementate è quella che consente il tracking di
un singolo dispositivo. In questo caso il server risponde ad ogni richiesta del client
(applet) con la posizione del dispositivo richiesto1 .
Un’altra modalità di funzionamento consente il tracking di molteplici dispositivi
1
Qualora sia attivo
8.3 Applet
59
contemporaneamente. In questa modalità sono visualizzati sulla mappa, all’interno
del browser web, tutti i dispositivi interessati.
Richesta di un percorso
Altra funzionalità sviluppata permette di richiedere il percorso effettuato da un
oggetto in un intervallo temporale. Ad esempio si può chiedere che sia mostrato a
video il percorso effettuato da un’auto fra le ore 15.00 e le ore 16.30 di un determinato
giorno.
Ad una richiesta simile la servlet risponde con il percorso effettuato dal dispositivo nell’intervallo temporale richesto.
8.3
Applet
In base a quanto affermato nel paragrafo “Filosofia di sviluppo”, l’applet originaria
non è stata modificata direttamente e il funzionamento di base è rimasto invariato.
Grazie all’estendibilità prevista dall’applicativo originale, è stato sufficiente implementare le classi rispettando le convenzioni imposte, e specificarle nel file di layout
per far sı̀ che l’applet le utilizzi.
8.3.1
Scheda dettagli
Una delle funzionalità modificate è la finestra di pop-up che viene aperta nel momento in cui si clicca su un elemento della mappa. Se l’elemento è un record della mappa GIS ne vengono mostrati gli attributi, in maniera simile, tranne che nell’aspetto
grafico, all’implementazione originale.
Se invece si vogliono visualizzare gli attributi di un dispositivo GPS di cui si sta
8.4 MIDLet
60
facendo il tracking, i dati vengono chiesti al server dei dati tramite una richiesta
HTTP.
8.3.2
Pannello di controllo per il tracking
Tramite il pannello di controllo è possibile effettuare il tracking di una flotta.
Si può effettuare il tracking di un gruppo di oggetti mobili, o specificare, tramite
l’identificativo, i singoli dispositivi da monitorare per ogni tipo.
È inoltre possibile richiedere il percorso effettuato, in un intervallo di tempo, da
un singolo dispositivo.
8.3.3
Registrazione
Tramite la pagina JSP “register.jsp” è possibile registrare i dispositivi GPS di cui
potrà essere fatto il tracking.
8.4
MIDLet
Su un dispositivo mobile, dotato di JVM2 , è possibile installare un’applicazione di
tipo J2ME[16], [17]. Questo tipo di applicazioni prende il nome di MIDlet, che è
l’equicalente di un’applet per il browser.
La MIDlet[11] sviluppata, permette di connettersi tramite bluetooth a un dispositovo GPS, leggere la posizione attuale e inviarla al server di tracking.
2
http://java.sun.com
8.4 MIDLet
8.4.1
61
Configurazione dei parametri di connessione
La MIDlet deve essere configurata tramite il pannello “Options”. Bisogna inserire
l’url a cui è raggiungibile il server e l’identificativo preventivamente registrato.
8.4.2
Comunicazione Bluetooth
Al lancio della MIDlet, bisogna effettuare la ricerca dei dispositivi Bluetooth nel
range e scegliere il GPS che si vuole utilizzare.
8.4.3
Invio della propria posizione
Una volta agganciato il GPS si può fare lo “start”. La MIDlet instaurerà una
connessione con il GPS e ogni 10 secondi aggiornerà la propria posizione al server
impostato in fase di configurazione.
Capitolo 9
Funzionamento
9.1
Oggetti mobili
USAlov, come già detto, prevede la possibilità di effettuare il tracking di oggetti
mobili suddivisi in categorie.
Un oggetto, per essere monitorato, deve registrarsi sul server tramite la pagina
“register.jsp”. Qui a seconda del tipo1 che rappresenta inserirà dei parametri che lo
caratterizzano. Per esempio un autobus avrà proprietà quali il numero, il percorso,
il numero di posti, oppure un camion avrà proprietà relative al modello, alla merce
trasportata, al peso etc.
9.1.1
I dispositivi GPS
Per dispositivo GPS si intende un dispositivo qualsiasi che invii le proprie coordinate
al tracking server. I dispositivi quindi possono essere di qualsiasi tipo. È possibile
1
Il server può gestirne svariati tipi
9.1 Oggetti mobili
63
Figura 9.1: Class diagram delle classi che mappano gli oggetti mobili
installare il sistema su un qualsiasi telefono cellulare o palmare (dotato di tecnologia
J2ME), in grado di comunicare con un ricevitore GPS.
Per poterli distinguere sulla mappa, si associa ad ogni dispositivo un identificativo univoco2 , e un tipo. Per tipo si intende un oggetto che il dispositivo rappresenta
nella realtà. Per esempio se si effettua il tracking di automobili il tipo associato
sarà, “Auto”, ovvero se si sta facendo il tracking di tecnici sparsi su un territorio3 il
tipo associato sarà, “Tecnico”.
Questa suddivisione in categorie consente di gestire, per ogni tipologia, caratteristiche peculiari.
2
3
Operazione effettuata in fase di registrazione
Vedi capitolo “Sviluppi futuri”
9.1 Oggetti mobili
9.1.2
64
La classe “GPSDevice”
Nel caso di USAlov è stata realizzata la classe “GPSDevice” nell’omonimo package,
che rappresenta, da un punto di vista “Object-Oriented”, un’astrazione di un oggetto
mobile. Questa classe infatti fornisce alcuni metodi ed alcune proprietà ma demanda
alla classi che la estenderanno il compito di fornire ulteriori istanze e metodi, ossia,
rispettivamente, ulteriori proprietà e funzionalità, dell’oggetto che mappa.
La classe “GPSDevice” ha le seguenti proprietà:
id identificatico dell’oggetto,
type tipo (descrizione in formato testuale, eg. Auto, Autobus, Camion...),
lastX l’ascissa dell’ultima posizione rilevata,
lastY l’ordinata dell’ultima posizione rilevata,
lastTime la data (comprensiva di ora minuto e secondo) dell’ultimo rilevamento.
e i seguenti metodi:
getLastCoord() è un metodo di utilità che serve a restituire una stringa contente
l’ultima posizione del dispositivo,
setByRequest() il server gestisce dispositivi GPS astratti e non ne conosce a priori
il tipo, questo metodo permette di impostare tutte le proprietà del dispositivo,
getFieldsValue() questo metodo ritorna un array di oggetti in cui sono presenti
dei riferimenti a tutte le istanze del dispositivo,
getFieldsName() questo metodo invece ritorna un array di stringhe, dei nomi di
tutte le proprietà del dispositivo.
9.2 Servlet
65
I metodi astratti non sono implementati nella classe “GPSDevice” ma si richiede
lo siano nelle classi che la estendono.
In questo modo è immediato creare un nuovo oggetto che rappresenti un’entità
reale. Basta creare una nuova classe che mappa l’oggetto, e farle estendere la classe
“GPSDevice”. Quindi la nuova classe erediterà i metodi e le istanze della classe
estesa4 e implementerà i metodi dichiarati astratti.
9.2
Servlet
Il compito principale del server è quello di ricevere le coordinate relative alla posizione dalla MIDlet, e di comunicarle poi all’applet.
La servlet, classe “UsServlet” contenuta nel package “us.serv.controller”, quando
riceve una richeista HTTP con dei parametri la analizza, e in base al tipo di richista,
effettua determinate operazioni. Utilizza la classe “USAction” contenuta nel package
“us.serv.model” che è una classe di metodi statici, metodi messi a disposizione della
servlet per effettuare le proprie operazioni.
9.2.1
Comunicazione con la MIDlet
La UsServlet riceverà una richiesta HTTP dalla MIDlet, contenente i parametri
relativi alle coordinate5 della posizione.
A questo punto li trasformerà, tramite apposite librerie di conversione, nel sistema di proiezione cartografica utilizzato dalle mappe e li memorizzerà su due
strutture dati: il database e in una struttura dati attiva.
4
5
Detta classe padre secondo la terminologia Objected Oriented
Latitudine e longitudine
9.2 Servlet
66
Database Sul database saranno memorizzati l’identificativo del dispositivo, la
data in cui ha effettuato la comunicazione e la posizione.
Struttura dati attiva In un’apposita struttura dati attiva viene tenuto traccia
dei dispositivi attivi. Nella fattispecie, ogni qualvolta un dispositivo aggiorna la
propria posizione viene costruito l’oggetto che lo mappa e viene aggiunto in tale
struttura hash.
9.2.2
Memorizzazione delle posizioni
La servlet, prima di memorizzare le coordinate relative alla posizione ne effettua la
trasformazione in base alla proiezione cartografica della mappa. Questa operazione
viene svolta dalla libreria Java GeoTransform.
In particolare viene utilizzato il metodo “write” della classe “UsAction” per effettuare la trasformazione delle coordinate che poi saranno memorizzate sul database.
Per la trasformazione viene usata la classe “Nmea” contenuta nel package “us.util”.
L’oggetto Nmea ha un metodo “parseMessage(String lat, String lon)” che accetta
latitudine e langitudine e imposta le proprietà in base alla trasformazione nella
proiezione cartografica WGS84 fuso 32N.
All’inizio dello sviluppo tale classe accettava direttamente la stringa NMEA e
ne effettuava il parsing e la trasformazione delle coordinate derivanti, in quanto non
veniva effettuata nessuna operazione di analisi della stringa sul dispositivo mobile.
In seguito si è ritenuto opportuno effettuare tale parsing direttamente nella MIDlet
ed è stato implementato il nuovo metodo nella classe “Nmea”, alla quale però non
si è voluto cambiare il nome per motivi storici.
9.3 Applet
9.2.3
67
Comunicazione con l’applet
Per la comunicazione con l’applet, anche in questo caso, il server non fa nient’altro
che rispondere alle richieste HTTP. A seconda della richesta e dei parametri passati
con la richiesta, il server analizza i propri dati e risponde in modo appropriato.
9.3
Applet
9.3.1
Layers
USAlov raggruppa, anche in fase di visualizzazione, i dispositivi mobili per categoria,
utilizzando un layer per ogni tipo. All’avvio i layer contenenti i dispositivi mobili
saranno ovviamente vuoti, e verranno riempiti con gli oggetti che rappresentano i
dispositivi mobili, in base alle richieste dell’utente.
9.3.2
Scheda dettagli
Quando si clicca su di un elemento di una mappa viene generato un evento a
cui risponde una delle classi presenti nel vettore dei listener caricato in fase di
inizializzazione dall’applet.
Un listener rappresenta, in Java, un ascoltatore, ossia una classa in grado di
rispondere ad eventi.
All’avvio, la “SarApplet”, carica in un vettore di listener le classi che implementano le interfacce di seguito elencate.
CarteAttribute Interfaccia da implementare per effettuare la visualizzazione dei
dati.
9.3 Applet
68
CarteHostListener Questa è l’interfaccia per i listener abilitati a ricevere gli
eventi dell’applet. Implementandola se ne potrà controllare il comportamento.
Le interfacce dichiarano i seguenti metodi.
void setParameters(CarteHost host, XmlElement layout) Invocato quando
l’applet setta i parametri ottenuti dal file di layout. In fase di inizializzazione
l’applet carica il file di layout, ne effettua il parsing, quindi crea e aggiunge i
componenti specificati ed invoca il metodo.
void stop() Invocato quando l’applet viene terminata. Viene utilizzato per terminare tutte le attività in background.
void showAttributes(LayerVector lyr, Vector records) Invocato quando devono essere visualizzati gli attributi dei record.
La classe che è stata implementata è “UsFrame” e fa parte del package “us.listener”.
Aggiungendo il tag:
<object class=‘‘us.listener.UsFrame’’/>
essa viene caricata in fase di inizializzazione dalla “SarApplet”. Come richesto
implementa le interfacce di cui sopra.
In particolare crea una finestra grazie alla classe “Card2” presente nel package
“us.Frame”. Come ormai sarà charo, i metodi di questa classe vengono invocati
quando si clicca con il mouse su di un elemento della mappa (vedi figura 9.2).
Quest’ultima estende le funzionalità della classe originale ma dà anche la possibilità di visualizzare i dati inerenti un dispositivo GPS di cui si sta facendo il
tracking.
9.3 Applet
69
Figura 9.2: Scheda dettagli
Il client non conosce a priori tutti gli attributi dei record che rappresentano
dispositivi GPS, a differenza dei record che rappresentano elementi di una mappa
GIS.
Quindi per mostrare tali attributi la nuova classe “Card2”, utilizza un’ulteriore
classe chiamata “RequestGPSData” facente parte del package “us.applet”. Questa
implementa il metodo “getFields()” il quale restituisce un “Vector” di stringhe6
contenenti gli attributi del GPS richiesto. Il metodo effettua una richiesta HTTP al
server:
6
Vector¡String¿ notazione Java 5.0
9.3 Applet
70
http://url server /read data.rlv?
id=identificativo gps &type=tipo gps
ed effettua il parsing della risposta.
9.3.3
Pannello di Tracking
Nella toolbar di USAlov è stato aggiunto un ulteriore bottone, come nel caso precedente inserendo il seguente tag
<object type=‘‘panel’’bounds=‘‘0,0,1,35’’ align=‘‘top’’>
<object type=‘‘toolbar’’ name=‘‘toolkit’’
bounds=‘‘0,0,460,1’’ align=‘‘left’’>
...
<object
class=‘‘us.listener.ComunicationServer’’
bounds=‘‘150,7,23,23’’
image=‘‘USAlovResources/GPSView.gif’’/>
...
</object>
</object>
nel file di layout ed implementadone le classi che ne definiscono il comportamento.
La classe, come si può vedere dal tag, si chiama “ComunicationServer” e si trova
nel package “us.listener”. Essa implementa le seguenti interfacce:
CarteHostListener Di questa interfaccia si è discusso nel paragrafo precedente.
9.3 Applet
71
Figura 9.3: Pannello di tracking
CarteListener Controlla le azioni da intraprendere in base ad eventi scatenati
sull’applet.
ActionListener L’interfaccia del listener per ricevere eventi di azioni. L’oggetto
creato, appartenente a questa classe, viene registrato come componente grazie al metodo “addActionListener”. Quando l’evento viene generato viene
invocato il metodo “actionPerformed”.
ed estende la seguente classe:
ImageButton Controlla il bottone incluso nell’interfaccia.
9.3 Applet
72
Quindi implementa i seguenti metodi7 :
• Interfaccia “CarteListener”
void mouseMapPressed(MouseEvent e) Questo metodo viene invocato
quando viene premuto un bottone su un componente della mappa.
void mouseMapReleased(FloatRectangle selRect, MouseEvent e) Questo
metodo viene invocato quando viene rilasciato il bottone del mouse da
un componente della mappa. Esso accetta l’area selezionata durante il
“Drag & Drop”.
void mouseMapMoved(MouseEvent e) Questo metodo viene invocato ogni
qual volta si muove il mouse sulla mappa.
void afterMapDraw(Graphics g) Questo metodo è chiamato ogni volta
che viene ridisegnata la mappa. Qui si inserisce il codice che modifca
l’immagine della mappa finale mostrata a video.
• Interfaccia “ActionListener”
void actionPerformed(ActionEvent e) Invocato per svolgere un’azione in
risposta ad un evento.
e ne eredita tutti quelli dalla classe “ImageButton”. Quest’ultimi si preoccupano
della creazione grafica del bottone, del colore, della posizione e di tutto ciò che è
necessario per la creazione di un bottone.
Quando si preme il bottone sulla barra dell’applet viene invocata la classe “ComunicationServer” che mostra a video il pannello di tracking. Questo pannello
permette di accedere alle funzionalità descritte nei prossimi paragrafi.
7
Sono da aggiungere i metodi dell’interfaccia “CarteHostListener”
9.3 Applet
73
Figura 9.4: Tracking di alcuni dispositivi contemporaneamente
Posizione dei dispositivi
Per ogni categoria di dispositivi si dovrà specificarne l’identificativo e tramite la
pressione del tasto “Start/Refresh” questi saranno visualizzati sulla mappa se attivi
in quel momento.
È anche possibile scegliere di monitorare tutti i dispositivi di una determinata categoria tramite il bottone “All” avendo selezionato la categoria nel pannello a scelte
multiple. Oppure tutti i dispositivi di tutte le categorie previste tramite il bottone
“All types” della categoria selezionata. Ad ogni cambiamento si dovrà ripremere il
bottone “Start/Refresh” per aggiornare la lista degli oggetti da monitorare.
9.3 Applet
74
In dettaglio, alla pressione del tasto per aprire il pannello di tracking, viene invocato il metodo “actionPerformed” della classe “ComunicationServer” che effettua
le seguenti operazioni in cascata:
• controlla le categorie di dispositivi GPS per popolare il menu a tendina in cui
scegliere la categoria dell’oggetto;
• legge dal file “gps.xml” caricato sul server, per impostare la lista dei dispositivi
GPS da monitorare;
• crea un’istanza della classe “GPSView” contenuta nel package “us.window”
che è responsabile della creazione e della gestione del pannello di tracking.
Tracking di default All’avvio, viene caricato un file XML in cui sono specificati i
dispositivi da monitorare di default. Tale file risiede sul server e non è prevista (vedi
capitolo “Sviluppi futuri”) la possibilità di modificarlo lato client. Tale operazione
viene effettuata grazie alla classe “GPSViewXMLParseFile” contenuta nel package
“us.util” che implementa i metodi per effettuare il parsing del file XML.
<?xml version=‘‘1.0’’ encoding=‘‘UTF-8’’>
<gps type=‘‘Tecnico di secondo livello’’
id=‘‘145643GflT’’/>
<gps type=‘‘Tecnico di primo livello’’ id=‘‘19756DlF’’/>
Alla pressione del tasto “Start” viene creata (se non esiste già) un’istanza della
classe “ThreadShowGPS” contenuta nel package “us.applet”. Questa classe è un
thread e quindi esegue le proprie operazioni in background senza interrompere lo
svolgimento delle altre. Tale processo, finché non viene fermato, esegue sempre il
seguente ciclo di operazioni per ogni categoria di dispositivi:
9.3 Applet
75
• pulisce il layer corrispondente alla categoria,
• crea una lista con tutti gli identificativi da monitorare separati da virgola,
• invia una richiesta HTTP al server per richiedere la posizione del dispositivi
di cui al punto precedente,
http://server url /read.rlv?ids=identificativi gps&type=categoria
• inserisce in base alla stringa ricevuta, “n” record nel layer corrispondente alla
categoria, rappresentativi degli “n” dispositivi di cui si è fatta richiesta di
monitoraggio,
• effettua l’aggiornamento grafico della mappa con i nuovi record.
Inseguimento di un dispositivo
Un’altra modalità di tracking è quella che consente di inseguire letteralmente un
determinato oggetto. Infatti selezionando il tipo nel menù a tendina e inserendo
l’identificativo nell’apposita area di testo verrà effettuato l’inseguimento dell’oggetto
mobile (“follow mode”).
Questo compito è portato a termine dalla classe “ThreadFollowGPS” contenuta
nel package “us.applet”. Questa effettua il seguente ciclo di operazioni:
• pulisce il layer corrispondente alla categoria,
• crea una stringa con l’identificativo da monitorare,
• invia una richiesta HTTP al server per richiedere la posizione del dispositivo
di cui al punto precedente,
9.3 Applet
76
http://server url /read.rlv?id=identificativo gps&type=categoria
• inserisce, o aggiorna nel caso già esista, in base alla stringa ricevuta, il record
nel layer corrispondente alla categoria, rappresentativo del dispositivo di cui
si è fatta richiesta di monitoraggio,
• effettua l’aggiornamento della mappa con i nuovi record,
• centra la mappa rispetto al dispositivo inseguito.
Durante il tracking lo zoom della mappa rimarrà invariato ma essa avrà sempre al centro il dispositivo che si sta monitorando. Per questa funzionalità viene
utilizzata la funzione “UsCenterAt()” della classe “Carte” contenuta nel package
“org.alov.map” (vedi capitolo “Codice sorgente” per una spiegazione più dettagliata
dell’algoritmo utilizzato).
Visulizzazione del percorso di un dispositivo
L’ultima funzionalità presente nel pannello di tracking è quella che permette di richiedere il percorso fatto da un dispositivo in un determinato intervallo di tempo.
Selezionando la categoria dell’oggetto sarà sufficiente inserirne l’identificativo, la data di inizio e fine del periodo da monitorare e premere il pulsante “Get Path”. Quindi
sulla mappa sarà mostrato il percorso effettuato dall’oggetto in quell’intervallo di
tempo.
La classe incaricata è “PathGPS” contenuta nel package “us.applet”. Tale classe
esegue ciclicamente le seguenti istruzioni.
• Accetta nel costruttore un riferimento ad una struttura dati contenente dei
punti. Tale struttura viene sistematicamente riletta tramite il metodo “af-
9.3 Applet
77
Figura 9.5: Percorso di un oggetto mobile
terMapDraw(Graphics g)” della classe “ComunicationServer”, ad ogni refresh
della mappa, dove vengono aggiunti i punti contenuti nella struttura.
• Crea una stringa con l’identificativo di cui richiedere il percorso e l’intervallo
di tempo.
• Invia una richiesta HTTP al server per richiedere il percorso del dispositivo di
cui al punto precedente.
http://server url /getPath.rlv?id=identificativo gps
&type=categoria&from=data di partenza&type=data di arrivo
9.4 MIDLet
78
• Inserisce, in base alla stringa ricevuta, i punti nella struttura dati di cui al
primo punto. I punti rappresentano il percorso del dispositivo nell’arco di
tempo richiesto.
• Effettua l’aggiornamento della mappa con i nuovi punti.
9.4
MIDLet
La classe di partenza della MIDlet è “USAlovMIDlet” e si trova nel package “us.mid”.
Questa come richesto da J2ME estende la classe “MIDlet” di base. Essa implementa anche l’interfaccia “CommandListener” in modo di essere in grado di accettare e
processare comandi ricevuti tramite la tastiera del telefono cellulare.
Questa MIDlet all’avvio crea un menu che permette di accedere alle voci di
seguito elencate.
9.4.1
Ricerca Bluetooth
La MIDLet come prima cosa deve agganciare un dispositivo bluetooth.
Quindi il telefono cellulare dovrà scegliere fra i dispositivi bluetooth nel range8
(10m c.a) con cui comunicare.
La classe che si occupa di ciò è “SearchGPS” del package “us.gps” ed effettua la
ricerca di tutti i dispositivi bluetooth nel range. A ricerca completata essa crea una
lista dei dispositivi GPS trovati e la visualizza a video utilizzando il riferimento al
costruttore passato dalla classe di partenza.
Scelto il dispositivo con il quale si vuole comunicare si può tornare al menu
principale tramite il tasto “Back”.
8
Nel nostro caso i dispositivi GPS nel range
9.4 MIDLet
79
Figura 9.6: Ricerca di un ricevitore GPS bluetooth
9.4.2
Opzioni di connessione
Un volta scelto il dispositivo GPS, è necessario impostare i parametri di connessione
al server dei dati9 .
Tramite il menu si sceglie la voce “Options” (opzioni) e si accede all’apposita
interfaccia ove sarà possbile impostare l’identificativo del dispositivo10 e l’url del
9
10
Tale operazione va effettuata solo la prima volta che si utilizza la MIDlet
Preventivamente registrato sul server
9.4 MIDLet
80
Figura 9.7: Impostazione delle opzioni di connessione
server a cui connettersi.
La classe “USAlovMIDlet” si occupa di creare il form per l’inserimento di tali dati mentre il salvataggio è affidato alla classe “DbStore” presente nel package
“us.db”. Il cellulare infatti permette di memorizzare informazioni in un cosı̀ detto
“RecordStore” secondo una struttura a record. “DbStore” ha il compito di salvare
i dati sul supporto di memorizzazione del cellulare e di ritrovarli le volte successive.
9.4 MIDLet
9.4.3
81
Verifica della connessione
La MIDlet prevede anche la possibilità di controllare la connessione verso il server.
Si invierà una stringa di prova al server il quale risponderà in senso afferamtivo
solo se l’identificativo impostato è registrato.
Responsabile di questa operazione è la classe “CheckConn” contenuta nel package
“us.internet”. Essa invia una richesta HTTP, tramite la rete GPRS dell’operatore
di telefonia mobile, al server impostato. La stringa sarà cosı̀ composta:
http://url server /checkByPhone.jsp?id=id impostato.
A tale stringa il server risponderà con un messaggio di errore o di conferma. Quindi se la risposta è positiva vuol dire che la connessione è riuscita e che l’identificativo
comunicato è registrato sul database del server.
9.4.4
Invio della propria posizione al server
A questo punto, terminate le fasi di ricerca del dispositivo e di impostazione delle
opzioni di connessione si può lanciare l’applicazione nella modalità di funzionamento
principale.
Allo “Start” la MIDlet si connette al dispositivo GPS tramite bluetooth, processa
la stringa ricevuta e la invia al server.
La comunicazione bluetooth avviene in modo molto simile ad una comunicazione
client / server. Il dispositivo GPS, nel nostro caso farà da server, mentre il telefono cellulare sarà il client. A differenza della comunicazione client / server, con
il bluetooth, è sufficiente che il dispositivo effettui una prima richiesta al ricevitore
GPS, in tal modo quest’ultimo inizierà a rispondere con alcune informazioni fino a
richiesta di interruzione.
9.4 MIDLet
82
Figura 9.8: Aggiornamento della propria posizione al server di tracking
La stringa di connessione bluetooth è del tipo:
btspp://indirizzo dispositivo bluetooth :1
dove l’indirizzo del dispositivo bluetooth viene ricavato in base al GPS selezionato
precedentemente.
Quindi la classe “Start” contenuta nel package “us.gps” effettua la prima connessione con il dispositivo.
Il dispositivo GPS risponde con delle stringhe conformi al protocollo NMEA. La
9.4 MIDLet
83
MIDlet si occupa quindi di processare tali stringhe e di trasformarle in una forma
comprensibile al server.
Tali stringhe vengono analizzate tramite le classi contenute nel package “gps” e
scomposte in forma di latitudine e longitudine.
A questo punto le informazioni vengono inviate al server dati tramite una richiesta di tipo HTTP:
http://url server ?write.jsp?id=identificativo gps
&lat=latitudine &lon=longitudine
Capitolo 10
Codice sorgente
In questo capitolo saranno analizzati alcune porzioni del codice sorgente non analizzate nei precedenti capitoli.
10.1
Modifiche apportate ai sorgenti originali
In base a quanto affermato in precedenza, riguardo la filosofia di sviluppo, le modifiche effettuate sui sorgenti sono state bene poche.
10.1.1
Classe Carte
Alla classe “Carte” contenuta nel package “org.alov.map” sono stati aggiunti i
seguenti metodi:
void usCenterAt(double x, double y)
Centra la mappa sul punto passato come parametro, lasciando invariato il livello di
zoom attuale.
10.1 Modifiche apportate ai sorgenti originali
85
double width = Math.abs(currentRect.x2 - currentRect.x1);
double height = Math.abs(currentRect.y2 - currentRect.y2);
newRect.x1 = x - width/2; newRect.y1 = y - height/2;
newRect.x2 = x + width/2; newRect.y2 = y + height/2;
Vector<Layer> getEmptyLayers()
Restituisce un elenco dei layers vuoti. Serve a stabilire i layers che rappresentano
categorie di oggetti mobili.
10.1.2
Classe UploadServlet
L’architettura dell’applicativo originale, lato server, è stata arricchita con le funzionalità atte al caricamento di tabelle, che rappresentano categorie di oggetti mobili.
Nella servlet “UploadServlet” contenuta nel package “org.alov.serv” sono state
effettuate le seguenti modifiche.
Link “Empty Shapefile”
Cliccando su questo link si aggiunge una tabella vuota. Questa tabella è la rappresentazione di uno shapefile di tipo puntuale che, a regime, viene interpretato come
un layer vuoto dal client dove saranno ospitati, a runtime, gli oggetti mobili.
Metodo loadPumpPage()
Tramite il metodo dell’overloading dei metodi permesso da Java è stato creato un
nuovo metodo loadPumpPage().
Tale metodo si occupa di creare, ed inviare al browser la pagina HTML per il
10.2 Classi sviluppate
86
caricamento delle mappe. Il nuovo metodo crea la pagina nel caso particolare in cui
si voglia effettuare il caricamento di una mappa vuota.
10.1.3
Costanti
La classe “Const” contenuta nel package “org.alov.util”, contiene alcune costanti
relative al nome e alla versione dell’applicazione.
10.2
Classi sviluppate
In figura 10.1 sono mostrate le classe aggiunte.
Figura 10.1: Classi aggiunte
10.2 Classi sviluppate
10.2.1
87
Servlet
Lato server è stata creata l’infrastruttura per il prelevamento dal database delle
informazioni riguardo gli oggetti mobili e la comunicazione con l’applet. A questo
scopo, sono stati aggiunte le classi contenute nei packages “us.serv.*”.
La classe principale è la servlet “UsServlet”. Essa, secondo quanto stabilito dal
pattern MVC[14] di Sun, utilizza i metodi statici messi a disposizione dalla classe
di action “UsAction” per compiere le proprie operazioni.
GPSDevicesList
“GPSDevicesList” è la struttura dati attiva in cui si tiene traccia dei dispositivi attivi
in ogni momento. Questa classe estende la classe “Hashtable” di Java per aggiungere
alcune funzionalità. In particolare implementa il metodo “getType(String type)” e
sovrascrive il metodo “toString()”. Il primo serve a restituire una nuova struttura
dati uguale a quella di partenza ma contenente solo gli oggetti del tipo richiesto;
il secondo restituisce un stringa contenente le coordinate di ogni oggetto mobile
presente nella struttura al momento della richiesta.
ThreadRefreshListMobiles
La classe “ThreadRefreshListMobiles” è un thread che pulisce la struttura dati appena illustrata. La servlet “UsServlet”, in fase di inizializzazione crea un’istanza di
tale classe, passando come parametri nel costruttore un riferimento all’istanza “GPSDeviceList”, e l’intervallo di tempo in cui periodicamente deve essere effettuata la
pulizia. La servlet legge i parametri di configurazione dal file “web.xml”1 indicanti
1
Si rimanda il lettore alla documentazione di Tomcat per ulteriori approfondimenti a riguardo
10.2 Classi sviluppate
88
l’intervallo di tempo da far passare fra un’analisi e l’altra della struttura e verifica
se attivare tale analisi2 .
DBManager
Un’ulteriore operazione eseguita dalla Servlet in fase di inizializzazione è il caricamento del “DBManager”. Tale classe consente una separazione concettuale del
livello applicativo che si occupa dell’accesso alla base di dati. Per la creazione di tale
classe viene analizzato il file di configurazione “db.properties” contenente i parametri
per l’accesso al database.
Metodo service
Il metodo service della classe “UsServlet” si occupa a runtime di soddisfare le richieste ricevute dai client (applet e dispositivo mobile). Come previsto dal pattern
MVC, l’applicazione è configurata in mode che tutte le richieste che terminano con
un certa sequenza di caratteri dopo il punto vengono indirizzate ad una specifica
servlet. La parte antecedente viene utilizzata, quindi, per interpretare l’operazione
da eseguire.
La prima operazione che effettua la servlet è l’analisi della richiesta ricevuta e in
base ad essa effettua le operazioni necessarie. Ad esempio, una richiesta HTTP del
tipo
http://url server /read data.rlv?
id=identificativo gps &type=tipo gps
viene interpretata, in base a quanto appena affermato, in questo modo:
2
In fase di configurazione o debug può essere utile non attivare questa funzionalità
10.2 Classi sviluppate
89
l’ultima parte “.rlv” permette al server web di indirizzare la richiesta alla servlet
in questione, in base alle istruzioni inserite nel file “web.xml”; la parte appena
precedente “read data” rappresenta il comando. Ad esempio, nel caso riceva il
comando in questione, la servlet, verifica che siano presenti i parametri “id” e “type”,
e in caso affermativo restituisce una stringa contenente le proprietà del dispositivo
GPS richiesto. Tali operazioni, come già detto, vengono eseguite utilizzando i metodi
statici della classe “UsAction”
In base a quanto appena illustrato sarà chiaro che il metodo service è costituito
da una serie di “statement” (if / else if / if) sul comando ricevuto, in cascata fino a
trovare il comando ricevuto.
10.2.2
Applet
Lato client l’applet è stata arricchita con le classi contenute nei package “us.applet”,
“us.listener” e “us.window”.
Le classi “ComunicationServer” e “UsFrame” vengono caricate in fase di avvio
dalla “SarApplet”. il loro funzionamento è stato già illustrato nei capitoli precedenti.
Le classi contenute nel package “us.window” vengono utilizzate da quest’utlime e
sono le classi che visualizzano il pannello di tracking e la scheda dettagli.
10.2.3
Tracking
Per eseguire le operazioni riguardo il tracking, lato client vengono utilizzate le classi
contenute nel package “us.applet”. Questo package contiene, tra le altre, le classi “ThreadFollowGPS” e “ThreadShowGPS”, che consentono, rispettivamente, di
monitorare un singolo oggetto mobile e una flotta di essi. Entrambe sono strutturate come thread, svolgendo quindi, operazioni in background senza interrompere
10.2 Classi sviluppate
90
gli altri processi, ed entrambe utilizzano i metodi statici della classe “GPSLayer”
per l’inserimento dell’oggetto mobile sulla mappa mostrata a video. In particolare
quest’ultima classe implementa i seguenti due metodi:
Record addGpsToLayer(String line, Layer layerToFollow, Record rec)
che si occupa di aggiungere il record passato come parametro al layer, anch’esso
passato come parametro, in base alle informazioni contenute nella “line”.
E il metodo:
boolean showGpssInLayer(String line, Layer layer)
che si occupa di analizzare la linea ricevuta ed aggiungere al layer gli oggetti
mobili in base ad essa.
Aggiunta di un dispositivo
Per l’aggiunta di un dispositivo si utilizzano i riferimenti alle istanze utilizzate per
disegnare la mappa a video:
// Imposta il tipo di forma punto layer.objectType = 1;
layer.drawOrder = 1;
// Crea un nuovo Record rec = layer.newRecord();
rec.setId(requestToServer); rec.figType = 1; rec.centroid =
new FloatPoint(x, y); rec.extent = new FloatRectangle(x, y,
x, y); rec.setField(0, id);
// Crea un nuova figura nel record appena creato shp =
rec.newShape(1);
10.2 Classi sviluppate
91
// Imposta la posizione delle figura shp.xCoords[0] = x;
shp.yCoords[0] = y;
// Aggiunge il nuovo record al Layer
layerToFollow.addRecord(rec);
Richiesta al server
Come si è visto entrambi i metodi analizzati in precedenza accettano una linea di
testo fra i parametri. Tale linea è il risultato di un richesta al server. Tale richesta
viene effettuata nel seguente modo:
String urlString = urlToRequest
URL uRL = new URL(urlString);
InputStream urlStream = uRL.openStream();
InputStreamReader inputStreamReader = new
InputStreamReader(urlStream);
BufferedReader br = new BufferedReader(inputStreamReader);
String line = br.readLine();
La classe “PathGPS” si occupa delle richieste relative al percorso effettuato da
un oggetto.
10.2.4
MIDlet
Come già discusso nei capitoli precedenti la classe principale della MIDlet è “USAlovMIDlet”. L’elenco delle classi sviluppate è mostrato in figura 10.2
La classe principale estende la classe “MIDlet” ed implementa la classe “CommandListener”, entrambe classi J2ME. Essa disegna la prima schermata e reagisce
ai comandi inviati dalla tastiera del telefono cellulare.
10.2 Classi sviluppate
92
Figura 10.2: Classi sviluppate per la MIDlet
USAlovMIDlet implementa, inoltre, il metodo “commandAction”, secondo quanto stabilito dall’interfaccia su citata, per l’esecuzione delle operazioni richieste dall’utente.
Questo metodo è invocato ogni volta che l’utente sceglie un’operazione dal tastierino. Di seguito ne è riportato un esempio a scopo esemplificativo3 .
public void commandAction(Command c, Displayable s)
{
if (c == cmExit)
{
destroyApp(true);
notifyDestroyed();
}
else if (c == cmStart) {
start = new Start(dbstore, choosedGPS)
3
Il codice riportato è solo a scopo dimostrativo e per ragioni di leggibilità non corrisponde a
quello reale. Lo stesso vale per il codice riportato successivamente.
10.2 Classi sviluppate
93
dbs.closeRecordStore(); start.start();
}
...
}
else if (c == cmCheckConn)
{
dbs = new DbStore();
checkConn = new CheckConn(dbStore);
dbs.closeRecordStore();
checkConn.start();
}
}
La classe “CheckConn” permette di verificare la connessione con il server, e la
classe “SearchGPS” permette di effettuare la ricerca dei dispositivi GPS bluetooth
nel range. Entrambe sono strutturate come thread, e quindi svolgono le proprie
operazioni in background.
La classe “SearchGPS” inoltre, implementa l’interfaccia “DiscoveryListener”, che
è un’interfaccia fornita dalla libreria bluetooth di J2ME. Essa garantisce che la
classe implementi i metodi per la ricerca di dispositivi bluetooth. Di seguito è
mostrato un esmpio del metodo “deviceDiscovered()” che è il metodo che viene
invocato ogniqualvolta viene trovato un dispositivo bluetooth durante la fase di
ricerca.
10.2 Classi sviluppate
94
public void deviceDiscovered(RemoteDevice device,
DeviceClass arg1)
{
if (devices.indexOf(device) == -1)
{
devices.addElement(device);
}
}
Invece a ricerca terminata è invocato il metodo “inquiryCompleted()”.
public void inquiryCompleted(int arg0)
{
GPSList = new List(‘‘USALov:
GPS Search
result’’,List.IMPLICIT);
GPSList.addCommand(cmSelect);
GPSList.addCommand(cmBack);
GPSList.setCommandListener(this);
Enumeration e = devices.elements();
while (e.hasMoreElements())
{
RemoteDevice rd = (RemoteDevice)
e.nextElement();
GPSList.append(rd.getFriendlyName(false) +
+ rd.getBluetoothAddress(), null);
10.2 Classi sviluppate
95
}
USm.display.setCurrent(GPSList);
}
La classe “DbStore” si occupa della gestione dei dati memorizzati sul “record
store” del telefono cellulare. Ad esempio per prelevare l’identificativo memorizzato
sulla memoria del telefono utilizza le seguenti istruzioni:
byte[] byteId = rs.getRecord(1);
return new String(byteId);
invece per memorizzarlo:
byte[] byteId = new byte[50];
byteId = id.getBytes();
rs.setRecord(1, byteId, 0, byteId.length);
Infine la classe “Start” si occupa della lettura della posizione attuale da ricevitore
GPS e dell’invio al server. Anch’essa è un thread, in quanto tutte le operazioni di
I/O (eg. connesione ad internet, comunicazioni bluetooth), rischiano di bloccare il
dispositivo mobile.
Essa in fase di istanziazione, ovvero nel costruttore, effettua la connessione con
il dispositivo bluetooth:
String url = ‘‘btspp://’’ +
choosedDevice.getBluetoothAddress() + ‘‘:1’’
StreamConnection connection = (StreamConnection)
Connector.open(url, Connector.READ);
10.2 Classi sviluppate
96
InputStreamReader reader = new
InputStreamReader(connection.openInputStream());
successivamente legge le informazioni ricevute:
String output = new String();
int input;
while ((input = reader.read()) != LINE DELIMITER)
output += (char) input;
output = output.substring(1, output.length() - 1);
Infine analizza la stringa (il codice di analisi della stringa non è mostrato, ma si
rimanda il lettore al capitolo sul protocollo NMEA) e la invia al server:
String url = ‘‘http://url server /write.rlv?
id=identificativo gps &pos=posizione ’’;
InputStream is = Connector.openInputStream(url);
InputStreamReader isr = new InputStreamReader(is);
char[] risArray = new char[20];
isr.read(risArray);
String ris = new String(risArray);
if (ris.indexOf(OK) > 0)
// Il cellulare è riuscito a stabilire la
connessione // La risposta del server è contenuta
nella variabile di tipo stringa ris
else
10.2 Classi sviluppate
// Il cellulare non è riuscito a stabilire la
connessione con il server
97
Capitolo 11
Installazione e configurazione
L’installazione dell’applicazione presuppone che sul server siano già installati e
configurati Tomcat e MySql, entrambi alle versioni 5.
Per installare l’applicazione è sufficiente effettuare il deploy del file “usalov.war”1 .
Successivamente sarà ncessario caricare le mappe in formato “shapefile” sul database
tramite l’interfaccia fornita dall’applicazione. Infine bisognerà personalizzare i file.
di configurazione in base alle proprie esigenze come di seguito descritte.
11.1
Installazione
Per effettuare il deploy accedere tramite browser web all’interfaccia “Tomcat Manager” dalla pagina iniziale di Tomcat. Nel form “war file to depoly” inserire il file
“usalov.war” e cliccare sul tasto deploy.
1
Per richiedere il file contattare l’autore della tesi tramite email al’indirizzo “[email protected]”
11.2 Caricamento dei dati geografici
11.2
99
Caricamento dei dati geografici
USAlov ha ereditato ed integrato l’interfaccia di gestione e caricamento delle mappe,
raggiungibile all’indirizzo:
http://url del server /usalov/pump
Username e password sono configurabili all’interno del file “WEB-INF/mapservhome/mapserv.xml”. Inserire o modificare (se già presente) il tag:
<master user=‘‘username ’’ password=‘‘password ’’ ip=indirizzo ip 2 />
11.2.1
Caricamento delle mappe
Effettuato l’accesso, tramite il link “Upload shapefile” si può effettuare il caricamento di un file di mappa. Tramite i link sotto la voce “Setup”, bisogna impostare
i parametri di accesso al database. Il caricamento della mappa consiste nella creazione di una tabella contenente i dati della mappa. Sono necessari un file shape
“nome.shp” e il file di database “dbase.dbf”. Per poter accedere dal client alle
informazioni è però necessario effettuare la registrazione.
A caricamento completato il sistema chiede all’utente se si vuole registrare la
mappa. Cliccando sul pulsante “Register this dataset?” o successivamente cliccando
sul link “Vector Dataset”, si registra la mappa. Bisogna indicare alcuni parametri,
quali la tabella di riferimento (quella creata nello step appena precedente), i parametri per l’accesso al database (almeno in lettura sempre alla stessa tabella) ed
alcuni altri parametri descrittivi riguardo i campi da inviare al client e le informazioni riguardanti il tipo e il tema della mappa. Se si sceglie di registrare la mappa
2
Indirizzo IP della macchina da cui si accede, “*” per essere abilitati ad accedere da tutti gli
indirizzi IP
11.3 Impostazione dei dati
100
subito dopo il processo di caricamento il sistema inserirà automaticamente alcuni
campi.
11.2.2
Gestione oggetti mobili
Per la gestione degli oggeti mobili è necessario utilizzare ad una tabella vuota.
Tramite il link “Empty Shapefile”, sarà creata una mappa vuota.
Tale mappa deve essere utilizzata per registrare gli oggetti mobili sul database. Il
sistema comunica solo all’avvio i layers da gestire e quindi, per ogni oggetto devono
essere state registrate delle mappe “virtuali” che saranno poi popolate a runtime
dal sistema lato client.
Ad esempio se si vuole configurare il sistema per gestire il tipo di oggetto “Autobus” si deve creare la tabella vuota tramite il link “Empty Shapefile” e successivamente registrare la mappa basandosi sulla tabella appena creata. Successivamente,
per gestire un’ulteriore categoria di oggetti mobili, sarà sufficiente registrare un’altra
mappa contenente
11.3
Impostazione dei dati
Una volta caricati i dati geografici sul database bisogna editare il file “project.xml”
per istruire l’applet sulle mappe da scaricare all’avvio:
<?xml version=“1.0”?>
<project zoomunits=“m” usetime=“no”>
<domain name=“Full map” full=“yes” xmin=“909823.0”
ymin=“4500250.0” xmax=“1053050.0” ymax=“4610210.0”/>
<layer name=“1” label=“BN PROV” visible=“yes”>
11.3 Impostazione dei dati
101
<dataset id=“1”>
</dataset>
<symbol filled=“no” outline=“0:0:0”/>
</layer>
<layer name=“2” label=“Auto” visible=“yes”>
<dataset id=“2”>
</dataset>
<renderer type=“default”>
<symbol
image=“USAlovResources/GPSDevice/auto.png”
label=“Auto” />
</renderer>
<renderer type=“label” labelfield=“EMPTY ID”
usezoom=“yes”>
<symbol fill=“255:0:0” outlined=“255:0:0”
size=“10” font=“Dialog” label=“ID Auto” position
= “3”/>
</renderer>
</layer>
</project>
Bisogna inserire il tag layer per ogni layer che si vuole visualizzare. Esso deve contenere il tag dataset con l’identificativo comunicato dal sistema in fase di
registrazione della mappa sul database. Per ulteriori dettagli sui tag illustrati, si
11.3 Impostazione dei dati
102
rimanda alla documentazione di TimeMap, disponibile per il download, sul sito web
http://www.timemap.net.
Capitolo 12
Sviluppi futuri
12.1
Espandibilità
Come nell’applicazione di partenza anche durante questo sviluppo si è cercato di
preservare l’espandibilità rispettando i principi fondamentali sanciti dall’approccio
“Object-Oriented”.
12.2
MIDlet per cellulari con antenna GPS integrata
Recentemente il mercato ha proposto telefoni cellulari con ricevitore GPS integrato
(vedi capitolo “Ulteriori informazioni” nell’appendice di questa dissertazione). La
MIDlet sviluppata per USAlov permette l’utilizzo di un telefono cellulare che comunichi con un ricevitore GPS tramite interfaccia bluetooth. Per essere compatibile
con i telefoni cellulari con GPS integrato la MIDlet deve essere modificate per quanto
riguarda la parte di interfacciamento con il ricevitore GPS.
12.3 Visualizzazione di informazioni sul cellulare
12.3
104
Visualizzazione di informazioni sul cellulare
Una funzionalità aggiuntiva potrebbe essere quella di visualizzare informazioni su
altri utenti del sistema connessi: posizione, distanza, percorso.
12.4
Gestione del formato SVG sul cellulare
Altra possibile estensione riguarda la visualizzazione di mappe animate in formato
SVG[12], che riportano ad esempio, un percorso di un dispositivo.
Figura 12.1: Analisi del territorio
12.5 Configurazione dei dispositivi da monitorare
12.5
105
Configurazione dei dispositivi da monitorare
Per motivi di sicurezza un applet, non può accedere ai dati sul disco rigido del client
su cui sta girando, a meno che non sia certificata.
Certificando l’applet sarebbe possibile accedere a file locali al client in cui sono memorizzati i dispositivi da monitorare all’avvio. In questo modo non sarà
necessario al riavvio dell’applet riconfigurare il pannello di tracking.
12.6
Sicurezza
Gestire l’autenticazione degli utenti che si connettono al sistema tramite il cellulare.
Profilazione degli utenti tramite dispositivo mobile.
12.7
Gestione di eventi
Gestione di informazioni da e verso il cellulare riguardanti determinati eventi.
Per esempio sarebbe interessante inviare la propria posizione ad altri utenti connessi al sistema ed essere avvisati quando questi si trovano al di sotto di una distanza
prestabilita.
12.8
Modifica mappe dal cellulare
Invio informazioni agli utenti (telefoni cellulari) di carattere generale. Ad esempio,
in caso di blocchi temporanei di viabilità, si potrebbero avvisare gli altri utenti che
si trovano nella zona interessata.
12.9 Analisi del territorio
12.9
106
Analisi del territorio
Oltre agli strumenti atti alla navigazione stradale si potrebbe sfruttare la tecnologia
utilizzata dal sistema per effettuare la catalogazione di srutture.
Figura 12.2: Analisi del territorio
Un comune interessato a censire i semafori per esempio, potrebbe sfruttare la
possibilità della comunicazione con il cellulare per impostare le coordinate geografiche dei semafori, su un database per permetterne la visualizzazione su di una mappa
della zona interessata.
Parte III
Appendice
Capitolo 13
Software
13.1
Software e linguggio di programmazione
Linguaggio di sviluppo Java 5.0
Web Server Apache Tomcat 5.5
Database SQL MySQL Server 5
Piattaforma di sviluppo Eclipse 3.1
13.2
MIDP 2.0
Uno dei punti di forza del linguaggio di programmazione Java, è proprio la portabilità
e infatti anche sui dispositivi mobili è spesso presente una, seppura ridotta, JVM.
In particolare è stato introdotto il protocollo bluetooth non presente nella versione MIDP 1.0.
13.3 Sun Java Wireless Toolkit 2.3 Beta
13.3
109
Sun Java Wireless Toolkit 2.3 Beta
La “Sun Java Wireless Toolkit” è un insieme di strumenti per la creazione di applicazioni Java da eseguire su dispositivi mobili. Esso consiste di strumenti di sviluppo,
utility, e simulatori di dispositivi.
13.4
Tomcat 5
Ormai alla versione 5.x, è il web server più utilizzato per sviluppare applicazioni
web scritte in Java.
13.5
MySQL 5
È opensource, e una vasta gamma di sviluppatori e utilizzatori contribuisce giorno
per giorno alla sua diffusione e al suo miglioramento.
È stato scelto questo database sia per motivi “ideologici” che per motivi pratici.
Difatti esso, proprio grazie alla sua licenza, è diffusissimo come tipo di database e
ciò assicura affidabilità e un supporto notevole.
13.6
Eclipse
L’editor utilizzato per lo sviluppo è Eclipse 3.1. Basato su Java, grazie alla sua
espandibilità a plug-in e, anche in questo caso, al tipo di licenza aperta, è diffusissimo
dalla comunità di sviluppatori e può contare sulla presenza di migliaia di plug-ing.
13.6 Eclipse
13.6.1
110
Plug-in
Uno dei punti di forza di questo IDE di sviluppo è la sua estendibilità attraverso
plugin. In fase di sviluppo, infatti, numerosi sono stati i plugin utilizzati e altrettanti
i vantaggi derivati dal loro utilizzo.
Per lo sviluppo delle pagine JSP, il debugging, e la gestione di Tomcat sono
stati installati i plugin di Sysdeo1 . Per la redazione di diagrammi UML[15] è stato
utilizzato il plugin di Omondo2 .
Per lo sviluppo dei pannelli grafici è stato utlizzato il plugin Visual Editor.
Per lo sviluppo della MIDlet, EclipseME3 ha permesso di testare l’applicazione
direttamente nell’IDE.
1
inserire sito web
http://www.omondo.com - controllare
3
http://www.eclipseme.org
2
Bibliografia
[1] Burrogh P.A. 1986, Principles of geographical information systems for land
resource assessment,
Clarendon Press, Oxford, U.K, 194pp.
Mogorovich P., Mussio P. 1988, Automazione del Sistema Informativo
territoriale.
Elaborazione Automatica dei Dati Geografici, Masson, 1988. p.503-8 vol.2
[2] WGS 84 Implementation manual - EUROCONTROL e IfEN (1998)
[3] http://www.nmea.org (febbraio 2006)
[4] http://www.camiresearch.com/Data Com Basics/RS232 standard.html
(febbraio 2006)
[5] http://it.wikipedia.org/wiki/EIA-422 (febbraio 2006)
[6] “GPS signal structure and theoretical performance,” in Global Positioning System: Theory and Application, vol. I, B. W. Parkinson and J. J. Spilker, Jr.,
Eds. Washington, DC: American Institute of Aeronautics and Astronautics,
1996, ch. 3, pp. 57-120.
BIBLIOGRAFIA
112
[7] J. J. Spilker, Jr., “GPS signal structure and performance characteristics,”
Navigation: J. Inst. Navigation, vol. 25, no. 2, pp. 121-146, Summer 1978.
[8] D. A. Divis, “GLONASS emerges; Change in ISNS game plan,” GPS World,
vol. 7, no. 5, p. 12, May 1996.
[9] Sito web del progetto Galileo:
http://europa.eu.int/comm/dgs/energy transport/galileo/index en.htm (febbraio 2006)
[10] “ESRI Shapefile Technical Description,”
An ESRI White Paper, July 1998
[11] http://java.sun.com/products/midp/index.jsp (febbraio 2006)
[12] http://www.w3.org/Graphics/svg (febbraio 2006)
[13] http://www.ai.sri.com/geotransform/
[14] http://java.sun.com/blueprints/patterns/MVC.html (febbraio 2006)
[15] Sinan Si Alhir, “UML in a Nutshell”,
Oreilly
[16] Core J2ME Technology & MIDP
By John W. Muchow
Publisher : Prentice Hall PTR
Pub Date : December 21, 2001
Pages : 737
[17] J2ME in a Nutshell
Kim Topley
BIBLIOGRAFIA
Publisher: O’Reilly
Edition March 2002
478 pages
113
Elenco delle figure
2.1
Architettura di un software WebGIS . . . . . . . . . . . . . . . . . . 11
5.1
Disposizione dei satelliti . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2
Intersezione di tre sfere di raggio noto . . . . . . . . . . . . . . . . . . 31
5.3
Satelliti in orbita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4
Architettura di Galileo . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.1
Screenshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2
Struttura sviluppata . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.1
Logo di TimeMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.2
Database di TimeMap . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.3
Tabella generata per la memorizzazione di uno shapefile contenente
le strade di una città . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.4
Screenshot dell’applet . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8.1
Interfaccia di caricamento delle mappe . . . . . . . . . . . . . . . . . 57
9.1
Class diagram delle classi che mappano gli oggetti mobili . . . . . . . 63
9.2
Scheda dettagli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
9.3
Pannello di tracking
. . . . . . . . . . . . . . . . . . . . . . . . . . . 71
ELENCO DELLE FIGURE
115
9.4
Tracking di alcuni dispositivi contemporaneamente . . . . . . . . . . 73
9.5
Percorso di un oggetto mobile . . . . . . . . . . . . . . . . . . . . . . 77
9.6
Ricerca di un ricevitore GPS bluetooth . . . . . . . . . . . . . . . . . 79
9.7
Impostazione delle opzioni di connessione . . . . . . . . . . . . . . . . 80
9.8
Aggiornamento della propria posizione al server di tracking . . . . . . 82
10.1 Classi aggiunte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
10.2 Classi sviluppate per la MIDlet . . . . . . . . . . . . . . . . . . . . . 92
12.1 Analisi del territorio . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
12.2 Analisi del territorio . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Elenco delle tabelle
6.1
Funzionalità: I = Modificata e rivista, O = Originale, N = Nuova . . 44
8.1
Struttura della tabella history . . . . . . . . . . . . . . . . . . . . . . 55
8.2
Struttura della tabella registered . . . . . . . . . . . . . . . . . . . . 55
8.3
Structure of table autobus . . . . . . . . . . . . . . . . . . . . . . . . 56
Capitolo 14
Ulteriori informazioni
14.1
Infrastruttura utilizzata
Per le prove ed i test è stato utilizzato un telefonino Nokia 6630 ed un ricevitore
GPS Royal Tek dotato di processore Sirf III con 20 canali di ricezione.
14.2
Telefoni con ricevitori GPS
I telefoni con ricevitori GPS al momento (febbraio 2006) sul mercato sono:
• Samsung D500
• Motorola V545
• Motorola V980
• Motorola A1000
• Motorola E1000
14.3 Questo documento
14.3
118
Questo documento
Questo documento è stato impaginato in LATEX1 .
14.4
Sistema operativo
Sia durante la fase di sviluppo che di test, sono stati utilizzati, in modo completamente intercambiabile, sistemi operativi Linux o Windows. In articolare Debian
GNU/Linux (testing)2 e Microsoft Windows XP Professional3 . Tale intercambiabilità è stata possibile grazie all’utilizzo di un linguaggio di programmazione indipendente dalla piattaforma quale Java, e la disponibilità della macchina virtuale
per esso per entrambi i sistemi. L’utilizzo di software aggiuntivo opensource quali
Tomcat e MySql, ha poi reso completamente trasparente la scelta.
Bisogna però segnalare le differenza prestazionali riscontrate specie in fase di caricamento delle mappe GIS sulla base di dati. Su un sistema operativo Linux il tempo
impiegato è stato notevolmente inferiore rispetto al sistema operativo antagonista.
14.5
Browser web
Il browser web utilizzato è stato Mozilla Firefox 1.54 .
1
http://www.latex.org
http://www.debian.org
3
http://www.microsoft.com
4
www.mozilla.org
2

Tracking di dispositivi mobili in ambienti WebGIS

Documenti correlati

Prodotti

Supporto

Tracking di dispositivi mobili in ambienti WebGIS

Documenti correlati

Aggiungere questo documento alla raccolta (s)

Aggiungere questo documento salvato

Suggeriscici come migliorare StudyLib