QGIS hackfest a Pisa – 18-22 marzo 2010

E’ ufficiale: si terra’ a Pisa, dal 18 al 22 marzo 2010, presso il Parco di San Rossore-Migliarino-Massaciuccoli (sala Gronchi) il 3° QGIS hackfest:Gli sviluppatori di QGIS si troveranno per dare forte impulso allo sviluppo del progetto, risoluzione di bug, traduzioni,….Molto probabilmente ci sara’ la possibilita’ di seguiri anche alcuni flashcourses (tipo “Scrivere un plugin in python per QGIS”); a pagamento, in modo da avere le risorse per pagare la trasferta agli sviluppatori che vengono a donare il loro tempo.

Si puo’ partecipare a molti livelli diversi, dal supporto logistico, all’hard coding, passando per la documentazione, traduzione, bug checking, e molte altre cose.
Per ulteriori informazioni contattare Paolo Cavallini (cavallini at faunalia dot it).

pgrouting | calcolo percorso minimo tra due punti

Prima di tutto e’ necessario creare un database Postgresql ed aggiungerci l’estensione spaziale Postgis.

come utente postgres si entra in un database esistente o in un template:

# psql template1;

– Creiamo il database e impostiamo la proprietà all’utente (nel nostro caso “sit”):

template1=# CREATE DATABASE routing OWNER sit template template_gis;

il template_gis e’ stato creato a priori (database con estensioni spaziali postgis incorporate; questo per evitare ogni volta di dover aggiungere le tabelle “geometry_column” e “spatial_ref_sys”);

– Ci colleghiamo al database appena creato:

template1=# /connect routing;

e diamo i permessi necessari all’utente “sit” sulla tabella spaziali:

routing=# GRANT ALL ON geometry_columns to sit;
routing=# GRANT SELECT ON spatial_ref_sys to sit;

– Aggiungiamo le funzioni di routing (dopo essere usciti dal database ed esserci autenticati come utente “postgres”):

# psql -d routing -f /usr/share/postlbs/routing_core.sql

# psql -d routing -f /usr/share/postlbs/routing_wrappers.sql

# psql -d routing -f /usr/share/postlbs/routing_topology.sql

– Reperiamo i dati: nel mio caso ho reperito il planet italiano dal sito http://download.geofabrik.de/osm/europe/. Ho scaricato gli SHP. Dopo aver fatto un clip dei dati sul confine regionale di interesse (Veneto) medianti i preziosissimi ftools di qgis ho ottenuto il grafo stradale del territorio veneto.

– Importiamo i dati del database mediante il modulo shp2pgsql. Ecco la sintassi del comando (con SRID settato a 4326, i dati sono in lat-long WGS84).

$ shp2pgsql -S -s 4326 /home/sit/geodatabase/shp/stradario_regione/stradario_regione_seg.shp stradario_regione routing > /home/sit/sql/stradario_regione.sql

$ psql -h localhost -U postgres -d routing -f /home/sit/sql/stradario_regione.sql

Per i passi successivi ho seguito questo ottimo tutorial ):

– Aggiungiamo 3 colonne alla tabella: una per memorizzare gli ID dei nodi iniziali, una per gli ID dei nodi finali e la’ltra per la lunghezza:

routing=> ALTER TABLE stradario_regione ADD COLUMN source integer;

routing=> ALTER TABLE stradario_regione ADD COLUMN target integer;

routing=> ALTER TABLE stradario_regione ADD COLUMN length double precision;

– Creiamo la topologia e aggiungiamo il valore della lunghezza al campo appena creato:

routing=> SELECT assign_vertex_id(‘stradario_regione’, 0.0001, ‘the_geom’, ‘gid’);

routing=> UPDATE stradario_regione SET length = length(the_geom);

– Creiamo gli indici per le colonne “source”, “target” e “the_geom”;

routing=> CREATE INDEX source_idx ON stradario_regione(source);

routing=> CREATE INDEX target_idx ON stradario_regione(target);

routing=> CREATE INDEX geom_idx ON stradario_regione USING GIST(the_geom GIST_GEOMETRY_OPS);

– Impostiamo la query di routing e salviamo il tutto in una nuova tabella chiamata “dijkstra_resust” (prima di tutto cancelliamo una eventuale tabella omonima precedentemente creata):

routing=> DROP TABLE IF EXISTS dijsktra_result;

