Presentazione di tesi - Generazione automatica di siti con mappe geografiche

1. UNIVERSITÀ DEGLI STUDI DI TRIESTE
Facoltà di Ingegneria
Tesi di Laurea
in Ingegneria Informatica
GENERAZIONE AUTOMATICA DI SITI CON
MAPPE GEOGRAFICHE
Laureando Relatore
Martino Miani Prof. Leonardo Felician
Anno accademico 2010-2011

2. I – Indice
I – Indice ............................................................................................................. 2
1 – Introduzione ................................................................................................. 4
2 – Analisi preliminare ........................................................................................ 5
3 – API di Google ................................................................................................ 6
I – Google Maps API ...................................................................................... 6
II – Google Fusion Tables API ........................................................................ 7
III – Google Sites API ..................................................................................... 7
IV – Google Custom Search API ..................................................................... 8
4 – Il codice di test e le tabelle dati aggiuntive ................................................... 8
I –Codice di Test............................................................................................ 8
II – Tabelle aggiuntive ................................................................................... 9
Analisi delle Entità .................................................................................. 9
Analisi delle relazioni ............................................................................ 11
Analisi dei volumi .................................................................................. 12
Creazione delle tabelle ......................................................................... 12
5 – Procedure e funzioni del progetto .............................................................. 14
Autenticazione Utente .......................................................................... 15
Crea una pagina di Sites ........................................................................ 15
Elimina una pagina di Sites ................................................................... 16
Capitolo: I – Indice
Modifica una pagina singola di Sites ..................................................... 16
Richieste Batch ..................................................................................... 17
Recupera dati di pagina di Sites ............................................................ 17
2

3. Crea tabella di Fusion............................................................................ 17
Aggiungi righe in tabella di Fusion ........................................................ 18
Elimina righe da tabella di Fusion ......................................................... 18
Cerca punto geografico ......................................................................... 18
Mostra Nodo Singolo ............................................................................ 19
URL Encode .......................................................................................... 19
Controllo URL........................................................................................ 20
Web Content ........................................................................................ 21
Controllo connessione a Internet .......................................................... 21
6 – Realizzazione dell’interfaccia ...................................................................... 22
7 – Tempi di esecuzione ed errori ..................................................................... 25
8 – Conclusioni ................................................................................................. 27
Bibliografia ....................................................................................................... 28
Ringraziamenti.................................................................................................. 29
Capitolo:
3

4. 1 – Introduzione
Questa tesi riguarda l’espansione di un una base dati preesistente, con la
finalità di pubblicarne il contenuto su web attraverso la geolocalizzazione e la
pubblicazione su un sito internet.
L’obbiettivo finale è lo sviluppo di un’interfaccia e del suo codice di
funzionamento per la pubblicazione automatica, di dati selezionati, su un sito
internet appositamente costruito in Google Docs e la generazione delle relative
mappe geografiche attraverso Google Fusion Tables e Google Maps.
Il committente ha fornito la struttura dei dati preesistenti e un’analisi dei
requisiti richiesti dall’applicazione da sviluppare. Il progetto è dunque iniziato con
lo studio della compatibilità dei requisiti con l’offerta delle API di Google, per poi
passare ad un’analisi dei dati già forniti e di quelli richiesti per il funzionamento
dell’applicativo per valutare la necessità di introdurre nuove tabelle o nuovi campi
all’interno della base dati.
Le fasi principali dello sviluppo sono state:
 Analisi preliminare della struttura esistente
 Studio dell’offerta delle API di Google
 Realizzazione del codice di test e delle tabelle dati aggiuntive
 Realizzazione del codice finale
 Progettazione e sviluppo dell’interfaccia utente
 Conclusioni
Il progetto è stato sviluppato in Microsoft Access 2003 e codice VBA, secondo
Capitolo: 1 – Introduzione
volontà del committente che ha necessità di implementare il lavoro completo
all’interno di un suo database già sviluppato in questo ambiente.
4

