1. UNIVERSITÀ DEGLI STUDI DI TRIESTE
Dipartimento di Ingegneria e Architettura
Corso di Laurea Triennale in Ingegneria Informatica
PROGETTO E REALIZZAZIONE DI
UN’APPLICAZIONE WEBGIS PER LA
VISUALIZZAZIONE DI EMISSIONI
INQUINANTI
Laureando: Relatore:
Diego HUSU Chiar.mo Prof.
Maurizio FERMEGLIA
Anno accademico 2011/2012

2. Indice
1. Introduzione ................................................................................................................. 1
2. Analisi e Design ............................................................................................................. 3
2.1 Cos’è il PRTR?.......................................................................................................... 3
2.2 Il PRTR dell’Università di Trieste ............................................................................. 3
2.3 Il database............................................................................................................... 6
2.4 Analisi dei requisiti.................................................................................................. 7
2.5 Le mappe di Google Maps ...................................................................................... 9
2.6 Design delle pagine ................................................................................................. 9
2.7 Struttura di file e cartelle...................................................................................... 11
3. Realizzazione............................................................................................................... 13
3.1 Struttura della homepage..................................................................................... 13
3.1.1 Intestazione HTML5 ....................................................................................... 13
3.1.2 Il corpo di index.html ..................................................................................... 15
3.1.3 Il foglio di stile index.css ................................................................................ 20
3.1.4 Il corpo di mobindex.html ............................................................................. 25
3.1.5 Il foglio di stile mobindex.css......................................................................... 27
3.2 Javascript .............................................................................................................. 30
3.2.1 L’inizializzazione............................................................................................. 31
3.2.2 Implementazione delle mappe...................................................................... 32
3.2.3 Il geocoding degli indirizzi ............................................................................. 35
3.2.4 Altre funzioni sulla gestione delle mappe ..................................................... 36
3.2.5 La funzione Submit ........................................................................................ 38
3.2.6 Le funzioni testInvio(e) .................................................................................. 40
3.3 La pagina di report ................................................................................................ 41
3.3.1 Il form per il report ........................................................................................ 42
3.4 Il file di configurazione web.config ....................................................................... 47
4. Conclusioni.................................................................................................................. 48
5. Bibliografia .................................................................................................................. 49
6. Ringraziamenti ............................................................................................................ 50

3. 1. Introduzione
Questa tesi tratta la progettazione e lo sviluppo di un’applicazione WebGIS atta alla
visualizzazione di dati relativi alle emissioni inquinanti presenti nel database PRTR
dell’Università degli Studi di Trieste.
L’obiettivo è la realizzazione di un’applicazione che permetta di elencare la quantità di
sostanze inquinanti emessa in una certa area geografica, rendendo il servizio fruibile a
tutti da più piattaforme in modo semplice e intuitivo.
Questo lavoro espande il sistema informativo già presente, aumentando le possibilità
di accesso ed estendendole, di fatto, a chiunque in qualsiasi momento, necessitando
semplicemente di un accesso a internet tramite un qualsiasi dispositivo dotato di
browser web. In particolare offre una funzionalità non presente sul sito già online: la
possibilità di eseguire query geografiche con l’aiuto di una mappa interattiva,
disponibile finora solo tramite applicazione Windows Phone 7.5 o Windows PC.
Il lavoro di sviluppo è stato svolto in varie fasi, qui di seguito elencate:
• Analisi del software esistente per l’accesso alla base dati
• Analisi dei requisiti dell’applicazione
• Definizione della struttura dell’applicazione e dei layout delle pagine
• Preparazione dell’ambiente di lavoro e installazione dei software necessari
• Analisi delle Stored Procedure e delle tabelle del database utili all’applicazione
• Studio ed implementazione del controllo di Google Maps
• Sviluppo dei campi del form e delle funzioni Javascript per l’interazione
automatica degli elementi della homepage
• Perfezionamento dello stile della homepage
• Studio ed implementazione degli elementi di ASP.NET necessari
all’applicazione, in particolare GridView, SqlDataSource e DropDownList
• Test in ambiente locale
• Pubblicazione sul web e test dopo la pubblicazione
1

4. Per la realizzazione si devono soddisfare determinati vincoli:
• L’applicazione deve implementare un controllo mappe interattivo, per facilitare
la selezione del range di ricerca.
• Deve essere raggiungibile e facilmente visualizzabile da personal computer,
smartphone e tablet.
• La progettazione deve considerare gli eventuali sviluppi e miglioramenti futuri
effettuati da altre persone, e rendere questo lavoro il più semplice possibile.
• L’applicazione dev’essere facilmente utilizzabile da ogni tipologia di utenza,
semplificando le interazioni e aumentando gli automatismi.
• Tutta l’interfaccia dev’essere in lingua inglese, e graficamente deve richiamare
lo stile del sito già esistente.
• Devono essere ridotte al minimo le ridondanze, per non appesantire l’utilizzo
all’utente comune.
Per raggiungere questo obiettivo, sono stati utilizzati i seguenti software:
• Microsoft Visual Studio 2012 Ultimate per la programmazione
• Microsoft SQL Server 2008 R2 Express per l’accesso al database esistente in
locale in fase di sviluppo
• Microsoft Access 2007 per avere un’interfaccia grafica migliore nell’analisi della
struttura dei dati di interesse per l’applicazione accedendo al database sul SQL
Server 2008 R2 Express
• Browser per testare le funzionalità in fase di sviluppo: Google Chrome, Mozilla
Firefox, Opera, Internet Explorer
L’utilizzo del software richiede un browser che supporti Javascript. Non è necessaria
alcuna registrazione e chiunque può già accedere ai contenuti liberamente da qualsiasi
parte del mondo tramite il nome http://prtrgis.units.it .
2

5. 2. Analisi e Design
2.1 Cos’è il PRTR?
PRTR è acronimo di Pollutant Release and Transfer Register. Sono database che
memorizzano i dati di emissioni inquinanti emesse nell’ambiente da impianti
industriali. Esistono diversi PRTR, come l’E-PRTR in Europa e il Toxics Release Inventory
negli Stati Uniti.
2.2 Il PRTR dell’Università di Trieste
L’Università degli Studi di Trieste, assieme all’organizzazione ICS-UNIDO, ha sviluppato
un PRTR che attualmente memorizza alcuni dati riguardanti le città di Alessandria
d’Egitto, Atene ed Ankara.
Il database è già accessibile tramite:
Sito web http://prtr.units.it
Applicazione per Windows Phone
Applicazione per Windows PC
Ognuna di queste applicazioni offre un report, strutturato in maniera diversa.
Il sito web offre una pagina di report dove è possibile selezionare facilities, sostanza
emessa e periodo di emissione. Selezionati i parametri, la pagina crea dei link in una
tabella. Nella colonna dei prodotti chimici inserisce il link (se disponibile) al sito
http://www.echemportal.org/ che specifica la sostanza oggetto dell’emissione. Nella
colonna delle facilities inserisce il link alla pagina della facility e nella colonna centrale
inserisce i link ai report corrispondenti alla richiesta effettuata.
3

6. Figura 2.2.1 – Ricerca report sul sito web http://prtr.units.it
.1
L’applicazione per Windows Phone implementa le mappe di bing per un’interfaccia
geografica, semplificata per una visualizzazione migliore su smartphone. L’app è
scaricabile gratuitamente dallo Store.
Figura 2.2.2 - Applicazione per Windows Phone
4

7. Infine, l’applicazione per PC Windows ha un funzionamento simile all’app per Windows
app
Phone, estendendo le informazioni fornite. Utilizza il plugin di Google Earth per una
, fornite.
visualizzazione geografica interattiva con controlli semplici e intuitivi.
zzazione
La navigazione è libera sulla mappa usando i controlli di Google Earth, o cercando un
indirizzo nell’apposito campo del geocoder.
Per fare una richiesta geografica al database è sufficiente disabilitare la navigazione
con l’apposito checkbox in basso a sinistra e cliccare su un punto della mappa, che sarà
sinistra
preso come il punto centrale del range di ricerca.
Figura 2.2 – Main screen della applicazione PC Windows
2.3
L’apertura di un’altra finestra ci permetterà di scegliere un periodo e un raggio in
’altra
chilometri, così da visualizzare i dati sulle sostanze inquinanti.
,
Cliccando poi su un agente chimico si visualizza un grafico rappresentante le quantità
emesse.
5