routing=> CREATE TABLE dijsktra_result(gid int4) with oids;

routing=> SELECT AddGeometryColumn(‘dijsktra_result’, ‘the_geom’, ‘4326’, ‘MULTILINESTRING’, 2);

routing=> INSERT INTO dijsktra_result(the_geom) SELECT the_geom FROM dijkstra_sp(‘stradario_regione’, 73441, 13547);

Questa query trova il percorso minimo tra due vertici (con ID pari a 73441 e 133547).

In prima battuta, nel mio caso, ho ottenuto un messaggio d’errore per violazione di un CONSTRAINT:

ERROR: new row for relation “dijkstra_result” violates check constraint “enforce_geotype_the_geom”

Ho cancellato questo constraint (via pgadmin3) e re-impartito la query ottenendo la nuova tabella dijkstra popolata. Il risultato si può visualzzare in qgis.

GRASS | il modulo v.distance

Dati due vettori in GRASS, uno lineare (rete dell’acquedotto) ed uno puntuale (localizzazione degli idranti) mi si era posto il problema di “travasare” un dato relativo alle tratte di acquedotto (nel caso particolare il diametro della condotta) nella tabella attributi degli idranti. Lo scopo era quello di conoscere il diametro della tratta che forniva ogni idrante.

Spulciando tra i moduli di GRASS (grandissimo GRASS! :-)) ho trovato v.distance. Questo modulo consente di trovare gli oggetti che si trovano ad una certa distanza (in base ad una threeshold impostata) da una serie di oggetti puntuali; inoltre permette di salvare attributi degli oggetti più vicini “agganciandoli” aquelli sorgente.

Ecco un dettaglio dei dati che avevo a disposizione:

– un vettore lineare chiamato “rete_acqua” con una serie di attributi tra cui il diametro della tratta (colonna chiamata “diametro“);

– un vettore puntuale chiamato “idranti” con una serie di attributi ai quali voglio aggiungere un ulteriore dato relativo al diametro della condotta; per memorizzare questo attributo ho creato una nuova colonna “sezione_co“;

– il comando in GRASS per ottenere il risultato voluto e’:

v.distance from=idranti to=rete_acqua upload=to_attr to_column=diametro column=sezione_co out=v_distance_idranti_rete

Consultando la tabella attributi del vettore “idranti” vediamo che la colonna “sezione_co” e’ stata aggiornata con i valori di “diametro” della tratta di acquedotto piu’ vicina.

da google maps a………………qgis

Un amico mi ha postato il link ad una “sua” mappa creata in gmaps nella quale ha inserito alcuni punti per i propri scopi.
Mi ha chiesto se era possibile recuperare i dati geo-localizzati in quella mappa (salvarli in formato digeribile da un gis) per effettaure ulteriori elaborazioni.
Ho scoperto (googolando un pochino) che sono sufficienti pochi passaggi per ottenere i “propri” dati in formato KML.
Procedere some segue:

– aprire il link della mappa;
– click con tasto dx su “Visualizza in google earth” -> copy link to the clipboard
– incollare sulla barra degli indirizzi sostituendo il pezzo di stringa [output=nl] con [output=kml].
– dare invio: viene chiesto di salvare il file in formato .kml
– aprire il file con qgis.

A questo punto si può salvare in SHP, importare in Posgis, Grass e fare le opportune elaborazioni.

qgis | compilazione in Debian

Mi sono buttato nella compilazione di qgis.
Grazie alle dritte di Paolo Cavallini ho provato per la prima volta su Debian Lenny.

A distanza di qualche mese ho riprovato tutta la procedura di Debian Sid: le istruzioni qui riportate fanno riferimento a questa distribuzione.
Ad oggi (settembre 2011) i sorgenti di QGIS sono reperibili su github e non più su SVN. Pertanto la procedura riportata qualche mese fa (la tengo comunque per memoria e viene indicata in coda al post in grigetto) viene aggiornata.

Tutto quanto segue è spiegato benissimo in questa pagina wiki di QGIS. Unica differenza: il comando per il recupero dei sorgenti da git hub indicato “git clone git://github.com/qgis/Quantum-GIS.git” non funziona. Dopo qualche secondo compare un messaggio di time-out. Sostituendolo con il seguente “git clone https://github.com/qgis/Quantum-GIS.git” (come indicato qui:”http://www.qgis.org/wiki/Using_Git“) tutto funziona a dovere.