5. 2 – Analisi preliminare
Al primo incontro con il committente è stato fornito un modello di sito internet
su cui strutturare l’obbiettivo di lavoro:
http://sites.google.com/site/hotelpressreview. Il sito è curato dal committente ed
aggiornato in maniera manuale in base ai dati contenuti nel database personale
del committente. Tale forma di manutenzione era valutata possibile su una mole
limitata di elementi ma, essendo cresciuta ed avendo raggiunto le migliaia di
elementi, si è ritenuto necessario sviluppare un sistema di aggiornamento
automatizzato.
La struttura già esistente è sviluppata in Access 2003, per questo motivo è
stato richiesto di espanderne le funzionalità realizzando l’automatizzazione con il
codice dell’ambiente già in uso. Del database è stata fornita la struttura delle
query e delle tabelle principali che forniscono tutti i dati di interesse per la
pubblicazione su web.
I dati da trattare sono diverse tipologie di attività di interesse turistico come
alberghi, hotel, ristoranti e musei o di interesse enogastronomico come aziende
agricole, produttori di vino o olio. Di tali attività si ha la necessità di trovare una
locazione precisa sulla mappa geografica in base ad informazioni limitate, come
la sola Nazione, o più specifiche come la Regione e la Città. Tale ricerca è
effettuata manualmente su Google Maps e i risultati sono salvati su specifiche
mappe di “My Maps”. Il servizio offerto da Google permette di salvare anche tutti i
dettagli relativi all’attività, se presenti, e di aggiungere ulteriori dati, come i link
Capitolo: 2 – Analisi preliminare
agli articoli di recensione scritti dal committente, ordinati per data di
pubblicazione. Uno degli scopi del progetto è riuscire a riprodurre questa serie di
operazioni in modo da rendere automatico il processo, senza però perdere le
informazioni fornite dal servizio di Google Maps.
Sul sito internet, oltre alle mappe, sono presenti anche delle pagine di lista in
cui gli articoli di recensione vengono suddivisi per continente (fatta eccezione per
5

6. l’Italia) ed ordinati in base alla loro data di pubblicazione. La gestione manuale di
queste pagine, originariamente semplice, si è complicata con l’aumento della
mole di dati. Il committente ha dunque richiesto che anche questa parte venisse
gestita e generata in maniera automatica in base ai dati forniti.
3 – API di Google
Per procedere alla creazione del programma ci siamo documentati sull’offerta
dei servizi Google e sulla loro possibile implementazione. Le API offerte da
Google permettono un facile sviluppo in ambiente .NET, C# o Java (non
utilizzabili per il nostro scopo) e di accedere al server dei feed che si occupa
dell’aggiornamento dei servizi attraverso richieste http di tipo “GET” o “POST”
contenenti codice XML correttamente strutturato. Quest’ultimo strumento ci ha
permesso di utilizzare ed adattare i servizi di Google all’interno del codice VBA di
Access 2003.
I – Google Maps API
Verificata la tipologia di dati da trattare ci siamo subito occupati di verificare
quale fosse il metodo migliore per geolocalizzare gli indirizzi degli elementi. Per
fare ciò si è pensato prima di tutto di appoggiarsi a strumenti di uso comune e già
utilizzati dal committente, come “Google My Maps”. Tale strumento si è
dimostrato subito particolarmente limitato per quanto riguarda lo scopo di
automatizzazione del processo di pubblicazione dei dati, non permettendo un uso
diretto da parte del software, in quanto vincolato dal necessario intervento
dell’utente attraverso l’interfaccia web. La scelta è dunque ricaduta sulle API di
Capitolo: 3 – API di Google
Google Maps.
Tali API erano però in fase di abbandono da parte di Google che proponeva
l’uso delle nuove Fusion Tables e dunque non sono state studiate ed utilizzate
oltre la versione di test iniziale.
6

7. II – Google Fusion Tables API
Fusion Tables rispetto al metodo di interrogazione di Maps, tramite feed e
codice xml appositamente creato, introduce la possibilità di fare delle richieste
SQL direttamente ai server che gestiscono i dati delle mappe; in tal modo
possono facilmente essere generate mappe attraverso query geografiche. Le
richieste http non sono più solo xml, ma vi è un cospicuo utilizzo di codice SQL
che permette di interagire direttamente con le tabelle. Le possibilità offerte da
Fusion Tables non si limitano unicamente alla creazione di mappe
personalizzate, ma permettono anche di creare query spaziali di vario genere
come:
 Heatmaps che forniscono informazioni geografiche riguardo alla densità
di una determinata ricerca
 Traffic Layer che possono fornire informazioni costantemente aggiornate
sul traffico in una determinata zona (già in uso nelle grandi città come
Roma o Milano)
 Bicycling layers che forniscono informazioni ai ciclisti, come piste ciclabili