8. Figura 2.2.4 – Un esempio di visualizzazione delle emissioni con la applicazione per PC Windows
L’obiettivo di questo progetto è estendere questo metodo di accesso ai dati tramite un
software GIS, rendendolo accessibile a chiunque via web.
2.3 Il database
I dati presenti nel database PRTR dell’Università degli Studi di Trieste sono organizzati
gli
in una struttura comprendente più di 100 tabelle, altrettante viste e più di 200 Stored
Procedure.
Tuttavia, ai fini della nostra applicazione sarà utile solo una piccola parte.
applicazione
6

9. In particolare:
• La tabella ReportPeriod, e i suoi campi
o ID, numero intero identificativo del periodo
o Title, stringa descrittiva del periodo, ad esempio “Year 2000”.
• La Stored Procedure “Statistics_GetByRegion”, che fornisce tutte le emissioni
inquinanti nel range di ricerca, elencate per sostanza e distinte per elemento
dell’ambiente inquinato. Essa richiede i parametri:
o Latitudine del centro dell’area di ricerca, secondo il sistema
sessagesimale con valori interi
o Longitudine del centro dell’area di ricerca, con medesime caratteristiche
o Raggio dell’area, intero e in chilometri
o CultureCode, identificativo della lingua (per noi impostato a en-US)
o Periodo, identificato tramite l’ID numerico.
• La funzione “GetDistance”, chiamata dalla Stored Procedure. Dati due punti a
latitudine e longitudine conosciute, essa ne calcola la distanza. Approssima la
terra ad una sfera di raggio 6371Km e usa un semplice algoritmo per il calcolo
della distanza di due punti sulla superficie della sfera.
2.4 Analisi dei requisiti
Si vuole realizzare un software per implementare una nuova funzione, e rendere il
servizio di ricerca delle emissioni inquinanti tramite software GIS accessibile a tutti gli
utenti.
Si è scelto di utilizzare la piattaforma web per l’accesso, costruendo un nuovo sito con
l’obiettivo di renderlo usufruibile dall’utente comune.
Per questo motivo, il fine principale e prioritario è la semplicità di utilizzo.
Il sito deve innanzitutto essere accessibile sia da computer che da smartphone o
tablet. Deve offrire un’interfaccia simile all’applicazione per PC Windows, inserendo
7

10. una mappa con dei controlli semplici per selezionare il centro dell’area di ricerca delle
emissioni.
È necessario un campo per il geocoding degli indirizzi, una funzione di
geolocalizzazione e controlli automatici per semplificare e velocizzare l’interazione
dell’utente.
Tramite un form si dovranno inserire latitudine, longitudine e range di ricerca.
La struttura richiesta è una divisione in 3 pagine:
La home page per la visualizzazione da computer
La home page per la visualizzazione da smartphone
La pagina di generazione del report
La pagina di generazione del report dev’essere scritta in linguaggio ASP.NET, le altre in
HTML5 con dei controlli in Javascript.
Le funzioni di Javascript devono essere inserite in un’unico file. Invece per gli
stilesheets saranno necessari 3 file separati, uno per ogni pagina.
Lo stile visivo del sito deve richiamare il sito già esistente. In entrambi dev’essere
inserito un link che permetta di passare dalla vecchia alla nuova applicazione e
viceversa.
Nel report si visualizzano solo le informazioni essenziali.
Lo scopo è far accedere un target molto vasto di persone, mettendole a conoscenza, il
più semplicemente possibile, della quantità di sostanze emesse in una determinata
località.
Si deve disporre di una tabella con il nome dell’agente inquinante e le quantità di
emissioni di quell’agente, divise per luogo di rilascio e con una colonna che indichi la
quantità totale rilasciata nel periodo.
8

11. 2.5 Le mappe di Google Maps
La scelta del controllo mappe da inserire nell’applicazione è caduta su Google Maps,
sicuramente il più utilizzato. Sul web è fornita una documentazione1 dettagliata
sull’uso di tutti gli oggetti disponibili sulle varie piattaforme di sviluppo.
Le API di Google Maps offrono un’ampia possibilità di modifica dell’interfaccia,
inserendo o rimuovendo controlli con estrema facilità.
Sono implementabili in un’applicazione Web tramite l’uso di codice Javascript.
2.6 Design delle pagine
Le due versioni della home si distingueranno per un diverso posizionamento degli
oggetti della pagina.
Nella versione per l’accesso da PC solitamente abbiamo un monitor con la base
orizzontale di dimensioni maggiori rispetto alla verticale.
Sui dispositivi mobili i rapporti invece sono invertiti, anche se sui prodotti di nuova
generazione possono essere ruotati in base alle indicazioni dell’accelerometro e
disporsi quindi in modalità Landscape, cioè con l’orizzontale sul lato più lungo.
Le risoluzioni possono comunque essere inferiori su molti dispositivi.
Alla luce di queste considerazioni si è deciso di impostare le visualizzazioni come
indicato nei schemi delle due figure.
Nella versione per calcolatore, avremo una disposizione che tenga conto della
risoluzione orizzontale maggiore, con il posizionamento, sotto la barra del titolo, della
mappa a destra per una larghezza del 60% del corpo della pagina, mentre a sinistra
1
La documentazione per l’implementazione con codice javascript è disponibile all’indirizzo
https://developers.google.com/maps/documentation/javascript/
9

12. saranno presenti i campi editabili per le richieste al servizio di geocoding e per le query
al database.
Figura 2.6.1 – Schema per il design della home page da PC
Nella versione mobile, invece, la struttura è più verticale, con la mappa estesa a tutta
la larghezza del corpo. Sotto di essa i campi per il geocoding e la query.
Figura 2.6.2 – Schema per il design della home page da dispositivo mobile
10

13. La pagine di report infine ha una struttura più semplice.
Sotto il titolo si posiziona un campo per la selezione del periodo di ricerca, e in basso si
dispone la tabella che raccoglie i dati di risposta della query.
Figura 2.6.3 - Schema per il design della pagina di report
2.7 Struttura di file e cartelle
La struttura del sito è rappresentata in figura 2.7.1.
Nella root directory sono incluse le 3 pagine del sito, più i file contenenti il codice
associato in Javascript e C# e il file web.config per la configurazione della stringa di
connessione.
Sono presenti 2 subdirectory:
• Css, contenente i fogli di stile per le pagine
• Pics, contenente tutte le immagini utili al sito.
L’accesso al sito, schematizzato in figura 2.7.2, si effettua sulla pagina index.html. In
caso di accesso da mobile il reindirizzamento è automatico a mobindex.html.
Entrambe le versioni della home infine indirizzano a report.aspx per la visualizzazione
dei dati.
11

14. Figura 2.7.1 – Struttura del sito
Figura 2.7.2 – Accesso al sito
12

15. 3. Realizzazione
Lo sviluppo è partito dallo studio e l’implementazione delle mappe di Google.
Per la loro gestione si è utilizzato il linguaggio Javascript.
Successivamente si è completata la versione per computer della home page del sito,
dapprima con l’inserimento dei campi del form per la query, poi il campo per il
geocoding e infine implementando i controlli automatici.
Finite di implementare le funzionalità della homepage, è stata perfezionata tramite
modifiche al file CSS associato per allineare bene gli elementi.
Terminata la pagina principale si è sviluppata la versione mobile partendo dalla pagina
appena sviluppata.
Perfezionata quest’ultima è stata scritta la pagina di report in ASP.NET, seguendo una
metodologia analoga alle precedenti, cioè completando prima l’aspetto funzionale e
poi quello estetico.
Ogni passaggio è stato accompagnato da una serie di test funzionali, come anche al
completamento dell’applicazione. Dopo la pubblicazione si sono eseguiti altri test
funzionali e si son fatti eseguire anche ad altre persone per verificarne la facilità di
utilizzo.
Tutto il codice descritto in questo documento è stato scritto dal laureando.
3.1 Struttura della homepage
3.1.1 Intestazione HTML5
L’intestazione HTML5 nelle due versioni della homepage è pressochè identica. Infatti
cambia solo il riferimento al foglio di stile.
13

16. L’intestazione della homepage per l’accesso da PC è rappresentata nella figura
seguente.
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<link rel="shortcut icon" href="/Pics/icon.ico" />
<title>Pollutant Release and Transfer Register</title>
<link rel="stylesheet" type="text/css" href="Css/index.css"/>
<script type="text/javascript"
src="http://maps.google.com/maps/api/js?sensor=false"></script>
<script type="text/javascript" src="JavaScript.js"></script>
</head>
[...body...]
</html>
Figura 3.1.1.1 – Intestazione della pagina index.html
Nel documento per la versione mobile cambia solo il link al foglio di stile:
<link rel="stylesheet" type="text/css" href="Css/mobindex.css"/>
Figura 3.1.1.2 – Riferimento al foglio di stile in mobindex.html
Identifichiamo la dichiarazione del DOCTYPE nella prima riga.
Tra i tag <head> e </head> troviamo i link ai fogli di stile di tipo text/css, all’icona
“shortcut icon” che appare nel browser vicino al titolo della pagina. Quest’ultimo è
anch’esso presente nel tag <title> ed è quindi “Pollutant Release and Transfer
Register”.
I due tag <script> identificano le componenti Javascript della pagina. La prima, con
src="http://maps.google.com/maps/api/js?sensor=false" richiama le API di Google
Maps, la seconda invece include il file Javascript.js creato per contenere tutte le
funzioni di Javascript.
14

