[Gfoss] GaussBoaga / Proj4 v.3.8.0

[a.furieri a lqt.it]

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.