[Gfoss] GaussBoaga / Proj4 v.3.8.0

Mer 23 Maggio 2012 00:50:10 CEST

Io comunque la proposta di un campo authority l'ho fatta a Frank, La
troverei comunque utile, nel caso ci fosse una volontà di non
allontanarsi troppo da EPSG ufficiale.

Proporrei anche un poll sull'opportunità o meno di avere i parametri
di trasformazione nei nostri 3003/3004. Se fosse ritenuto inopportuno,
potremmo proporre d'aggiungere un'eccezione dentro
datum_shift_pref.csv.

Riguardo l'uso apparentemente casuale di +ellps e +datum, immagino
(spero!) abbia in realtà un senso preciso perché i due concetti sono
ben diversi!
Sandro, mi stai inducendo a perdermi tra il codice delle Proj4! :D

giovanni

Il 23 maggio 2012 00:34,  <a.furieri a lqt.it> ha scritto:
> 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 a 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