OSMit2009

Venerdi’ 5 giugno e sabato 6 giugno a Trento si e’ tenuta la prima conferenza italiana OpenStreetMap!
Osptite d’onore con sorpresa di tutti: Steve Coast!!!

Gruppone OSMit2009

Gruppone OSMit2009


da sx: Simone Cortesi, Steve Coast, io :-)

da sx: Simone Cortesi, Steve Coast, io 🙂


Interventi interessantissimi. Tania Fabrello di Piazza Telematica mi ha chiesto di affiancarla in un intervento che illustrava la positiva esperienza di Piazza Tech di Schio. Si sono tenute anche un paio di tavole rotonde. Una improntata sulla nuova licenza ODBL (OpenData BaseLicense) che sta avanzando: in compagnia di Steve e con l’aiuto di Simone Aliprandi e Andrea Rossato, giuristi “afferrati” in tema di licenze e copyleft, si e’ cercato di capire la “bonta’” della bozza attualmente proposta. Sembra che questa nuova licenza sia “buona”…..
Si e’ poi parlato di integrita’ del dato.
Mi piace sottolineare la risposta di Steve ad una domanda di Simone Cortesi:
Q: “Quando OSM sarà completo?”
A: “In the future!” 🙂

maemo mapper | again!

Sto testando alla grande maemo -mapper (applicativo per navigazione che gira su nokia internet tablet).
La navigazione avviene tramite pre-caricamento di un file GPX dal menu “Rotte”.
Il file GPX puo’ essere generato mediante alcuni servizi disponibili on-line. Ho testato openrouteservice.org che permette di generare un percorso definendo indirizzo di partenza e di arrivo. Si basa su dati openstreetmap e fornisce in output un file in formato GPX o XML. Il file GPX puo’ essere caricato in Maemo-mapper ma non contiene la descrizione del percorso tale da poter essere interpretato dal sintetizzatore vocale (disponibile solo previa installazione del pacchetto “flite”). Il file XMl invece contiene la descrizione del percorso ma non e’ caricabile in maemo-mapper: :-|.
In alternativa si possono usare i servizi forniti da http://gnuite.com/cgi-bin/gpx.cgi; si tratta di un servizio che sfrutta la “rete” di googlemaps :-|. In questo modo si ottiene un GPX interpretabile dal sintetizzatore vocale.
Sono alla ricerca di un modo per convertire il file XML fornito da http://www.openrouteservice.org in GPX “valido” per il navigatore di maemo-mapper. Tuttavia ho anche scoperto che esiste un progettino (mi pare mantenuto dal creatore di maemo-mapper, John Costigan) che ha il lodevole scopo di creare un sistema di definzione dei percorsi interno a maemo-mapper. Una descrizione si trova qui.

maemo mapper | navigazione

Maemo mapper funziona come navigatore, registratore di tracce, wpt,…
Per la navigazione ci sono due modi (non presenta un sistema di ricerca di indirizzi):

– 1. si pianifica in precedenza il percorso caricando una “rotta” da file GPX. Per un primo test mi sono appoggiato all’ottimo servizio di routing OpenRouteService.org.
Basta indicare l’indirizzo di partenza e si ottiene una descrizione del percorso (in aggiunta alla visualizzazione sulla mappa). Questo si puo’ scaricare in formato GPX.
Fatto questo lanciare MP. Dal menu’ scegliere “Rotte” -> “Apri” e selezionar eil GPX appena scaricato.
In questo modo viene visualizzato il tracciato in verde che verra’ seguito durante il routing.

– 2. se si e’ connessi alla rete dal menu’ selezionare Rotta -> Scarica.

Menu -> Rotta -> Scarica

Compare una finestra di impostazione della posizione di partenza e di arrivo (si puo’ scegliere se usare l’ttuale posizione GPS come partenza) . Inserire l’indirizzo della partenza e della destinazione (avendo impostato prima il “Router” che puo’ essere Goole o Yandex). Dare Ok e vedremo visualizzata in verde sulla mappa la traccia che indica il percorso da fare. Se abbiamo installato anche il sintetizzatore vocale comincera’ a parlarci per dirci cosa far :-).

Impostazione della rotta da percorrere

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!

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.

Render di dati OSM con Mapnik: uno stile slippy map like

Da un po’ di tempo sto cercando di approfondire Openlayers. Tra le tante cose sto cercando di creare delle tiles “in casa” attraverso Mapnik e di “vestirle” con uno stile per quanto possibile simile alla slippy map do OSM.
Per il render con Mapnik è necessario disporre di un file (notoriamente ma non ncecessariamente chiamato osm.xml) per l’impostazione degli stili di render delle way, dei simboli, ecc… alle varie scale. Attualmente non è disponibile un osm.xml che crei in maniera fedele lo stile della slippy map. Per questo motivo ho cercato di crearne uno a partire dal file reperibile da qui.

