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 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:
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!
#1 by Umberto on 29 luglio 2009 - 12:02
Grazie Flavio
#2 by Claudio on 3 settembre 2009 - 12:52
ottimo post! queste conversioni mi stanno facendo impazzire…
per la conversione inversa (GB->WGS84) basta invertire gli ultimi parametri?
dopo la conversione ottengo una mappa vuota e non capisco il motivo
grazie in ogni caso
#3 by Nicola on 22 ottobre 2009 - 08:31
ciao Claudio,io ho il tuo stesso problema,ossia convertire le coordinate da Gauss Boaga a WGS84 e volevo sapere se tu avevi risolto in qualche modo utilizzando il comando ogr2ogr.E’ importante in quanto mi serve per la tesi.
Grazie
#4 by Claudio on 22 ottobre 2009 - 13:36
ringrazio Flavio per l’aiuto!
Purtroppo Nicola non posso aiutarti, nel corso del mio progetto non si è più rivelata necessaria la conversione della mappa…
buona fortuna per la tesi!
#5 by flaviorigolon on 6 dicembre 2010 - 15:33
ciao,
ho ri-sbattuto contro questa operazione. E QGIS si è dimostrato ancora una volta fedelissimo e potentissimo compagno di viaggio.
Dovendo convertire alcuni SHP da Gauss-Boaga Fuso Ovest a WGS84 ho seguito le importantissime informazioni riportate su questo thread (grazie Sandro!).
In effetti ho seguito questi passi.
- Lanciare QGIS;
- Caricare lo SHP da convertire;
- Dal Menu’: Vector -> Strumenti di gestione dati -> Definisci la proiezione in uso
Nella finestra che compare cliccare sul pulsante “Scegli” e cercare la proiezione con EPSG=40000 (Italy mainland zone 1 GB Roma40);
- Dare OK. In questo modo abbiamo definito il sistema di riferimento per il nostro layer (che sapevamo essere in GB Fuso Ovest – siamo in Regione Veneto, Comune di Montecchio Maggiore, Provincia di Vicenza);
- Rimuovere dalla TOC il layer appena definito, quindi ricaricarlo nuovamente;
- Dal menù: Vector -> Strumenti di gestione dati -> Esporta a nuova proiezione
Nella finestra che compare scegliere WGS84 (codice EPSG=4326).
Per verificare il risultato ho caricato, mediante il plugin “OpenLayers Plugin”, il layer OSM della zona e mi sembra che i dati “tornino” molto bene.
#6 by Flavio on 11 settembre 2009 - 06:25
ciao,
per la conversione inversa utilizzo direttamente grass/qgis in base a questi step (che cito dal post relativo al data import in OSM):
- importazione degli SHP in GRASS mediante il modulo v.in.ogr;
- riproiezione dei vettoriale così ottenuti dal sistema 3003 al 4326 mediante il modulo v.proj;
- esportazione dei vettori riproiettati in SHP (nuovamente);
Come vedi i codici EPSG (3003 per GB ovest e 4326 per WGS 84) hanno al loro interno i parametri corretti per la ri-conversione (cio’ non avviene nella conversione inversa).
#7 by luca m on 16 novembre 2011 - 12:27
ciao a tutti,
putroppo nell eseguire la procedura sopraesposta mi si genera un errore ma non capisco come risolvere.
1-avevo a disposizione un file gpx, che tramite qgis ho convertito in file shape con SR: wgs84 (EPSG:4326)
2-utilizzando ogr2ogr eseguo la prima parte del presente tutorial riuscendo a generare un nuovo file shape con SR: Gauss Boaga zona 1 (EPSG:3003), dal quale si conferma vi sia un sistematico scostamento rispetto alla ctrn veneto
3-Nell eseguire:
ogr2ogr output.shp input.shp -s_srs EPSG:4326 +towgs84 EPSG:3003
ottengo il seguente errore:
FAILURE: Couldn’t fetch requested layer ‘+towgs84′
4-In aternativa se eseguo:
ogr2ogr outpu.shp trackwg.shp -s_srs EPS=intl +lat_0=0 +lon_0=9 +k=0.999600 +x_0=150000,-49.1,-9.9,0.971,-2.917,0.714,-11.68
ottengo il seguente errore:
Failed to process SRS definition: æ+proj=tmerc
Che cosa è incorretto nella mia sintassi? nel caso 4- il mio script differisce da quello propsto per il fatto che gli shape di input e output sono due file distinti mentre voi riportate sempre $nome_ref.shp
Ringraziando nella speranza
Luca
#8 by flaviorigolon on 16 novembre 2011 - 12:55
ciao Luca,
il $nome_ref.shp è il nome (variabile perchè inserito in uno script) dello shp. Va benissimo che siano diversi qelli di input e output altrimenti collidono.
Per la sintassi di ogr2ogr: sembrano mancare dei pezzi nel comando (manca la “G” in EPS(G) e mancan la dichiarazione del +proj che va incluso fra singole apici e con tutti i parametri), prova così:
ogr2ogr output.shp trackwg.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′
spero aiuti
a presto
flavio
PS: possiamo darci del “tu”
? ciao!