UNIVERSITÀ DEGLI STUDI DI TRIESTE

Facoltà di Ingegneria

Tesi di Laurea

in Ingegneria Informatica

GENERAZIONE AUTOMATICA DI SITI CON

MAPPE GEOGRAFICHE

Laureando

Martino Miani

Relatore

Prof. Leonardo Felician

Anno accademico 2010-2011

Cap

ito

lo: I

– In

dic

e

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

Modifica una pagina singola di Sites ..................................................... 16

Richieste Batch ..................................................................................... 17

Recupera dati di pagina di Sites ............................................................ 17

Cap

ito

lo:

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

Cap

ito

lo: 1

– In

tro

du

zio

ne

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

volontà del committente che ha necessità di implementare il lavoro completo

all’interno di un suo database già sviluppato in questo ambiente.

Cap

ito

lo: 2

– A

nal

isi p

relim

inar

e

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

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

Cap

ito

lo: 3

– A

PI d

i Go

ogl

e

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

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.

Cap

ito

lo: 3

– A

PI d

i Go

ogl

e

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

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.

Cap

ito

lo: 4

– Il

co

dic

e d

i tes

t e

le t

abel

le d

ati a

ggiu

nti

ve

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

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

Cap

ito

lo: 4

– Il

co

dic

e d

i tes

t e

le t

abel

le d

ati a

ggiu

nti

ve

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

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

Cap

ito

lo: 4

– Il

co

dic

e d

i tes

t e

le t

abel

le d

ati a

ggiu

nti

ve

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

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

Cap

ito

lo: 4

– Il

co

dic

e d

i tes

t e

le t

abel

le d

ati a

ggiu

nti

ve

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

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à

Autorizzazione

Collega l’entità “utente” con l’entità “sito”; definisce l’utente autorizzato

ad operare sul sito.

Molti a molti: ogni utente può avere l’autorizzazione alla modifica di uno

o più siti che possono essere condivisi tra più utenti differenti.

Cap

ito

lo: 4

– Il

co

dic

e d

i tes

t e

le t

abel

le d

ati a

ggiu

nti

ve

12

Appartenenza

Collega l’entità “pagina” all’entità “sito”, definisce a quale sito appartiene

la pagina

Uno a molti: più pagine possono appartenere ad un solo sito

Localizza Collega le attività localizzate alle attività originali

Uno a uno: ogni attività ha la sua localizzazione univoca

Rappresenta

Collega l’entità localizzata all’entità “icona” che la rappresenta sulla

mappa

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

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.

Cap

ito

lo: 4

– Il

co

dic

e d

i tes

t e

le t

abel

le d

ati a

ggiu

nti

ve

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.

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.

Cap

ito

lo: 5

– P

roce

du

re e

fu

nzi

on

i del

pro

gett

o

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

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.

Cap

ito

lo: 5

– P

roce

du

re e

fu

nzi

on

i del

pro

gett

o

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

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,

Cap

ito

lo: 5

– P

roce

du

re e

fu

nzi

on

i del

pro

gett

o

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

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

Cap

ito

lo: 5

– P

roce

du

re e

fu

nzi

on

i del

pro

gett

o

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

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.

Cap

ito

lo: 5

– P

roce

du

re e

fu

nzi

on

i del

pro

gett

o

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

localizzato. Procede dunque ad analizzare il file in cerca dei dati rilevanti ed utili

alla costruzione della nuova mappa e li salva nel database.

Cap

ito

lo: 5

– P

roce

du

re e

fu

nzi

on

i del

pro

gett

o

19

Seleziona

elemento

È già stato

geolocalizzato?

SI

Ricerca tramite

Google Map

Search

NO

Trovato con la

ricerca?

Segnala nel Log

per impostazione

manuale

NO

Salva i dati di

Google

SI

Finiti gli

elementi?

Esci dalla ricerca

SI

NO

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

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

Cap

ito

lo: 5

– P

roce

du

re e

fu

nzi

on

i del

pro

gett

o

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

Controlla tutti?

SI

NO È marcato

come valido?

SI

NO

È link valido?

Marca come

linkvalido = SI

SI

Segnala sul Log e

marca come

linkvalido = NO

NO

Ho terminato

gli elementi?

Esci dalla routine

SI

NO

Cap

ito

lo: 5

– P

roce

du

re e

fu

nzi

on

i del

pro

gett

o

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.

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

Cap

ito

lo: 6

– R

ealiz

zazi

on

e d

ell’i

nte

rfac

cia

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.

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;

Cap

ito

lo: 6

– R

ealiz

zazi

on

e d

ell’i

nte

rfac

cia

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

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

Cap

ito

lo: 6

– R

ealiz

zazi

on

e d

ell’i

nte

rfac

cia

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

operazioni attraverso una linea di controllo e lo status attuale

dell’operazione.

Cap

ito

lo: 7

– T

emp

i di e

secu

zio

ne

ed e

rro

ri

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.

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%

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

0

50

100

150

200

250

500 1000 2500 5000

Tempo medio di generazione (in minuti) stimato in base al volume di elementi

tempo

Cap

ito

lo: 7

– T

emp

i di e

secu

zio

ne

ed e

rro

ri

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%.

Cap

ito

lo: 8

– C

on

clu

sio

ni

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.

Cap

ito

lo: B

iblio

graf

ia

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

Cap

ito

lo: R

ingr

azia

men

ti

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