[Gfoss] Assegnare proiezione in gvSIG

Pietro Blu Giandonato p.giandonato at gmail.com
Tue Sep 11 09:17:05 CEST 2007


Sito molto molto utile Markus, grazie della segnalazione.

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.

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
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
iii) CRS 1) e 2) non è possibile definire una trasformazione.

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).

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.

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.

A presto,
PB




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/    -> 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
> http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
>
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: http://www.faunalia.com/pipermail/gfoss/attachments/20070911/891089c0/attachment-0001.htm 


More information about the Gfoss mailing list