presenti in una zona o percorsi consigliati adatti ai ciclisti
III – Google Sites API
Le API di Google Sites offrono tutto un parco di strumenti adito alla gestione
delle pagine di un sito ospitato sulla piattaforma: creazione, modifica,
eliminazione e condivisione di elementi, pagine e sito stesso; il tutto attraverso
richieste http sul sito di feed di Google Site. La gestione attraverso le API non è
però completa e perfettamente funzionante, vi sono infatti ancora numerosi bug e
Capitolo: 3 – API di Google
mancanze che obbligano l’utente a dover gestire alcuni parametri in maniera
manuale attraverso la WebUI di Google. Questo non impedisce al nostro software
di generare e gestire le pagine, ma ha creato diverse complicazioni durante la
fase di sviluppo e la necessità di alcuni workaround per risolvere le difficoltà
senza dover chiedere l’intervento dell’utente.
7

8. IV – Google Custom Search API
Il loro uso permette di creare motori di ricerca personalizzati o di raffinare
alcune ricerche in maniera specifica. Nel nostro progetto queste API non sono
state usate in maniera attiva in quanto presentano limitazioni notevoli per gli
utenti non paganti, ma hanno permesso di affinare l’uso della ricerca sul motore
standard di Google. Le API infatti presentano un elenco ben definito dei parametri
utilizzabili nelle query del motore per ottenere dati specifici. Tali parametri hanno
permesso di limitare le ricerche degli indirizzi e ottenere tutte le informazioni
possibili sull’attività trovata, in modo tale da poter fornire le stesse informazioni
nella visualizzazione delle nostre mappe.
4 – Il codice di test e le tabelle dati aggiuntive
I –Codice di Test
All’inizio della scrittura del codice ci siamo occupati di verificare i limiti delle
API, per capire quanto si può fare e quanto si può estrapolare e salvare in
maniera utile sul nostro database. Per questo motivo è stata creata un interfaccia
Capitolo: 4 – Il codice di test e le tabelle dati aggiuntive
di test, con pulsanti limitati all’esecuzione di un comando specifico delle API,
definito con una procedura in un modulo di VBA, che ha permesso di testare:
 Autenticazione dell’utente
 Creazione di una pagina di Sites
 Eliminazione di una pagina di Sites
 Modifica di una pagina singola di Sites.
 Più modifiche in batch delle pagine di Sites
 Recupero dati pagina
 Creazione di una Tabella di Fusion
 Aggiunta di righe nelle tabelle di Fusion.
 Eliminazione di righe nelle tabelle di Fusion
 Cercare un punto geografico
8

9. II – Tabelle aggiuntive
Verificate le possibilità e le necessità degli strumenti offerti da Google, è stato
necessario progettare delle tabelle che permettessero la memorizzazione delle
nuove informazioni.
Analisi delle Entità
Rispetto alla base dati fornita dal committente sono state individuate alcune
nuove entità, i loro attributi ed i campi possibili identificatori primari:
Utente
 ID_utente: è il codice univoco che identifica l’utente all’interno del
database
 Utente: è il nome descrittivo dell’utente
 Mail: è lo username di accesso dell’utente per i servizi Google
 Password: è la password relativa allo username
Sito
 ID_sito: è il codice univoco che identifica il sito
 OrigineDati: è il percorso al database dei dati
Capitolo: 4 – Il codice di test e le tabelle dati aggiuntive
 TitoloSito: è la titolazione del sito
 Dominio: è il dominio univoco del sito, permette di definire un dominio
esterno a quello predefinito di Google Sites
 Sitename: è il nome del sito, la parte finale dell’URL, nome univoco sul
web
 ultimaGen: è la data di ultima generazione completa del sito
Pagina
 ID_pagina: è il codice univoco che identifica la pagina
 ID_sito: è il codice che collega una pagina ad un sito
 NomePagina: definisce il nome della pagina così come comparirà nel
path
9

10.  Etag: il codice univoco della pagina, varia ad ogni modifica
 Path: è il percorso della pagina, se diverso da quello di root
 Titolo: definisce il titolo della pagina, così come deve comparire
nell’intestazione web
 PossoEliminare?: definisce la possibilità o meno di eliminare la pagina al
fine di rigenerarla
Attività:
 ID: è il codice univoco dell’elemento
 Nome: è il nome dell’elemento
 Città: è la città in cui si trova l’elemento
 Regione/Country: è la località in cui si trova l’elemento
 TipoIndirizzo: caratterizza il tipo di attività
 Provincia: solo per la tabella Italy, è sempre relativo all’indirizzo
 Nazione: la nazione dell’elemento
