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!

GPX | magie con gpsbabel :-)

GPX è un formato di interscambio dati per dispositivi GPS. Sostanzialmenete è un file XML. Al suo interno vengono memorizzate, oltre alle coordinate X,Y e Z, anche altre informazioni quali DATE e TIMESTAMP. E proprio quest’ultimo dato è l’oggetto di questo post. Tutto è nato dalla necessità di salvare i dati recuperati via GPS in uno SHP (shape file: formato dati standard in ambito GIS) in modo da poter localizzare (mediante query) la mia posizione ad una determinata ora. Caricando un file GPX in Qgis vengono visualizzate tracce (trk), waypoint (wpt) e rotte (rte). Durante l’acquisizione della traccia vengono “taggati” n punti ogni TOT secondi (ho impostato la rilevazione della posizione in base al tempo). La traccia visualizzata diventa un record unico e ad essa sono abbinati una serie di dati. Ma in questo modo non riesco a risalire alla mia posizione; i dati sono riferiti al tracciato nella sua interezza. Esiste un tool davvero eccezionale: GPSBABEL. Consente una buona serie di “magie” per convertire dati GPX. In particolare è possibile convertire una traccia in una serie di wp. In questo modo ad ogni punto viene associato anche il momento in ci è stato rilevato. In seconda battuta si può trasformare il nuovo GPX con i wp in SHP mediante OGR2OGR o GPX2SHP. vediamo i passi necessari:

– trasformazione delle tracce in waypoint mediante gpsbabel:
$ gpsbabel -i gpx -f nome_traccia.gpx -x transform,wpt=trk -o gpx -F nome_wp.gpx

– conversione del GPX in SHp mediante gpx2shp:
$ gpx2shp -w -o nome_wp.shp nome_wp.gpx

Visto che questo lavoro dovrebbe processare una serie di tracce recuperate in tempi diversi da persone diverse ho predisposto (una vera operazione di hackeraggio artigianale vista la mia bassissima esperienza di programmazione) un piccolo e semplice script in Perl. Lo script ha come requirements la presenza di perl, gpsbabel e gpx2shp e deve essere eseguito all’interno della directory contenente i GPX da processare.
Lo script in formato PDF: gpx_trk2wpt_gpx2shp. Copiare il testo e incollarlo in un nuovo file. Dare un nome al file (Es: converter_gpx_shp.pl) con estesnione .pl e lanciarlo con:
$ perl converter_gpx_shp.pl
All’avvio viene chiesto il nome del GPX da elaborare (omettendo l’estensione .GPX) ed il nome da dare al file generato. A fine operazione vengono generati un nuovo GPX contente i WP delle tracce ed uno SHP con i WP stessi.
Questo SHP può essere caricato in Qgis per le opportune elaborazioni.

pmapper | export in XLS dei dati di una query

Pmapper: i dati visualizzati in forma tabellare quando si interroga la mappa con il pulsante di “interrogazione” o mediante ricerca possono essere esportati in formato PDF, CSV e XLS. Quest’ultima opzione non funziona di default. E’ necessario avere installato il pacchetto “pear”. In Debian procedere con:

# apt-get install php-pear

Viene scaricato e installato (come dipendenza) anche il pacchetto “php5-cli”

Una volta installato (da root) lanciare il comando: (reperito da qui):

# pear install -f OLE

poi

# pear install -f Spreadsheet_Excel_Writer

Fatto.