Riporto qui i passaggi importanti testati su Debian Sid (unstable).

– Preparazione dell’ambiente installando i pacchetti necessari via apt-get (o synaptic):

# apt-get install build-essential debhelper bison cmake doxygen flex graphviz grass-dev libexpat1-dev libfcgi-dev libgdal1-dev libgeos-dev libgsl0-dev libpq-dev libproj-dev libqt4-dev libqtwebkit-dev libqwt5-qt4-dev libspatialite-dev libsqlite3-dev pkg-config pyqt4-dev-tools python python-dev python-qt4 python-qt4-dev python-sip python-sip-dev txt2tags

– Creiamo le directory necessarie:

$ mkdir -p ${HOME}/dev/cpp

– poi ci spostiamo nella nuova directory “cpp”

cd ${HOME}/dev/cpp

– scarichiamo da github i sorgenti di QGIS con il comando:

$ git clone https://github.com/qgis/Quantum-GIS.git

Questo crea una nuova directory “Quantum-GIS” e vi scarica all’interno i sorgenti.

– Ci spostiamo all’interno:

$ cd Quantum-GIS

– e creiamo una nuova directory “build-master”; al suo interno lanceremo la compilazione:

$ mkdir build-master

– Entriamo

$ cd build-master

e lanciamo ccmake

$ ccmake .. -Wno-dev

il sistema preparerà l’ambiente per la compilazione fornendoci una serie di opzioni.

– abilitare i “global python bindings” schiacciando INVIO (la voce cambia da “OFF” a “ON”)
– dare “c” (sta per “configure”). A questo punto possono presentarsi dei messaggi di errore. Nel mio caso mi avvertiva della mancanza di alcune librerie (libgsl e altro…). Uscire con “e”, poi “q” (quit) e installare i pacchetti necessari (se abbiamo installato come da istruzioni sopra, non dovrebbero comunque esserci problemi).

– dare nuovamente il comando “c” e poi “g” (sta per “generate”). Dovrebbe tornare la console; questo indica che tutto è pronto per la compilazione.

– Impartiamo ora il make. Facendo tesoro di un post di Alessandro Furieri in cui riporta un trucchetto eccezionale per velocizzare il processo di make lanciamo il comando

$ make -j4

il suffisso “j4” indica a make di eseguire la compilazione in 4 thread paralleli. Il risultato è una compilazione molto più veloce che sottopone la CPU ad un carico costante del 100% ca.

– Infine installiamo (da root) con il classico:

# make install

—————————————————————————————————————-

In alternativa alla compilazione diretta è possibile crearsi i pacchetti “.deb”. Per fare questo risaliamo di una posizione con:

$ cd ..

e poi diamo il comando (come root):

# dpkg-buildpackage -us -uc -b

Questo creerà tutti i pacchetti necessari nella directory “Quantum-GIS”.

Risaliamo quindi di una posizione e installiamo tutti i pacchetti con:

# dpkg -i *.deb

Durante l’installazione è comparso un messaggio d’errore: ” Si sono verificati degli errori nell’eleborazione: libqgis-dev”. Verificando le dipendenze di questo pacchetto mi sono accorto della mancanza di “qt4-designer”. Installato questo tutto è andato a posto.

<inizio vecchia procedura>

– Creare una directory di lavoro (es: compila_qgis):
$ mkdir compila_qgis
Spostarsi dentro la directory appena creata:
$ cd compila_qgis
E’ necessario avere installato alcuni pacchetti. Li installiamo:
# apt-get install subversion cmake flex bison libgsl0-dev libboost-python-dev python-eggtrayicon python-foomatic python-gnome2 python-gps python-gtkhtml2 python-gtkmozembed python-qt4-dev python-reportlab python-svn grass-dev libqt4-gui sharutils sip4 libqwt5-qt4-dev libqt4-core pyqt4-dev-tools qt4-qmake libqt4-dev libgdal-dev libncurses5-dev dpkg-dev debhelper libexpat1-dev libxext-devlibfontconfig1-dev proj libxi-dev libxrandr-dev libxrender-dev libice-dev libsm-devcmake-curses-gui

