[Gfoss] Assegnare proiezione in gvSIG
Antonio Falciano
afalciano at yahoo.it
Tue Sep 11 09:58:01 CEST 2007
Pietro Blu Giandonato ha scritto:
> Vorrei a questo punto sottoporvi un problema che ho riscontrato riguardo
> l'utilizzo di dati con differenti CRS.
> In ufficio, in Regione, utilizziamo ArcXXX per lavorare abitualmente,
> con layer con i seguenti CRS:
> 1) Gauss-Boaga est (ESRI "Monte_Mario_Italy_2")
> 2) ED50 UTM33N (ESRI "ED_1950_UTM_Zone_33N")
> 3) WGS84 UTM33N (ESRI "WGS_1984_UTM_Zone_33N")
> ...per non parlare dei 32N e anche 34N per la parte più a est della Puglia.
In Puglia, devo darvi atto, si presenta la casistica più ampia...
> Il problema è l'amata-odiata Gauss-Boaga. Mi spiego...
> Caricando in una mappa di ArcXXX tre layer ognuno con un CRS differente
> tra quelli citati sopra, accade quanto segue:
> a) impostando il CRS della mappa come 1) si sovrappongono correttamente
> i layer 1) e 3) ma non 2)
> b) impostando il CRS delle mappa come 2) si sovrappongono correttamente
> i layer 2) e 3) ma non 1)
> c) impostando il CRS della mappa come 3) tutti i layer si sovrappongono
> correttamente.
>
> Qui appresso i parametri delle trasformazioni tra:
> i) CRS 2) e 3), tipo: Geocentric Translation, parametri: dx = -104.0; dy
> = -101.0; dz = -140.0
ED_1950_To_WGS_1984_1 1133 Geocentric_Translation -87 -98 -121
> ii) CRS 1) e 3), tipo: Position Vector, parametri: dx = -104.0; dy =
> -49.1; dz = 9.9; rx = 0.971; ry = -2.917; rz = 0.714 ; s = -11.68
Monte_Mario_To_WGS_1984_4 1660 Position_Vector -104.1 -49.1 -9.9 0.971
-2.917 0.714 -11.68
> iii) CRS 1) e 2) non è possibile definire una trasformazione.
Dovresti utilizzare "in serie" le due citate in precedenza mediante
project tool.
>
> Appare chiaro dunque che la mancata sovrapposizione tra i layer 1) e 2)
> settando uno o l'altro dei CRS è dovuta al fatto che manca una
> trasformazione tra i due sistemi di riferimento. Il problema invece non
> sussiste se scegliamo il WGS84 UTM33N come sistema di rappresentazione
> dell'intera mappa, poichè 1) e 2) possono essere trasformati nel 3).
Infatti, le trasformazioni "composte" di coordinate ricorrono ad datum
geocentrico di appoggio (WGS84).
>
> Se avrete pazienza, sono costretto a fare una digressione.
> Quando ArcXXX era nella versione ArcView 3.0, il CRS Gauss-Boaga (GB)
> non era "cagato" nemmeno per sbaglio da questi, e ricordo che mi si pose
> il serio problema di dover riproiettare proprio in GB delle carte
> topografiche IGM che avevo georeferenziato in ED50 UTM33N grazie al
> reticolo sovrastampato, CRS che invece era supportato. Ovviamente non
> avendo ArcView i parametri GB nel proprio database non potevo procedere
> alla riproiezione.
>
> Riuscii però a procurarmi una pubblicazione, che purtroppo ho smarrito e
> non ricordo nemmeno di chi fosse, una sorta di piccolo trattato di
> cartografia che parlava proprio della trasformazione tra GB e ED50
> UTM33N. Il testo affermava che il problema della GB consisteva nel fatto
> che i parametri di trasformazione cambiavano per ogni foglio di taglio
> 1: 100.000, e riportava in appendice una serie di tabelle che elencavano
> i suddetti parametri foglio per foglio di tutta Italia. Grazie ad esse
> calcolai in maniera spartana i parametri per la Puglia, mediando quelli
> del foglio più a NO e quello più a SE. In tal modo sarei stato in grado
> di mitigare al meglio l'errore dovuto ai centri di proiezione differenti
> per ogni foglio, ottenendo un file di definizione della GB per la Puglia
> abbastanza preciso. I parametri di definizione erano identici al ED50
> UTM33N, cambiavano solo il falso est e il falso nord, rispettivamente
> 2.519.941 metri e -186 metri.
>
> Molto simile a quello che nelle versioni seguenti di ArcView 3.x sarebbe
> poi stato il GB, finalmente supportato, ma in cui falso il est è
> 2.520.000 metri e il falso nord 0 metri. Questa piccola differenza,
> usando il GB "ufficiale", mi portava a riproiezioni di layer che
> generavano uno shift diagonale che andava da 50 a oltre 200 metri,
> mentre con il "mio" GB lo shift era quasi inesistente.
Questo perchè i tuoi parametri, con buona approssimazione, riproducono
lo scostamento esistente tra i due sistemi cartografici. ESRI, invece,
così come altri software (es.: gvSIG), utilizzano delle trasformazioni di
default che non necessariamente si prestano bene al caso dell'Italia
peninsulare, bensì a Sicilia e/o Sardegna. Affidarsi alla proiezione al
volo comporta l'utilizzo di queste trasformazioni di default e quindi
accuratezze inaccettabili, mentre definire il CRS ed la trasformazione
da adottare (un pò come hai fatto tu), quando ciò è possibile,
garantisce un corretto utilizzo del software. Al momento in ambito
GFOSS, GRASS e Qgis che utilizzano le librerie PROJ consentono di
applicare le trasformazioni aggiungendo al WKT di proj il parametro
+towgs84, ovvero le traslazioni, le rotazioni ed un fattore di scala
(questi ultimi sono presenti solo nelle trasformazioni a 7 parametri tipo
Position Vector e Coordinate Frame).
C'è anche da dire che le trasformazioni dell'EPSG presentano accuratezze
fino a 4 m e quindi per grandi scale a partire dal 25k lasciano il tempo
che trovano...
>
> Oggi continuo a usare in alcuni casi gli stessi parametri che misi a
> punto allora, quando purtroppo costretto ad utilizzare dati GB e ED50
> UTM33N contemporaneamente, che non si sovrappongono affatto tra loro, a
> meno di non impostare per la vista/mappa la WGS84 UTM33N. Usando il CRS
> "rivisto e corretto" invece, tutto si sovrappone, a prescindere dal CRS
> scelto per la visualizzazione.
>
> Chi è arrivato fin qui a leggere si chiederà: e allora? E allora vi
> chiedo se avete mai riscontrato situazioni del genere anche dalle vostre
> parti. E magari qualche superesperto di CRS potrà chiarire la situazione.
E' normale. E' così ovunque in tutta Italia.
>
> A presto,
> PB
Ciao
Antonio
>
>
>
>
> Il 10/09/07, *Markus Neteler* ha scritto:
>
> On Sun, Sep 09, 2007 at 06:44:57AM -0700, mando wrote:
> >
> > Salve,
> > ho iniziato a dare un'occhiata a gvSIG, ma non riesco a capire come
> > assegnare ad un layer la proiezione corretta.
> > Ho una base con raster 1:25000 e 1:5000 della provincia di rimini
> e con QGIS
> > li carico correttamente con Monte Mario (Rome) Italy zone 2.
> >
> > Ora in QGIS carico anche i confini ISTAT dei comuni italiani che
> sono in
> > ELD79/UTM zone 32 e tramite proiezione al volo vengono correttamente
> > sovrapposti ai dati sopra descritti.
> >
> > In gvSIG non riesco a fare questo. Quale proiezione devo
> assegnare o meglio,
> > esistono delle tabelle di confronto dei vari nomi e codici (EPSG,
> postgis,
> > etc) in modo da poter sapere quale proiezione usare?
>
> Credo che sia il solito problema che il software non contiene
> i datum geodetici di GaussBoaga. Non ho verificato con gvSIG pero'.
>
> Missa che GRASS e' l'unico GIS libero che contiene questi
> parametri :) Infatti, e' un po triste che tanti software hanno
> ancora questo problema.
>
> Se mancano i datum italiani in gvSIG, bisogna definire la proiezione
> "a mano" includendo il parametro "towgs84...". Nell'archivio di questa
> lista dovrebbono esserci questi parametri (si trovano anche GRASS o
> sul sito http://crs.bkg.bund.de/crs-eu/
> <http://crs.bkg.bund.de/crs-eu/> -> CRS Description -> national -> I).
>
> ciao
> Markus
>
> ------------------
> ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
> ITC -> since 1 March 2007 Fondazione Bruno Kessler
> ------------------
>
> _______________________________________________
> Iscriviti all'associazione GFOSS.it:
> http://www.gfoss.it/drupal/iscrizione
> Gfoss a faunalia.com <mailto:Gfoss a faunalia.com>
> http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
> Gfoss a faunalia.com
> http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.485 / Virus Database: 269.13.13/998 - Release Date: 10/09/2007 8.48
More information about the Gfoss
mailing list