ATTENZIONE: il Progetto Strade è da considerarsi defunto! Collaboriamo invece a OpenStreetMap e a tutto il suo indotto.

Creare un database su PostGIS, alimentarlo con i dati prelevati dal GPS utilizzando gpsbabel e ripuliti con QGIS (magari!) oppure GRASS. Presentare i dati con MapServer. Vedere l'integrazione con dati vettoriali liberamente disponibili tipo VMap0.

OpenStreetMap ha optato per la Creative Commons, Attribution-ShareAlike (brevemente CC By-SA). Dopo aver seguito la discussione sulla mailing list siamo in perfetta sintonia ed usiamo la stessa licenza nella sua ultima versione 2.5. Qui una pagina wiki dove OpenStreetMap discute il problema della licenza.

Le obiezioni principali alla licenza ShareAlike riguardano su cosa è da intendersi lavoro derivato, ma la licenza è abbastanza chiara in propostio. Generalmente si può dire questo: No, non puoi distribuire lavori derivati prendendo dati CC-By-Sa e dati non-CC-By-SA.

• Interfaccia web per upload file GPX.
• Pagina MapServer.
• Pagina per il download dei dati.

• http://www.openstreetmap.org/
• http://freemap.vm.bytemark.co.uk/~nick/freemap/
• http://www.upct.org/
• http://www.atlanteitaliano.it/
• http://mapgeneration.berlios.de/tiki/tiki-index.php
• Applet Java della Terra
• Modalità di istituzione ed aggiornamento del Catasto delle strade

Login con nome e password (gestione utenti manuale, direttamente sul database).

Upload del file in formato GPX, il file rimane parcheggiato sul server nella directory /var/www/default/gps/upload/. Prima di inserirlo definitivamente nel database (vedi avanti) è possibile editare alcune informazioni e selezionare quali parti (waypoint o tracksegment) effettivamente inserire. Si possono caricare waypoint e tracce, forse successivamente si potranno gestire anche le rotte.

Dopo aver effettuato l'upload è possibile visualizzare il file com testo oppure nella sua struttura XML convertita in array PHP. Il parsing dei file GPX avviene con la libreria XMLToArray.php che carica tutto in RAM e qiundi risente delle limitazioni del PHP. La dimensione massima trattabile di un file GPX si aggira intorno ai 500 kb.

Cliccando sul nome del file GPX viene mostrata una form con le track contenute del file GPX e i tracksegment a loro volta contenuti in esse. Prima di inserire nel database si possono editare i seguenti campi:

Queste sono le chiavi uniche usate nelle varie tabelle; sia le track che i tracksegment sono identificati in modo univoco dal GPX di origine e dalla posizione che hanno al suo interno:

• L'inserimento di una traccia senza nome fallisce, anche se il nome viene aggiunto nella form di inserimento.
• Controllare cosa succede con file .gpx troppo grossi: l'approccio tutto in RAM fatto con PHP non funziona.

I dati grezzi provenienti dal GPX sono in PostGIS, il risultato finale viene mantenuto per il momento in GRASS. L'editing conviene farlo in con il plugin GRASS di QGIS.

La strategia individuata consiste nell'utilizzare due layer GRASS; il primo chiamato strade_edit contiene i vettori in fase di elaborazione, il secondo chiamato strade contiene il lavoro via via consolidato. La procedura potrebbe grosso modo essere così:

Individuare uno o più tracksegment da usare come base per tracciare una porzione strada. Per facilitare il compito si aggiunge in QGIS un layer PostGIS con tutti i trackpoint, la label mostra l'id del tracksegment e l'id del punto. Con lo script strade-trkseg-info si possono avere altre informazioni riguardo al tracksegment:

$ strade-trkseg-info 349
GPX file 54: Firenze, S. Casciano, Mercatale, Scandicci
Date: 2005-04-30 15:01:38
Tracksegments in this GPX file:
  id     348     1 pts
  id     349   340 pts
  id     350   699 pts

Individuato uno o più tragsegment li si converte in shapefile con lo script strade-trkseg2shape

strade-trkseg2shape 349 350

Lo shapefile (in realtà sono tre file con estensione .shp .shx e .dbf) viene salvato in una directory temporanea. Lo script utilizza al suo interno pgsql2shp con una sintassi del tipo:

