[Gfoss] GaussBoaga / Proj4 v.3.8.0

[Antonio Falciano]

Grazie innanzitutto a Sandro, Madi e Giovanni per lo sforzo profuso nel
cercare di chiarire ulteriormente questa faccenda...

Il 22/05/2012 23.16, G. Allegri ha scritto:
> Riporto anche qua la logica adottata nella scelta dei parametri di
> trasformazione, spiegata nella risposta di Frank [1] e implementata in
> [2].
>
>   * Viene preferita la trasformazione che interessa l'area maggiore per
> un dato GCS

logica a mio modesto avviso non condivisibile che, a sua volta,
contrasta con quanto poi lo stesso Frank afferma nel finale:

"Also, please understand that no set of shift values is ideal and I
prefer something broadly reasonable to something that is super
in one local region and very poor in another where the datum is
used.   The "largest area of use" rule of thumb is intended to
select on this basis."

>   * Viene evitata ogni trasformazione deprecata
>   * Vengono evitate i record che sono stati ridefiniti ("superceeded")
> da altre regole
>
> E'possibile forzare una trasformazione indicandola dentro [3].

Benissimo! Ad esempio:

##############################################
#
# We don't want to apply TOWGS84 values for NAD27 - we prefer to use
# datum grid shift files.
#
4267,-1

...mi pare abbastanza esplicito! :)

> Frank invita a suggerire una logica alternativa che permetta di
> evitare la "questione italiana". Non credo ci siano opzioni diverse se
> dei parametri vanno definiti. Il punto è se sia opportuno definirli
> per il 3003 e il 3004...

Ma certo che non e' opportuno!

> giovanni
>
>
> [1] http://lists.osgeo.org/pipermail/gdal-dev/2012-May/032895.html
> [2] http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/build_pcs.py
> [3] http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/datum_shift_pref.csv
>
> Il 22 maggio 2012 22:48, G. Allegri<giohappy a gmail.com>  ha scritto:
>> Grazie Margherita,
>> ho dato seguito all'email di Even.
>>
>> giovanni
>>
>> Il 22 maggio 2012 22:25, Margherita Di Leo<diregola a gmail.com>  ha scritto:
>>> Ciao,
>>>
>>> ho segnalato la cosa sulla ML di gdal, e forse abbiamo una
>>> pista: http://lists.osgeo.org/pipermail/gdal-dev/2012-May/032891.html

Tornando alla pista segnalata da Even, e' evidente che il changeset
http://trac.osgeo.org/proj/changeset/2172 non ci tocca neanche di
striscio, tuttavia qui sono gia' presenti i parametri +towgs84 dove non
dovrebbero stare. Quindi il fattaccio e' accaduto prima e occorre
pertanto esaminare le revision a ritroso:
http://trac.osgeo.org/proj/changeset/2104 --> idem
http://trac.osgeo.org/proj/changeset/2034 --> idem
http://trac.osgeo.org/proj/changeset/1874 --> idem
mentre qui pare che sia avvenuto il tutto:
http://trac.osgeo.org/proj/changeset/1824 --> (http://bquot.com/cj9)
Regenerated epsg init file from EPSG 7.4.1 with big datum upgrade
del 28 febbraio 2010... un "big datum upgrade" che purtroppo non ci 
soddisfa tutti.

ciao
Antonio

-- 
Antonio Falciano
http://www.linkedin.com/in/antoniofalciano