17. 3.1.2 Il corpo di index.html
Verticalmente, la pagina è divisa in 5 div html:
• titlediv
• menu
• mapformdiv
• legenddiv
• footdiv
<body onload="testBrowser()">
<div id="titlediv">
[…]
</div>
<div id="menu">
[…]
</div>
<div id="mapformdiv">
[…]
</div>
<div id="legenddiv">
[…]
</div>
<div id="footdiv">
[…]
</div>
</body>
Figura 3.1.2.1 – Disposizione dei div nel body di index.html
All’accesso alla pagina viene chiamata la funzione Javascript testBrowser() che verrà
analizzata nel capitolo dedicato alle funzioni Javascript.
Il div con id titlediv contiene al suo interno altri due div:
• imgleft
• imgright
che contentogno al loro interno le due immagini posizionate, rispettivamente, a
sinistra e a destra del titolo.
Quest’ultimo è scritto semplicemente tra i 2.
15

18. Allineamento, scelta e dimensione del carattere e tutte le impostazioni di stile sono
scritte nel relativo file CSS, descritto nel capitolo seguente.
<div id="titlediv">
<div id="imgleft">
<img src="Pics/ICSUNIDO.gif" id="Img1" alt="Logo UNIDO" />
</div>
Pollutant Release and Transfer Register
<div id="imgright">
<img src="Pics/UNEP-MAP-small.gif" id="Img2" alt="Logo UNEP/MAP" />
</div>
</div>
Figura 3.1.2.2 – Codice e visualizzazione del div titlediv
Il div menu è inserito richiamando il menù del sito già esistente. Ho inserito solo un link
alla homepage del sito già esistente del PRTR dell’Università degli studi di Trieste. Lo
stile è lo stesso di quest’ultimo.
<div id="menu">
<a href="http://prtr.units.it">
PRTR full site <img src="Pics/WebResource.gif" />
</a>
</div>
Figura 3.1.2.3 – Codice e visualizzazione del div menudiv
Il div mapformdiv è suddiviso orizzontalmente in 2 div:
• formdiv
• mapdiv
Il primo è a sua volta suddiviso verticalmente in altri 3 elementi:
• addsearch
• formtitdiv
• qform
16

19. L’altro invece è creato per accogliere l’oggetto mappa al suo interno.
<div id="mapformdiv">
<div id="formdiv">
<div id="addsearch">
[…]
</div>
<div id="formtitdiv">
[…]
</div>
<div id="qform">
[…]
</div>
</div>
<div id="mapdiv">
<div id="map" style="width:100%;height:100%;">
</div>
</div>
</div>
Figura 3.1.2.4 – Codice del div mapformdiv
Figura 3.1.2.5 – Visualizzazione del div mapformdiv
Il div addsearch presenta un’etichetta associata all’input address di tipo text, il campo
dove è possibile inserire un indirizzo per il geocoding. Alla pressione di un tasto si
chiama la funzione Javascript testInvio(event) che verrà analizzata in seguito.
17

20. <div id="addsearch">
<label for="address">Search an address on map:</label>
<br />
<input id="address" name="address" type="text" placeholder="Address"
onkeypress="testInvio(event)" />
<input id="subadd" name="subadd" title="Search" value="Search" type="image"
src="Pics/search.png" onclick="codeAddress()" />
<input id="showme" name="showme" title="Show my position"
value="Show my position" type="button" onclick="retmypos()" />
</div>
Figura 3.1.2.6 – Codice del div addsearch
Gli altri due input sono pulsanti. Il pulsante subadd invia la richiesta di geocoding e
viene visualizzato come l’immagine presente nell’attributo src, il pulsante showme
invece riporta la mappa allo stato di partenza.
Il div formtitdiv contiene solo una stringa che fa da etichetta al form sottostante.
<div id="formtitdiv">
<b>Query details:</b>
</div>
Figura 3.1.2.7 – Codice del div formtitdiv
Il div qform contiene al suo interno il form da compilare per identificare l’area
geografica di ricerca, consentendo l’impostazione di Latitudine e Longitudine del
centro dell’area, e il raggio in Km della stessa.
Ognuno di questi campi è caratterizzato da un’etichetta che lo identifica e un campo
text per l’inserimento dei valori. I controlli sui campi vengono effettuati con apposite
funzioni Javascript.
Sui campi latitudine e longitudine è presente un controllo simile a quello presente nel
campo testuale per il geocoding. Analizza se è stato premuto il tasto Invio e, in quel
caso, posiziona la mappa con il centro sulle coordinate presenti nei campi.
Allo stesso modo, la pressione del tasto Invio nel campo Range porta alla pagina di
report come la pressione del pulsante Search Data presente sotto di esso.
18

21. <div id="qform">
<form id="queryform" name="queryform" >
<label for="latit">Latitude:</label>
<input id="latit" name="latit" type="text" placeholder="Latitudine"
required="required" onkeypress="testInvio3(event)"
onchange="chglatlng()" />
<br />
<label for="longit">Longitude:</label>
<input id="longit" name="longit" type="text" placeholder="Longitudine"
required="required" onkeypress="testInvio3(event)"
onchange="chglatlng()" />
<br />
<label for="range">Range (km):</label>
<input id="range" name="range" type="text" placeholder="Range"
required="required" onkeypress="testInvio2(event)" />
<br />
<input id="subque" type="button" value="Search data" onclick="Submit()"/>
<br />
</form>
</div>
Figura 3.1.2.8 – Codice del div qform
Per rendere più comprensibile l’interfaccia si è inserito un div legenddiv contenente
una semplice istruzione che aiuti l’utente nell’utilizzo della stessa.
<div id="legenddiv">
Searching an address or clicking a point on the map sets Latitude and
Longitude. Changing Latitude and Longitude values shows that point on the map.
</div>
Figura 3.1.2.9 – Il div legenddiv
Infine, il div footdiv contiene il copyright inserito e stilizzato come nel sito già esistente.
<div id="footdiv">
Copyright © 2008 United Nations Industrial Development Organization
</div>
Figura 3.1.2.10 – Codice e visualizzazione del div footdiv
19

