[Gfoss] GaussBoaga / Proj4 v.3.8.0

[a.furieri a lqt.it]

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.