[Gfoss] impiego di grigliati con proj 4.8.0 - ex GaussBoaga / Proj4 v.3.8.0

[Andrea Peri]

A beneficio di altri:

Vista la situazione abbastanza caotica prodotta dalle nuove proj4.8.0.
Ho ritenuto di fare delle prove per vedere come si puo' compensare la cosa,
facendo uso dei grigliati IGM (in formato NTv2)

http://87.30.244.175/nota_tecnica_NTv2.pdf

Il banco di prova per i tests ho usato un mapserver sotto Linux:

Il test si è sviluppato cosi':
dati di partenza in epsg:25832 (realizzazione etrs89-etrf2000) alias:
UTM-ETRF2000

dati attesi in output in epsg:3003 (alias GaussBoaga) e/o in epsg:4326
(alias WGS84)

Ipotesi di partenza:

nella installazione di proj si e' fatto uso delle cartelle di default e
quindi la definizioni epsg sono contenute nella cartella:
/usr/local/share/proj

Esecuzione:

Step 1)

supponendo che il file con i grigliati IGM si chiami
"44101110_44301150_R40_S89.gsb", tale file va copiato nella cartella di
default
delle definizioni epsg (/usr/local/share/proj).
Attenzione che potrebbero essere piu' di uno ogni file racchiude i
grigliati per passare da un sistema di riferimento a un altro.
In questo caso si parla di un file che contiene i grigliati per passare da
Roma40 a ETRS89.

Ovviamente se ci sono piu' file andranno copiati tutti quanti e usato di
volta in volta quello opportuno.

Step 2)

sempre nella cartella /usr/local/share/proj
si apre il file "epsg".

In esso si
modifica la definizione di epsg:3003 cambiandola da

<3003> +proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0
+ellps=intl +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +units=m
+no_defs  <>

a

<3003> +proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0
+ellps=intl +nadgrids=44101110_44301150_R40_S89.gsb +units=m +no_defs  <>

Si lascia invece invariata la definizione di epsg:25832 cosi' come è
proposta nel file epsg:

<25832> +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
+no_defs  <>

Si lascia altresi' invariata la definzione di epsg:4326
come proposta nel file:

<4326> +proj=longlat +datum=WGS84 +no_defs  <>

Step 3)

imposto un progettino MapServer per vedere dei risultati di riproiezione al
volo:

Nel mapfile imposto il seguente parametro per i dati in input:

  PROJECTION
    "+init=epsg:25832 +towgs84=0,0,0,0,0,0,0"
  END

inizio le prove:

Step 4)

Provando con Mapserver a farsi inviare una mappa riproiettata al volo da
Mapserver su epsg:3003 usando dati nativi in epsg:25832 il risultato
collima molto bene
con quello atteso per dei dati nativi in gaussBoaga (a essere pessimista ci
potrà essere qualche centimetro di differenza, ma probabilmente è inferiore)

Step5)

Provando a farsi inviare da mapserver una mappa su epsg:25832 (il sistema
di riferimento nativo dei dati in input) il dato arriva naturlamente
corretto.

Step 6)

Provando a farsi inviare da MapServer una mappa su epsg:4326 (sistema
geografico), il dato arriva riproietato correttamente con una buona
collimazione nei confronti del
medesimo dato nativo in lat-long calcolato sulla realizzazione
etrs89-etrf2000.

Step 7)
giusto per completezza ho provato a inserire i grigliati (tramite nadgrid
sulla definizione di epsg:4326,
ma il risultato viene molto errato.

[Considerazioni finali]

Nella ipotesi che i dati in ingresso siano epsressi in epsg:25832
(utm-etrf2000),
e ipotizzando che i sistemi ammessi in output siano epsg:4326, epsg:3003 e
epsg:25832,
i grigliati vanno inseriti solamente nella definizione di epsg:3003.

Mentre in quella epsg:4326 non servono (idem a maggior ragione in quella
epsg:25832).

Una ultima considerazione:

Ovviamente se si è in situazione opposta:

dati nativi in gaussBoaga, e in output si vuole supportare epsg:3003,
epsg:25832 e epsg:4326, i grigliati andranno inseriti nella sola
definizione di epsg:25832

Andrea.


-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20120523/b0211371/attachment.html>