[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