22. 3.1.3 Il foglio di stile index.css
Questo foglio di stile è associato alla pagina index.html.
Abbiamo delle caratteristiche generali scritte all’inizio del file. Riguardano un piccolo
aggiustamento eseguito per la differenza di interpretazione del codice da parte di
alcuni browser che di default avevano dei parametri che influivano sullo stile visivo di
alcuni elementi, posizionandoli erroneamente.
A questo è dovuta la regola img che imposta margin e border a 0 per tutte le immagini.
Per lo stesso motivo è stato necessario impostare l’allineamento degli input per una
visualizzazione migliore.
img {
margin:0;
border:0;
}
input {
vertical-align:bottom;
margin-right:4px;
margin-left:4px;
}
Figura 3.1.3.1 – La regola per immagini e input di index.html
I link, presenti nel menù, sono regolati dalle seguenti regole, che impostano il colore
degli stessi per renderli visivamente uguali al sito già esistent.
a:link {color:#FFFFC0; text-decoration:none}
a:visited {color: #FFFFC0; text-decoration:none}
a:hover {color:#FFFFC0;}
a:active {color:#FFFFC0;}
Figura 3.1.3.2 – Regole per i link
Regole sono definite anche per il body, con larghezza del 100% per un minimo di 820
pixel, valore minimo necessario ad una visualizzazione corretta della pagina. Altezza
con regolazione automatica, testo allineato al centro, margine nullo in alto, sfondo
bianco e margini laterali automatici.
20

23. body {
width:100%;
height:auto;
min-width:820px;
text-align:center;
margin-left:auto;
margin-right:auto;
margin-top:0px;
background-color:#ffffff;
}
Figura 3.1.3.3 – Regole per il corpo della pagina index.html
Seguono le regole per i div. Ognuno ha la propria regola per definirne carattere,
allineamenti, margini, colori e tutto il necessario.
Il titlediv imposta il carattere al suo interno in Arial a una dimensione di 25 pixel,
definisce i propri margini e una larghezza del 100% per un’altezza fissata a 36 pixel.
Al suo interno, imgleft e imgright definiscono i propri margini e, tramite la regola float,
il loro allineamento, rispettivamente a sinistra e a destra, all’interno del loro
contenitore.
#titlediv {
width:100%;
height:36px;
margin-left:auto;
margin-right:auto;
margin-top:0px;
margin-bottom:0px;
font:25px Arial;
vertical-align:middle;
}
#imgleft {
float:left;
margin-left:3px;
margin-top:3px;
}
#imgright {
float:right;
margin-right: 3px;
margin-top:0px;
}
Figura 3.1.3.4 – Regole per il div titlediv e i suoi interni imgleft e imgright
21

24. Il div menu imposta il colore dello sfondo al suo interno per renderlo identico al menù
del sito esistente. Imposta l’allineamento del testo al centro, con un carattere Arial di
13 pixel. Le dimensioni orizzontali sono del 100% e l’altezza gestita automaticamente.
#menu {
background-color:#92A9B4;
width: 100%;
height: auto;
text-align:center;
font:13px arial;
}
Figura 3.1.3.5 – Regole per il div menu
Il div mapformdiv ha larghezza del 100%, e un’altezza fissata a 450 pixel. Lascia 10 pixel
di margine rispetto al menu.
#mapformdiv {
width:100%;
height:450px;
margin-top:10px;
background-color:#ffffff;
}
Figura 3.1.3.6 – Regole per il div mapformdiv
Al suo interno, formdiv si posiziona a sinistra, con testo allineato al centro e una
larghezza ridotta a 39% rispetto al suo contenitore. L’altezza invece è del 100%.
#formdiv {
width:39%;
height:100%;
float:left;
text-align:center;
}
Figura 3.1.3.7 – Regole per formdiv
Al suo interno, tutti gli elementi sono allineati a sinistra per una visualizzazione
corretta. Gli altri parametri servono ad inquadrare bene i vari elementi per dare una
disposizione dinamica e sempre piacevole da vedere.
22

25. #addsearch {
width:100%;
height:100px;
text-align:center;
float:left;
}
#formtitdiv {
width: 75%;
height: 40px;
text-align:center;
float:left;
}
#qform {
width:80%;
height:200px;
float:left;
}
Figura 3.1.3.8 – Regole per formdiv e i suoi div interni
Il form ha anch’esso delle caratteristiche di stile, regolate dal codice in figura seguente.
É stato necessario definire questa regola per avere allineati a destra i campi del form.
form#queryform {
width:100%;
height:100%;
text-align:right;
}
Figura 3.1.3.9 – Regole per il form queryform
Il mapdiv contiene la mappa. Ha una larghezza del 59% rispetto al mapformdiv. Viene
allineato a destra a meno di un piccolo margine di 10 pixel per un puro fatto estetico.
#mapdiv {
width:59%;
height:100%;
float:right;
margin-right:10px;
}
Figura 3.1.3.10 – Regole definite per il div contenente la mappa
Il legenddiv compare al di sotto di mappa e form, col testo posizionato centralmente.
Viene lasciato un po’ di margine superiore, e il testo è in Arial a 12px.
23

26. #legenddiv {
width:100%;
height:auto;
margin-top:10px;
text-align:center;
font: 12px Arial;
}
Figura 3.1.3.11 – Regole per legenddiv
Per ultimo, footdiv è stilizzato secondo le seguenti regole:
#footdiv {
width: 100%;
height: auto;
background-color:#FFFFC0;
text-align:center;
font:13px arial;
margin-top:20px;
}
Figura 3.1.3.12 – Regole per footdiv
Vengono infine definite delle semplici regole dimensionali per i vari input presenti
nella pagina. Vengono tutti trattati singolarmente.
Queste semplici regole non fanno altro che regolare le dimensioni dei vari pulsanti.
#submit {
width:100px;
height:29px;
}
#subadd {
width:29px;
height:29px;
margin:0px;
}
#showme {
width:130px;
height:29px;
margin-top:5px;
}
Figura 3.1.3.13 – Regole per i pulsanti di index.html
24

27. Sugli input di tipo text, invece, si è regolata l’altezza del campo address, e i margini
degli altri 3 per distanziarli tra loro e rendere il form visivamente più piacevole. Senza
quest’impostazione infatti browser come Internet Explorer o Firefox non lasciavano
alcun margine tra gli stessi.
#address {
height:23px;
}
#latit, #longit, #range {
margin-top: 2px;
margin-bottom: 2px;
}
Figura 3.1.3.14 – Regole per gli input di tipo text in index.html
3.1.4 Il corpo di mobindex.html
La pagina per browser di dispositivi mobile è divisa verticalmente similmente alla
versione per computer. Abbiamo 4 div:
• titlediv
• menu
• mapformdiv
• footdiv
<body onload="initialize()">
<div id="titlediv">
[…]
</div>
<div id="menu">
[…]
</div>
<div id="mapformdiv">
[…]
</div>
<div id="footdiv">
[…]
</div>
</body>
Figura 3.1.4.1 – Disposizione dei div nel body di mobindex.html
25

28. Qui la funzione Javascript eseguita all’accesso alla pagina non è la stessa di index.html.
Questo è dovuto al fatto che in questa vizualizzazione non si esegue un controllo sul
browser utilizzato. Maggiori dettagli nel capitolo 3.2 dedicato a Javascript.
Gli elementi titlediv, menu e footdiv sono uguali al documento index.html e sono già
stati analizzati nel capitolo 3.1.2.
Invece mapformdiv presenta un cambiamento piuttosto sostanziale nella disposizione
degli elementi, adeguandolo allo schema di figura 2.6.2.
Nel codice HTML5 questo si nota relativamente poco.
I div mapdiv e formdiv sono invertiti di posizione.
Tra di loro spunta legenddiv che posiziona le istruzioni sotto la mappa.
Il codice interno a tutti gli elementi è uguale alla versione index.html, si rimanda a
quanto già analizzato nel capitolo 3.1.1 per vederne il codice nel dettaglio.
Nella figura 3.1.4.3 si vede come appare diversamente questo elemento rispetto alla
versione per computer.
<div id="mapformdiv">
<div id="mapdiv">
[…]
</div>
<div id="legenddiv">
[…]
</div>
<div id="formdiv">
<div id="addsearch">
[…]
</div>
<div id="formtitdiv">
[…]
</div>
<div id="qform">
[…]
</div>
</div>
</div>
Figura 3.1.4.2 – Struttura di mapformdiv
26

29. Figura 3.1.4.3 – Visualizzazione di mapformdiv per dispositivi mobili
3.1.5 Il foglio di stile mobindex.css
Le modifiche apportate nella visualizzazione per browser mobili si notano di più nel
foglio di stile.
Le regole per immagini e link sono identiche ad index.css rimando al capitolo 3.1.3 per
index.css,
l’analisi delle stesse.
Le regole per il body cambiano leggermente. La larghezza minima è ora impostata a
680 pixel e si pone la grandezza del carattere Arial a 25 pixel. Le altre caratteristiche
rimangono invariate.
27

30. Il titlediv ingrandisce il carattere, maggiorandolo di ulteriori 3 pixel rispetto alla
versione per PC della pagina. Al suo interno, imgleft e imgright mantengono le
medesime regole viste nel capitolo 3.1.3.
Anche il div menu è pressochè uguale al precedente, e anche qui cambia solo il
carattere, leggermente più grande e posto a 16 pixel. Il mapformdiv cambia invece solo
l’altezza, che viene regolata automaticamente.
All’interno di quest’ultimo ci sono i cambiamenti più sostanziali. mapdiv infatti ora è
posto in alto, sopra agli altri elementi, con una larghezza pari al 90% e un’altezza fissa a
350 pixel. Margini destro e sinistro sono gestiti in automatico, per un posizionamento
centrale, mentre in alto vengono lasciati 10 pixel di margine.
#mapdiv {
width:90%;
height:350px;
margin-top:10px;
margin-left:auto;
margin-right:auto;
}
Figura 3.1.5.1 – Regole per mapdiv
Sotto alla mappa, legenddiv ha una larghezza pari al 100%, il testo viene allineato
centralmente e ridimensionato a 16 pixel, sempre con font Arial. Anche qui un margine
di 20 pixel lo distanzia dall’elemento superiore.
#legenddiv {
width:100%;
height:30px;
margin-top:20px;
text-align:center;
font: 16px Arial;
}
Figura 3.1.5.2 – Regole per legenddiv
formdiv si posiziona sotto al precedente. La sua larghezza è regolata al 100%, il testo
viene allineato al centro e l’altezza viene gestita in automatico.
Viene lasciato un margine superiore di 15 pixel.
28