Molto probabilmente non tutti sono necessari ma averli non fa male 🙂
Poi scarichiamo l’svn con:
$ svn co https://svn.osgeo.org/qgis/trunk/qgis qgis_unstable
– creiamo le directory necessarie
$ mkdir qgis_unstable/build/
– ci spostiamo dentro:
$ cd qgis_unstable/build/
– diventare root e poi:
# ccmake .. -Wno-dev
– abilitare i “global python bindings” schiacciando INVIO (la voce cambia da “OFF” a “ON”)
– dare “c” (sta per “configure”). A questo punto possono presentarsi dei messaggi di errore. Nel mio caso mi avvertiva della mancanza di alcune librerie (libgsl e altro…). Uscire con “e”, poi “q” (quit) e installare i pacchetti necessari (se abbiamo installato come da istruzioni sopra, non dovrebbero cmq esserci problemi).
– ritornare in cmake con
# ccmake .. -Wno-dev
In questo modo si apre (sempre nella console) un pannello per impartire comandi di cmake (il compilatore).
– dare ancora il comando “c”, poi “g”: in questo modo si generano gli script necessari. Il pannello di cmake si chiude da se e ci ritroviamo con la console.
A questo punto risalire alla directory superiore con:
# cd ..
– lanciare il comando per la creazione dei .deb
# dpkg-buildpackage -us -uc -b
– vengono visualizzati una serie di log di comandi (nel mio caso, ad un certo punto si e’ fermato perche’ non trovava “grass-dev” e “libqt4-dev”; installato questi e re-impartito il comando di creazione dei pacchetti)
– si risale nuovamente di una posizione:
# cd ..
– si installano i .deb generati:
# dpkg -i *.deb

Se tutto e’ andato a buon fine ritorna la console con #.
Lanciare qgis:
$ qgis [INVIO]

Per le successive compilazioni basta impartire il comando:
$ svn up https://svn.osgeo.org/qgis/trunk/qgis qgis_unstable
in modo da aggiornare la versione SVN scaricata.
Poi continuare nuovamente con i comandi riportati sopra.
Può succedere che durante la fase di creazione del pacchetti “# dpkg-buildpackage -us -uc -b” venga riportato un errore di conflitti con alcuni pacchetti (nel mio caso qgis-dev e libqgis-dev). Rimuovere il pacchetto libqgis1.2.0-dev. Eventualmente (se non si conosce il nome del pacchetto) può essere utile usare il comando:
# dpkg –list | grep qgis
In questo modo troviamo tutti i pacchetti relativi a qgis e possiamo facillmente individuare quelli “scomodi”. Per rimuoverli (compresi i file di configurazione) impartire:

# dpkg –purge nome_pacchetto (p.e.: # dpkg –purge libqgis1.2.0-dev)

Quindi re-impartire il comando di creazione dei pacchetti.

</fine vecchia procedura>

OSM | data import

