pgrouting | compilazione in debian Lenny

Ho provato ad installare l’estensione di postgresql-postgis per il routing chiamata pgRouting. Si tratta di una estensione che consente di effettuare analisi di reti.

Ho tentato la compilazione (in Debian Lenny) in quanto non esiste come pacchetto precompilato per debian. Questo perche’ la compilazione “canonica” dei sorgenti mi ritornava un errore in sede di “make”. Ho notato (alla fine di tutta la storia) che la creazione dei .deb e la loro installazione può risultare propedeutica alla compilazione canonica (se il lettore ha notizie certe che possono confermare o demolire questa ipotesi posti un commento al post; sarei molto felice di approfondire la questione). La creazione dei .deb che vediamo tra poco consente di installare solo la parte “core” delle librerie. Questo a causa della della mancanza delle librerie GAUL nei repos ufficiali (necessarie per il problema del TSP – Travel Sale Person) e delle CGAL (necessarie per le driving distance) rilasciate sotto licenza QPL, quindi non libere.

Per avere TSP e driving distance e’ pertanto necessario installare dai sorgenti, la cui compilazione va a buon fine (o almeno per me e’ stato cosi’) solo dopo l’installazione del “core” pacchettizzato debian.

Creazione dei pacchetti .deb delle core library (senza funzioni TSP e DD)

Prima di tutto ho scaricato i sorgenti da qui.

Seguendo le istruzioni riportati nel sito ho seguito i seguenti passi:

– diamo un controllo ai requirements: cmake ed i compilatori C e C++ li dovremmo trovare già installati nella nostra distro; mancano invece le librerie Boost Graph Library (BGL), le Genetic Algorithm Utility Library (GAUL, per il problema del “commesso viaggiatore”), e le librerie computazionali Geometry Algorithms Library (CGAL, per il driving);

– per installare le BGL ho usato apt-get (sono già nei repo di Lenny): # apt-get install libboost-graph-dev

– anche le CGAL si trovano: installate via synaptic;

– le GAUL invece le ho scaricate dal sito: una volta fatto, scompattare il sorgente e impartire i comandi riportati nella pagina di istruzioni indicata sopra. I comandi sono:

$ ./configure –disable-slang

$ make

# make install

Seguendo le istruzioni riportate su questa pagina (nascosta, in quanto non c’e’ link del sito che la punti) ho compilato le librerie a partire dall’SVN:

– creare una directory in cui scaricare i sorgenti (nel mio caso $ mkdir compila_pgrouting);

– spostarsi nella directory appena creata e lanciare: $ svn checkout http://pgrouting.postlbs.org/svn/pgrouting/trunk pgrouting

– spostarsi nella directory pgrouting: $ cd pgrouting e diventare root

– creare i paccheti con: # dpkg-buildpackage -b -rfakeroot -uc -us

– risalire di una posizione : # cd ..

– installare i pacchetti con: # dpkg -i *.deb

A questo punto bisogna aggiungere le funzioni di routing al database (che deve essere gia’ un database spaziale). NB: il database ci chiama routing nel nostro caso.

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

L’installazione copia due file con le istruzioni SQL. (routing_core.sql e routing_core_wrappers.sql). Seguendo i tutorial si notera’ che ad un certo punto, dopo avere importato i dati del database, e’ necessario creare la topologia dei dati. Per fare questo viene indicata una funzione “add_vertex_id” secondo questa sintassi:

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

dove:

– stradario_regione= nome tabella che contiene i dati;

– 0.0001= tolleranza di snap per la ricerca di nodi non collegati agli archi (espressa in unita’ di misua dei dati; nel mio caso avendo EPSG=4326 sono decimillesimi di grado);

– the_geom=colonna geometrica della tabella interessata;

– gid= colonna con gli id degli oggetti (solitamente la colonna “gid”).

In prima battuta, lanciando la query ho ottenuto questo messaggio:

ERROR: function assign_vertex_id(unknown, numeric, unknown, unknown) does not exist

Infatti, navigando all’interno del database, nella sezione “Function” dello schema “public” non si trova una funzione chaimata “add_vertex_id”. Scrivendo il lista pgrouting mi e’ stato indicato da Anton Patrushev (che ringrazio infinitamente) che le regole per la pulizia topologica sono state spostate in un file di struzioni SQL chiamato “routing_topology.sql”. Ma purtroppo questo file non viene copiato in “usr/share/postlibs/” come gli altri due files indicati sopra (forse un bug?). Tuttavia questo file si trova nei sorgenti scaricati da SVN. Quindi ho copiato il file in “/usr”share/postlibs/” e lanciato l’istruzione (come utente postgres):

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