31. #formdiv {
width:100%;
height:auto;
float:left;
text-align:center;
margin-top:15px;
background-color:#ffffff;
}
Figura 3.1.5.3 – Regole per “formdiv”
I div interni hanno tutti impostato un margine superiore non nullo, pari a 15, 35 e 10
pixel in addsearch, formtitdiv e qform, che hanno rispettivamente altezze di 100, 50 e
400 pixel. I primi 2 hanno larghezza del 100% mentre l’ultimo l’ha fissata a 345 pixel ed
è posto in posizione centrale. Al suo interno, il form queryform ha il testo allineato a
destra, larghezza del 100% e altezza regolata in automatico.
#addsearch {
width:100%;
height:100px;
text-align:center;
float:left;
margin-top:15px;
}
#formtitdiv {
width: 100%;
height: 50px;
text-align:center;
float: left;
margin-top:35px;
}
#qform {
width:345px;
height:400px;
margin-top:10px;
text-align:center;
margin-left:auto;
margin-right:auto;
}
form#queryform {
width:100%;
height:auto;
text-align:right;
}
Figura 3.5.1.4 – Regole per gli oggetti interni a “formdiv”
29

32. Infine, footdiv non cambia rispetto alla versione esaminata nel capitolo 3.1.3, se non
per un margine superiore maggiore che in questo caso è pari a 50 pixel.
I pulsanti e gli input di tipo text hanno le medesime regole già viste per index.css.
3.2 Javascript
Il codice Javascript è interamente incluso in un file, unico per entrambe le versioni
della homepage, chiamato Javascript.js e richiamato dalla stringa seguente, inserita nei
tag <head> delle pagine.
<script type="text/javascript" src="JavaScript.js"></script>
Figura 3.2.1 – Stringa di collegamento del file Javascript.js nelle pagine HTML5 che lo utilizzano
Come visto nei capitoli precedenti, nelle due homepage abbiamo due funzioni diverse
chiamate al momento dell’accesso.
<body onload="testBrowser()">
<body onload="initialize()">
Figura 3.2.2 – Chiamata delle funzioni appropriate all’apertura della home
Queste stringe impongono, all’apertura della pagina, l’esecuzione della funzione
Javascript adatta. Essa è testBrowser() in index.html e initialize() per la pagina
mobindex.html.
La funzione testBrowser() altro non fa che analizzare l’useragent per conoscere il
browser utilizzato, e se si necessita quindi della visualizzazione per PC o della versione
per smartphone.
In caso riconosca la stringa ‘Mobile’ all’interno di esso, passa alla versione per
smartphone ed interrompe ogni operazione. L’interruzione forzata è stata necessaria
30

33. per risolvere un piccolo bug legato alla doppia richiesta di geolocalizzazione in caso di
accesso da smartphone.
Fatto ciò, se non viene interrotta per i motivi sopracitati, la funzione chiama initialize()
per far partire l’inizializzazione della pagina.
function testBrowser() {
var useragent = navigator.userAgent;
if (useragent.indexOf('Mobile') != -1) {
location = "mobindex.html";
return;
}
initialize();
}
Figura 3.2.3 – La funzione testBrowser()
In Javascript.js abbiamo 2 variabili definite globalmente, map e mylatlng. Queste due
variabili vengono utilizzate da più funzioni, e la prima rappresenta l’oggetto mappa di
Google Maps, la seconda è un oggetto della classe LatLng di Google Maps che conterrà
le coordinate della posizione dell’utente, se è possibile individuarle. Nel caso non fosse
possibile saranno inserite le coordinate di Piazzale Europa dove è sito il campus
dell’Università degli Studi di Trieste.
var map;
var myLatLng;
Figura 3.2.4 – Le variabili globali di Javascript.js
3.2.1 L’inizializzazione
La funzione initialize() inizia a lavorare sulle funzionalità geografiche. Prima di tutto
crea le variabili lat e lng per salvare i valori di latitudine e longitudine, darle il valore
preimpostato con le coordinate del campus dell’Università di Trieste come deciso in
fase di progettazione e poi provare la geolocalizzazione.
Se la geolocalizzazione va a termine, chiama la funzione showPosition() che salva le
coordinate ottenute nelle apposite variabili.
31