Le modifiche fatte sono, per ora, molto ridotte ma consentono di ottenere delle tiles un po’simili a quelle di OSM. Il file per gli stile è scaricabile da qui. Il formato è l’odt (wordpress non consente di caricare file XML). L’intenzione è di rendere disponibili i futuri aggiornamenti. Stay tuned sul link riportato.

Mapnik | un tiles cacher di dati OSM

Creare delle tiles a partire dal db OSM? Si può fare in locale. Come? Basta installare Mapnik, Postgresql con estensione spaziale postgis e scaricare un planet di OSM.

Ecco come ho fatto i miei test. Molto probabilmente non è la strada più diretta e corretta, ma a volte “smazzarsi” un po’ di codice e un po’ di errori aiuta a comprendere un po’ di più le cose. In questo/i post faccio riferimento a operazioni svolte con Debian (Lenny).

Partiamo dall’inizio:-

– installare Postgresql con estensione spaziale postgis (per questo rimando alle pagine relative);

– installare mapnik con

# apt-get install mapnik (oppure tramite “synaptic”);

– reperiamo i dati del planet che ci interessa: io ho scaricato il planet italiano da qui. Si ottine il file italy.osm.bz2.

– creare il database che riceverà i dati. Diventare utente postgres e creare il db con:

# createdb -E UTF8 -O sit osm

dove “osm” è il nome del db e “sit” è il nome dell’utente

– creare il linguaggio per il db:

# createlang plpgsql osm

– aggiungere le tabelle per fare in modo che sia un geodb:

# psql -d osm -f /usr/share/postgresql-8.3-postgis/lwpostgis.sql

– Fare in modo che le tabelle spaziali siano di proprietà dell’utente sit:

# echo “ALTER TABLE geometry_columns OWNER TO sit; ALTER TABLE spatial_ref_sys OWNER TO sit;” | psql -d osm

– popliamo il db creato tramite “osm2pgsql”

# osm2pgsql -m -d osm /home/sit/osm/data/italy.osm.bz2

– posizionarsi nella home directory e lanciare il comando:

$ svn checkout http://svn.openstreetmap.org/applications/rendering/mapnik

In questo modo reperiamo una serie di file e directory già strutturate per effettuare le operazioni di rendering. Viene creata una directory “mapnik”.

– Posizionarsi in “mapnik”

$ cd mapnik

– scaricare gli SHP di linee di costa e boundary:

$ wget http://tile.openstreetmap.org/world_boundaries-spherical.tgz

$ tar zxvf world_boundaries-spherical.tgz

$ wget http://hypercube.telascience.org/~kleptog/processed_p.zip

$ unzip processed_p.zip