Il “fenomeno” OpenStreetMap (la mappa del mondo libera creata da migliaia di utenti in tutto il mondo) si sta diffondendo in maniera vertiginosa.
Al contributo degli utenti (i cosiddetti “mappers”) si aggiunge la sensibilita’ di alcune amministrazioni (detentrici di dati cartografici) che hanno “liberato” i dati cartografici. Per citare alcuni esempi in Veneto in ordine di “liberazione”: comune di Schio, comune di Montecchio Maggiore, comune di Vicenza.
Le delibere con le quali questi dati sono stati liberati parlano di utilizzo per qualsiasi scopo: in particolare possono essere utilizzati e caricati all’interno del Db del progetto OSM. Ma come si caricano questi dati?
Parlando di dati territoriali (in genere gestiti mediante sofware G.I.S. – Geographic Informazion System) vengono forniti in un formato standard in ambito GIS: il formato Esri Shape (brevemente SHP). Questo formato contiene informazioni relative alla geometria degli oggetti che rappresenta (coordinate dei vertici) e informazioni alfanumeriche (tabelle degli attributi) associate agli oggetti. In ambito OSM questo e’ importante in quanto consente di mantenere attributi quali il nome della strada, il tipo di strada, ecc.
Tecnicamente bisogna anche affrontare un problema relativo al sistema di proiezione usato per rappresentare questi dati. I dati di OSM sono in coordinate lat-long (latitudine-longitudine) che in termini di EPSG code (codice mondiale per l’identificazione di un sistema di coordinate) corrisponde a 4326.
Mentre i dati forniti dalla amminstrazioni (Veneto in particolare) sono in Gauss-Boaga (fuso Ovest nella nostra zona, Vicenza).
Si tratta quindi di convertire i dati dal sistema Gauss-Boaga (codice EPSG 3003) al WGS84 (codice EPSg 4326).
Per fare questo ci sono piu’ metodi e/o software (nel campo del software libero in particolare). In genere io agisco in questo modo (ma non e’ il modo migliore, solo quello che mi pare piu’ comodo e che mi permette di fare controlli nei passaggi di conversione).
– Importazione deggli SHP in GRASS mediante il modulo v.in.ogr;
– riproiezione dei vettoriale così ottenuti dal sistema 3003 al 4326 mediante il modulo v.proj;
– esportazione dei vettori riproiettati in SHP (nuovamente);
– Eventuale modifica/correzione/aggiunta di attributi delle tabelle alfanumeriche collegate. Cito per es. il caso dei dati del Comune di Vicenza. Gli SHP fornitici (molto ben fatti, tra l’altro) conservavano solo il nome della strada (ma e’ gia’ molto importante questo). Mediante Qgis ho modificato la tabella degli attributi aggiungendo un campo “highway” popolato per tutti con “unclassified” ed un campo “source” popolato per tutti con “Comune di Vicenza”.
– Conversione degli SHP in OSM mediante lo script shp2osm reperito da qui. Si tratta di uno script in perl (e’ necessario avere installato Perl). Il comando per lanciarlo e’:
$ perl shp2osm nome_file.shp > nome_file.osm
In questo modo viene salvato l’output di elaborazione del processo nel file nome_file.osm;
– JOSM: apertura del nuovo nome_file.osm creato e download della zona di interesse dal server OSM.
A questo punto abbiamo due layers: nome_file.osm e data.osm.
– Adesso il lavoro diventa delicato: si tratta di vedere quali sono le strade non ancora presenti nel DB osm. Attivando alternativamente i 2 layers si vedono le differenze.
Caso 1: strada non presente nel db OSM: e’ il caso piu’ semplice (relativamente :-)). Selezionare la strada (o le strade tenendo premuto il tasto “Shift” da tastiera), selezionare la voce “Copy” dal menù “Edit”. Rendere attivo il layer di OSM e dal menù “Edit” selezionare “Paste”. In questo modo abbiamo copiato gli oggetti selezionati nel nuovo layer. Controllare i nodi di intersezione con le altre strade per verificarne il merge. Se la parte terminale di una strada si avvicina ad un vertice di una strada esistente selezionare i due nodi e schiacciare il tasto “M” (merge). Se la parte terminale si avvicina ad un arco (privo di nodi in prossimità) selezionare il nodo finale della nuova strada importata e schiacciare “J” (Join) per unire le due strade nella prossimità di quel punto. (Attenzione: a volte schiacciando il tasto “J” non succede niente. Questo e’ dovuto ad una distanza troppo grande tra vertice e arco. La tolleranza non rileva la presenza del nodo. Per ovviare a questo “avvicinare” il vertice all’arco e riprovare con “J”). Controllare poi i dati legati agli oggetti. Se tutto è in ordine la strada può considerarsi a posto.

sovrapposizione dati OSM e dati ottenuti dalla conversione SHP2OSM
sovrapposizione dati OSM e dati ottenuti dalla convrsione SHP2OSM

Caso 2: strada gia’ presente nel db (layer) OSM: e’ il caso più delicato. In questo caso si verifica la “vicinanza” delle due tracce. Spesso lascio le tracce presenti limitandomi a verificare il merge dei nodi e la coerenza deggli attributi. Scostamenti notevoli si hanno soprattutto nelle zone del centro storico o nelle strade in cui si presenta “l’effetto canyon” (il segnale del GPS viene disturbato dalla presenza di edifici alti su entrambi i lati della strada). In questo caso rettifico la traccia pesente adattandola a quella importata. E controllo merge dei nodi e “allineamento” degli attributi.
Alla fine si può procedere all’upload dei dati sul server.

Qgis | campagna mirata per risolvere bugs e tickets

Paolo Cavallini, presidente di gfoss.it e responsabile del settore finances & marketing (oltre ad altri importanti ruoli) del progetto qgis lancia una campagna per raccogliere fondi mirati alla risoluzione dei principali bugs del software gis open source qgis. Più siamo e meglio è 🙂