34. Infine, pone il focus sul campo address, quello dedicato al geocoding. Così, da pc,
all’apertura della pagina si può già inserire un indirizzo da tastiera senza l’uso del
mouse per selezionarlo.
function initialize() {
var lat = 45.658069;
var lng = 13.792465;
if (navigator.geolocation) {
// browser con supporto per la geolocalizzazione
navigator.geolocation.getCurrentPosition(showPosition);
} else {
// nessun supporto alla geolocalizzazione
// restituisce un alert con errore
alert("Error while trying to find your location. nPlease check your
settings and allow location services.");
createMap(lat, lng);
}
document.getElementById("address").focus();
}
Figura 3.2.1.1 – Funzione initialize()
La funzione showPosition(position) chiamata salva le coordinate della posizione
rilevata nelle variabili predisposte e passa questi valori alla funzione che crea la mappa
sulla pagina web: la funzione createMap(lat,lng).
function showPosition(position) {
lat = position.coords.latitude;
lng = position.coords.longitude;
createMap(lat, lng);
}
Figura 3.2.1.2 – Funzione showPosition(position)
3.2.2 Implementazione delle mappe
L’oggetto map è l’elemento principale che crea la mappa.
32

35. map = new google.maps.Map(document.getElementById("map"), myOptions);
Figura 3.2.2.1 – La stringa di crazione della mappa
Viene creata come oggetto Map di Google Maps grazie ai due parametri tra parentesi.
Il primo è il div dove verrà posizionata la mappa. Il secondo, myOptions, contiene le
impostazioni della stessa ed è rappresentato nella figura seguente.
var myOptions = {
zoom: 15, // Fattore di Zoom
center: mylatlng, // Coordinate
mapTypeId: google.maps.MapTypeId.HYBRID, //Tipo di mappa
zoomControl: true, //Controlli di Google Maps, true: attivi, false:
//disattivi
scaleControl: true,
panControl: false,
mapTypeControl: false,
streetViewControl: false,
rotateControl: false,
overviewMapControl: false
};
Figura 3.2.2.2 – L’oggetto MyOptions
Tutte le impostazioni della mappa sono regolate da questo oggetto.
Imposta il posizionamento iniziale con i parametri zoom e center. MapTypeId imposta
il tipo di visualizzazione della mappa, nelle impostazioni tipiche di Google Maps:
Satellite, Roadmap o Ibrida. Nell’applicazione si è scelta l’opzione ibrida, con vista da
satellite e indicazione delle strade.
Gli altri parametri sono di tipo boolean, e rappresentano i controlli attivabili sulla
mappa. Nell’applicazione ho lasciato inseriti solo il controllo relativo allo zoom, che si
presenta in formato esteso nella versione per computer e in formato ridotto nella
versione mobile, e l’indicazione della scala.
Il codice finora analizzato in questo capitolo è incluso nella funzione Javascript
createMap(lat,lng).
La funzione viene chiamata con le coordinate del punto al centro della mappa.
33

36. Queste coordinate vanno a creare l’oggetto mylatlng della classe LatLng di Google
Maps.
La funzione posiziona anche un marker nel centro della mappa, se le coordinate sono
diverse dal valore preimpostato. Nel caso siano uguali infatti indicherebbe che non si è
potuto geolocalizzare l’utente e il marker diventa inutile.
function createMap(lat, lng) {
mylatlng = new google.maps.LatLng(lat, lng);
var myOptions {
[…]
};
map = new google.maps.Map(document.getElementById("map"), myOptions);
if (lat != 45.658069 || lng != 13.792465) {
var marker = new google.maps.Marker({
position: mylatlng,
map: map,
title: 'Your location'
});
}
saveLatLng(mylatlng);
google.maps.event.addListener(map, 'click', function (event) {
//Inserisce nel form Lat e Lng dei punti cliccati sulla mappa
saveLatLng(event.latLng);
});
}
Figura 3.2.2.3 – La funzione createMap(lat,lng)
Si mette infine l’applicazione in ascolto di eventuali eventi legati al click del mouse col
puntatore sulla mappa.
Tramite l’evento addListener si specifica la funzione da chiamare in caso di ‘click’
sull’oggetto map: la funzione saveLatLng(location).
Tramite questa funzione abbiamo il primo controllo automatico dei campi del form.
Infatti essa, chiamata in fase di creazione della mappa, inserisce subito dei valori nei
campi.
34

37. In latitudine e longitudine inserisce i valori delle coordinate della location passata
come parametro, approssimati a 4 cifre decimali. Nel campo range invece inserisce il
valore ‘30’ se in quel momento non è presente nessun valore.
function saveLatLng(location) { //Inserisce nel form Lat e Lng della location
var Latitude = location.lat().toFixed(4);
var Longitude = location.lng().toFixed(4);
document.queryform.latit.value = Latitude;
document.queryform.longit.value = Longitude;
if (document.queryform.range.value == "") {
document.queryform.range.value = '30';
}
}
Figura 3.2.2.4 – La funzione saveLatLng(location)
3.2.3 Il geocoding degli indirizzi
Le richieste di geocoding vengono gestite dalla funzione Javascript codeAddress().
Questa funzione viene chiamata premendo il pulsante di ricerca o premendo Invio nel
campo address.
Crea la variabile address dove salva il contenuto del campo apposito.
function codeAddress() {
geocoder = new google.maps.Geocoder();
var address = document.getElementById("address").value;
geocoder.geocode({ 'address': address }, function (results, status) {
if (status == google.maps.GeocoderStatus.OK) {
map.setCenter(results[0].geometry.location);
saveLatLng(results[0].geometry.location);
} else {
alert("Geocode was not successful for the following reason: " +
status);
}
});
}
Figura 3.2.3.1 – Codice della funzione codeAddress()
35

38. Crea un nuovo oggetto Google Maps Geocoder e chiama il geocode, testando lo status.
Se ok, imposta il centro della mappa sulle coordinate restituite dalla richiesta tramite il
comando map.setCenter, e chiama la funzione saveLatLng(location) per inserire i valori
negli appositi campi. In caso di status diverso si apre un messaggio di alert,
specificando anche la tipologia di errore così come fornita dalla API di Google.
3.2.4 Altre funzioni sulla gestione delle mappe
L’interazione con l’oggetto map viene eseguita da altre 2 funzioni: chglatlng() e
retmypos().
Quest’ultima viene chiamata dal pulsante showme (visualizzato come “Show my
position”) e riporta la pagina alle condizioni iniziali, centrando la mappa sulle
coordinate rilevate dalla geolocalizzazione (o sul Campus dell’Università di Trieste se
questa non è stata possibile). Riporta anche lo zoom a livello iniziale e reinserisce le
relative coordinate nei campi del form.
function retmypos() { //ritorna a posizione di geolocalizzazione
map.setCenter(mylatlng);
map.setZoom(15);
saveLatLng(mylatlng);
}
Figura 3.2.4.1 – La funzione retmypos()
La funzione chglatlng() legge i valori nei due campi Latitude e Longitude, e centra la
mappa in quel punto.
Viene chiamata ogni qualvolta il valore di uno dei due campi è cambiato manualmente,
o alla pressione del tasto Invio mentre si scrive in uno di essi.
Il numero decimale delle coordinate ha presentato un problema di convenzione: per la
gestione dei valori decimali in Javascript occorre utilizzare come separatore tra interi e
decimali il carattere ‘.’ (punto). Ma molte volte, l’utenza è solita usare come
36

39. separatore il carattere ‘,’ (virgola), presentando un problema di riconoscimento della
stringa inserita come numero e generando errori.
Quindi la prima cosa da fare è un test sulle virgole. Se è presente il carattere ‘,’
(virgola), tramite il comando replace si sostituisce la stessa con il carattere ‘.’ (punto)
così da renderlo compatibile. Dopo la sostituzione, il numero decimale viene riscritto
all’interno del campo per essere visualizzato correttamente col punto e non creare
incompatibilità con le altre funzioni.
I valori vengono salvati in due variabili create appositamente, lat e lng.
Le due condizioni IF, invece, dopo la sostituzione del carattere di separazione,
controllano che il valore stringa all’interno dei campi rappresenti effettivamente un
valore numerico. Se non lo è, tramite un alert avvisa del problema per la correzione
dello stesso. Se lo è, invece, lo converte da stringa a numero.
function chglatlng() { //cambiando i campi lat o lng la mappa si centra
//automaticamente
var lat = document.queryform.latit.value;
lat = lat.replace(",", ".");
document.queryform.latit.value = lat;
var lng = document.queryform.longit.value;
lng = lng.replace(",", ".");
document.queryform.longit.value = lng;
if (isNaN(lat)) {
alert('Latitude value is not a number. Please modify it.');
return;
} else {
var lat2 = parseFloat(lat);
}
if (isNaN(lng)) {
alert('Longitude value is not a number. Please modify it.');
return;
} else {
var lng2 = parseFloat(lng);
}
var latlng = new google.maps.LatLng(lat, lng);
map.setCenter(latlng);
map.setZoom(8);
}
Figura 3.2.4.2 – La funzione chglatlng()
37

40. Dopo la conversione non resta altro che creare un oggetto Google Maps LatLng per
salvarci i valori ottenuti per centrare la mappa sul nuovo punto chiamando la funzione
setCenter dell’oggetto mappa creato in precedenza. Inoltre ho scelto di settare uno
zoom più “esterno” per ridurre i problemi in caso di coordinate inserite in modo
errato. Per questo è stata utilizzata la funzione setZoom dello stesso oggetto.
3.2.5 La funzione Submit
Submit() è la funzione dalla quale si parte per la ricerca nel database.
Verifica se c’è qualcosa nei campi, e se vi è almeno un campo vuoto avvisa che si
necessita di un valore in ogni campo. Poi si verifica che in ogni campo ci sia un numero,
identificando eventuali errori con l’indicazione su dove si trova l’errore.
function Submit() {
var valuestr;
var lat = document.queryform.latit.value;
var lng = document.queryform.longit.value;
var flag = false; //flag "is negative?"
lat = parseFloat(lat);
lng = parseFloat(lng);
if (document.queryform.latit.value == "" || document.queryform.longit.value
== "" || document.queryform.range.value == "") {
//Controlla eventuali campi vuoti
alert("Please enter a value in all the fields of the query");
return;
}
if (isNaN(document.queryform.latit.value)) { // Controlla se i valori sono
alert("Latitude value is not a number"); // number, se no ritorna
return; // errore e interrompe
}
if (isNaN(document.queryform.longit.value)) {
alert("Longitude value is not a number");
return;
}
if (isNaN(document.queryform.range.value)) {
alert("Range value is not a number");
return;
}
Figura 3.2.5.1 – Prima parte della funzione Submit() con i test sui campi
38

41. Ho scelto di usare i valori decimali nella homepage per una visualizzazione
semplificata, però il database per la richiesta accetta le coordinate geografiche in
sessagesimale, con numeri interi. Pertanto questi valori vanno convertiti.
La conversione in Javascript delle coordinate l’ho creata grazie alla funzione
Math.floor(float) che però presenta un problema con i valori negativi. Infatti la
funzione viene chiamata con un valore numerico decimale e restituisce l’intero di
valore inferiore a quello passato alla chiamata. Funziona benissimo per i numeri
positivi (ad esempio 27,8 restituisce 27), mentre per i numeri negativi restituisce un
numero con valore assoluto maggiore di un’unità (infatti -27,8 restituisce -28). Il
problema è stato risolto inserendo un flag che viene posto a true se il numero è
negativo, e lavorando sul valore assoluto del numero per avere le coordinate corrette.
La conversione da decimale a sessagesimale quindi è stata fatta prendendo l’intero del
valore decimale pari ai gradi sessagesimali. Sottraendo questo valore dal numero
decimale di partenza si ottiene un numero minore di 1 e maggiore di 0 che,
moltiplicato per 60, fa risultare i minuti primi.
La parte intera di questi ultimi viene quindi divisa per 60 e sottratta al numero che
avevamo ottenuto precedentemente, dando come risultato un ulteriore numero
decimale. Moltiplicato quest’ultimo per 3600 (60*60), ciò che ne risulta è pari ai minuti
secondi della coordinata, approssimati ad un intero.
Le ultime righe creano la stringa valuestr, scrivendo tutti i parametri al suo interno con
la convenzione classica dell’URL rewriting.
È quindi un insieme di attributi del tipo “id=value” concatenati dal carattere ‘&’
(ampersand). Questa stringa verrà inserita nell’URL chiamando la pagina report.aspx,
così da passare tutti i parametri in modo semplice, veloce ed efficace per la richiesta al
database.
La riga “Location = ‘Report.aspx?’ + valuestr” crea l’URL con i parametri e vi accede,
chiamando quindi la pagina di report.
39

42. //latitudine
if (lat < 0) {
flag = true; //Numero negativo? flag a 1 per segnalarlo
lat = -lat; //prendo il suo valore assoluto
}
var latg = Math.floor(lat);
var latm = Math.floor((lat - latg) * 60)
var lats = (lat - latg - (latm / 60)) * 3600;
lats = lats.toFixed(0);
if (flag) {
latg = -latg;
flag = false; //inserisce i gradi negativi e riazzera flag
}
//longitudine
if (lng < 0) {
flag = true; //Numero negativo? flag a 1 per segnalarlo
lng = -lng; //prendo il suo valore assoluto
}
var lngg = Math.floor(lng);
var lngm = Math.floor((lng - lngg) * 60);
var lngs = (lng - lngg - (lngm / 60)) * 3600;
lngs = lngs.toFixed(0);
if (flag) {
lngg = -lngg;
flag = false; //inserisce i gradi negativi e riazzera flag
}
valuestr = "ltg=" + latg + "&ltm=" + latm + "&lts=" + lats;
valuestr = valuestr + "&lng=" + lngg + "&lnm=" + lngm + "&lns=" + lngs;
valuestr = valuestr + "&rg=" + document.queryform.range.value;
location = "report.aspx?" + valuestr;
}
Figura 3.2.5.2 – Seconda parte della funzione Submit() e passaggio alla pagina di report
3.2.6 Le funzioni testInvio(e)
Le 3 funzioni testInvio(e), testInvio2(e) e testInvio3(e) sono 3 semplici funzioni che
testano, ad ogni pressione di un tasto in un campo, se si è premuto Invio.
In caso positivo, chiama la funzione apposita per quel campo.
La funzione testInvio(e) è associata al campo per il geocoding, e chiama la funzione
codeAddress(). Inoltre sposta il cursore sul campo del Range per velocizzare l’uso
dell’applicazione.
La funzione testInvio2(e) è associata al campo Range, e chiama la funzione Submit().
40

43. La funzione testInvio3(e) è associata ai campi di Latitudine e Longitudine, e chiama la
funzione chglatlng().
function testInvio(e) {
var key = e.keyCode || e.which;
if (key == 13) {
codeAddress();
document.queryform.range.focus(); //Imposta il focus sul campo range
}
}
function testInvio2(e) {
var key = e.keyCode || e.which;
if (key == 13) {
Submit();
}
}
function testInvio3(e) {
var key = e.keyCode || e.which;
if (key == 13) {
chglatlng();
}
}
Figura 3.2.6.1 – Le funzioni testInvio(e)
3.3 La pagina di report
La pagina dedicata ai report è strutturata tramite ASP.NET in 2 elementi principali.
Il primo elemento è una DropDownList, che consente la selezione del periodo delle
emissioni da cercare. Ad esso è associato un pulsante per aggiornare i risultati in base
al valore del periodo.
Il secondo elemento è una GridView che conterrà i dati della risposta alla query al
database.
Questi due sono disposti all’interno del form repform.
Lo stile della pagina è legato alle pagine già viste in precedenza. Sono riportati allo
stesso modo i div titlediv, menu e footdiv. Anche a livello di regole nel relativo file CSS
“Report.css” abbiamo le medesime regole degli altri file, ad eccezione di una
41

44. regolazione diversa per la larghezza minima della pagina, qui fissata a 630 pixel,
necessaria per rendere ben presentabile la gridview.
3.3.1 Il form per il report
Il form contiene 2 div, ognuno dedicato a uno dei 2 elementi principali della pagina.
Il primo è “DropDown1”, che come suggerito dal nome conterrà la lista dei periodi per
la selezione.
Il secondo, “GridViewGis”, è dedicato alla tabella dei valori.
<form id="repform" runat="server">
<div id="DropDown1">
[…]
</div>
<div id="GridViewGis">
[…]
</div>
</form>
Figura 3.3.1.1 – Il form repform
Entrambi hanno, nel relativo file CSS, un insieme di regole definito appositamente. Per
la DropDown abbiamo una semplice definizione dei margini superiore e inferiore.
Si impone poi al div contenente la tabella una larghezza compresa tra 450 e 800 pixel.
Quando possibile, questa dovrà essere pari al 75% della larghezza della pagina.
#DropDown1 {
margin-top:10px;
margin-bottom:15px;
}
#GridViewGis {
margin-left:auto;
margin-right:auto;
text-align:center;
width:75%;
min-width:450px;
max-width:800px;
}
Figura 3.3.1.2 – Regole di stile per i due div del form
42

