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<gioha...@gmail.com> ha scritto:
Grazie Margherita,
ho dato seguito all'email di Even.
giovanni
Il 22 maggio 2012 22:25, Margherita Di Leo<direg...@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
_______________________________________________
Gfoss@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
