====== Progetto Strade ======
DELETEME **ATTENZIONE:** il //Progetto Strade// è da considerarsi defunto! Collaboriamo invece a **[[http://www.openstreetmap.org/|OpenStreetMap]]** e a tutto il suo indotto.
===== Idea iniziale =====
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**.
==== La licenza ====
[[http://www.openstreetmap.org/|OpenStreetMap]] ha optato per la **[[http://creativecommons.org/licenses/by-sa/2.0/|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 [[http://wiki.openstreetmap.org/index.php/Legal_FAQ|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**.
===== Link operativi =====
* Interfaccia web per [[http://paros.rigacci.org/gps/|upload file GPX]].
* Pagina [[http://paros.rigacci.org/cgi-bin/mapserv?map=/var/www/maps/strade.map&mode=browse|MapServer]].
* Pagina per il [[download|download dei dati]].
===== Altri progetti di riferimento =====
* [[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]]
* [[http://www.skolelinux.org/portal/user_experience/test_schools/test_schools_map|Applet Java della Terra]]
* {{catasto_delle_strade.pdf|Modalità di istituzione ed aggiornamento del Catasto delle strade}}
===== Procedure in essere =====
=== Login ===
Login con nome e password (gestione utenti manuale, direttamente sul database).
=== Upload ===
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**.
=== Visualizzazione dei file GPX ===
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 **[[http://www.devarticles.com/c/a/PHP/Converting-XML-Into-a-PHP-Data-Structure/6/|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.
=== Inserimento di una traccia nel database ===
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:
^ Campo_della_form ^ Database ^ Commento ^
^ Description | gpxfiles.descr | Testo libero, aiuta a riconoscere il contenuto del file; ad esempio la data di acquisizione. |
^ Date and Time | gpxfiles.date_time | Insieme all'ID dell'utente identifica il file GPX in maniera **univoca**. Conviene lasciare il timestamp originale del file GPX, in modo da evitare l'inserimento accidentale dello stesso file più volte. |
^ Note | gpxfiles.note |Testo libero con note sul percorso: nomi delle strade, mezzo di trasporto, qualità segnale GPS, ... |
^ Track Name | tracks.gps_name | Il nome della traccia è obbligatorio e viene generalmente assegnato in automatico dal GPS, ma può essere modificato. Il nome non identifica la traccia in modo univoco. Come chiave contro inserimenti multipli accidentali viene utilizzato **l'identificativo del file gpx** di origine e la **posizione** al suo interno. |
^ Insert | - | Se viene tolto il segno di spunta, il tracksegment non verrà inserito nel database |
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:
^ Tabella ^ Campi ^
| gpxfiles | date_time, iduser |
| tracks | idgpx, gpx_position |
| tracksegments | idgpx, gpx_position |
=== TODO ===
* 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.
===== Editing: dalle tracce grezze alle strade =====
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
==== Altri comandi utili ====
* 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
==== Rimane da fare ====
* 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.
===== Da linea GRASS a poligono PostGIS =====
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.