45. Il div contenente la lista a discesa con i valori del periodo è caratterizzato dal tag
asp:DropDownList che contiene una serie di attributi.
Oltre al solito ID, qui impostato a Period, ci sono i 3 attributi con i quali si impostano i
valori tra cui sarà possibile scegliere.
La scelta sarà possible con tutti i valori contenuti nella risorsa dati SQL
PeriodDataSource, che estrae i dati necessari dal database tramite la query specificata
nella definizione con l’attributo SelectCommand.
La query estrae i campi ID e Title dalla tabella ReportPeriod, e usa la stringa di
connessione definita nel file di configurazione dell’applicazione.
Con DataTextField si è impostato il campo Title della tabella del database come campo
contenente i valori da elencare nella lista.
DataValueField invece indica ID come il campo contenente il valore assunto dalla
selezione, che verrà poi utilizzato nella query principale dell’applicazione.
A fianco della lista è stato inserito un pulsante, visualizzato con il testo “Search for this
period” che ricarica la tabella GridView usando il valore del periodo indicato.
<div id="DropDown1">
Select the period:
<asp:DropDownList ID="Period" runat="server” DataSourceID="PeriodDataSource"
DataTextField="Title" DataValueField="ID" >
</asp:DropDownList>
<asp:SqlDataSource ID="PeriodDataSource" runat="server"
ConnectionString="<%$ ConnectionStrings:PRTRConnectionString %>"
SelectCommand="SELECT [ID], [Title] FROM [ReportPeriod]">
</asp:SqlDataSource>
<asp:Button ID="SubPeriod" OnClick="SubPeriod_Click" runat="server"
Visible="true" Text="Search for this period" />
</div>
Figura 3.3.1.3 – Codice contenuto in “DropDown1”
43

46. “GridViewGis” è composto da 3 elementi:
• La GridView ReportGis
• La SqlDataSource GisViewDataSource
• L’etichetta label1.
L’etichetta visualizza un testo che viene modificato da una semplicissima funzione C# al
momento della pressione del pulsante, la funzione SubPeriod_Click.
Questa funzione analizza la gridview ReportGis per conteggiare il numero di risultati
ottenuti. Se questo numero è 0 scrive la stringa “No data found in this period”,
altrimenti scrive “Data expressed in Kg”. In ogni caso, imposta a true la visibilità della
stessa che, al caricamento della pagina, è impostata a false.
protected void SubPeriod_Click(object sender, EventArgs e) {
ReportGis.DataBind();
if (ReportGis.Rows.Count == 0) {
label1.Text = "No data found in this period";
label1.Visible = true;
} else {
label1.Text = "Data expressed in Kg";
label1.Visible = true;
}
}
Figura 3.3.1.4 – La funzione C# che modifica il contenuto dell’etichetta label1
<div id="GridViewGis">
<asp:GridView ID="ReportGis" […] </asp:GridView>
<asp:SqlDataSource ID="GisViewDataSource" […] </asp:SqlDataSource>
<asp:Label ID="label1" runat="server" Visible="false" ></asp:Label>
</div>
Figura 3.3.1.5 – Codice contenuto in “GridViewGis”
La SqlDataSource accede alla Stored Procedure “Statistics_GetByRegion” e ottiene
tramite questa i dati necessari per riempire la GridView.
La risorsa è strutturata in modo ben diverso rispetto alla precedente. Oltre agli
attributi diversi per specificare l’utilizzo di una Stored Procedure, devono venir
specificati tutti i parametri della richiesta.
44