$ mv coastlines/* world_boundaries/

$ rmdir coastlines

– spostarsi nella directory world_boundaries:

$ cd world_boundaries

$ wget http://tile.openstreetmap.org/shoreline_300.tar.bz2

$ tar xvjf shoreline_300.tar.bz2

– fare una copia del file set-mapnik-env e chiamarla, per esempio, z0-set-mapnik-env.

$ cp set-mapnik-env z0-set-mapnik-env

– editare questo file indicando il nome corretto del database postgresql da usare ed il nome corretto dell’utente che ha accesso al db stesso. Nell’header del file c’è una chiara e semplice spiegazione dei settaggi.

– lanciare il comando:

$ source ./z0-set-mapnik-env

– poi:

$ ./customize-mapnik-map >$MAPNIK_MAP_FILE

– creare una copia del file generate_tiles.py (chiamarla i.e. “z0_generate_tiles.py”) e modificarla adattando la bbox alla zona di interesse. Nel mio caso, dovendo operare in un’area ristretta della Provinica di Vicenza ho editato nel modo seguente (riporto un estratto della parte finale del file, l’unica modificata). Basta commentare le parti da omettere con un “#” seguito da uno spazio ” “.

—————————————————————————————————

# Change the following for different bounding boxes and zoom levels

#

# Start with an overview

# World

# bbox = (-180.0,-90.0, 180.0,90.0)

# bbox = (11.0,45.0, 12.0,46.0)

# render_tiles(bbox, mapfile, tile_dir, 0, 0, “World”)

# minZoom = 10

# maxZoom = 16

# bbox = (-2, 50.0,1.0,52.0)

# render_tiles(bbox, mapfile, tile_dir, minZoom, maxZoom)

# Montecchio Maggiore

bbox = (11.37,45.47, 11.45,45.56)

render_tiles(bbox, mapfile, tile_dir, 1, 12 , “Montecchio”)

# Muenchen

# bbox = (11.4,48.07, 11.7,48.22)

# render_tiles(bbox, mapfile, tile_dir, 1, 12 , “Muenchen”)

—————————————————————————————

– infine lanciare il comando che genera la tiles

$ ./z0_generate_tiles.py

Nella directory “tiles” vengono generate le tiles (appunto :-)).

Le immagini così generate (PNG) possono essere usate in locale in caso di mancanza di connessione alla rete o solo per caricare dati locali invece di doverli scaricare dai server OSM. A titolo di esempio riportiamo il caso di un applicativo basato su Openlayers. In questo caso basta indicare un nuovo layer (nella pagina HTML che visualizzerò i dati) con la seguente sintassi:

———————————————————————————————————————————————————————

var newLayer = new OpenLayers.Layer.OSM(“Mapnik@home”, “http://localhost/openlayer/tiles/”, {numZoomLevels: 19});

map.addLayer(newLayer);

———————————————————————————————————————————————————————

dove http://localhost/openlayer/tiles/” è il percorso locale per raggiungere le immagini PNG (questa direcotry deve essere accessibile all’utente www-data).

Sotto è riportato un esempio di render di dati OSM realizzato con mapnik; il tutto visualizzato con tramite Openlayers.

Esempio di render effettuato con Mapnik e visualizzato mediante Openlayers

Esempio di render effettuato con Mapnik e visualizzato mediante Openlayers

Conversione di uno Shapefile in GML

Con Openlayers è possibile visualizzare dati provenienti da server diversi: Googlemaps, Yahoo!, OpenStreetMap,…. Ma non si ferma qui. C’è la possibilità di caricare dati propri (mediante overlay) siano essi vettoriali di tipo polygon, line o point. Esistono principalmente due modi per caricare dati vettoriali: GML oppure Vector mediante i costrutti “OpenLayers.Layer.GML” e “OpenLayers.Layer.Vector” (esiste anche la possibiltà di inserire punti mediante file di testo).

Ho fatto dei test usando il formato GML. Funziona! Lavorando con i sistemi Gis in genere si hanno a disposizione file in formato SHP. La conversione può essere fatta mediante ogr2ogr; il comando è il seguente:

$ ogr2ogr -f GML nome_file.gml nome_file.shp

In questo modo si ottiene un file in fromato GML utilizzabile da openlayers.

Openlayers | il webgis nel sito della nonna

Il titolo di questo post è ovviamente scherzoso: non voglio togliere nulla alle nonne!
Ma uno strumento come openlayers merita davvero data la sua semplicità: consente di “annegare” all’interno di pagine HTML del codice javascript per visualizzare un webgis perfettamente funzionante. Se poi questo webgis consente di utilizzare i dati di Openstreetmap abbiamo fatto Bingo! Ed è proprio così.

Sullla pagina principale del progetto sono riportate le righe di codice da copiare e incollare su una propria pagina e vederne il funzionamento: provare per credere. Certo, come tutti gli strumenti offerti dal mondo open source, le cose che si possono fare sono tantissime, più o meno complesse/complicate. Sto cercando di mettere in piedi una serie di “applicativi” o meglio “soluzioni” che sfruttano openlayers per caricare dati OSM a cui sovrapporre dati “custom”. Esempio: un amministrazione comunale può essere invogliata a liberare i suoi dati cartografici (e quindi, ovviamente, concederne l’uso per OSM) e su questa base georiferire una serie di informazioni. Penso alla localizzazione di servizi, punti di interesse, cantieri in essere e/o previsti, localizzazione di qualsiasi cosa ritenuta importante ai fini della gestione della macchina comunale.

Openlayers è una raccolta di librerie in javascript che permettono di visualizzare cartografia in una qualsiasi pagina HTML senza avere bisogno di installare alcunchè sul server. Tutto funziona via javascript. Consente di caricare dati da googlemaps, yahoo!,…..e anche OSM!

Questo è il primo di una serie di post che vorrei pubblicare. Se non altro per stare in linea con lo scopo di questo blog (una sorta di quadernone degli appunti) e costruire una documentazione per quanto possibile esaustiva sull’utilizzo di questo strumento a mio avviso eccezionale.
Ad altro post un esempio di codice per la localizzazione di elementi puntuali (in formato GML) con visualizzazione a popup (cloud) degli attributi facendo click su uno di essi.

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!