Questo il post girato in lista gfoss.it lunedì 27 aprile 2009:

“Com’e’ noto, nessun software e’ immune dai bugs, e qgis non fa
eccezione. Ho deciso di dare una mano in concreto per risolverne alcuni,
mettendo a disposizione qualche soldo per coinvolgere un paio di
sviluppatori in piu’ ed assegnare loro specifici bugs.
Si tratta quindi non di un finanziamento per il funzionamento generale
del processo, ma di uno mirato alla risoluzione di bugs specifici, da
erogarsi solo in caso di effettiva soluzione.
Se altri collaborano, il processo sara’ ovviamente piu’ rapido ed efficace.”

L’iniziativa è semplice: chi vuole propone un bug o ticket da risolvere e stanzia una cifra per stimolarne la risoluzione; lo sviluppatore valuta se quella cifra è congrua (ovviamente più siamo a “donare” e più aumenta la possibilità che il bug/tischet venga preso in considerazione).

Dal canto mio sollecito la soluzione di un ticket https://trac.osgeo.org/qgis/ticket/748 relativo alla digitalizzazione “in appoggio” a linee o parti di linee e/o parti di poligoni senza dover rincorrere i vertici “one by one”.
E’ attiva la pagina http://www.qgis.org/wiki/Bugs per contribuire.

Conversione di uno SHP da coordinate WGS84 a Gauss-Boaga Fuso Ovest (GB Fuso Ovest -> WGS84 nel commento)

Questo post è l’evoluzione di quello relativo a “GPX | magie con gpsbabel”. In quel post è descritta una procedura per convertire un file GPX (trk) in SHP (wpt) avente una tabella attributi popolata anche con il TIMESTAMP. Questo per consentire di “rincorrere” il percorso effettuato in base all’ora di interrogazione.

Tuttavia questa conversione di formato produce in output dati geografici in un sistema di coordinate universale per i GPS: il WGS84 (codice EPSG:4326).

E’ utile poter convertire tali dati anche in altri sistemi di riferimento; in particolare, lavorando in Veneto, è basilare convertire tutto in Gauss_boaga Fuso Ovest (codice EPSG:3003) quale sistema di riferimento adottato dalla Regione Veneto per la CTRN (Carta Tecnica Regionale Numerica). Per fare questo ci viene in aiuto un altro magico tool: ogr2ogr. E’ uno strumento che consente la conversione di svariati formati vettoriali, compresa la possibilità di convertirli da un sistema di riferimento ad un altro.

La sintassi del comando è di questo tipo:

$ ogr2ogr output.shp input.shp -s_srs EPSG:4326 -t_srs EPSG:3003

In questo esempio si effettua la conversione di un file SHP da WGS84 a Gauss-Boaga Fuso Ovest.

Ma il risultato che si ottiene non è buono: caricando lo SHP generato (es tramite Qgis) e sovrapponendolo alla CTRN si nota uno scostamento rigido verso nord-ovest.

Nell’immagine seguente si può notare lo scostamento rispetto alla reale posizione della strada.

 

traccia riproiettata senza parametri "+towgs84"

traccia convertita senza parametri "+towgs84"

Questo errore si può rimediare inserendo i parametri comprensivi di “+towgs84” in luogo di “-t_srs”. Pertanto il comando per ottenere una riproiezione corretta (ci sono ancora errori, ma notevolmente ridotti) è il seguente:

$ ogr2ogr gb_$nome_ref.shp $nome_ref.shp -s_srs EPSG:4326 -t_srs ‘+proj=tmerc +ellps=intl +lat_0=0 +lon_0=9 +k=0.999600 +x_0=1500000 +y_0=0 +units=m +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68’

Il risultato è questo:

qgis_si_towgs

traccia convertita con parametri "+towgs84"

Per continuare con il post precedente sopra citato ho aggiornato lo script in Perl già pubblicato. In sostanza lo script fa 4 cose:

– scarica i dati dal GPS (nel caso specifico un i-blue 747);

– converte le track (trk) in waypoint (wpt) per poter memorizzare il TIMESTAMP di ogni punto;

– converte il nuovo GPX in SHP (con tabella attribuiti ben popolata);

– converte lo SHP generato dal sistema WGS84 a Gauss-Boaga Fuso Ovest

Questo lo script integrale: script_trk2wpt

Se trovate imprecisioni commentate!