Locazione Geografica:
 ID: è il codice univoco dell’attività, permette il collegamento alle tabelle
Capitolo: 4 – Il codice di test e le tabelle dati aggiuntive
originali.
 Nome: è il nome della locazione da trovare, così come definita
dall’utente
 Googlename: è il nome della locazione riscontrato dalla ricerca su
Google, utile per un confronto
 Indirizzo: è l’indirizzo della locazione fornito per effettuare la ricerca
 Gindirizzo: è l’indirizzo riscontrato a seguito della ricerca su Google
 Info: è il campo che raccoglie i dati informativi ottenuti dalla ricerca su
Google
 Point: le coordinate geografiche del punto in termini KML
 CoordENZ: le coordinate geografiche non codificate, definite come Est,
Nord e altitudine Z
10

11.  NoteWeb: è il campo in cui vengono memorizzati i link agli articoli dopo
essere stati formattati in HTML
 Icon: è il valore che descrive l’icona da usare sulla mappa
Google Apps
 ID_GApps: è il codice univoco che identifica un’applicazione
 GdataType: è il testo “user friendly” che definisce l’applicazione
 GdataCode: è il testo che definisce l’applicazione nelle richieste di
autenticazione
 GdataToken: è il codice univoco di identificazione dell’applicazione sui
server Google
 GdataFeedSite: è il path del server di autenticazione dell’applicazione
Fusion Table:
 NomeTabella: definisce il nome della tabella in termini umani
 Table_ID: è il codice univoco della tabella fornito da Google
Icona:
 TipoIndirizzo: definisce il tipo di attività dell’elemento
Capitolo: 4 – Il codice di test e le tabelle dati aggiuntive
 CodiceIcona: è il codice Fusion Table dell’icona
Analisi delle relazioni
Successivamente sono state studiate le relazioni e le cardinalità presenti tra le
entità riconosciute. Si possono osservare delle tabelle contenenti le descrizioni
delle relazioni e dei ragionamenti che hanno portato all’identificazione delle
cardinalità:
Relazione Cardinalità
Collega l’entità “utente” con l’entità “sito”; definisce l’utente autorizzato
ad operare sul sito.
Autorizzazione
Molti a molti: ogni utente può avere l’autorizzazione alla modifica di uno
o più siti che possono essere condivisi tra più utenti differenti.
11

12. Collega l’entità “pagina” all’entità “sito”, definisce a quale sito appartiene
Appartenenza la pagina
Uno a molti: più pagine possono appartenere ad un solo sito
Collega le attività localizzate alle attività originali
Localizza
Uno a uno: ogni attività ha la sua localizzazione univoca
Collega l’entità localizzata all’entità “icona” che la rappresenta sulla
mappa
Rappresenta
Uno a molti: un’icona può rappresentare più attività dello stesso genere
Analisi dei volumi
Per le entità sono stati valutati i volumi, in modo da avere dei valori
caratterizzanti delle quantità dei dati da trattare.
Concetto Tipo Volume
Utente E 1
Capitolo: 4 – Il codice di test e le tabelle dati aggiuntive
Sito E 1
Pagina E 16
Locazione Geografica E 5000
Google Apps E 20
Fusion Table E 8
Icone E 200
Creazione delle tabelle
Sono state dunque create quattro tabelle fondamentali per mantenere i dati
relativi all’utente, al sito internet da aggiornare e alle pagine di cui è composto,
con una struttura tale da permettere un eventuale sviluppo futuro.
12

13. È stata poi fatta una valutazione delle informazioni necessarie alla
geolocalizzazione delle attività. Tale valutazione ha portato, per non influire sulla
struttura originale del database, alla creazione di tabelle dedicate alla
memorizzazione delle informazioni geografiche. Queste ultime, contraddistinte
dalla nomenclatura “geo_”, contengono l’ID ed il nome del punto localizzato (in
modo da poter essere collegate alle tabelle originali), oltre a campi specifici che
riguardano la localizzazione geografica, i dati ottenuti dalla ricerca tramite Google
Maps e il WebContent. Le tabelle “geo_” forniscono i dati da importare su Fusion
Tables per formare le mappe del sito.
Capitolo: 4 – Il codice di test e le tabelle dati aggiuntive
Il codice icona utilizzato nelle tabelle “geo_” viene estratto dalla tabella
“tbl_icone” che associa il tipo di attività (es. Hotel, Ristorante, Museo) ad uno
specifico codice di Fusion Tables, in modo tale da generare un’icona differente
per ogni tipologia e differenziarle nel caso in cui si trovino nella stessa mappa.
13

