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.