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.

maemo-mapper | nokia N810

Mi e’ arrivato il Nokia N810. Diversamente da quello che si può pensare parlando di Nokia, l’N810 e’ tutto tranne un telefono :-).
E’ basato su SO Maemo (Debian based).
Ho “tribolato” un pochettino prima di riuscire ad installare maemo-mapper. Ma alla fine ci sono riuscito.
Inizialmente il problema era dovuto al fatto che non tutti gli ISP (Internet Service Provider) possono accedere ai repository di maemo: dalla rete aziendale infatti venivano bloccati gli accessi. Trovata la rete giusta sono riuscito a recuperare la lista dei pacchetti da una serie di report recuperati da qui.
Cercando di installare l’applicazione dal gestore delle applicazioni mi risultavano errori di dipendenze non risolte con alcune librerie: libgdbm3, libglib2.0-0,libhildonfn2, libhildonhelp0, libosso1. Ho “smazzato” la rete per un po’ fino a quando ho trovato un post illuminante per installare un piccolo pacchetto che consentisse di autenticarsi come root (per la console) e agire via apt-get. Il pacchetto installato si chiama “easyroot”. Una volta installato lanciare la console e digitare
$ sudo gainroot
A questo punto il prompt cambia presentando il “famoso” cancelletto (#) di root.
Da li ho lanciato un
# apt-get update
# apt-get dist-upgrade
# apt-get install maemo-mapper
Durante questa fase viene chisto se installare o meno software non autenticato con alternative di risposta [y,N].
Bisogna rispondere con una “s” se si intende installare (usa la lingua di default del sistema; nel mio caso l’italiano). Schiacciando “y” come proposto si presenta un “aborted”. Superato questo scoglio l’installazione e’ andata liscia. Al primo lancio lo stupore: gran software!!! Usa OSM come cartografia di base…ma questo e’ solo l’inizio.
Un’ottima guida per iniziare con maemo-mapper si trova qui
Il Nokia N810 e’ dotato di ricevitore GPS integrato. Ma non si “viaggia” bene con questo dispositivo. L’aggancio dei satelliti richide tempi lugnhi (>5 minuti quando va bene). Ho provato (come indicato in varie guide reperite dalla rete) a collegalo via BT all’iblue 747. Durante la connessione viene richiesto di inserire il codice di accesso. Ho perso un tot di tempo per capire che bastava inserire “0000” (quattro zeri). Dopo di chè l’aggancio e’ stato quasi immediato!