14. Tutti i servizi di Google necessitano di un’identificazione dell’utente a livello
server, per verificare ad ogni operazione l’autorizzazione, e richiedono l’utilizzo di
un token che contiene il codice univoco della sessione. Tale codice viene
generato per ogni servizio; al fine di memorizzare i token di tutti i servizi utilizzati
è stata creata la tabella “tbl_GoogleApps” nella quale sono memorizzati i nomi dei
servizi, i siti di feed per l’autenticazione, il codice dell’applicazione ed il token
della sessione.
Per finire sono state previste 3 tabelle, caratterizzate dal termine Log, nelle
quali vengono registrati gli errori durante le diverse procedure. “GeoLogError” è
utilizzata per segnalare tutti i punti di cui non viene trovata la locazione
geografica; in “LinkLog” sono memorizzati i link che risultano non attivi; mentre in
“BatchLog” sono segnalati eventuali errori nella procedura di creazione delle liste
e dunque di elementi mancanti nelle pagine. Tutte le tabelle di tipo “Log” vengono
azzerate ad ogni nuovo utilizzo dell’applicazione, così da garantire la presenza
Capitolo: 5 – Procedure e funzioni del progetto
degli errori dell’ultima sessione evitando la sovrapposizione con i dati delle
precedenti generazioni.
5 – Procedure e funzioni del progetto
Una volta testate le procedure e costituite le tabelle aggiuntive si è passati alla
fase di affinamento del progetto. Le procedure sono state dunque pulite dai dati
fissi (di test) e modificate in modo da poter utilizzare dati in ingresso e gestire le
tabelle a seconda del caso e poter essere accorpate e richiamate per i diversi
scopi.
14

15. Autenticazione Utente
La procedura si occupa di autenticare l’utente ai servizi di Google, l’utente
deve perciò essersi preventivamente registrato alla piattaforma Google.
Viene effettuata una richiesta http di tipo POST al server di autenticazione di
Google https://www.google.com/accounts/ClientLogin, nella quale è specificato il
nome utente (mail), la password, il servizio a cui ci si vuole autenticare e
l’applicazione che si vuole autenticare. In caso di autenticazione positiva il server
restituisce il codice di autenticazione del servizio “Auth” che viene memorizzato
nel database per poter essere utilizzato durante tutte le successive richieste al
servizio. In caso di autorizzazione respinta è fornito un messaggio di errore che
descrive il tipo di errore verificatosi di modo che l’utente possa procedere alla
soluzione del problema.
In tutte le procedure dei servizi Google è utilizzato il token di autenticazione Capitolo: 5 – Procedure e funzioni del progetto
specifico del servizio, viene cioè inserito negli header della richiesta http.
Crea una pagina di Sites
La procedura si occupa di generare e trasmettere il codice xml corretto al
servizio feed di Google Sites, attraverso una richiesta http di tipo POST. Crea il
codice xml inserendo i dettagli specifici della pagina come Titolo e path relativo,
infine completa gli header richiesti ed invia il tutto al sito di feed di Google Site.
Nella sua versione di test si occupava di generare anche le colonne della lista,
15

16. ma un bug nella gestione delle liste da parte del server di Google non permette
l’interpretazione corretta dei link se la lista viene creata con la pagina. Si è
dunque scelto di creare la pagina secondo un modello, adeguatamente preparato
e memorizzato tra i modelli di Sites; in questo modo il bug non si verifica e non è
necessario l’intervento dell’utente nella fase di generazione. La procedura si
occupa anche di memorizzare i campi Entry_ID ed Etag univoci della pagina per
poter essere utilizzati nelle fasi di modifica ed eliminazione, tali campi sono
restituiti dal server in caso di risposta positiva alla creazione della pagina.
Elimina una pagina di Sites
Al contrario della precedente, si occupa di cancellare una pagina specifica del
Capitolo: 5 – Procedure e funzioni del progetto
sito, sempre attraverso una richiesta http. In questo caso però viene fatta una
richiesta DELETE che specifica il path della pagina e il suo Entry_ID univoco,
inoltre negli header viene specificato l’Etag per essere sicuri che non sia
cancellata una versione diversa della pagina.
Modifica una pagina singola di Sites
La procedura si occupa di modificare la pagina selezionata in maniera
adeguata attraverso una richiesta di tipo PUT. Viene generato il codice xml
relativo alla pagina con i dati specifici, come la titolazione delle colonne della lista
ed i link alla mappa. Questa procedura si è rivelata un passo necessario nella
generazione delle pagine di lista a seguito del workaround istituito nel sistema di
16

