[Gfoss] correzioni locali datum

[Massimo Di Stefano]

Esatto Frankie ...,
vecchio topic :

http://osgeo-org.1803224.n2.nabble.com/towgs-params-and-epsg-code-for-Italy-regions-td2449517.html

"""
The policy of Proj.4 is that when a datum has 
several alternative towgs84-shifts in the EPSG database, then Proj.4 
cannot know which one is best, so no one at all is chosen. (Until you 
add some towgs84 parameters manually, I mean.)   
"""

P.S.

/me ... start joke

.. a chi possiede (aziende) o chi potrebbe usare (università) 
una *stazione totale* dotata di *GPS ad alata precisione*

si potrebbe far partire una campagna di acquisizione "punti omologhi" (WGS84 - GBR40)
dai quali ricavare nuovi set di parametri di trasformazione (magari divisi per regione)

Dato che i vertici IGM non sono "liberi" 
.. pur'avendo a disposizione le monografie per la stima di parametri locali ...
non li si può poi redistribuire.

/me stop joke ...


Il giorno 15/ott/2010, alle ore 20.15, Francesco Paolo Lovergine ha scritto:

> On Wed, Oct 13, 2010 at 08:29:38PM +0200, Antonio Falciano wrote:
>> Il 13/10/2010 20.05, Paolo Cavallini ha scritto:
>>> Il 13/10/2010 17:26, Antonio Falciano ha scritto:
>>>> Torna, eccome... Se tu parli di correzione del datum ed io di parametri
>>>> di trasformazione (del datum), parliamo della stessa cosa, o sbaglio?
>>>> 
>>>> +towgs84   3 or 7 term datum transform parameters
>>>> http://trac.osgeo.org/proj/wiki/GenParms
>>> 
>>> Ciao.
>>> Ma tu questi parametri ce li hai? Sai che siano scritti in un posto standard? Non
>>> capisco come mai, ma ognuno li tramanda come se fossero la ricetta della crostata
>>> della nonna :)
>>> Saluti, e grazie.
>> 
>> Paolo,
>> i parametri sono tutti contenuti nel database EPSG
>> (http://www.epsg-registry.org/), non nel ricettario della nonna! ;)
>> Sul blog di Andrea Antonello troverai istruzioni dettagliate:
>> http://jgrasstechtips.blogspot.com/2008/03/how-to-find-and-use-bursa-wolf.html
>> 
>> EPSG:3044 ETRS89/TM32
>> http://spatialreference.org/ref/epsg/3044/
>> dalle ns parti, coincide di fatto con EPSG:32632, visto che
>> l'orientamento di GRS80 e di WGS84 e' lo stesso, quindi:
>> +proj=utm +zone=32 +ellps=GRS80 +units=m +towgs84=0,0,0 +no_defs
>> 
>> EPSG:2077 ELD79/UTM zone 32N
>> http://spatialreference.org/ref/epsg/2077/
>> e' definito per la Libia, mentre per l'Italia non ha senso...
>> qui coinciderebbe con EPSG:23032! Ma se proprio uno ci tiene ad
>> utilizzarlo in Italia contribuendo ad alimentare la babele gia' esistente:
>> +proj=utm +zone=32 +ellps=intl +units=m +towgs84=-87,-98,-121 +no_defs
>> 
>> Il primo passi pure, mentre il secondo non lo inserirei nel wiki.
>> 
> 
> Tutto corretto, ma con beneficio di inventario. Quando EPSG non inserisce
> parametri di trasformazione puo' semplicemente essere che non esiste
> un set di parametri unici perche' convenzionalmente 
> si adottano grigliati locali, ovvero la materializzazione non e' 
> univocamente determinata. Se occorre lavorare con dati allineati 
> a tali grigliati si rischiano fastidiosi shift non lineari dei 
> punti trasformati con set 'medi' inadatti. Ben venga l'iniziativa
> della RER, ma qual e' il grado di precisione? E' opportuno dichiararlo IMHO.
> 
> -- 
> Francesco P. Lovergine
> _______________________________________________
> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
> Gfoss a lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non rispecchiano necessariamente
> le posizioni dell'Associazione GFOSS.it.
> 474 iscritti al 18.9.2010

-------------- parte successiva --------------
Un allegato HTML ?tato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20101015/92982705/attachment.htm>