rigacci.org

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Appunti GIS ======

===== GRASS =====

Pacchetti installati in Debian Sarge: ''fftw2'', ''gdal-bin'', ''grass'', ''grass-doc'', ''libgrass'', ''tcl8.3'', ''tk8.3''. Scaricato il database di esempio [[http://grass.itc.it/sampledata/spearfish_grass57data.tar.gz|spearfish]], scompattato in ''$HOME/grass/'' (il nostro **GRASS databse**), il tutto è contenuto nella sottodirectory ''spearfish57''. Si lancia ''grass'' in una finestra terminale, selezionare la directory ''spearfish'' come **location** e ''PERMANENT'' come **mapset**. Quindi si clicca ''Enter GRASS''.

Per iniziare a veder qualcosa bisogna aprire una finestra grafica (un **GRASS monitor**), lo si fa con il comando ''**d.mon**'' oppure dall'interfaccia Tcl/Tk:

  * Display, Start display, x0
  * Display, Display raster maps
  * Display, Display vector maps

Per editare i punti di un vettoriale, dalla toolbar:

  * Add vector
  * Digitize map

==== Iniziare un progetto ex novo ====

Un po' di documentazione è disponibile per [[http://grass.itc.it/grass60/manuals/html60_user/index.html|GRASS 6.0.x]] e per [[http://grass.itc.it/grass61/manuals/html61_user/index.html|GRASS 6.1.x]].

Supponiamo che la directory ''$HOME/grass/'' sia il nostro **GRASS databse**, creiamo una nuova **''LOCATION''** di nome **strade**, che verrà memorizzata nella directory ''**$HOME/grass/strade**''. Si avvia GRASS e si clicca il pulsante **Create New Location**, le informazioni fornite sono:

^ LOCATION            | strade              |
^ MAPSET              | niccolo             |
^ DATABASE            | /home/niccolo/grass |
^ Coordinate system   | Latitude-Longitude  |
^ Datum name          | wgs84               |
^ Datum Transformation Parameters |       1 |
^ NORTH EDGE          |              46.696 |
^ SOUTH EDGE          |              36.943 |
^ WEST EDGE           |               6.264 |
^ EAST EDGE           |              19.268 |
^ GRID RESOLUTION E-W |                   1 |
^ GRID RESOLUTION N-S |                   1 |

Nel progetto potremo avere diversi ''**MAPSET**'', ad esempio per consentire l'accesso a più utenti contemporaneamente oppure per poter suddivire il progetto in componenti separati logicamente. Un //mapset// speciale di nome ''**PERMANENT**'' viene creato automaticamente quando viene creata una nova //location//, sarà accessibile in scrittura solo al proprietario del database, contiene i limiti geografici della //location// e può essere usato per contenere tutti gli elementi ereditati in sola scrittura da tutti gli altri //mapset//.

Le impostazioni di cui sopra dipendono dal fatto che il nostro progetto si estende a tutta l'Italia e vogliamo lavorare con le coordinate espresse in latitudine/longitudine secondo il datum WGS84 (sono le impostazioni predefinite del nostro GPS).

Definita e creata la **location** (''strade'') e il **mapset** (''niccolo''), si vuole creare una **vector map** (''trk_strade'') che contiene un **layer** (''1_line'') con le linee da poter a digitalizzare.

Purtroppo **non si riesce a creare una //vector map// a partire dal nulla**, si deve importare qualcosa di preesistente. Ecco un esempio che esegue i seguenti passi:

  - Esporta una **geometry PostGIS** verso uno **shapefile**
  - Importa lo shapefile in un **vector map** di GRASS **temporaneo**
  - Effettua il merge del vector temporaneo nel **vector map definitivo**

Dalla shell di sistema si effettua l'export da PostGIS:

<code bash>
pgsql2shp \
    -f shapefile \
    -h 127.0.0.1 \
    -u dbuser \
    -P dbpass \
    -g trkseg \
    dbname "SELECT id, trkseg FROM tracksegments WHERE id = 65"
</code>

Poi nella shell di GRASS si usano i seguenti comandi per importare lo shapefile:

<code bash>
# Import the Shapefile into a new GRASS vector map.
# Shapefile does not specify a projection: we use location's projection (-o).
v.in.ogr dsn=shapefile.shp output=tmp_trkseg min_area=0.0001 snap=-1 -o

# Add the new GRASS vector map to the final one.
# Omit the "-a" if the output vector map does not exists yet.
v.patch -a input=tmp_trkseg output=trk_strade
v.build map=trk_strade

# Remove the temporary vector.
g.remove vect=tmp_trkseg
</code>

==== Layer vettoriali e attributi ====

GRASS can be linked to one or many database management systems (DBMS). The db.* set of commands provides basic SQL support for attribute management, while the v.db.* set of commands operates on the vector map.

Per assegnare degli attributi ad un vettore bisogna assegnare una o più **categorie** allo stesso. Una //categoria// è in pratica un identificativo dell'oggetto vettoriale e viene memorizzato nello stesso file che contiene la geometria. Con ''**v.category**'' si possono manipolare le categorie.

Gli oggetti vettoriali possono essere collegati ad una o più tabelle del database, ogni collegamento ad un distinto attributo viene chiamato **Layer**.

Layers: It is possible to link the geographic objects in one vector file to one or more tables. Each link to a distinct attribute table is called a layer. GRASS layers do not contain any geographic objects, but consist of links to attribute tables in which vector objects can have zero or more categories. If a vector object has zero categories in a layer, then it does not appear in that layer. In this fasion some vector objects may appear in some layers but not in others. The practical benefit of this system is that it allows placement of thematically distinct but topologically related objects in a single file (e.g. forests and lakes). These virtual layers also are useful for linking time series attribute data to a series of locations that did not change over time. By default the first layer is active, i.e. the first table corresponds to the first layer. Further tables are linked to subsequent layers. Using v.db.connect layers can be listed or maintained.

SQL support: The DBF driver provides only very limited SQL support (as DBF is not an SQL DB) while the other DBMS backends (such as PostgreSQL, MySQL etc) provide full SQL support since the SQL commands are sent directly to the DBMI. SQL commands can be directly executed with db.execute, db.select and the other db.* modules. 
 When creating vector maps from scratch, in general an attribute table must be created and the table must be populated with one row per category (using v.to.db). However, this can be performed in a single step using v.db.addtable along with the definition of table column types. 

===== Dati Regione Toscana =====

La Regione Toscana mette a disposizione gratuitamente alcuni dei dati cartografici in suo possesso (bontà loro... li abbiamo pagati noi!). Purtroppo la licenza non è libera. Vedere la pagina **[[regione_toscana]]**.

===== VMap0 =====

Scaricato  e scompattato il file v0eur.tar.gz da [[http://geoengine.nga.mil/ftpdir/archive/vpf_data/v0eur.tar.gz]] (seguendo un link da [[http://www.mapability.com/info/vmap0_intro.html|www.mapability.com]]). L'archivio contiene dati vettoriali in formato **VPF** (**Vector Product Format**), si tratta di uno standard militare identificato dalla sigla MIL-STD-600006.

Andras Fabian ha fatto la conversione dei dati VMap0 in formato shapefile e gli ha resi disponibili su [[http://frederic.cs.dal.ca/pub/STDW/VMAP0/]].

Nel documento {{grassnews_vol3.pdf}} ci sono alcune note su come importare i dati VMap0 in GRASS. Purtroppo il comando necessario ''**ogr2ogr**'' (contenuto nel pacchetto Debian ''**gdal-bin**'') non supporta il formato VPF, lo si scopre lanciando il comando ''**ogrinfo --formats**'' e notando che **OGDI** non è tra i formati supportati.

Pare che il pacchetto OGDI (documentazione in {{ogdi.pdf}}) invece faccia al caso nostro, non esiste pacchettizzato Debian e quindi si fa dai sorgenti:

<code sh>
cd /usr/local/download/ogdi
tar zxvf ogdi-3.1.4.tar.gz
cd ogdi-3.1.4/
export TOPDIR=/usr/local/download/ogdi/ogdi-3.1.4
export LD_LIBRARY_PATH=$TOPDIR/bin/Linux
./configure
make
make install
</code>

Controllare che in ''/etc/ld.so.conf'' sia compreso il percorso ''/usr/local/lib'', casomai aggiungerlo ed eseguire ''**ldconfig**''.

A questo punto si possono vedere alcune informazioni sull'archivio VMap0 con ''**ogdi_info**'', ad esempio il datum utilizzato è il **North American Datum 1983** su ellissoide **GRS80** (codice **EPSG 4269**) come scritto nell'articolo //Grass News// visto prima.

Si esportano i dati in formato shapefile con ''**ogdi_import**'', quindi si convertono in PostGIS con ''**shp2pgsql**'' (dal pacchetto PostGIS):

<code>
$ ogdi_info -u gltp:/vrf/home/niccolo/vmap0/v0eur/vmaplv0/eurnasia
Projection = `+proj=longlat +datum=nad83'
Bounds
north = 89.999900
south = 30.000000
east = 179.999900
west = -60.000000
...
...
$ ogdi_import -no-dict -u gltp:/vrf/home/niccolo/vmap0/v0eur/vmaplv0/eurnasia -f Area -o polbnda -l 'polbnda@bnd(*)'
Projection = `+proj=longlat +datum=nad83'
$ shp2pgsql -s 4269 polbnda.shp vmap0 > polbnda.sql
Shapefile type: Polygon
Postgis type: MULTIPOLYGON[2]
</code>

Queste sono le opzioni usate per ''ogdi_import'':

^Opzione        ^Significato                          ^
|-u <url>       |URL del database vettoriale.\\ Usare la sintassi ''**%%gltp:[//<hostname>]/driver/<path>%%**''\\ L'hostname viene omesso per una connessione locale.\\ Il driver usato nel nostro caso è il **vrf** (Vector Relational Format), un altro possibile driver è il **grass** per un datastore GRASS.  |
|-no-dict       |Alcuni server possono usare un parametro //Dictionary// per limitare i dati restituiti. Non nel nostro caso.  |
|-o <filename>  |Nome del file da creare. Nel caso nostro vengono creati i file ''**.shp**'', ''**.shx**'' e ''**.dbf**''.  |
|-f <family>    |Seleziona la famiglia di oggetti da trattare, i valori ammessi sono: ''**Line**'', ''**Area**'', ''**Point**'', ''**Matrix**'', ''**Image**'', ''**Text**'', ''**Edge**'', ''**Face**'', ''**Node**'' o ''**Ring**''  |
|-l <layer>  |Stringa che indica quali oggetti selezionare, la sintassi generica è ''**%%DatastoreElement@Datastore(Expression)%%**''.\\ Per il driver **vrf** la sintassi è ''**%%FEATURE_NAME@COVERAGE(REQUEST)%%**'' che definisce una specifica feature (es. //roads//), un tipo di coverage (es. //transportation//) e la richiesta da fare sulla tabella della feature indicata (es. //TYPE = double_lane//).\\ Nel caso nostro si seleziona tutta la tabella //Administrative Areas// (**polbnda**) che appartiene al coverage //Boundary// (**bnd**).  |

==== Problemi ====

Il MULTIPOLYGON ricavato con shp2pgsql presenta delle anomalie, per esempio alcune regioni sono tagliate da un meridiano e/o parallello, ad esempio la Sicilia è tagliata verticalmente in due poligoni (id 5108 e 5502). Motivi? Rimedi?

<code>
strade=> SELECT id,nam FROM vmap0 WHERE nam = 'SICILIA';
  id  |   nam
------+---------
 5106 | SICILIA
 5107 | SICILIA
 5108 | SICILIA
 5502 | SICILIA
(4 rows)
</code>

===== Altri programmi di supporto =====

==== gpsbabel ====

Permette di fare download/upload e di convertire tra quasi tutti i formati file dei GPS conosciuti! Ad esempio per fare il download dei dati da un GPS Garmin collegato alla prima porta seriale:

<code>
gpsbabel -w -i garmin -f /dev/ttyS0 -o gpx -F waypoints.gpx
gpsbabel -t -i garmin -f /dev/ttyS0 -o gpx -F tracks.gpx
gpsbabel -r -i garmin -f /dev/ttyS0 -o gpx -F routes.gpx
</code>

==== gpsdrive ====
Car navigation system. Può essere collegato direttamente ad un GPS, monstra in tempo reale la posizione sulla mappa e il percorso effettuato. Gestisce waypoint e tracce. Può scaricare al volo da Internet le mappe raster in varie scale da [[http://www.expedia.com/|www.expedia.com]].

Se non è collegato al GPS attiva la modalità simulazione, veramente antipatica se si vuole utilizzare il programma per visualizzare le proprie tracce sovrapposta alla cartografia prelevata da Expedia.

Per convertire dei file GPX (track o waypoint) al formato gpsdrive si usa al solito gpsbabel:

<code>
gpsbabel -t -i gpx -f trk_2005-08-11.gpx -o gpsdrivetrack -F .gpsdrive/track_2005-08-11.sav
gpsbabel -w -i gpx -f wpt_2005-03-06.gpx -o gpsdrive      -F way_2005-03-06.txt; cat way_2005-03-06.txt >> .gpsdrive/way.txt
</code>

GpsDrive legge automaticamente gli waypoint dal file ''**~/.gpsdrive/way.txt**'', mentre dal menu //Misc//, //Load track file// è possibile caricare la traccia desiderata.

==== gpsd/gpsd-clients ====
GPS (Global Positioning System) service daemon e cliente relativo, per condividere un GPS su LAN.

==== gpsman ====

GPS Manager (GPSMan) is a graphical manager of GPS data that makes possible the preparation, inspection and edition of GPS data in a friendly environment. GPSMan supports communication and real-time logging with both Garmin and Lowrance receivers and accepts real-time logging information in NMEA 0183 from any GPS receiver.

Un po' primitivo, ma va anche a CUI.

==== gpx2shp ====

Convert GPS or GPX file to ESRI/Shape file.  Include the tools gps2shp and gpx2shp.  These are very useful when using collected GPS points with existing GIS tools like qgis and GRASS.

===== Standard di riferimento =====

**GPX**\\
GPX (the [[http://www.topografix.com/gpx.asp|GPS Exchange Format]])  is a light-weight XML data format for the interchange of GPS data (waypoints, routes, and tracks) between applications and Web services on the Internet. See [[gpx|appunti GPX]].

**Shapefile**\\
Formato vettoriale basato su file; proprietario ma aperto; è composto di 3-5 file, uno con le coordinate (.shp), uno di indice (.shx), uno di dati (.dbf), e a volte altri; non è topologico. Compatibile con Mapserver.

**Geodb**\\
Ci vuole Postgis, dopodiché la vita è facile: da Postgis butti dentro tutto, poi li puoi manipolare in tutti i modi che ti vengono a mente (anche da Openoffice!). Compatibile con Mapserver.

**Formato topologico**\\
In un formato topologico un confine fra due poligoni è una linea sola, nel non topologico sono due forme che, casualmente, sono (più o meno) sovrapposte.