17. creazione delle pagine: l’utilizzo di modelli non permette infatti di personalizzare il
contenuto della pagina e quindi di inserire il link alla mappa relativa.
Richieste Batch
La procedura si occupa di generare codice xml che permette l’esecuzione di
più operazioni in una sola richiesta al servizio di feed. Google Sites offre un
sistema di richieste multiple che dovrebbe permettere di migliorare
l’ottimizzazione del codice in favore di velocità e occupazione di rete, tale servizio
è la richiesta batch. Questo metodo è stato scelto per caricare più rapidamente le
pagine di lista, inserendo più righe contemporaneamente all’interno di ogni
pagina. Allo stato attuale del progetto il sistema genera un solo elemento per ogni
richiesta in quanto il server non gestisce correttamente tutte le operazioni
successive alla prima. È stato comunque scelto di mantenere questo metodo di
aggiornamento perché in caso di risoluzione del problema, da parte di Google,
sarebbe facilmente aumentabile il numero di elementi generati.
Recupera dati di pagina di Sites
Si occupa di recuperare l’Entry_ID e l’Etag della pagina in base al nome. La
procedura permette di recuperare tutti i dettagli prima della rigenerazione, così da
avere le informazioni aggiornate anche a seguito di eventuali interventi manuali.
È infatti prassi di Google modificare l’Etag ad ogni modifica della pagina, in modo
Capitolo: 5 – Procedure e funzioni del progetto
da tenere traccia delle diverse versioni della stessa e prevenire modifiche
accidentali.
Crea tabella di Fusion
Permette la creazione di una tabella all’interno di Fusion Tables. Questa
procedura è stata utilizzata nei moduli di test, ma non è utilizzata nel codice
finale. Le API di Fusion permettono tramite codice SQL di creare e specificare
ogni dettaglio della nuova tabella, ciò ha portato molti meno problemi di
interpretazione da parte dei server di Google e quindi una maggior facilità di
sviluppo.
17

18. Aggiungi righe in tabella di Fusion
La procedura si occupa di aggiungere righe compilate all’interno della tabella
selezionata. Inserisce nelle tabelle di mappa tutti i dati relativi ai punti geografici
trovati con la geolocalizzazione: nome, informazioni di Google, link agli articoli di
recensione, coordinate geografiche. Essendoci un limite di 500 richieste SQL per
ogni richiesta http, la procedura si occupa anche di dividere le richieste in gruppi
di dimensione corretta in modo da non generare errore sui server.
Elimina righe da tabella di Fusion
Inizialmente concepita come Elimina tabella, ci si è poi convertiti al semplice
svuotamento della stessa prima di inserire i nuovi dati. La procedura fa una
richiesta SQL di tipo DELETE che porta all’eliminazione di tutti i dati, ma non
delle definizioni della visualizzazione della mappa.
Cerca punto geografico
È la procedura che si occupa di geolocalizzare tutte le attività del database in
base al nome, la nazione e il tipo di attività del dato. Attraverso una richiesta http
di tipo POST all’indirizzo specifico delle ricerche geografiche di Google e con i
parametri corretti, selezionati tra quelli messi a disposizione da Google Custom
Search, la procedura ottiene in risposta un file KML con tutti i dettagli del punto
Capitolo: 5 – Procedure e funzioni del progetto
localizzato. Procede dunque ad analizzare il file in cerca dei dati rilevanti ed utili
alla costruzione della nuova mappa e li salva nel database.
18