47. Vi sono 3 diversi tipi di parametro:
• QueryStringParameter: sono i parametri che vengono estratti dalla Query
String nell’URL.
• Parameter: il parametro CultureCode è fissato a en-US
• FormParameter: Il parametro IDPeriod viene modificato mediante un elemento
del form.
<asp:SqlDataSource ID="GisViewDataSource" runat="server"
ConnectionString="<%$ ConnectionStrings:PRTRConnectionString %>"
SelectCommand="Statistics_GetByRegion" SelectCommandType="StoredProcedure">
<SelectParameters>
<asp:QueryStringParameter Name="LongitudeDeg" QueryStringField="lng"
Type="String" />
<asp:QueryStringParameter Name="LongitudeMin" QueryStringField="lnm"
Type="String" />
<asp:QueryStringParameter Name="LongitudeSec" QueryStringField="lns"
Type="String" />
<asp:QueryStringParameter Name="LatitudeDeg" QueryStringField="ltg"
Type="String" />
<asp:QueryStringParameter Name="LatitudeMin" QueryStringField="ltm"
Type="String" />
<asp:QueryStringParameter Name="LatitudeSec" QueryStringField="lts"
Type="String" />
<asp:QueryStringParameter Name="Range" QueryStringField="rg" Type="String" />
<asp:Parameter Name="CultureCode" Type="String" DefaultValue="en-US" />
<asp:FormParameter FormField="Period" Name="IDPeriod" Type="Int32" />
</SelectParameters>
</asp:SqlDataSource>
Figura 3.3.1.6 – GisViewDataSource per il caricamento dei dati per la tabella
La gridview utilizza la risorsa dati appena descritta. Prende alcuni dei valori resi
disponibili dalla Stored Procedure, in quanto altri erano ridondanti.
La tabella viene costruita con le colonne, definite nei tag Columns, che ne definiscono
la struttura. Ogni colonna è definita tramite il tag asp:Boundfield con 4 attributi:
• DataField, indica il campo nella risposta del database per quella colonna
• HeaderText, indica il testo visualizzato nell’intestazione della colonna
• ReadOnly, settato a true per tutti i campi
• SortExpression, identifica il campo per le operazioni di ordinamento
Il tag Itemstyle definisce per ogni colonna gli allineamenti del testo inserito.
45

48. La GridView presenta numerosi attributi che ne identificano lo stile di base. Si
impostano:
• La larghezza al 100%
• La risorsa dati GisViewDataSource
• Colore, tipo e spessore del bordo
• Il valore di padding delle celle
• Il colore dello sfondo (bianco) del corpo della tabella
• Impaginazione dei risultati (consentita)
• Autogenerazione delle colonne (non consentita)
• Griglia di linee verticali per separare le colonne (GridLines).
<asp:GridView ID="ReportGis" runat="server" AutoGenerateColumns="False"
DataSourceID="GisViewDataSource" Width="100%" AllowPaging="True"
BackColor="White" BorderColor="Black" BorderStyle="Solid" BorderWidth="1px"
CellPadding="3" ForeColor="Black" GridLines="Vertical" >
<AlternatingRowStyle BackColor="#DDDDDD" />
<Columns>
<asp:BoundField DataField="FullName" HeaderText="Chemical Name"
ReadOnly="True” SortExpression="FullName">
<ItemStyle HorizontalAlign="Center" VerticalAlign="Middle" />
</asp:BoundField>
<asp:BoundField DataField="QuantityAir" HeaderText="Air" ReadOnly="True"
SortExpression="QuantityAir" >
<ItemStyle HorizontalAlign="Center" VerticalAlign="Middle" />
</asp:BoundField>
<asp:BoundField DataField="QuantityInjection" HeaderText="Injection"
ReadOnly="True" SortExpression="QuantityInjection" >
<ItemStyle HorizontalAlign="Center" VerticalAlign="Middle" />
</asp:BoundField>
<asp:BoundField DataField="QuantityWater" HeaderText="Water" ReadOnly="True"
SortExpression="QuantityWater" >
<ItemStyle HorizontalAlign="Center" VerticalAlign="Middle" />
</asp:BoundField>
<asp:BoundField DataField="QuantityLand" HeaderText="Land" ReadOnly="True"
SortExpression="QuantityLand" >
<ItemStyle HorizontalAlign="Center" VerticalAlign="Middle" />
</asp:BoundField>
<asp:BoundField DataField="QuantityTotal" HeaderText="Total" ReadOnly="True"
SortExpression="QuantityTotal" >
<ItemStyle HorizontalAlign="Center" VerticalAlign="Middle" />
</asp:BoundField>
</Columns>
<FooterStyle BackColor="#92A9B4" />
<HeaderStyle BackColor="#92A9B4" Font-Bold="False" ForeColor="White" />
<PagerStyle BackColor="#92A9B4" ForeColor="Black" HorizontalAlign="Center" />
</asp:GridView>
Figura 3.3.1.7 – La GridView costruita per i risultati
46

49. Lo stile viene poi perfezionato con i seguenti tag interni:
• AlternatingRowStyle, il quale imposta un colore di sfondo alternativo per le
righe pari della colonna
• FooterStyle, che allo stesso modo cambia colore al footer della tabella
• HeaderStyle, che oltre a cambiare il colore dello sfondo al header imposta il
font come non-bold e di colore bianco
• PagerStyle, che modifica lo stile del controllo delle pagine, per tabelle con
troppi risultati, con testo nero e allineamento centrale.
3.4 Il file di configurazione web.config
Il file di configurazione web.config imposta la stringa di connessione al database.
Viene richiamata per ogni accesso da effettuare alla base dati tramite il suo nome
PRTRConnectionString.
Il suo valore contiene 5 elementi:
• Data Source, che imposta il server al quale si deve accedere tramite il suo
indirizzo IP e relativa porta.
• La Network Library DBMSSOCN imposta il protocollo di accesso TCP/IP
• L’Initial Catalog indica PRTR come database al quale accedere all’interno del
server
• User Id e Password impostano i dati di accesso al database
<?xml version="1.0"?>
<configuration>
<connectionStrings>
<add name="PRTRConnectionString" connectionString="Data
Source=140.105.127.92,1433; Network Library=DBMSSOCN; Initial Catalog=PRTR;
User Id=____; Password=____" providerName="System.Data.SqlClient"/>
</connectionStrings>
</configuration>
Figura 3.4.1 – Il file web.config. User ID e Password sono stati oscurati.
47

50. 4. Conclusioni
Gli obiettivi prefissati sono stati completamente raggiunti e i vincoli soddisfatti.
L’applicazione è stata spedita al Ministero dell’Ambiente di Ankara per la pubblicazione
sul loro sito.
Sono state create:
• 2 pagine HTML5
• 1 pagina ASP.NET
• 1 file C#
• 3 documenti CSS3
• 1 file Javascript
• 1 file di configurazione
In dettaglio, il codice scritto viene quantificato in:
• 137 righe di codice nelle 2 pagine HTML5
• 79 righe di codice per la pagina ASP.NET
• 20 righe di codice C#
• 405 righe di codice CSS3
• 222 righe di codice Javascript
• 6 righe di codice per il file di configurazione
Il lavoro è completo e l’applicazione è già in produzione.
È stata testata su vari dispositivi mobile, con Sistema Operativo iOS, Android e
Windows Phone, rispondendo bene alle necessità. Su PC è stata testata con browser
Internet Explorer, Safari, Opera, Google Chrome e Mozilla Firefox.
Tutti i vincoli sono stati soddisfatti e la semplicità d’uso ricercata è da ritenersi più che
soddisfacente.
48

51. 5. Bibliografia
• Marco Virgolin (2012), Sviluppo di un’applicazione Windows Phone 7.5 per la
visualizzazione di dati di emissioni inquinanti, tesi di laurea triennale, Università
degli Studi di Trieste
• Pollutant Release and Transfer Register v3.0 Technical Documentation
• https://developers.google.com/maps/documentation/javascript/ Google Maps
Javascript API v3 Developer’s Guide
• http://msdn.microsoft.com/it-it/library/ms123401 Libreria MSDN
• http://www.asp.net/ The official Microsoft ASP.NET Site
• http://www.html.it/ Html.it, sito di guide per la programmazione
49

52. 6. Ringraziamenti
Volevo ringraziare innanzitutto il professor Fermeglia per la grande disponibilità e per
l’aiuto con un problema che mi era giunto per finire gli esami.
Ringrazio molto i miei genitori che hanno reso possibile il mio percorso di studi.
Un grazie alla mia ragazza Valentina che mi ha spronato sempre e mi ha aiutato
psicologicamente ad affrontare le difficoltà del mio percorso.
Ringrazio Gianluca per le opinioni sulle bozze della mia interfaccia.
Ringrazio i miei amici che non hanno protestato troppo per tutte le volte che ho
rifiutato di uscire di casa nell’ultimo periodo, e in particolare a Simone che mi ha
sempre dato forza.
Ringrazio molto Sandro e Daniel per i consigli e gli aiuti su alcuni dei miei ultimi esami.
Ringrazio tutti quelli che mi hanno supportato: gli amici di Festazza, quelli del Sito de
Sandro, le persone che conosco da una vita ma anche qualcuna che conosco da poco.
Ringrazio infine anche chi non credeva in me, per avermi rafforzato.
50