e magicamente la funzione “add_vertex_id” si trova tra le “Function” del database.

A questo punto ho re-impartito la query (dopo essere entrato nel db come utente “sit”) per la creazione della topologia:

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

e questo e’ l’output del comando:

NOTICE: CREATE TABLE will create implicit sequence “vertices_tmp_id_seq” for serial column “vertices_tmp.id”
CONTEXT: SQL statement “CREATE TABLE vertices_tmp (id serial)”
PL/pgSQL function “assign_vertex_id” line 14 at EXECUTE statement
assign_vertex_id
——————
OK
(1 row)

Aprendo i dati in qgis e interrogando un qualsiasi arco del grafo si nota che i campi “sorce” e “target” sono popolati con gli ID dei nodi iniziale e finale dell’arco stesso.

Compilazione integrale dei sorgenti

La compilazione integrale dei sorgenti (per avere le funzioni di TSP e driving distance) avviene come da manuale: ho seguito anche questa ottima guida.

– spostarsi nella directory ottenuta dalla scompattazione dei sorgenti di pgrouting, quindi:

– $ cmake -DWITH_TSP=ON -DWITH_DD=ON .

– $ make

– # make install

[ 16%] Built target routing_tsp
[ 50%] Built target routing_dd
[100%] Built target routing
Install the project…
— Install configuration: “”
— Installing: /usr/lib/postgresql/8.3/lib/librouting.so
— Installing: /usr/share/postlbs/routing_core.sql
— Installing: /usr/share/postlbs/routing_core_wrappers.sql
— Installing: /usr/share/postlbs/routing_topology.sql
— Installing: /usr/lib/postgresql/8.3/lib/librouting_tsp.so
— Installing: /usr/share/postlbs/routing_tsp.sql
— Installing: /usr/share/postlbs/routing_tsp_wrappers.sql
— Installing: /usr/lib/postgresql/8.3/lib/librouting_dd.so
— Installing: /usr/share/postlbs/routing_dd.sql
— Installing: /usr/share/postlbs/routing_dd_wrappers.sql

– Quindi ho aggiunto le funzioni TSP e DD al database “routing” creato in precedenza:

– (come utente postgres):

# psql -d routing -f /usr/share/postlbs/routing_tsp.sql (crea 1 funzione)

# psql -d routing -f /usr/share/postlbs/routing_tsp_wrappers.sql (crea 5 funzioni)

# psql -d routing -f /usr/share/postlbs/routing_dd.sql (crea 2 funzioni)

# psql -d routing -f /usr/share/postlbs/routing_dd_wrappers.sql (crea 1 funzione)

# ./configure --disable-slang

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.

conversione di DVD audio/video in mp3

Non sono un esperto di multimedia e derivati ma mi e’ capitato (mi è stato chiesto) di convertire la traccia audio registrata da DVD in formato MP3.

Ho trovato questo strepitoso programma: devidify.

Una volta scaricato scompattarlo e, da riga di comandoo, spostarsi all’interno della directory che si viene a creare.

Il programma si lancia con il comando:

$ ./devidify

Compare un’interfaccia grafica dalla quale si posso impostare vari parametri. In sostanza il programma effettua una scansione (tasto “Scan”) del lettore DVD alla ricrca di tracce. Se ne trova crea un elenco (i capitoli) nel quale si possono spuntare le tracce da convertire. Impostato tutto si lancia il ripping (tasto “Rip”) durante il quale vengono creati dapprima le tracce in formato WAV. In seconda battuta (in automatico) vengono convertiti in MP3.

A questo punto abbiamo “n” tracce MP3. Se vogliamo fonderle in un solo file ci viene in aiuto il programma “mp3wrap” (l’ho installato dai repository di Debian Lenny).

E’ un programmino che funziona solo da riga di comando con poche opzioni ma fenomenale. A titolo di esempio supponiamo di disporre di 4 file MP3 chiamati primo.mp3, secondo.mp3, terzo.mp3 e quarto.mp3 e vogliamo unirli per ottenre il file totale.mp3. Ecco la sintassi:

$ mp3wrap totale.mp3 primo.mp3 secondo.mp3 terzo .mp3 quarto.mp3

Fatto.

gpsbabel | 747A+

Attualmente possiedo un GPS data-logger della Transystem: l’iblue 747. Utilizzo mtkbabel per la gestione dei tempi di campionamento, per il download dei dati e per la cancellazione degli stessi.

Oggi ho provato il modello più recente: l’iblue 747 A+. Non funziona con mtkbabel. E’ necessario utilizzare il kernel linux > 2.6.29. Sulla mia Debian Lenny ho la versione 2.6.26. Che fare?

Ho cercato in rete ed alla fine ho trovato questa illuminante pagina: gpsbabel, again!

Il GPS in questione viene identificato come “/dev/ttyACM0” (per verificarlo lanciare il comando dmesg da console).

Per scaricare i dati mediante gpsbabel dare il seguente comando:

gpsbabel -t -w -i mtk -f /dev/ttyACM0 -o gpx -F out.gpx

In questo modo vengono scaricate le tracce (“t”), i waypoint (“w”) nel formato gpx e nel file di destinazione out.gpx. Fatto.

Per eliminare le tracce scaricate aggiungere “,erase” dopo la specifica del chipset “mtk“.

Impostare il colore delle frecce terminali di una polilinea con inkscape

Inkscape (programma free e open source per la grafica vettoriale) consente di creare linee e polilinee impostando anche i “terminatori”. Sono simboli pre-impostati come frecce, pallini, quadrati, ecc. Tuttavia, per default, quando si crea una linea di un determinato colore e si imposta il simbolo per le parti terminali, queste assumo il colore nero. Per fare in modo che linea e simboli abbiano lo stesso colore e’ necessario selezionare la linea in oggetto, poi dal menu’ degli strumenti andare su: Effects -> Modify Path -> Color Markers to Match Stroke.

Per la versione in italiano, come giustamente indicato da Michele (che ringrazio!) nel suo commento: Effetti -> Modifica tracciato -> “Uniforma colore delimitatori e contorno”

E come cita l’home page del sito di inkscape: “Draw Freely” 🙂

Settimana del software libero a Vicenza

Dal 14 al 19 settembre si terra’ a Vicenza (Parco Citta’) la “settimana del software libero” organizzata dal LUG Vicenza (un grazie particolare a Luca!). Grazie alla disponibilita’ dei proprietari di “Parco Citta’”, che hanno messo a disposizone degli spazi, sara’ possibile toccare piu’ da vicino il pinguino.
Gli appuntamenti sono densi e ricchi. A questa pagina si trovano i dettagli di tutti gli eventi.
Mi permetto di segnalare gli incontri previsti per mercoledi’ 16 settembre. Si parlera’ di OSM. OpenStreetMap e’ un progetto mondiale che mira a creare una mappa (si, la mappa geografica e stradale) libera di tutto il mondo. Contribuire e’ semplice e non servono particolari skill o professionalita’……..Per chi e’ curioso di saperne di piu’, appuntamento a Parco Citta’. 🙂

Settimana del software libero a Vicenza - Volantino by Andrea Lazzarotto

Postgis | calcolare la lunghezza totale di uno strato lineare

Postgis offre 1000 strumenti per l’analisi spaziale. Una di queste, semplice quanto efficace, e’ la possibilita’ di calcolare la lunghezza totale degli oggetti memorizzati in una tabella di tipo LINESTRING.

Per esempio possiamo porci questa domanda : qual e’ la lunghezza totale delle strade, espressa in Km?
Procediamo:

– connettersi al database con psql:

$ psql -h nome_host -U nome_utente nome_database;

– una volta entrati (dopo aver digitato la password) impartire la seguente istruzione SQL:

nome_database=> SELECT sum(length(the_geom))/1000 AS km_roads FROM nome_tabella;

Nel mio caso ho ottenuto:

km_roads
——————
187.869370073215

che rappresenta la lunghezza totale espressa in Km.

Nel caso si volesse recuperare la lunghezza delle strade distinte per categoria (o meglio “classificazione”):

nome_database=> SELECT classifica,sum(length(the_geom))/1000 AS km_roads FROM grafo_new GROUP BY classifica;

In questo modo si ottiene la lunghezza distinta per classificazione di strade

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