19. Seleziona
elemento
SI
È già stato
geolocalizzato?
NO
Ricerca tramite
Google Map
Search
Segnala nel Log
Trovato con la
NO per impostazione
ricerca?
manuale
SI
Salva i dati di
Google
Finiti gli
NO
elementi?
SI
Esci dalla ricerca
Mostra Nodo Singolo
È la funzione che si occupa di fare l’analisi del file KML, ricerca il nodo richiesto
all’interno del file e restituisce il valore desiderato. Nella sua versione originale
Capitolo: 5 – Procedure e funzioni del progetto
era previsto l’uso di xPath come linguaggio di analisi del documento, tale
funzione è però mal implementata all’interno di Access2003, perciò è stato usato
XSLT per raggiungere i nodi, seppur non altrettanto funzionale.
URL Encode 1
La funzione si occupa di convertire le stringhe di testo in codice urlencode, in
modo da poter trasmettere il codice SQL attraverso le richieste http. Con questo
1
La funzione è stata copiata da un sito internet specializzato. L’indirizzo è specificato nel codice
19

20. metodo i caratteri vengono codificati in maniera univoca e non si verificano errori
relativi a caratteri speciali o lingue particolari.
Controllo URL
La sua funzione è quella di verificare che i link agli articoli di recensione siano
funzionanti, in modo da inserire solo informazioni valide ed aggiornate all’interno
del sito. La procedura, attraverso la funzione “IsLink”, effettua una richiesta http di
tipo HEAD che le permette di verificare rapidamente se la pagina richiesta esiste,
in caso di risposta affermativa, il link è marcato come valido, altrimenti è
segnalato sul log per permettere un controllo manuale.
Seleziona
elemento
SI
NO È marcato
Controlla tutti?
come valido?
SI NO
SI È link valido? NO
Capitolo: 5 – Procedure e funzioni del progetto
Segnala sul Log e
Marca come
marca come
linkvalido = SI
linkvalido = NO
Ho terminato
NO gli elementi?
SI
Esci dalla routine
.
20

21. Web Content
La procedura si occupa di generare il Web Content dei punti geolocalizzati in
precedenza secondo i criteri richiesti dal committente. Alla tabella con i link è
applicato un filtro, in modo da ottenere solo gli elementi relativi al punto
considerato ed ordinarli per data dal più recente al più vecchio; così viene
generato il codice HTML per ogni link e salvato nell’ordine corretto all’interno del
campo NoteWeb della tabella che andrà a formare la mappa.
Capitolo: 5 – Procedure e funzioni del progetto
Controllo connessione a Internet2
Rapida funzione che controlla la connessione ad internet. Essendo l’intero
progetto strettamente legato alla connessione ad internet, è fondamentale sapere
se questa è attiva.
2
La funzione è stata copiata da un sito internet specializzato. L’indirizzo è specificato nel codice
21

22. 6 – Realizzazione dell’interfaccia
L’interfaccia è stata sviluppata attraverso l’uso delle form di Access 2003;
considerate le necessità del committente sono state sviluppate 4 form che
permettono la gestione di tutte le necessità:
 Home, che introduce l’utente all’applicazione e permette la definizione
dei parametri fondamentali per l’autenticazione, l’uso del database e
l’aggiornamento del sito.
Capitolo: 6 – Realizzazione dell’interfaccia
 Controllo utente, la “stanza dei bottoni” che offre l’accesso a tutte le
funzioni del progetto. Da questa interfaccia è possibile:
o Effettuare il controllo dei link che andranno poi a formare il Web
Content e visualizzare eventuali errori avvenuti durante il controllo,
è possibile inoltre selezionare se fare il controllo su tutti i link o
solo su quelli non ancora validi, attraverso l’uso di una combo box;
o Localizzare i punti geografici non ancora individuati, attraverso la
ricerca automatica su Google Maps e la visualizzazione di un
report nel quale sono segnalati gli elementi non trovati;
o Aprire il form di verifica dei dati localizzati;
22

23. o Generare le liste e le mappe separatamente per le diverse pagine
o Generare le liste e le mappe per tutte le pagine del sito
o Visualizzare il report della generazione
o Controllare, grazie ai valori di congruenza, l’entità dei dati trattati e
possibili errori nelle pagine di lista
Capitolo: 6 – Realizzazione dell’interfaccia
 Verifica dati, permette di controllare tutti i dati geolocalizzati per
modificare eventuali errori nella ricerca o inserire le coordinate
geografiche dei punti che non sono stati trovati attraverso la procedura
23

24. automatica. Per semplificare l’inserimento delle coordinate è stato
inserito un pulsante che permette di filtrare i campi e visualizzare i soli
campi non localizzati.
 Operazioni, fornisce costantemente l’attività del programma durante le
Capitolo: 6 – Realizzazione dell’interfaccia
operazioni attraverso una linea di controllo e lo status attuale
dell’operazione.
24

