On Tue, 22 May 2012 22:48:17 +0200, G. Allegri wrote:
Grazie Margherita,
ho dato seguito all'email di Even.
altro giro di verifiche alla luce delle risposte di Even prima,
e di Frank Warmerdam a seguire.
e' definitivamente confermato che il file EPSG distribuito con
le Proj4 4.8.0 e' stato prodotto a partire da GDAL, usando questo
script python:
epsg_tr.py --config OVERRIDE_PROJ_DATUM_WITH_TOWGS84 FALSE \
-proj4 -skip -list gcs.csv > epsg
epsg_tr.py --config OVERRIDE_PROJ_DATUM_WITH_TOWGS84 FALSE \
-proj4 -skip -list pcs.csv >> epsg
n.b: l'opzione OVERRIDE_PROJ_DATUM_WITH_TOWGS84 FALSE e'
esattamente intesa a preservare, per quanto possibile, il
vecchio stile, evitando cioe' di sostituire +datum con +towgs84
un po' di esempi concreti per capire meglio come funziona:
---------------
4.7: <32632> +proj=utm +zone=32 +ellps=WGS84 +datum=WGS84 +units=m
+no_defs
4.8: <32632> +proj=utm +zone=32 +datum=WGS84 +units=m +no_defs
N.B.: e' sparito a sorpresa il termine +ellps; tutto il resto e'
invariato, ma si tratta comunque di WGS84 nativo.
---------------
4.7: <3814> +proj=tmerc +lat_0=32.5 +lon_0=-89.75 +k=0.9998335
+x_0=500000 \
+y_0=1300000 +ellps=GRS80 +datum=NAD83 +units=m +no_defs
4.8: <3814> +proj=tmerc +lat_0=32.5 +lon_0=-89.75 +k=0.9998335
+x_0=500000 \
+y_0=1300000 +datum=NAD83 +units=m +no_defs
anche qua, e' sparito +ellps, ma tutto il resto e' uguale.
N.B. se invece lo generiamo con OVERRIDE_PROJ_DATUM_WITH_TOWGS84 TRUE:
4.8: <3814> +proj=tmerc +lat_0=32.5 +lon_0=-89.75 +k=0.9998335
+x_0=500000 \
+y_0=1300000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
ora e' sparito +datum, e riappare a sorpresa +ellps: personalmente
trovo delizioso il termine +towgs84 tutto settato a ZERO: utilissimo
per consumare qualche ciclo di CPU e per tenere belli caldi i registri
:-D
forse sbaglio, ma parrebbe quindi che +ellps e +datum siano considerati
interscambiabili a gogo ... graditi lumi da parte di quelli che
"sussurrano
agli ellissoidi"
--------------
4.7: <3003> +proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 \
+y_0=0 +ellps=intl +units=m +no_defs
4.8: <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
e finalmente siamo arrivati al nostro amatissimo GB ex-nazionale.
ecco spiegato l'arcano: qua non esiste nessuna definizione +datum,
abbiamo
sempre e solo +ellps
OVERRIDE_PROJ_DATUM_WITH_TOWGS84 viene interpretato esattamente alla
lettera: quando non esiste il termine +datum, allora il termine
+towgs84
viene inserito "a prescindere"; impostando l'opzione a FALSE oppure a
TRUE
non cambia assolutamente nulla, il risultato e' sempre il medesimo :-P
come ci ha poi cortesemente spiegato FW, il termine +towgs84 viene
scelto
in base al "caso medio", cioe' a quel che si presume che sia il piu'
popolare
e che possa soddisfare il maggior numero di utenti (geodesia
democratica ?)
================
provando a tirare le somme:
a) a partire da GDAL 1.8.0 e' stata introdotto un cambio sostanziale
nei
criteri di gestione delle stringhe geodetiche di Proj4
sono sicuramente state prese alcune sagge cautele per limitare i
danni
di questa brusca "rivoluzione".
ciononostante, circa 2900 SRIDs su 3700 sono bruscamente cambiati,
cioe' tutti quelli che non esponevano un termine +datum
a spanne, tutti quelli "storici" anteguerra sono stati massacrati,
ed
in pratica si sono salvati solo gli SRS piu' recenti basati su
WGS84,
NAD83, GRS80 e pochissimi altri.
b) il fatto che i tempi di aggiornamento di GDAL, GeoTIFF e Proj4 siano
esageratamente lunghi spiega perche' ce ne siamo accorti solo ora;
in
effetti si tratta di scelte nate circa 2 anni fa, ma che iniziano a
diventare evidenti solo oggi ai fini pratici.
c) probabilmente in molti casi i criteri "nuovi" saranno molto piu'
graditi
ai mitici "utenti medi", e renderanno piu' facile l'uso di
funzionalita'
tipo reproject-on-the-fly.
altrettanto sicuramente manderanno al manicomio gli utenti
professionali
... ma non si puo' sempre avere tutto dalla vita ;-)
conclusione:
non c'e' nussun bug (purtroppo), si tratta di precise scelte di
progetto.
piaccia o non piaccia, questo e' il nuovo scenario con il quale siamo
destinati a doverci confrontare nei prossimi anni.
prendiamone atto, e cerchiamo di limitare i danni al minimo facendo
ampia
opera di divulgazione e di corretta informazione: renderemo sicuramente
un
servizio utile a tutta quanta la nostra community nazionale.
grazie comunque a tutti quei volenterosi che si sono generosamente
spesi
per arrivare a chiarire definitivamente questo spiacevole garbuglio.
ciao Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012
