[Gfoss] GaussBoaga / Proj4 v.3.8.0

[G. Allegri]

Ottimo resoconto Sandro, questi giorni non ero riuscito a studiarmi
meglio il caso. Grazie.
Davo per scontato si sapesse che l'EPSG Registry non distribuisce il
file epsg così come lo conosciamo nel mondo GFOSS...

giovanni

Il 22 maggio 2012 15:47,  <a.furieri a lqt.it> ha scritto:
> On Mon, 21 May 2012 13:36:02 +0200, Francesco P. Lovergine wrote:
>>
>> Pensavo fosse ormai ampiamente noto, quoto per esempio hamish_b in
>> un recente scambio con lui in merito:
>>
>>> pps- AFAIK proj 1.8.0's epsg file makes a big problem for GRASS,
>>> QGIS, and others as it has removed all the +datum= terms and
>>> replaced them with +towgs84= coefficients. ------ cut -----
>>
>>
>> Quindi il casino sembra un po' più esteso della sola zona italiana...
>> Tra parentesi, si potrebbe pensare che ci siano gli estremi per una
>> violazione di licenza dei dati EPSG ----- cut -----
>>
>
> allora, qualche novita' e qualche approfondimento, spero utili:
>
> a) Proj4 non e' affatto il punto di partenza; e' semplicemente
>   il punto d'arrivo finale.
>   come gia' segnalavo ieri (ma forse e' passato inosservato ad
>   alcuni) le definizioni CRS nascono da GDAL, passano da GeoTIFF
>   e solo all'ultimo confluiscono in PROJ.4
>   tutto il ciclo di gestione del file EPSG e' spiegato chiaramente qua:
>   http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/README
>
> b) non esiste nessun omino che prepara a mano il file delle definizioni
>   EPSG: e' semplicemente il risultato di un processo completamente
>   automatico; per l'esattezza, di uno script Python dentro a GDAL
>
> c) giusto per pedanteria: il file EPSG ... col cavolo che e' EPSG :-D
>   il deliverable offerto direttamente da EPSG usa su un medello dati
>   complicatissimo, basato su decine di tavole e viste DBMS.
>   non assomiglia minimamente alle semplici stringhe geodetiche di Proj4,
>   assomiglia piuttosto alla definizioni SRS-WKT
>   http://www.epsg.org/geodetic.html
>
> d) quindi, correttamente, il famoso e benedetto file EPSG e' semplicemente
>   un file di testo prodotto internamente da GDAL a beneficio di Proj.4
>   e di tutti gli altri packages che dipendono dalle Proj.4
>   ma e' comunque il frutto di una rielaborazione, non e' affatto un
>   prodotto supportato direttamente da EPSG.
>
> e) per motivi che sfuggono all'umana comprensione, ad un certo punto
>   qualche sviluppatore di GDAL ha deciso di introdurre dalla 1.8.0
>   un'opzione (infelicissima ...) che consentisse di sostituire tutte
>   le definizioni +datum con una +towgs84
>
> f) saggiamente, si trattava di un'opzione facoltativa: secondo la doc
>   citata in a) il modo standard per generare il file EPSG era quindi:
> epsg_tr.py --config OVERRIDE_PROJ_DATUM_WITH_TOWGS84 FALSE -proj4 \
> -skip -list gcs.csv > epsg
>   (insomma, seguire la vecchia strada consolidata, non la nuova).
>
> g) mi sono appena divertito a fare una veloce sessione di debugging
>   con GDAL trunk: l'opzione OVERRIDE_PROJ_DATUM_WITH_TOWGS84 e'
>   sicuramente presente nel codice, ma evidentemente nell'implementazione
>   attuale (e suppongo fin dalla 1.9.0 o addirittura dalla 1.8.0) c'e'
>   sotto qualche bel bug che la rende assolutamente inefficace.
>   ... da cui nasce a catena tutto il casino a seguire :-P
>
> h) n.b.: si tratta di un bug dalla storia lunga e tormentata.
>   vedi ticket #122 PROJ4 [guarda caso, aperto proprio da Hamish] ;-)
>   http://trac.osgeo.org/proj/ticket/122
>   questo bug viene dato come "closed"; ed infatti il problema non e'
>   affatto nella Proj4, e' tutto dentro a GDAL :-)
>   cose che capitano quando si apre un ticket nel trac sbagliato :-P
>
> h) giusto per conferma e verifica quick&dirty, ho brutalmente macellato
>   il codice di GDAL, eliminando radicalmente tutta la sezione legata
>   all'opzione OVERRIDE_PROJ_DATUM_WITH_TOWGS84
>   Sorpresa, in questo modo lo script python epsg_tr.py ora mi genera un
>   "sano" file EPSG vecchio stile, senza piu' nessuna assurdita' +towgs84 ;-)
>   giusto se qualche avventuroso si vuole divertire a fare due verifiche,
>   lo trovate qua: http://www.gaia-gis.it/epsg-trick.zip
>
> ------------------
>
> qualche volonteroso se la sente cortesemente di aprire un ticket su GDAL
> in base alle informazioni disponibili ????
> se permettere, penso di avere gia' dato abbastanza per la causa :-P
>
> 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