Sei instancabile Sandro! E' chiaro (ed evidente) che per l'uso quotidiano avere un +towsg84 di default è meglio che niente. L'utente generico, quindi, non può che goderne. Il punto è se, concettualmente, è opportuno o meno infilare una trasformazione all'interno di un codice epsg ufficiale. Io, e altri, riteniamo di no. Altri invece, più pragmatici, preferiscono di sì perché perlomeno aiuta a non commettere gravi errori di default.
La cosa importante è che l'utente sia cosciente della presenza dei +towgs84 nei 3003/3004 23032/23033, perché è più facile vedere un errore di 130 metri (e quindi essere costretti a valutare come operare in base al livello di precisione richiesta) che non un errore di pochi centrimetri, che in generale può andar bene ma in altri potrebbe introdurre imprecisioni meno evidenti. Grazie Sandro ;) giovanni Il 23 maggio 2012 13:47, <[email protected]> ha scritto: > On Wed, 23 May 2012 00:50:10 +0200, G. Allegri wrote: >> >> Proporrei anche un poll sull'opportunità o meno di avere i parametri >> di trasformazione nei nostri 3003/3004. Se fosse ritenuto inopportuno, >> potremmo proporre d'aggiungere un'eccezione dentro >> datum_shift_pref.csv. >> > > dopo tante chiacchiere: cosa cambia veramente ? > come ci insegna padre Galileo: "prova,e lo scoprirai" ;-) > > metodologia (all'acqua di rose, ma spero indicativa): > ----------------------------------------------------- > a) ho preso lo SHP dei comuni ISTAT che e' in ED50 (23032 zona 32N) > purtroppo non ho trovato nessuna cartografia in GB che coprisse > l'intero territorio nazionale e che fosse open data. > comunque ED50 assomiglia abbastanza a GB, visto che neppure per > ED50 e' definito +datum, quindi immagino che lo possiamo considerare > abbastanza significativo. > > b) a questo punto, per evitare di dovere maneggiare poligoni complessi, > ho semplicemente estratto un unico punto rappresentativo per ciascun > comune tramite ST_PointOnSurface() > > c) quindi ho usato Traspunto per tasformare in WGS84/UTM (32632 zona 32N) > ok, Traspunto e' "free beer", non e' "free speech" ... ma chissenefrega, > almeno supporta i grigliati e quindi dovrebbe assicurare una > trasformazione > ragionevolmente accurata e precisa (ammazza, quanto e' lento ...) > > a questo punto ho aggiunto altre due geometrie WGS84/UTM (32632). > > 1) UPDATE test SET new = ST_Transform(ed50, 32632); > 2) UPDATE test SET old = ST_Transform(ed50, 32632); > > tra la prima e la seconda trasformazione ho "taroccato" la spatial_ref_sys, > in modo da usare in un caso la stringa geodetica della proj 4.8, mentre > nell'altro caso ho usato la vecchia definizione della proj 4.7 > > 4.8: <23032> +proj=utm +zone=32 +ellps=intl +towgs84=-87,-98,-121,0,0,0,0 \ > +units=m +no_defs > 4.7: <23032> +proj=utm +zone=32 +ellps=intl +units=m +no_defs > > a questo punto e' possibile misurare le differenze (ST_Distance) tra i > punti riproiettati con le Proj4 vecchie/nuove rispetto all'attesa > calcolata da Traspunto (che si presume essere "vera"). > > ... giusto un pizzico di SQL, ed possiamo infine elaborare gli scostamenti > in modo "umanamente leggibile" > > > risultati: > ------------------------------------------- > usando la vecchia definizione proj 4.7 (nessun termine +towgs84) abbiamo > sempre un errore di approssimazione attorno ai 130 metri. > per la precisione: abbiamo circa 120m in friuli (min) e circa 140m in > sicilia (max). > > e questi invece sono i risultati con la nuova definizione 4.8: > regione|min|max|media > ------------------------------------------ > PIEMONTE|1.277394|4.024892|2.154641 > VALLE D'AOSTA|1.878692|2.384392|2.137171 > LOMBARDIA|1.315821|2.651201|1.757839 > TRENTINO|2.058717|6.168168|2.807766 > VENETO|1.342849|3.813670|2.352485 > FRIULI|0.387489|2.895905|1.164570 > LIGURIA|2.390399|3.955088|3.214253 > EMILIA|1.833147|2.782378|2.242143 > TOSCANA|2.018248|4.358725|3.056313 > UMBRIA|1.830834|2.856724|2.462150 > MARCHE|1.696620|3.412800|2.398695 > LAZIO|2.502648|4.830592|3.246603 > ABRUZZO|3.046290|4.033936|3.658762 > MOLISE|3.577080|4.438901|4.008658 > CAMPANIA|4.094453|9.479399|5.966463 > PUGLIA|2.959158|7.930232|6.169741 > BASILICATA|5.528439|9.448095|7.637302 > CALABRIA|8.612826|15.985373|12.509107 > SICILIA|11.987892|16.139030|14.917476 > SARDEGNA|2.798417|8.729139|5.858507 > > ora gli errori di approssimazione oscillano tra poche decine > di cm (friuli) e cira 16m (sicilia). > > se fissiamo una soglia arbitraria a 5m per il caso peggiore, > scopriamo che quasi tutta l'italia cade entro la soglia. > restano tagliate fuori: Trentino, Puglia, Sardegna, Basilicata, > e Campania. per la Calabria e la Sicilia abbiamo errori sempre > sopra ai 10m / 15m. > > se passiamo ad un'analisi per provincie, scopriamo che a > Trieste e Gorizia l'errore e' inferiore al metro (raccomandati !!!!) > viceversa i casi peggiori li abbiamo per Reggio Calabria, Messina, > Catania ed Enna, dove siamo sempre oltre ai 15m > > probabilmente e' presente un errore sistematico: ISTAT considera > tutta l'Italia nel fuso Ovest 32, ma meta' delle regioni sono > nel fuso Est 33 ... stranamente sia gli scostamenti minimi che > quelli massimi li abbiamo proprio per localita' del fuso Est 33, > quindi suppongo che gia' il dato ISTAT si porti dietro qualche > problema di approssimazione all'origine. > > se quindi depuriamo, e teniamo per buone solo le regioni del > fuso ovest 32 (Aosta, Piemonte, Liguria, Lombardia, Veneto, > Emilia, Toscana e Sardegna) allora abbiamo errori di circa > 2 o 3m sul continente, che arrivano a 5 / 8m in sardegna. > > e questo e' quanto: mi pare che ora abbiamo un quadro abbastanza > dettagliato per provare a fissare definitivamente le idee. > > > ciao Sandro > > -- > Il messaggio e' stato analizzato alla ricerca di virus o > contenuti pericolosi da MailScanner, ed e' > risultato non infetto. > _______________________________________________ [email protected] 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