25. 7 – Tempi di esecuzione ed errori
Nei test effettuati con 493 elementi si è riusciti a generare l’intero sito in 20
minuti, esclusa localizzazione dei dati e controllo dei link, utilizzando una linea
ADSL da 320 kbit/s in upload; una connessione di rete più veloce permetterebbe
tempi ancora migliori. I vantaggi per l’utente, in termine di tempo, sono
sicuramente positivi rispetto all’applicazione manuale delle modifiche sul sito.
Tempo medio di generazione (in minuti)
stimato in base al volume di elementi
250
200
150 tempo
100
50
0
500 1000 2500 5000
La geolocalizzazione ha generalmente tempi contenuti essendo effettuata solo
sui nuovi elementi e non sull’intero database. Per i punti che vengono trovati il
tempo medio di elaborazione è di 1 al secondo, nel caso dei non trovati il tempo
scende a 3 al secondo. Il tasso di errore sul campione testato è stato del 8,3%
Capitolo: 7 – Tempi di esecuzione ed errori
con 43 elementi non localizzati, di cui 34 facenti parte del campione Food &
Beverage che presenta molti elementi mancanti anche con la ricerca manuale;
filtrando questi dati il tasso di localizzazioni mancate scende al 2,8%, cioè 9
elementi su 321. Al fine di posizionare anche questi elementi è prevista una
procedura di immissione manuale delle coordinate a seguito di una ricerca del
punto desiderato, in tal modo i punti verranno localizzati e non si ripresenteranno
come mancanti alla ricerca successiva.
Il controllo dei link può essere critico dal punto di vista dei tempi se effettuato
su tutti gli elementi, perciò è stata introdotta la possibilità di controllare solo i
25

26. nuovi inserimenti e i link che risultano non attivi. Per una verifica completa del
campione a disposizione il tempo è stato di 8 minuti con una velocità media di
poco inferiore ad 1 link al secondo. Purtroppo non sono stati trovati metodi più
rapidi per il controllo dei link, ma è stato rilevato un solo falso positivo (link
segnalato erroneamente come inattivo) sull’intero campione di 493 link con un
tasso di errore dello 0,2%.
Capitolo: 7 – Tempi di esecuzione ed errori
26

27. 8 – Conclusioni
Lo sviluppo dell’applicazione, del sito internet e delle mappe si è concluso con
esito parzialmente positivo. Il vantaggio principale ottenuto dall’utilizzo
dell’applicativo è la possibilità di aggiornare completamente le liste e le mappe
del sito di Google Site senza l’intervento manuale dell’utente sulle pagine.
Il lavoro svolto può essere quantificato principalmente in:
 Progettazione e creazione di 11 tabelle
 4 form di gestione dell’applicazione
 1500 righe di codice non autogenerato in VBA
 3 report
 Progettazione ad hoc di 4 pagine di Google Sites
 Progettazione di 2 pagine di modello di Google Sites che sono di base
per la generazione di 22 pagine del sito.
Il lavoro di progettazione e sviluppo è stato complicato da repentine modifiche
dei servizi Google che hanno comportato la necessità di cambiare alcune parti
del programma in corso d’opera. La struttura delle tabelle non è stata
compromessa da tali variazioni che hanno colpito solo alcune parti del codice, il
che ci ha dato conferma della buona progettazione della base dati. Una modifica
dell’ultima ora al codice KML, generato dalle pagine di Google Maps, non ha
permesso la corretta generazione dei Balloon contenenti le informazioni di
Google e la parziale conclusione del progetto. Una soluzione a questo problema
potrebbe essere l’uso di un altro ambiente di sviluppo che supporti
completamente le API di Google.
Capitolo: 8 – Conclusioni
27

28. Bibliografia
https://code.google.com
http://msdn.microsoft.com
http://office.microsoft.com/it-it/access-help
http://forum.masterdrive.it
http://www.freevbcode.com
http://stackoverflow.com
Capitolo: Bibliografia
28

29. Ringraziamenti
Ringrazio
mia madre per la pazienza ed il supporto finanziario in questi
lunghi anni di università, Ester per avermi sopportato ed
incitato a completare questo percorso, tutti gli amici che mi
hanno fatto compagnia in questi splendidi anni.
Ora odio Google, i suoi strumenti di morte (fatti male) e il suo
forum di supporto generalmente poco collaborativo, eccezion
fatta per Kathryn del forum di Fusion Tables
Capitolo: Ringraziamenti
29