GaussBoaga / Proj4 v.3.8.0
Locked
123
123
 
|
Grazie Margherita,
ho dato seguito all'email di Even. giovanni Il 22 maggio 2012 22:25, Margherita Di Leo <[hidden email]> 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 > > ciao madi > > -- > Ing. Margherita Di Leo, Ph.D. > > _______________________________________________ > [hidden email] > 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 [hidden email] 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 |
|
|
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 * 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]. 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... 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 <[hidden email]> ha scritto: > Grazie Margherita, > ho dato seguito all'email di Even. > > giovanni > > Il 22 maggio 2012 22:25, Margherita Di Leo <[hidden email]> 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 >> >> ciao madi >> >> -- >> Ing. Margherita Di Leo, Ph.D. >> >> _______________________________________________ >> [hidden email] >> 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 [hidden email] 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 |
Re: GaussBoaga / Proj4 v.3.8.0
|
|
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<[hidden email]> ha scritto: >> Grazie Margherita, >> ho dato seguito all'email di Even. >> >> giovanni >> >> Il 22 maggio 2012 22:25, Margherita Di Leo<[hidden email]> 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 _______________________________________________ [hidden email] 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 |
|
|
In reply to this post by giohappy
On Tue, 22 May 2012 22:48:17 +0200, G. Allegri wrote:
> Grazie Margherita, > ho dato seguito all'email di Even. > altro giro di verifiche alla luce delle risposte di Even prima, e di Frank Warmerdam a seguire. e' definitivamente confermato che il file EPSG distribuito con le Proj4 4.8.0 e' stato prodotto a partire da GDAL, usando questo script python: epsg_tr.py --config OVERRIDE_PROJ_DATUM_WITH_TOWGS84 FALSE \ -proj4 -skip -list gcs.csv > epsg epsg_tr.py --config OVERRIDE_PROJ_DATUM_WITH_TOWGS84 FALSE \ -proj4 -skip -list pcs.csv >> epsg n.b: l'opzione OVERRIDE_PROJ_DATUM_WITH_TOWGS84 FALSE e' esattamente intesa a preservare, per quanto possibile, il vecchio stile, evitando cioe' di sostituire +datum con +towgs84 un po' di esempi concreti per capire meglio come funziona: --------------- 4.7: <32632> +proj=utm +zone=32 +ellps=WGS84 +datum=WGS84 +units=m +no_defs 4.8: <32632> +proj=utm +zone=32 +datum=WGS84 +units=m +no_defs N.B.: e' sparito a sorpresa il termine +ellps; tutto il resto e' invariato, ma si tratta comunque di WGS84 nativo. --------------- 4.7: <3814> +proj=tmerc +lat_0=32.5 +lon_0=-89.75 +k=0.9998335 +x_0=500000 \ +y_0=1300000 +ellps=GRS80 +datum=NAD83 +units=m +no_defs 4.8: <3814> +proj=tmerc +lat_0=32.5 +lon_0=-89.75 +k=0.9998335 +x_0=500000 \ +y_0=1300000 +datum=NAD83 +units=m +no_defs anche qua, e' sparito +ellps, ma tutto il resto e' uguale. N.B. se invece lo generiamo con OVERRIDE_PROJ_DATUM_WITH_TOWGS84 TRUE: 4.8: <3814> +proj=tmerc +lat_0=32.5 +lon_0=-89.75 +k=0.9998335 +x_0=500000 \ +y_0=1300000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs ora e' sparito +datum, e riappare a sorpresa +ellps: personalmente trovo delizioso il termine +towgs84 tutto settato a ZERO: utilissimo per consumare qualche ciclo di CPU e per tenere belli caldi i registri :-D forse sbaglio, ma parrebbe quindi che +ellps e +datum siano considerati interscambiabili a gogo ... graditi lumi da parte di quelli che "sussurrano agli ellissoidi" -------------- 4.7: <3003> +proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 \ +y_0=0 +ellps=intl +units=m +no_defs 4.8: <3003> +proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 \ +y_0=0 +ellps=intl +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 \ +units=m +no_defs e finalmente siamo arrivati al nostro amatissimo GB ex-nazionale. ecco spiegato l'arcano: qua non esiste nessuna definizione +datum, abbiamo sempre e solo +ellps OVERRIDE_PROJ_DATUM_WITH_TOWGS84 viene interpretato esattamente alla lettera: quando non esiste il termine +datum, allora il termine +towgs84 viene inserito "a prescindere"; impostando l'opzione a FALSE oppure a TRUE non cambia assolutamente nulla, il risultato e' sempre il medesimo :-P come ci ha poi cortesemente spiegato FW, il termine +towgs84 viene scelto in base al "caso medio", cioe' a quel che si presume che sia il piu' popolare e che possa soddisfare il maggior numero di utenti (geodesia democratica ?) ================ provando a tirare le somme: a) a partire da GDAL 1.8.0 e' stata introdotto un cambio sostanziale nei criteri di gestione delle stringhe geodetiche di Proj4 sono sicuramente state prese alcune sagge cautele per limitare i danni di questa brusca "rivoluzione". ciononostante, circa 2900 SRIDs su 3700 sono bruscamente cambiati, cioe' tutti quelli che non esponevano un termine +datum a spanne, tutti quelli "storici" anteguerra sono stati massacrati, ed in pratica si sono salvati solo gli SRS piu' recenti basati su WGS84, NAD83, GRS80 e pochissimi altri. b) il fatto che i tempi di aggiornamento di GDAL, GeoTIFF e Proj4 siano esageratamente lunghi spiega perche' ce ne siamo accorti solo ora; in effetti si tratta di scelte nate circa 2 anni fa, ma che iniziano a diventare evidenti solo oggi ai fini pratici. c) probabilmente in molti casi i criteri "nuovi" saranno molto piu' graditi ai mitici "utenti medi", e renderanno piu' facile l'uso di funzionalita' tipo reproject-on-the-fly. altrettanto sicuramente manderanno al manicomio gli utenti professionali ... ma non si puo' sempre avere tutto dalla vita ;-) conclusione: non c'e' nussun bug (purtroppo), si tratta di precise scelte di progetto. piaccia o non piaccia, questo e' il nuovo scenario con il quale siamo destinati a doverci confrontare nei prossimi anni. prendiamone atto, e cerchiamo di limitare i danni al minimo facendo ampia opera di divulgazione e di corretta informazione: renderemo sicuramente un servizio utile a tutta quanta la nostra community nazionale. grazie comunque a tutti quei volenterosi che si sono generosamente spesi per arrivare a chiarire definitivamente questo spiacevole garbuglio. ciao Sandro -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. _______________________________________________ [hidden email] 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 |
|
|
Io comunque la proposta di un campo authority l'ho fatta a Frank, La
troverei comunque utile, nel caso ci fosse una volontà di non allontanarsi troppo da EPSG ufficiale. 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. Riguardo l'uso apparentemente casuale di +ellps e +datum, immagino (spero!) abbia in realtà un senso preciso perché i due concetti sono ben diversi! Sandro, mi stai inducendo a perdermi tra il codice delle Proj4! :D giovanni Il 23 maggio 2012 00:34, <[hidden email]> ha scritto: > On Tue, 22 May 2012 22:48:17 +0200, G. Allegri wrote: >> >> Grazie Margherita, >> ho dato seguito all'email di Even. >> > > altro giro di verifiche alla luce delle risposte di Even prima, > e di Frank Warmerdam a seguire. > e' definitivamente confermato che il file EPSG distribuito con > le Proj4 4.8.0 e' stato prodotto a partire da GDAL, usando questo > script python: > > > epsg_tr.py --config OVERRIDE_PROJ_DATUM_WITH_TOWGS84 FALSE \ > -proj4 -skip -list gcs.csv > epsg > epsg_tr.py --config OVERRIDE_PROJ_DATUM_WITH_TOWGS84 FALSE \ > -proj4 -skip -list pcs.csv >> epsg > > n.b: l'opzione OVERRIDE_PROJ_DATUM_WITH_TOWGS84 FALSE e' > esattamente intesa a preservare, per quanto possibile, il > vecchio stile, evitando cioe' di sostituire +datum con +towgs84 > > un po' di esempi concreti per capire meglio come funziona: > > --------------- > 4.7: <32632> +proj=utm +zone=32 +ellps=WGS84 +datum=WGS84 +units=m +no_defs > 4.8: <32632> +proj=utm +zone=32 +datum=WGS84 +units=m +no_defs > > N.B.: e' sparito a sorpresa il termine +ellps; tutto il resto e' > invariato, ma si tratta comunque di WGS84 nativo. > > --------------- > 4.7: <3814> +proj=tmerc +lat_0=32.5 +lon_0=-89.75 +k=0.9998335 +x_0=500000 \ > +y_0=1300000 +ellps=GRS80 +datum=NAD83 +units=m +no_defs > 4.8: <3814> +proj=tmerc +lat_0=32.5 +lon_0=-89.75 +k=0.9998335 +x_0=500000 \ > +y_0=1300000 +datum=NAD83 +units=m +no_defs > > anche qua, e' sparito +ellps, ma tutto il resto e' uguale. > > N.B. se invece lo generiamo con OVERRIDE_PROJ_DATUM_WITH_TOWGS84 TRUE: > 4.8: <3814> +proj=tmerc +lat_0=32.5 +lon_0=-89.75 +k=0.9998335 +x_0=500000 \ > +y_0=1300000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs > > ora e' sparito +datum, e riappare a sorpresa +ellps: personalmente > trovo delizioso il termine +towgs84 tutto settato a ZERO: utilissimo > per consumare qualche ciclo di CPU e per tenere belli caldi i registri :-D > forse sbaglio, ma parrebbe quindi che +ellps e +datum siano considerati > interscambiabili a gogo ... graditi lumi da parte di quelli che "sussurrano > agli ellissoidi" > > -------------- > 4.7: <3003> +proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 \ > +y_0=0 +ellps=intl +units=m +no_defs > 4.8: <3003> +proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 \ > +y_0=0 +ellps=intl +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 > \ > +units=m +no_defs > > e finalmente siamo arrivati al nostro amatissimo GB ex-nazionale. > ecco spiegato l'arcano: qua non esiste nessuna definizione +datum, abbiamo > sempre e solo +ellps > OVERRIDE_PROJ_DATUM_WITH_TOWGS84 viene interpretato esattamente alla > lettera: quando non esiste il termine +datum, allora il termine +towgs84 > viene inserito "a prescindere"; impostando l'opzione a FALSE oppure a TRUE > non cambia assolutamente nulla, il risultato e' sempre il medesimo :-P > > come ci ha poi cortesemente spiegato FW, il termine +towgs84 viene scelto > in base al "caso medio", cioe' a quel che si presume che sia il piu' > popolare > e che possa soddisfare il maggior numero di utenti (geodesia democratica ?) > ================ > > provando a tirare le somme: > > a) a partire da GDAL 1.8.0 e' stata introdotto un cambio sostanziale nei > criteri di gestione delle stringhe geodetiche di Proj4 > sono sicuramente state prese alcune sagge cautele per limitare i danni > di questa brusca "rivoluzione". > ciononostante, circa 2900 SRIDs su 3700 sono bruscamente cambiati, > cioe' tutti quelli che non esponevano un termine +datum > a spanne, tutti quelli "storici" anteguerra sono stati massacrati, ed > in pratica si sono salvati solo gli SRS piu' recenti basati su WGS84, > NAD83, GRS80 e pochissimi altri. > > b) il fatto che i tempi di aggiornamento di GDAL, GeoTIFF e Proj4 siano > esageratamente lunghi spiega perche' ce ne siamo accorti solo ora; in > effetti si tratta di scelte nate circa 2 anni fa, ma che iniziano a > diventare evidenti solo oggi ai fini pratici. > > c) probabilmente in molti casi i criteri "nuovi" saranno molto piu' graditi > ai mitici "utenti medi", e renderanno piu' facile l'uso di funzionalita' > tipo reproject-on-the-fly. > altrettanto sicuramente manderanno al manicomio gli utenti professionali > ... ma non si puo' sempre avere tutto dalla vita ;-) > > conclusione: > non c'e' nussun bug (purtroppo), si tratta di precise scelte di progetto. > piaccia o non piaccia, questo e' il nuovo scenario con il quale siamo > destinati a doverci confrontare nei prossimi anni. > > prendiamone atto, e cerchiamo di limitare i danni al minimo facendo ampia > opera di divulgazione e di corretta informazione: renderemo sicuramente un > servizio utile a tutta quanta la nostra community nazionale. > > grazie comunque a tutti quei volenterosi che si sono generosamente spesi > per arrivare a chiarire definitivamente questo spiacevole garbuglio. > > > ciao Sandro > > -- > Il messaggio e' stato analizzato alla ricerca di virus o > contenuti pericolosi da MailScanner, ed e' > risultato non infetto. > > _______________________________________________ > [hidden email] > 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 [hidden email] 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 |
|
|
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. _______________________________________________ [hidden email] 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 |
|
|
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, <[hidden email]> 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. > [hidden email] 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 |
|
|
In reply to this post by a.furieri
Ciao Alessandro,
a) ho preso lo SHP dei comuni ISTAT che e' in ED50 (23032 zona 32N) volevo segnalarti, tra l'altro, uno strano comportamento di QGis usando i confini di regione "non generalizzati" di Istat: trascinando il file il QGis, invece di ED50, il SR risulta essere: ELD79 / UTM zone 32N ovvero EPSG:2077 mentre il file PRJ indica essere: "ED_1950_UTM_Zone_32N". Strano... quello che segue e' il testo completo del PRJ associato ai confini: PROJCS["ED_1950_UTM_Zone_32N",GEOGCS["GCS_European_1950",DATUM["D_European_1950",SPHEROID["International_1924",6378388.0,297.0]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",9.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]] Ciao Roberto _______________________________________________ [hidden email] 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 |
|
|
In reply to this post by giohappy
Grazie per il punto Sandro e Giovanni,
2012/5/23 G. Allegri <[hidden email]>
Allora, io aggiungerei che paradossalmente questo aumenta i possibili errori commessi di default, perche` uno si aspetta di utilizzare una definizione standard di EPSG e di poter controllare gli errori attesi, quando invece all'interno di quella definizione sono stati inclusi dei parametri, che di fatto possono anche diminuire l'errore, ma compromettono la capacita` di poter controllare in maniera consapevole l'errore stesso.
Considerando poi che tali parametri sono stati introdotti a monte di una filiera, e quindi vanno a riguardare diversi altri software che su di essi si basano, diventano ancora meno controllabili. Probabilmente altri bug segnalalati altrove trovano la loro origine proprio in questo comportamento inatteso delle gdal. Insomma, gli standard se ci sono forse servono a qualcosa :(
Quindi, la mia opinione e` che non facciano bene a nessuno... My 2 cents madi Ing. Margherita Di Leo, Ph.D. _______________________________________________ [hidden email] 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 |
Re: GaussBoaga / Proj4 v.3.8.0
|
|
Il 23/05/2012 15.03, Margherita Di Leo ha scritto:
> Allora, io aggiungerei che paradossalmente questo aumenta i possibili > errori commessi di default, perche` uno si aspetta di utilizzare una > definizione standard di EPSG e di poter controllare gli errori attesi, > quando invece all'interno di quella definizione sono stati inclusi dei > parametri, che di fatto possono anche diminuire l'errore, ma > compromettono la capacita` di poter controllare in maniera consapevole > l'errore stesso. > Considerando poi che tali parametri sono stati introdotti a monte di una > filiera, e quindi vanno a riguardare diversi altri software che su di > essi si basano, diventano ancora meno controllabili. Probabilmente altri > bug segnalalati altrove trovano la loro origine proprio in questo > comportamento inatteso delle gdal. Insomma, gli standard se ci sono > forse servono a qualcosa :( > Quindi, la mia opinione e` che non facciano bene a nessuno... Quoto in pieno. Sarebbe opportuno che tali librerie di base mantenessero un approccio il piu' possibile neutrale/agnostico ed aderente al database EPSG, tanto poi i client GIS ci mettono sicuramente del loro... Altrimenti sarebbe come avere un errore sistematico in partenza, che si propaga a macchia d'olio nei vari software a valle... Il rapporto costi/benefici mi sembra piuttosto elevato. :( ciao Antonio -- Antonio Falciano http://www.linkedin.com/in/antoniofalciano _______________________________________________ [hidden email] 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 |
|
|
In reply to this post by geodrinx
On Wed, 23 May 2012 14:57:48 +0200, Geo DrinX wrote:
> volevo segnalarti, tra l'altro, uno strano comportamento di QGis > usando i confini di regione "non generalizzati" di Istat: > > trascinando il file il QGis, invece di ED50, il SR risulta essere: > > ELD79 / UTM zone 32N ovvero EPSG:2077 > > mentre il file PRJ indica essere: > > "ED_1950_UTM_Zone_32N". > > Strano... quello che segue e' il testo completo del PRJ associato ai > confini: > > > PROJCS["ED_1950_UTM_Zone_32N",GEOGCS["GCS_European_1950",DATUM["D_European_1950",SPHEROID["International_1924",6378388.0,297.0]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",9.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]] > IMHO non ci piove: si tratta proprio esattamente di <23032> ED50 UTM 32N del resto lo dice la stessa ISTAT: http://www.istat.it/it/archivio/24613 "I dati sono in formato shapefile , formato pubblico di scambio dati in ambito GIS, sono rilasciati nel sistema di riferimento ED_1950_UTM Zona 32" evidentemente, se QGIS intende invece <2077> ELD79 / UTM zone 32N c'e' sotto un bel bug: prova ad aprire un ticket sul loro trac. anche se personalmente sospetto fortemente che il bug sia piuttosto dentro a GDAL (QGIS delega completamente a GDAL la gestione degli SHP) ciao Sandro -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. _______________________________________________ [hidden email] 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 |
Re: GaussBoaga / Proj4 v.3.8.0
|
|
In reply to this post by margherita
On Wed, May 23, 2012 at 03:03:10PM +0200, Margherita Di Leo wrote:
> > 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. > > > > Allora, io aggiungerei che paradossalmente questo aumenta i possibili > errori commessi di default, perche` uno si aspetta di utilizzare una > definizione standard di EPSG e di poter controllare gli errori attesi, > quando invece all'interno di quella definizione sono stati inclusi dei > parametri, che di fatto possono anche diminuire l'errore, ma compromettono > la capacita` di poter controllare in maniera consapevole l'errore stesso. > Considerando poi che tali parametri sono stati introdotti a monte di una > filiera, e quindi vanno a riguardare diversi altri software che su di essi > si basano, diventano ancora meno controllabili. Probabilmente altri bug > segnalalati altrove trovano la loro origine proprio in questo comportamento > inatteso delle gdal. Insomma, gli standard se ci sono forse servono a > qualcosa :( > Quindi, la mia opinione e` che non facciano bene a nessuno... > > My 2 cents > Aggiungerei che se si comincia a mischiare le carte con i Gis 'soliti noti' si finisce per non capirci più niente. Quanto ci scomettiamo che i soliti utenti ben informati inizieranno a dire che con i GFOSS 'non funziona nulla'? -- Francesco P. Lovergine _______________________________________________ [hidden email] 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 |
|
|
> Altri invece, più pragmatici, preferiscono di sì perché perlomeno aiuta a non commettere gravi errori di default.
Se per pragmatici si intende programmatori ed esperti e chi non accetta gli errori di 120 metri... >> Allora, io aggiungerei che paradossalmente questo aumenta i possibili errori commessi di default >> >> > Quanto ci scomettiamo che i soliti utenti ben informati inizieranno a dire che con i GFOSS 'non funziona nulla'? Li chiamerei piuttosto "accademici". Piuttosto, proposte concrete grazie. Saluti _______________________________________________ [hidden email] 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 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |