Gli spostament

Rappresentare graficamente gli spostamenti geografici che fece un vescovo durante il periodo in cui fu in carica ha creato numerosi problemi.

Innanzitutto è impossibile, persino nei giorni nostri con i sistemi di geolocalizzazione avanzati, conoscere ogni movimento che una persona fa nel corso della sua vita, perciò provare a ricreare gli spostamenti di un individuo vissuto nel medioevo, con le poche informazioni che si possiedono, necessita per forza di cose di un’approssimazione del percorso. In secondo luogo la realizzazione di questo percorso necessita di tappe che ci pongono di fronte ad un dilemma, ossia cosa considerare come punto di snodo (checkpoint). Come ultimo problema bisogna capire quale sia il sistema migliore per raffigurare su una mappa bidimensionale i tragitti percorsi da più individui in tempi diversi che aggiungono ulteriori dimensioni da prendere in considerazione.

Una delle mappature grafiche su cui mi sono basato per creare le funzioni per gli spostamenti è presente nel progetto Clavius on the Web26_{, dove si mostrano gli}

spostamenti del gesuita Cristoforo Clavio (1538-1612) in base alle lettere da lui prodotte. Tuttavia, questa visualizzazione del percorso, per quanto perfetta nella sua semplicità, non presentava alcuni dei problemi che ho dovuto affrontare per realizzare la mia mappatura.

In primis l’attore è unico e soprattutto, poiché il progetto è concluso e le tappe che lo coinvolgono sono ben definite, non era necessario trovare una soluzione per ulteriori aggiornamenti nella mappa.

Nel mio caso, invece, ci sono circa 20 soggetti descritti in diversi documenti ancora in fase di codifica. Questo significa che è stato necessario prevedere la possibilità di

26 _{Clavius on the Web project <http://wafi.iit.cnr.it/clavius/storytelling/clavius-life> [consultato in} 2019/04/01]

inserire nuovi dati (e quindi nuove tappe), che tendono a modificare il percorso a seconda dell’evento.

Questa natura proteiforme degli spostamenti ha comportato, quindi, la necessità di rispondere contemporaneamente tanto alle esigenze dei colleghi che lavorano alla codifica del codice, quanto alla creazione di un’interfaccia semplice e comprensibile per l’utente.

Inoltre va considerato il fatto che se la richiesta iniziale era quella di riportare le sedi nelle quali il vescovo aveva rogato il documento, nella codifica attuale queste informazioni non sono sempre presenti, o perlomeno non è facilmente associabile il documento alla sede e al vescovo corrispondente.

Le fasi di realizzazione

La soluzione a questi problemi è stata suddivisa in tre fasi:

1. Creare la corrispondenza tra vescovo, luogo e documento: per far coincidere questi tre elementi è stato necessario rinunciare alla richiesta iniziale di impostare il vescovo in funzione del documento da lui prodotto e ribaltare il rapporto creando una lista di documenti nei quali il vescovo veniva nominato e associato ad un determinato luogo. In sostanza non vengono più rappresentati sulla mappa le sedi dove i documenti sono stati rogati dal vescovo, ma i luoghi dove quel vescovo è stato presente e i documenti che lo citano. Questa impostazione è tuttavia momentanea poiché, anche se rispecchia più fedelmente gli spostamenti della persona nel corso della sua carriera episcopale, non risponde alla richiesta di utilizzare esclusivamente i documenti (ossia le fonti primarie).

2. Creare una codifica che permetta l’inserimento di nuove informazioni e che, allo stesso tempo, venga facilmente interpretata dal programma: il risultato di questa codifica ha portato all’inserimento di una lista di eventi presente per ciascun vescovo.

Ogni evento è il risultato di una informazione ricavata da uno o più documenti. Anche in questo caso però sono sorti dei problemi; infatti il luogo e la data sono definibili in funzione del documento rogato e non del vescovo a cui si fa cenno. Questo significa che il vescovo potrebbe essere stato fuori sede quando il documento venne prodotto o che vengano citati più vescovi nessuno dei quali era però il fautore del documento. Queste informazioni riportano quindi delle inesattezze, che dovranno essere risolte con nuove codifiche che coincidano con la lettura dei singoli documenti.

3. Creare delle funzioni che forniscano un’adeguata gestione dei percorsi ottenuti dalla codifica: l’obiettivo è permettere all’utente di poter visualizzare sia il percorso nel suo insieme sia, di volta in volta, le singole tappe.

Gli esperimenti per gli spostamenti (DirectionsService)

Il primo esperimento compiuto in questo senso ha cercato di sfruttare i servizi di geolocalizzazione dell’oggetto DirectionsService di Google.

Grazie alle API di Google è in sostanza possibile chiedere le indicazioni stradali alla piattaforma fornendo un punto di partenza, uno di arrivo ed eventuali tappe intermedie (waypoints). Questo servizio sfrutta un indirizzo, una posizione o delle coordinate geografiche: queste informazioni vengono poi elaborate ed il sistema fornisce il percorso ottimale in tempo reale.

Per ottenere poi la visualizzazione delle linee, degli indicatori e delle indicazioni testuali è necessario un altro oggetto chiamato DirectionsRenderer.

I servizi offerti tuttavia non si prestavano alla natura del progetto; infatti se da un lato agevolano di molto l’acquisizione dei percorsi, dall’altro creano diversi problemi, sia grafici che strutturali, che mi hanno portato a rinunciare al loro utilizzo.

I problemi riscontrati sono:

 Strutturali:

a. il limite di tappe per richiesta (OVER_QUERY_LIMIT): impostato a 10

waypoints (compresi partenza ed arrivo) per clienti standard e a 25 per clienti premium, con un per un certo intervallo di tempo (circa 5 secondi). Questo significa che nel caso in cui un vescovo abbia effettuato più di 10 tappe nella sua codifica il programma comunica l’errore di superamento del limite.

b. in maniera simile al GeocodingService, la difficoltà a trovare alcuni luoghi o a posizionarli correttamente nella mappa: ciò comporta l’elevata possibilità che vengano a generarsi errori nel risultato finale del percorso.

c. il prezzo del servizio, che dal 16 luglio 2018 ha un costo per ogni richiesta inviata a Google.

 Grafici

a. se si ripercorre la stessa tappa (es Sarzana, Luni, Sarzana) i marcatori vengono sovrapposti, non consentendo così la possibilità di capire quanti e quali

var directionsService = new google.maps.DirectionsService(); var directionsRenderer = new google.maps.DirectionsRenderer({

map: map,

markerOptions: markerOptions, polylineOptions: polylineOptions, });

Figura 15 - L’immagine mostra un esempio dell’utilizzo del DirectionService: si può notare l’errata posizione della città di Luni, il marker C nascosto e le indicazioni stradali confuse.

marcatori si trovano nello stesso punto.

b. le indicazioni stradali seguono ovviamente percorsi contemporanei (strade, autostrade etc) e, anche se è possibile evitare pedaggi e impostare il viaggio a piedi (con le proprietà avoidHighways e drivingOptions), l’effetto ottenuto non restituisce correttamente l’idea di un tragitto percorso nel medioevo. Per l’identico motivo, inoltre, i percorsi ripercorrono più volte le stesse strade creando una confusione grafica che non permette di capire né la direzione e neppure l’ordine di marcia.

c.

Con il secondo esperimento si è pensato invece di sfruttare la classe Polyline di Google e la possibilità di animare i simboli lungo l’intero segmento.

var linea_simbolo = {

path: google.maps.SymbolPath.FORWARD_CLOSED_ARROW };

var line = new google.maps.Polyline({

path: [{lat: 44.112518, lng: 9.959700}, {lat: 44.0596534, lng: 10.0027959}, {...},{...}], icons: [{ icon: linea_simbolo, offset: ‘100%’ }], map: map }); animateArrow(line); } function animateArrow(line) { var count = 0; window.setInterval(function() { count = (count + 1) % 200; var icons = line.get(‘icons’);

icons[0].offset = (count / 2) + ‘%’; line.set(‘icons’, icons);

}, 20); }