pgsql2shp -f trk_350 strade "SELECT id AS trkseg_id, trkseg FROM tracksegments WHERE id IN ($id1, $id2, ...)"

Dalla shell di GRASS si può convertire lo shapefile in un layer GRASS. Si utilizza il comando v.in.ogr per la conversione, v.patch per effettuare il merge, v.build per rigenerare la geometria del layer e g.remove per eliminare il layer temporaneo. Lo shapefile viene aggiunto al contenuto esistente del layer strade_edit:

v.in.ogr -o dsn=trk_350.shp output=trk_350_tmp min_area=0.0001 snap=-1
v.patch -a input=trk_350_tmp output=strade_edit --overwrite
v.build map=strade_edit
g.remove vect=trk_350_tmp

Se invece si vuole sovrascrivere il conenuto di strade_edit si semplifica il tutto in:

v.in.ogr -o dsn=trk_350.shp output=strade_edit min_area=0.0001 snap=-1 --overwrite
v.build map=strade_edit

Finalmente si può editare il layer strade_edit dentro QGIS (altrimenti c'è v.digit di GRASS): aggiungere, togliere e muovere nodi. Dividere se necessario le linee nei punti di intersezione delle strade. Aggiungere o togliere linee. NOTA: non è possibile unire due linee che hanno un estremo in comune, si lasciano semplicemente i vertici che coincidono grazie alla funzione snap, vedi più avanti.

Quando l'edit è soddisfacente si unisce il layer di editing a quello definitivo:

v.patch -a input=strade_edit output=strade --overwrite
v.build map=strade
# Come si fa a svuotare il layer strade_edit senza rimuoverlo?

Durante l'editing (digitize) del layer non è possibile unire due linee che hanno un'estremo in comune, l'operazione si effettua in automatico creando un layer temporaneo con il comando v.build.polylines. Verranno mantenuti solo i vertici necessari: inizio, fine e intersezione di linea. Purtroppo con questo comando si perdono tutti gli attributi (Field e Category), si possono assegnare nuovamente con il comando v.category. In questo esempio a tutte le linee viene assegnato Field pari a 1 e Category incrementata automaticamente a partire da 1:

v.build.polylines input=strade_edit output=strade_tmp
v.category input=strade_tmp output=strade_edit type=line option=add cat=1 layer=1 step=1

• Rinominare un layer vettoriale
• Esportare un layer di linee in uno shapefile

g.rename vect=pippo_tmp,strade_edit --overwrite
v.out.ogr input=strade_edit type=line dsn=samothraki.shp olayer=samothraki layer=1 format=ESRI_Shapefile

• Aggiungere gli attributi alle linee digitalizzate.
• Mantenere gli attributi! Verificare che non vadano persi con v.patch o v.build.polylines.
• Come sistemare un layer Grass che ha Category o Field sballati al punto tale che Qgis non lo visualizza.
• Esportare il layer definitivo in una tabella PostGIS? Importante mantenere gli attributi.

Supponiamo di avere una linea chiusa in GRASS, ad esempio il contorno di un'isola, da trasformare in un MULTIPOLYGON di PostGIS. Questi sono i passaggi.

Verificare la geometria della mappa GRASS:

v.build map=samothraki option=build
v.info samothraki

risulta Number of lines: 1. Si trasforma questa linea chiusa in un un boundary e si verifica il risultato:

v.type input=samothraki output=samothraki_bnd type=line,boundary
v.build map=samothraki_bnd option=build
v.info samothraki_bnd

deve risultare Number of areas: 1. A questo punto si esporta in uno shapefile:

v.out.ogr -p input=samothraki_bnd type=area dsn=samothraki_bnd olayer=samothraki_bnd layer=1 format=ESRI_Shapefile

Fuori da GRASS si utilizza l'utility shp2pgsql per convertire nell'opportuno script SQL:

shp2pgsql -a -s 4326 -g bnd samothraki_bnd.shp vmap0_polbnda > samothraki_bnd.sql

Attenzione che lo SRID suggerito a shp2pgsql (4326 nell'esempio) deve essere quello della mappa GRASS di partenza, non è possibile riproiettare la geometria in questo passaggio.