Salve,
sto provando il WMS della Regione Toscana, dopo vari empirismi ho
caricato il seguente URL:
Pare che ci sia un datum shift di qualche decina di metri.
Allego screenshot del WMS sovrapposto ad una traccia GPS, la
traccia e' quella sottile blu.
Qualcuno ne sa qualcosa?
Sapete eventualmente come contattare la Regione per farlo
correggere?
- Il programma dello screenshot e JOSM
- La zona e' lo svincolo Lucca Est della A11
--
Niccolo Rigacci
Firenze - Italy
Pare che ci sia un datum shift di qualche decina di metri.
Allego screenshot del WMS sovrapposto ad una traccia GPS, la
traccia e' quella sottile blu.
Se non sbaglio i dati WMS della regione toscana sono in gauss boaga
est o ovest (EPSG 3003 o 3004).
La riproiezione di questi dati in sistemi quali il 4326 o gli UTM (io
avevo provato con il 32632, UTM 32N) non è precisa usando proj4 (se la
regione usa mapserver o altri software opensource è probabile che ci
sia quello alla base).
Ti consiglio di provare a convertire i tuoi dati con software
"affidabili" (arcgis o Global Mapper se hai solo dati raster) per
verificare se l'errore è legato al sistema di proiezione.
Una nota OT: software affidabili come arcgis? Ritieni che arcgis abbia metodi di conversione più affidabili di proj4? Il passaggio da Gauss Boaga a UTM per essere affidabile davvero deve passare per i grigliati IGM o le isotransitive… Tutte le librerie general purpose (comprese quelle di arcgis) hanno un’inaffidabilità (o un affidabilità) confrontabile…
Giovanni
2008/2/5, Diego Guidi <diegoguidi@gmail.com>:
Pare che ci sia un datum shift di qualche decina di metri.
Allego screenshot del WMS sovrapposto ad una traccia GPS, la
traccia e’ quella sottile blu.
Se non sbaglio i dati WMS della regione toscana sono in gauss boaga
est o ovest (EPSG 3003 o 3004).
La riproiezione di questi dati in sistemi quali il 4326 o gli UTM (io
avevo provato con il 32632, UTM 32N) non è precisa usando proj4 (se la
regione usa mapserver o altri software opensource è probabile che ci
sia quello alla base).
Ti consiglio di provare a convertire i tuoi dati con software
“affidabili” (arcgis o Global Mapper se hai solo dati raster) per
verificare se l’errore è legato al sistema di proiezione.
Iscriviti all’associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell’Associazione GFOSS.it.
Una nota OT: software affidabili come arcgis?
No no aspetta, non mi infilate dentro un flame inutile...
Io ho fatto delel prove con dei raster UTM 32N usando
QGIS/GVSIG/MapServer e poi usando ArcMap/GlobalMapper, e con i secondi
il tutto era molto più preciso... ma magari mi son sbagliato io ad
usarlo.
On Tue, 5 Feb 2008 19:16:00 +0100, Diego Guidi wrote
> Pare che ci sia un datum shift di qualche decina di metri.
> Allego screenshot del WMS sovrapposto ad una traccia GPS, la
> traccia e' quella sottile blu.
Se non sbaglio i dati WMS della regione toscana sono in gauss boaga
est o ovest (EPSG 3003 o 3004).
La riproiezione di questi dati in sistemi quali il 4326 o gli UTM (io
avevo provato con il 32632, UTM 32N) non è precisa usando proj4 (se
la regione usa mapserver o altri software opensource è probabile che
ci sia quello alla base). Ti consiglio di provare a convertire i
tuoi dati con software "affidabili" (arcgis o Global Mapper se hai
solo dati raster) per verificare se l'errore è legato al sistema di proiezione.
A me è capitato di utilizzare proj4 con successo per convertire
da "coordinate toscane" a WGS84 lat-long quando mi sono
trovato a dovere alimentare GoogleTransit per la provincia
di Firenze
http://www.google.com/transit? \
ie=UTF8&ll=43.777663,11.260815&spn=0.077341,0.136642
Essenzialmente mi pare che sia l'esatto reciproco di quanto
viene segnalato [conversione da wgs84 a GaussBoaga fuso 1].
Anche a me è successo di tribolare abbastanza prima di
trovare i parametri giusti [usando i vari 3303 preconfezionati
più o meno avevo spostamenti dello stesso ordine di
grandezza di quelli segnalati], ma alla fine ho risolto
assegnando esplicitamente i seguenti parametri:
+proj=tmerc +lat_0=0 +lon_0=9 +k=0.999600 \
+x_0=1500000 +y_0=0 +ellps=intl +units=m +no_defs \
+towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 \
+to +proj=latlong +datum=WGS84
Spero possa risultare utile
Almeno nel mio caso ho ottenuto una sovrapposizione
decisamente soddisfacente sia con i vettoriali
che con i rasters di Google
saluti Sandro Furieri
Diego Guidi ha scritto:
Una nota OT: software affidabili come arcgis?
No no aspetta, non mi infilate dentro un flame inutile...
Io ho fatto delel prove con dei raster UTM 32N usando
QGIS/GVSIG/MapServer e poi usando ArcMap/GlobalMapper, e con i secondi
il tutto era molto più preciso... ma magari mi son sbagliato io ad
usarlo.
Le prestazioni di arcgis in termini di conversioni e trasformazioni sono
del tutto confrontabili a quelle ottenibili con proj.4, poichè di fatto
entrambi utilizzano versioni rivisitate e non dell'EPSG Geodetic
Parameter Dataset.
proj.4 è una base solida per il mondo GFOSS! Il vero problema, al
limite, è quale sw usa le proj e come le gestisce. Ad es. Qgis le
gestisce benissimo, gvSIG ancora no.
Forse con i "secondi" hai avuto modo di governare le trasformazioni
nella tua area geografica di interesse (oppure ti stava bene la
trasformazione di default), mentre con i secondi no. Ma da qui a dire
che sono più affidabili in termini di gestione dei CRS, comprendo la
reazione di Giovanni.
Ciao
Antonio
No figurati Diego, non intendevo alzare un flame. Scusa per il tono.
Può essere che (per certe aree) le due trasformazioni (Grass e Arcgis) portino a risultati con diversa accuratezza, però non lasciarti fuorviare da questo risultato parziale. In altre aree può accadere il contrario. Tutto dipende dai parametri di trasformazione.
Per prova, controlla quali parametri hai usato dentro Grass, e poi guarda quelli usati dentro Arcmap (nell’Arctoolbox avrai scelto una delle varie trasformazioni per passare a WGS84 dal menù a tendina…).
Ciao!
2008/2/5, a.furieri@lqt.it <a.furieri@lqt.it>:
On Tue, 5 Feb 2008 19:16:00 +0100, Diego Guidi wrote
Pare che ci sia un datum shift di qualche decina di metri.
Allego screenshot del WMS sovrapposto ad una traccia GPS, la
traccia e’ quella sottile blu.
Se non sbaglio i dati WMS della regione toscana sono in gauss boaga
est o ovest (EPSG 3003 o 3004).
La riproiezione di questi dati in sistemi quali il 4326 o gli UTM (io
avevo provato con il 32632, UTM 32N) non è precisa usando proj4 (se
la regione usa mapserver o altri software opensource è probabile che
ci sia quello alla base). Ti consiglio di provare a convertire i
tuoi dati con software “affidabili” (arcgis o Global Mapper se hai
solo dati raster) per verificare se l’errore è legato al sistema di proiezione.A me è capitato di utilizzare proj4 con successo per convertire
da “coordinate toscane” a WGS84 lat-long quando mi sono
trovato a dovere alimentare GoogleTransit per la provincia
di Firenze
http://www.google.com/transit?
ie=UTF8&ll=43.777663,11.260815&spn=0.077341,0.136642Essenzialmente mi pare che sia l’esatto reciproco di quanto
viene segnalato [conversione da wgs84 a GaussBoaga fuso 1].Anche a me è successo di tribolare abbastanza prima di
trovare i parametri giusti [usando i vari 3303 preconfezionati
più o meno avevo spostamenti dello stesso ordine di
grandezza di quelli segnalati], ma alla fine ho risolto
assegnando esplicitamente i seguenti parametri:+proj=tmerc +lat_0=0 +lon_0=9 +k=0.999600
+x_0=1500000 +y_0=0 +ellps=intl +units=m +no_defs
+towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68
+to +proj=latlong +datum=WGS84Spero possa risultare utile
Almeno nel mio caso ho ottenuto una sovrapposizione
decisamente soddisfacente sia con i vettoriali
che con i rasters di Googlesaluti Sandro Furieri
Iscriviti all’associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell’Associazione GFOSS.it.
Forse con i "secondi" hai avuto modo di governare le trasformazioni
nella tua area geografica di interesse (oppure ti stava bene la
trasformazione di default), mentre con i secondi no. Ma da qui a dire
che sono più affidabili in termini di gestione dei CRS, comprendo la
reazione di Giovanni.
Forse non sono stato abbastanza chiaro su questo punto... io per
affidabilità di proj4 mi riferivo esclusivamente alla gestione del
Gauss Boaga, mentre per tutti gli altri CRS non ho mai avuto problemi
di precisione.
On Tue, 5 Feb 2008 20:23:05 +0100, Diego Guidi wrote
> Forse con i "secondi" hai avuto modo di governare le trasformazioni
> nella tua area geografica di interesse (oppure ti stava bene la
> trasformazione di default), mentre con i secondi no. Ma da qui a dire
> che sono più affidabili in termini di gestione dei CRS, comprendo la
> reazione di Giovanni.Forse non sono stato abbastanza chiaro su questo punto... io per
affidabilità di proj4 mi riferivo esclusivamente alla gestione del
Gauss Boaga, mentre per tutti gli altri CRS non ho mai avuto problemi
di precisione.
Scusate se mi intrometto, ma devo osservare "da programmatore"
che stare facendo una gran confusione tra CODICE e DATI ..
Che le proj4 siano uno sw (=codice) favoloso è
assolutemente fuori di discussione.
Che i vari EPGS sul Gauss Boaga "preconfezionato" facciano
qualche pastrocchio è altrettanto accertato;
altrimenti non ci sarebbe nessun bisogno di "aggiustare
a mano" le matrici di trasformazione [come ho dovuto
fare io; vedi mail precedente]
Ma questo è semplicemente un problema di DATI (=parametri)
padellati e da correggere, non c'entra proprio nulla
con la bontà degli algotirmi, la qualità del codice etc etc
ciao Sandro
Ma questo è semplicemente un problema di DATI (=parametri)
padellati e da correggere, non c'entra proprio nulla
con la bontà degli algotirmi, la qualità del codice etc etc
Anche questo è correttissimo.
Chiudo questo mio contributo al post facendo notare che non si tratta di DATI PADELLATI. La trasformazione dal datum della proiezione Gauss-Boaga (Roma40 con ellissoide di Hayford) al datum WGS84 non è una trasformazione lineare. Non esiste una trasformazione buona per tutte le aree, perché si tratta di una rototraslazione a 7 parametri che, se basata sui punti IGM, vale comunque in un’area ristretta intorno ai punti omologhi sui quali sono stati definiti i 3 parametri di traslazione, i 3 di rotazione e quello di scala.
Tanto proj4 che arcgis sfrutta delle trasformazioni “medie” per aree estese, e quindi non potranno mai essere trasformazioni esatte, ne consegue che per far sovrapporre bene delle mappe nei due sistemi o si usa un modo empirico come Sandro (e in generale non è consigliabile!) o l’unico modo per trasformare correttamente i dati è usare i parametri forniti dall’IGM o il sw IGM Verto (che contiene il grigliato IGM).
Giovanni
Tanto proj4 che arcgis sfrutta delle trasformazioni "medie" per aree
estese, e quindi non potranno mai essere trasformazioni esatte,
Ecco perchè anche le trasformazioni di Global Mapper sono molto
precise in alcuni punti (Sardegna nord) ed un pò imprecise in altri
(Sardegna sud). Grazie per la spiegazione 
a.furieri@lqt.it ha scritto:
Scusate se mi intrometto, ma devo osservare "da programmatore"
che stare facendo una gran confusione tra CODICE e DATI ..Che le proj4 siano uno sw (=codice) favoloso è
assolutemente fuori di discussione.Che i vari EPGS sul Gauss Boaga "preconfezionato" facciano
qualche pastrocchio è altrettanto accertato;
altrimenti non ci sarebbe nessun bisogno di "aggiustare
a mano" le matrici di trasformazione [come ho dovuto
fare io; vedi mail precedente]
Ma questo è semplicemente un problema di DATI (=parametri)
padellati e da correggere, non c'entra proprio nulla
con la bontà degli algotirmi, la qualità del codice etc etc
Piuttosto che utilizzare qualcosa di "preconfezionato", del tipo "4 dati
in padella" :), occorre molto spesso rimboccarsi le maniche e
"cucinarseli" da sè i dati. Aggiustare a manina i parametri di
trasformazione significa avere piena coscienza di cosa ci sia dietro...
indipendentemente da algoritmi quasi secolari universalmente condivisi e
dal codice!
Ciao
Antonio
On Wed, 06 Feb 2008 10:06:59 +0100, Antonio Falciano wrote
Piuttosto che utilizzare qualcosa di "preconfezionato", del tipo "4 dati
in padella" :), occorre molto spesso rimboccarsi le maniche e
"cucinarseli" da sè i dati. Aggiustare a manina i parametri di
trasformazione significa avere piena coscienza di cosa ci sia dietro...
indipendentemente da algoritmi quasi secolari universalmente
condivisi e dal codice!Ciao
Antonio
Premesso che sono semplicemente uno sviluppatore sw, e quindi
confesso senza pudore la mia quasi totale incompetenza,
ma provo a tirare le somme di tutta la questione sulle
conversioni proj4 da GaussBoaga [=Rome40,=MonteMario]
a WGS84
1) non è concettualmente possibile ottenere una
trasformazione precisa ed esatta su tutto il fuso
2) invece occorre aggiustare di fino i parametri della
matrice di trasformazione caso per caso a seconda
della zona specifica
3) IGM95 definisce 1320 punti su una griglia con maglia
di 20Km; ciascun punto ha la sua specifica matrice,
e garantisce una precisione centimetrica in un raggio
di 10Km, vedi:
http://www.univ.trieste.it/hirema/officina/appunti/cartografia.html
Immagino che la griglia IGM95 sia alla base di Verto,
che tutto è meno che open source
4) come alternative open source mi sembra che esistano
solo queste definizioni di fonte Grass:
----------
rome40 "towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68"
"Italy (Peninsular Part)" "Accuracy 3-4m"
rome40 "towgs84=-168.6,-34.0,38.6,-0.374,-0.679,-1.379,-9.48"
"Italy (Sardinia)" "Accuracy 3-4m"
rome40 "towgs84=-50.2,-50.4,84.8,-0.690,-2.012,0.459,-28.08"
"Italy (Sicily)" "Accuracy 3-4m"
-----------
ovviamente una precisione di 3-4m non è proprio il top,
ma in molte situazioni puo' anche risultare soddisfacente;
e nulla vieta ai volenterosi e competenti di calcolare e
rendere pubblicamente disponibile qualche ulteriore zona
Comunque direi che la "Peninsular Part" da sicuramente
risultati accurati almeno in Toscana
5) la definizione EPSG [presa da PostGIS] invece è semplicemente:
------------
3003 +proj=tmerc +lat_0=0 +lon_0=9 +k=0.999600 \
+x_0=1500000 +y_0=0 +ellps=intl +units=m +no_defs
------------
non vedo traccia di +towgs84 di nessun tipo; vai a
sapere quali defaults assume, ma sicuramente usandola
si ottengono shifts molto evidenti [50-100m], sempre
con riferimento alla Toscana
saluti Sandro
1) non è concettualmente possibile ottenere una
trasformazione precisa ed esatta su tutto il fuso
...
4) come alternative open source mi sembra che esistano
solo queste definizioni di fonte Grass:rome40 "towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68"
"Italy (Peninsular Part)" "Accuracy 3-4m"
rome40 "towgs84=-168.6,-34.0,38.6,-0.374,-0.679,-1.379,-9.48"
"Italy (Sardinia)" "Accuracy 3-4m"
rome40 "towgs84=-50.2,-50.4,84.8,-0.690,-2.012,0.459,-28.08"
"Italy (Sicily)" "Accuracy 3-4m"
Ottimo riassunto! Appena trovo un attimo di tempo lo integro
nella http://it.wikipedia.org/wiki/Proiezione_di_Gauss-Boaga
--
Niccolo Rigacci
Firenze - Italy
> 4) come alternative open source mi sembra che esistano
> solo queste definizioni di fonte Grass:
>
> rome40 "towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68"
> "Italy (Peninsular Part)" "Accuracy 3-4m"
> rome40 "towgs84=-168.6,-34.0,38.6,-0.374,-0.679,-1.379,-9.48"
> "Italy (Sardinia)" "Accuracy 3-4m"
> rome40 "towgs84=-50.2,-50.4,84.8,-0.690,-2.012,0.459,-28.08"
> "Italy (Sicily)" "Accuracy 3-4m"
Suggerisco di inserire la proiezione originale di sandro e queste
modifiche in spatialreferences.org.
On Wed, 6 Feb 2008 12:43:24 +0100, Diego Guidi wrote
rome40 "towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68"
"Italy (Peninsular Part)" "Accuracy 3-4m"
rome40 "towgs84=-168.6,-34.0,38.6,-0.374,-0.679,-1.379,-9.48"
"Italy (Sardinia)" "Accuracy 3-4m"
rome40 "towgs84=-50.2,-50.4,84.8,-0.690,-2.012,0.459,-28.08"
"Italy (Sicily)" "Accuracy 3-4m"
Suggerisco di inserire la proiezione originale di sandro e queste
modifiche in spatialreferences.org.
Perfettamente d'accordo per l'aggiornamento delle banche dati !!!!
Comunque guarda che la "proiezione di sandro" non esiste
proprio; io mi sono semplicemente limitato ad usare:
------------
+proj=tmerc +lat_0=0 +lon_0=9 +k=0.999600 \
+x_0=1500000 +y_0=0 +ellps=intl +units=m +no_defs \
+towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 \
+to +proj=latlong +datum=WGS84
------------
se leggi bene, si tratta molto banalmente della
buona vecchia EPSG3003 combinata con il +towgs84
preso di peso da "Italy (Peninsular Part)" di Grass
... un semplice copy&paste ....
ciao Sandro
Diego Guidi ha scritto:
4) come alternative open source mi sembra che esistano
solo queste definizioni di fonte Grass:rome40 "towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68"
"Italy (Peninsular Part)" "Accuracy 3-4m"
rome40 "towgs84=-168.6,-34.0,38.6,-0.374,-0.679,-1.379,-9.48"
"Italy (Sardinia)" "Accuracy 3-4m"
rome40 "towgs84=-50.2,-50.4,84.8,-0.690,-2.012,0.459,-28.08"
"Italy (Sicily)" "Accuracy 3-4m"Suggerisco di inserire la proiezione originale di sandro e queste
modifiche in spatialreferences.org.
Sono trasformazioni già presenti nel database EPSG:
http://www.epsg-registry.org/
Basta digitare rispettivamente 1660, 1662 e 1664 in "retrieve by code"
Antonio
On Wed, 06 Feb 2008 13:04:18 +0100, Antonio Falciano wrote
Sono trasformazioni già presenti nel database EPSG:
http://www.epsg-registry.org/
Basta digitare rispettivamente 1660, 1662 e 1664 in "retrieve by code"Antonio
Esattissimo.
Ma allora il problema si sposta; perchè su QGis 0.9
e su PostGIS non riesco proprio a trovare le 1660,
1662 e 1664 ? non aggiornano gli EPSG ?
oppure ne usano solo un sub-set limitato ?
Comunque alla fine ho scoperto che tutta quanta
questa discussione è un doppione già approfonditamente
analizzato a suo tempo, vedi:
http://www.faunalia.com/pipermail/gfoss/2007-September/005654.html
comunque, repetita juvant
almeno per me è stato molto utile approfondire il punto
Sandro
Salve a tutti.
Invio in copia a Paolo Cavallini, che ha già risposto cortesemente al mio
collega Giuseppe Falcone.
Sto cercando di utilizzare QGIS, GPSBabel ed un ricevitore GPS bluetooth per
prelevare delle misure sul terreno acquisendo le coordinate da GPS.
Il GPS emette stringhe NMEA.
Uso QGIS 0.9.1, GPSBabel 1.3.4 (esterno, non quello interno a QGIS).
Ho ottenuto il risultato di acquisire il punto (waypoint) in QGIS.
Non riesco però a risolvere i seguenti problemi.
------------------------------
Problemi con QGIS:
* QGIS mi crea un layer per ogni singolo punto GPS rilevato: è possibile far
confluire più misure direttamente in un unico layer? Anche se metto sempre lo
stesso nome di layer, me ne fa uno nuovo ad ogni punto che acquisisco.
Il parametro "append_positioning=1" non ha nessun effetto.
La chiamata a gpsbabel è la seguente:
C:\Documents and Settings\editing\Desktop\gpsbabel\gpsbabel.exe -w -i
nmea,date=20080206,gpgga=1,get_posn,append_positioning=1 -o gpx %in %out
* posso ottenere nel layer QGIS otenuto anche i metadati del punto rilevato,
come ora della misura, precisione, numero di satelliti, ecc.
Questi dati sono presenti nel file GPX, ma nel layer QGIS non arrivano.
* la struttura a plugin di QGIS dovrebbe permettere di costruire un bottone
rapido che esegua la lettura di un punto da GPS senza chiedere niente
all'utente (nome file GPX, nome layer)? Esiste già qualcosa del genere?
Consigliereste ad un programmatore di imbarcarsi in questa avventura?
--------------------------------------
Problemi con GPSBabel:
* è possibile evitare di dichiarare la data a linea di comando per usare le
stringhe NMEA? non capisco perché non riceve data e ora direttamente dal
ricevitore GPS... inoltre nel file GPX creato riporta come data l'1 gennaio
1970...
<wpt lat="40.793428333" lon="17.129485000">
<ele>449.000000</ele>
<time>1970-01-01T09:33:13.000Z</time>
<name>Position</name>
<cmt>Position</cmt>
<desc>Position</desc>
<fix>3d</fix>
<sat>4</sat>
<hdop>9.900000</hdop>
</wpt>
* il manuale è piuttosto ostico... esiste un tutorial? 
---------------------------------------
Qualcuno è in grado di aiutarmi?
Le mie ricerche fin'ora si sono bloccate a questo... punto
Grazie!
Vito Meuli
--
Ing. Vito Meuli
Tecnologie Avanzate S.r.l.
via B. Croce, 49
70015 Noci (BA)
tel. +39 080 4979652
fax +39 080 4979263
email: v.meuli@tecnologieavanzate.it
http://www.tecnologieavanzate.it