Grazie a questo metodo era possibile visualizzare una freccia (o un altro simbolo) lungo l’intero percorso, ma questo significava anche essere costretti a guardare l’intera animazione per riuscire a comprendere il percorso. Il risultato che si otteneva era quindi una inefficiente freccia animata, che forniva ben poche informazioni visuali dell’itinerario del vescovo.

Contestualmente ho cercato di separare il percorso in più segmenti (uno per ogni due tappe) e animarli singolarmente: anche questa soluzione, però, risultava insoddisfacente, in quanto l’esito finale rappresentava una moltitudine di frecce che si muovevano contemporaneamente, dando l’effetto di guardare un formicaio sulla mappa.

La soluzione finale adottata è stata quindi quella di unire questi due ultimi esperimenti, fornendo però la possibilità o di gestire il percorso in ogni singola fase o di osservarlo nella sua interezza.

Le funzioni per gli spostamenti

Una volta compreso che non era possibile utilizzare le indicazioni di Google e che l’utilizzo delle polilinee sarebbe stato più efficace, ho proceduto a programmare una funzione base per la creazione di una singola linea ed in seguito altre funzioni che avrebbero utilizzato questo segmento per diversi scopi.

 La funzione percorso(p1, p2) genera una polyline che ha come vertici due posizioni geografiche inserite come parametro. Per rendere l’effetto più accattivante questa linea è stata trasformata in una curva di Bezier. Questa funzione base permette il massimo grado di flessibilità per la gestione del percorso poiché, a seconda dei casi, si può animare la freccia che la compone per creare l’effetto di movimento oppure collegare più linee per creare un percorso unico.

 Nella funzione createButtons() ad esempio è stata inserita la possibilità di visualizzare ogni singolo spostamento a seconda del pulsante cliccato. In questo caso la linea avrà come vertici i luoghi del documento selezionato e di quello precedente ad esso.

 Le funzioni animaPercorso() e animateArrow() servono invece per creare un insieme di segmenti che compongono l’itinerario del vescovo e a gestire ogni singola linea e la sua animazione. In pratica, ogni volta che appare una linea, la freccia si anima e, quando questa raggiunge la fine del segmento, appare una nuova linea animata. L’effetto creato permette di visualizzare l’itinerario completo senza però quella confusione che si verrebbe a creare se si visualizzassero tutte le linee contemporaneamente.

• La funzione animazionePercorso() invece serve per la gestione dell’itinerario. A seconda del pulsante premuto nella lista “Gestione percorsi” genera un effetto diverso che può essere l’animazione dell’itinerario, la visualizzazione del percorso intero o l’eliminazione delle linee.