Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
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 ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
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 ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
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. ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
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, a.furi...@lqt.it 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 ...
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
Ciao Alessandro, 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. 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,50.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 ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
Grazie per il punto Sandro e Giovanni, 2012/5/23 G. Allegri gioha...@gmail.com 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 madi -- Ing. Margherita Di Leo, Ph.D. ___ 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
Re: [Gfoss] 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 ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
Il 21/05/2012 21:17, Geo DrinX ha scritto: Esiste una zona in Italia in cui la trasformazione diretta ( senza towgs84 ) produce un risultato corretto? no, non e' matematicamente ammissibile. Infatti, la mia domanda era oziosa. Resta da chiedersi: cosa serve avere due codici che non servono a nulla, se non ad ottenere risultati errati ? Perche' non dichiararli obsoleti ? scusate se insisto: potete per cortesia spostare questa interessante discussione sul trac di proj? altrimenti rimane lettera morta, e mi pare un peccato. grazie. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
Ottimo resoconto Sandro, questi giorni non ero riuscito a studiarmi meglio il caso. Grazie. Davo per scontato si sapesse che l'EPSG Registry non distribuisce il file epsg così come lo conosciamo nel mondo GFOSS... giovanni Il 22 maggio 2012 15:47, a.furi...@lqt.it ha scritto: On Mon, 21 May 2012 13:36:02 +0200, Francesco P. Lovergine wrote: Pensavo fosse ormai ampiamente noto, quoto per esempio hamish_b in un recente scambio con lui in merito: pps- AFAIK proj 1.8.0's epsg file makes a big problem for GRASS, QGIS, and others as it has removed all the +datum= terms and replaced them with +towgs84= coefficients. -- cut - Quindi il casino sembra un po' più esteso della sola zona italiana... Tra parentesi, si potrebbe pensare che ci siano gli estremi per una violazione di licenza dei dati EPSG - cut - allora, qualche novita' e qualche approfondimento, spero utili: a) Proj4 non e' affatto il punto di partenza; e' semplicemente il punto d'arrivo finale. come gia' segnalavo ieri (ma forse e' passato inosservato ad alcuni) le definizioni CRS nascono da GDAL, passano da GeoTIFF e solo all'ultimo confluiscono in PROJ.4 tutto il ciclo di gestione del file EPSG e' spiegato chiaramente qua: http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/README b) non esiste nessun omino che prepara a mano il file delle definizioni EPSG: e' semplicemente il risultato di un processo completamente automatico; per l'esattezza, di uno script Python dentro a GDAL c) giusto per pedanteria: il file EPSG ... col cavolo che e' EPSG :-D il deliverable offerto direttamente da EPSG usa su un medello dati complicatissimo, basato su decine di tavole e viste DBMS. non assomiglia minimamente alle semplici stringhe geodetiche di Proj4, assomiglia piuttosto alla definizioni SRS-WKT http://www.epsg.org/geodetic.html d) quindi, correttamente, il famoso e benedetto file EPSG e' semplicemente un file di testo prodotto internamente da GDAL a beneficio di Proj.4 e di tutti gli altri packages che dipendono dalle Proj.4 ma e' comunque il frutto di una rielaborazione, non e' affatto un prodotto supportato direttamente da EPSG. e) per motivi che sfuggono all'umana comprensione, ad un certo punto qualche sviluppatore di GDAL ha deciso di introdurre dalla 1.8.0 un'opzione (infelicissima ...) che consentisse di sostituire tutte le definizioni +datum con una +towgs84 f) saggiamente, si trattava di un'opzione facoltativa: secondo la doc citata in a) il modo standard per generare il file EPSG era quindi: epsg_tr.py --config OVERRIDE_PROJ_DATUM_WITH_TOWGS84 FALSE -proj4 \ -skip -list gcs.csv epsg (insomma, seguire la vecchia strada consolidata, non la nuova). g) mi sono appena divertito a fare una veloce sessione di debugging con GDAL trunk: l'opzione OVERRIDE_PROJ_DATUM_WITH_TOWGS84 e' sicuramente presente nel codice, ma evidentemente nell'implementazione attuale (e suppongo fin dalla 1.9.0 o addirittura dalla 1.8.0) c'e' sotto qualche bel bug che la rende assolutamente inefficace. ... da cui nasce a catena tutto il casino a seguire :-P h) n.b.: si tratta di un bug dalla storia lunga e tormentata. vedi ticket #122 PROJ4 [guarda caso, aperto proprio da Hamish] ;-) http://trac.osgeo.org/proj/ticket/122 questo bug viene dato come closed; ed infatti il problema non e' affatto nella Proj4, e' tutto dentro a GDAL :-) cose che capitano quando si apre un ticket nel trac sbagliato :-P h) giusto per conferma e verifica quickdirty, ho brutalmente macellato il codice di GDAL, eliminando radicalmente tutta la sezione legata all'opzione OVERRIDE_PROJ_DATUM_WITH_TOWGS84 Sorpresa, in questo modo lo script python epsg_tr.py ora mi genera un sano file EPSG vecchio stile, senza piu' nessuna assurdita' +towgs84 ;-) giusto se qualche avventuroso si vuole divertire a fare due verifiche, lo trovate qua: http://www.gaia-gis.it/epsg-trick.zip -- qualche volonteroso se la sente cortesemente di aprire un ticket su GDAL in base alle informazioni disponibili se permettere, penso di avere gia' dato abbastanza per la causa :-P ciao Sandro -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. ___ 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 ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
allora, qualche novita' e qualche approfondimento, spero utili: Molto interessante! io capisco le ragioni qua esposte di entrambe le parti, ma spero che si possa salvare capra e cavoli... non vivo/lavoro in Italia e l'introduzione dei parametri towgs84 nei 3 sistemi piú comuni in Portogallo ha risolto un bel problema agli utOnti piú comuni. Infatti qua l'errore dovuto alla riproiezione senza parametri tra questi 3 sistemi é piú *alto* della differenza che c'é tra le origini dei sistemi stessi :) potete capire che é una cosa da mal di testa... e anche se i parametri hanno una precisione localizzata vanno bene per la maggior parte degli usi. OT Tra le curiositá geografiche tutte Portoghesi anche quella per cui i limiti ufficiali del Portogallo continentale sono rappresentanti da una linea *aperta*... scaricate il vettore da qua (istituto geografico) http://mapas.igeo.pt/wfs/sc500k.1 oppure date un'occhiata qua http://mapas.igeo.pt/Openviewer/sc500k_wms_cont.html e noterete che all'altezza di Évora/Badajoz il confine tra Portogallo e Spagna non é marcato... chi indovina il perché vince un premio! -- Giovanni -- ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
On Tue, 22 May 2012 16:57:12 +0100, Giovanni Manghi wrote: io capisco le ragioni qua esposte di entrambe le parti, ma spero che si possa salvare capra e cavoli... non vivo/lavoro in Italia e l'introduzione dei parametri towgs84 nei 3 sistemi piú comuni in Portogallo ha risolto un bel problema agli utOnti piú comuni. anche se i parametri hanno una precisione localizzata vanno bene per la maggior parte degli usi. Ciao Giovanni, nessuno si sogna di sostenere che i parametri +towgs84 non siano utili; al contrario, sono utilissimi, anzi direi praticamente indispensabili. ma proprio per questo non possono e non devo stare direttamente dentro alle EPSG standard (ed infatti, nella versione pura, non sono affatto previsti). come giustamente dici anche tu, sono a precisione localizzata; e quindi richiedono una qualche opportuna forma di intervento/scelta da parte dell'utEnte a seconda della zona di specifico interesse (con buona pace per gli utOnti ... che poi forse non sono neppure tanto utOnti, quanto piuttosti mal informati e tratti in inganno dalle magiche silver bullets che alcuni produttori proprietari dispensano a piene mani senza farsi troppi scrupoli). presumo che nel caso portoghese tutto sia piu' semplice, considerata la piu' modesta estensione territoriale. BTW il portogallo (per sua fortuna) e' quasi esattamente allineato lungo il meridiano, ed ha una modesta estensione est-ovest. sfortunatametne l'italia invece e' molto estesa sia in senso nord-sud (circa 12 gradi) che in senso est-ovest (anche qua, circa 12 gradi). al di la dell'errata percezione che ci hanno sciaguratamente instillato alle Elementari, l'italia non e' affatto allineata sul meridiano; e' piuttosto un bel quadrato, se la misuri correttamente in gradi, che e' l'unica misura che conta in geodesia. imporre sulla punta delle baionette una specifica versione localizzata valida sostanzialmente solo per l'Italia centrale lascia malamente scoperte un sacco di regioni che si trovano in posizioni meno baricentriche: e non e' quindi una bella soluzione nel nostro caso. oltre al fatto che complica notevolmente l'uso dei grigliati (occorre prima ripulire qualsiasi definizione +towgs84 eventualmente presente nella definizione ESPG di base) quindi parrebbe abbastanza ovvio che dovremmo inventarci una soluzione piu' sofisticata (= piu' furba), magari a due stadi: - le definizioni pure EPSG di base - piu' altre definizione extra (customizzate, non-EPSG) adatte alle varie macro-regioni. se hai seguito il thread, abbiamo anche iniziato a delineare i termini tecnici per rendere possibile una possibile soluzione di questo tipo, che ovviamente salverebbe tanto la capra quanto il cavolo: http://lists.gfoss.it/pipermail/gfoss/2012-May/023090.html se credi, puoi portare anche tu il tuo personale contributo alla discussione, sicuramente ben accetto e piu' che gradito visto che ci puoi portare elementi di conoscenza e di esperienza che esulano dal GB :-D Tra le curiositá geografiche tutte Portoghesi anche quella per cui i limiti ufficiali del Portogallo continentale sono rappresentanti da una linea *aperta*... chi indovina il perché vince un premio! mica c'entra per caso questo motivo qua ? http://en.wikipedia.org/wiki/Geography_of_Portugal Portugal's border with Spain remains a unresolved territorial dispute between the two countries. Portugal does not recognise the border between Caia and Cuncos River deltas, since the beginning of the 1801 occupation of Olivenza by Spain. This territory, though under de facto Spanish occupation, remains a de jure part of Portugal, consequently no border is henceforth recognised in this area. ciao Sandro -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
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. ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
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 ciao madi -- Ing. Margherita Di Leo, Ph.D. ___ 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 ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
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 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 ciao madi -- Ing. Margherita Di Leo, Ph.D. ___ 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 ___ 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
Re: [Gfoss] 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. Allegrigioha...@gmail.com ha scritto: Grazie Margherita, ho dato seguito all'email di Even. giovanni Il 22 maggio 2012 22:25, Margherita Di Leodireg...@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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
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=50 \ +y_0=130 +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=50 \ +y_0=130 +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=50 \ +y_0=130 +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=150 \ +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=150 \ +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. ___ Gfoss@lists.gfoss.it http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
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, a.furi...@lqt.it 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=50 \ +y_0=130 +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=50 \ +y_0=130 +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=50 \ +y_0=130 +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=150 \ +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=150 \ +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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
Il 20/05/2012 19:55, Andrea Peri ha scritto: la ProJ , per definizione, non applica mai una trasformazione towgs. potete per cortesia segnalare la cosa come ticket di proj? gia' che ci siamo, non sarebbe male introdurre i codici (extra EPSG, 4) per le varie correzioni +towgs, cosi' abbiamo sia il dato buono che quello piu' utilizzabile. grazie. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
Giusto qualche noiosissimo dettaglio tecnico preliminare, visto che si tratta di aspetti sicuramente poco noti, per quanto assolutamente critici: a) tutte le operazioni di conversione tra diversi SRS (riproiezione) dipendono dalle Proj4, e quindi in ultima analisi dal file delle definizioni EPSG che accompagna ciascuna release delle Proj4 b) la catena delle dipendenze che si dirama dal file delle definizioni EPSG e' molto articolata: GDAL, GeoTiff, Proj4, QGIS, PostGIS, SpatiaLite etc etc; tutti dipendono dalle EPSG in un modo o nell'altro. per evitare risultati incongruenti, e' auspicabile che tutti i vari progetti seguano regole comuni assolutamente consistenti. c) anche se e' del tutto controintuitivo, il file delle definizioni EPSG non nasce affatto dalle Proj4; al contrario, le Proj4 sono semplicemente il punto di arrivo finale del percorso. vedi: http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/README d) in pratica una nuova versione del file EPSG nasce sempre in GDAL - poi passa alle GeoTiff - finalmente arriva alle Proj4 - ed infine tocca le varie PostGIS, SpatiaLite, QIS etc etc - visto che si tratta di aspetti delicati al massimo, che tagliano trasversalmente tutti i progetti e che interessano intere nazioni (p.es. nel caso del Gauss-Boaga tutta l'Italia), sarebbe auspicabile che qualsiasi eventuale modifica venisse unanimemente condivisa dall'intera community nazionale, previo adeguato confronto e discussione. propongo quindi di chiudere qua questo thread, aprendone un altro finalizzato alla discussione sulle modifiche/patch/ticket da sottoporre ai maintainers di GDAL (visto che e' li il vero punto di partenza). ciao Sandro -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
On Mon, May 21, 2012 at 09:53:04AM +0200, Paolo Cavallini wrote: Il 20/05/2012 19:55, Andrea Peri ha scritto: la ProJ , per definizione, non applica mai una trasformazione towgs. potete per cortesia segnalare la cosa come ticket di proj? gia' che ci siamo, non sarebbe male introdurre i codici (extra EPSG, 4) per le varie correzioni +towgs, cosi' abbiamo sia il dato buono che quello piu' utilizzabile. grazie. Sfortunatamente non è l'unico pasticcio introdotto in 4.8, ragion per cui è opportuno evitarne in toto l'impiego. -- Francesco P. Lovergine ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
On Mon, 21 May 2012 13:21:18 +0200, Francesco P. Lovergine wrote: Sfortunatamente non è l'unico pasticcio introdotto in 4.8, ragion per cui è opportuno evitarne in toto l'impiego. Ciao Frakie, potresti dettagliare ? quali altre criticita' ti risultano con la Proj 4.8 ? grazie Sandro -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
On Mon, May 21, 2012 at 01:25:17PM +0200, a.furi...@lqt.it wrote: On Mon, 21 May 2012 13:21:18 +0200, Francesco P. Lovergine wrote: Sfortunatamente non è l'unico pasticcio introdotto in 4.8, ragion per cui è opportuno evitarne in toto l'impiego. Ciao Frakie, potresti dettagliare ? quali altre criticita' ti risultano con la Proj 4.8 ? grazie Sandro Pensavo fosse ormai ampiamente noto, quoto per esempio hamish_b in un recente scambio con lui in merito: pps- AFAIK proj 1.8.0's epsg file makes a big problem for GRASS, QGIS, and others as it has removed all the +datum= terms and replaced them with +towgs84= coefficients. Default transform terms are nice, but mandating that everyone use that specific set of terms with no way out (since the datum name was removed) is a bit of a disaster! at least for us in New Zealand where we have a lot of distortion and the NTv2 datum transform grid is very important. This is still unresolved, and so I have been happy to see that proj 1.8.0 has not yet entered sid, as it will cause bad problems for us (NZ,GRASS) once it does. (Users of the Potsdam, OSGB36, and NAD27 etc. datums are affected too..) Quindi il casino sembra un po' più esteso della sola zona italiana... Tra parentesi, si potrebbe pensare che ci siano gli estremi per una violazione di licenza dei dati EPSG, che al punto 2 recita: --- All data pertinent to a specific coordinate reference system MUST be copied without modification and all related pages/records must be included; --- Ergo a meno di non chiarire a chiare lettere che quei codici NON sono codici EPSG, la 4.8 chiaramente non è distribuibile. Ovviamente AFAIK (and IANAL). -- Francesco P. Lovergine ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
Il 21/05/2012 13:36, Francesco P. Lovergine ha scritto: Pensavo fosse ormai ampiamente noto, quoto per esempio hamish_b in immagino che ci siano gia' tickets aperti in proposito, giusto? saluti. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
Il 21/05/2012 13:37, Paolo Cavallini ha scritto: Il 21/05/2012 13:36, Francesco P. Lovergine ha scritto: Pensavo fosse ormai ampiamente noto, quoto per esempio hamish_b in immagino che ci siano gia' tickets aperti in proposito, giusto? in ogni caso, dato che i parametri sono molto comodi, la strada giusta pare quella di integrare gli EPSG con altre proiezioni ad hoc, per le quali ci sono codici riservati (4). dico bene? saluti. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
On Mon, 21 May 2012 13:36:02 +0200, Francesco P. Lovergine wrote: Pensavo fosse ormai ampiamente noto, quoto per esempio hamish_b in un recente scambio con lui in merito: pps- AFAIK proj 1.8.0's epsg file makes a big problem for GRASS, QGIS, and others as it has removed all the +datum= terms and replaced them with +towgs84= coefficients. ora finalmente mi e' assolutamente chiaro perche' ho dovuto rimettere pesantemente le mani su un paio di funzioni SpatiaLite con la 4.8. avevo capito che il problema era nel fatto che la definizione della 4326 WGS84 era cambiata all'improvviso [1], ma non avevo focalizzato che il casino era cosi' ampio e generalizzato. :-P [1] 4.7 4326: +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs 4.8 4326: +proj=longlat +datum=WGS84 +no_defs Ergo a meno di non chiarire a chiare lettere che quei codici NON sono codici EPSG, la 4.8 chiaramente non è distribuibile. Ovviamente AFAIK (and IANAL). concordo pienamente: e' una roba completamente diversa, che con EPSG ormai c'entra pochino ... e mi paiono molto fondate anche le tue perplessita' legali. personalmente direi che e' veramente una bruttissima regression; il sw libero ha sempre goduto (giustamente) ottima fama proprio perche' e' sempre stato assolutamente rigoroso nel rispetto maniacale degli standard. N.B.: non sottovalutiamo il problema; stiamo seriamente rischiando che *tutte* le prossime versioni di GDAL, GeoTIFF, PostGIS, splite etc utilizzino delle definizioni geodetiche quanto meno dubbie ... e stiamo rischiando l'effetto babele, se ciascun progetto si muovera' per proprio conto in autonomia e senza un chiaro coordinamento. direi che l'unica soluzione sensata parrebbe rilasciare rapidamente una Proj 4.8.1 che ripristini una totale conformita' con EPSG ciao Sandro -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
On Mon, May 21, 2012 at 01:40:02PM +0200, Paolo Cavallini wrote: Il 21/05/2012 13:37, Paolo Cavallini ha scritto: Il 21/05/2012 13:36, Francesco P. Lovergine ha scritto: Pensavo fosse ormai ampiamente noto, quoto per esempio hamish_b in immagino che ci siano gia' tickets aperti in proposito, giusto? in ogni caso, dato che i parametri sono molto comodi, la strada giusta pare quella di integrare gli EPSG con altre proiezioni ad hoc, per le quali ci sono codici riservati (4). dico bene? saluti. Si, solo che i codici custom non sono standard e a quel punto chiunque può adottare la convenzione che gli pare. Si arriva dritti dritti all'approccio alla ESRI. Non solo secondo me non è il massimo, ma va in direzione opposta a quello che andrebbe fatto in un mondo perfetto. -- Francesco P. Lovergine ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
Il 21/05/2012 14:05, Francesco P. Lovergine ha scritto: Si, solo che i codici custom non sono standard e a quel punto chiunque può adottare la convenzione che gli pare. Si arriva dritti dritti all'approccio alla ESRI. Non solo secondo me non è il massimo, ma va in direzione opposta a quello che andrebbe fatto in un mondo perfetto. capisco, ma non dare i parametri di correzione e' comunque un danno per gli utenti; alternative? saluti. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
ma non dare i parametri di correzione e' comunque un danno per gli utenti; Concordo. In piu' ho una domanda relativa ai codici 3003-4 : Esiste una zona in Italia in cui la trasformazione diretta ( senza towgs84 ) produce un risultato corretto? ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
On Mon, 21 May 2012 14:37:18 +0200, Geodrinx wrote: Esiste una zona in Italia in cui la trasformazione diretta ( senza towgs84 ) produce un risultato corretto? no, non e' matematicamente ammissibile. il GB nacque nei remoti anni '40. l'ellissoide di riferimento su cui si basa ha una forma significativamente diversa da quella ritenuta valida oggi (dopo tutte le osservazioni satellitari etc). non esiste nessun modo matematico rigoroso per convertire automaticamente da GB p.es. a WGS84 o RTEF2000. proprio perche' si tratta di due pianeti terra diversi, con una forma significativamente differente. soluzione *vera* (robusta e generalizzata): passare una matrice bursa-wolfe contenente gli opportuni parametri di correzione locale per ciascun singolo punto ... il famoso +towsg84 con i suoi 7 numeretti: 3 rotazioni (una per ciascun asse x, y, z) + 3 traslazioni (sempre per ciascun asse) + 1 fattore di scala. n.b.: correzione locale significa esattamente locale; se e' perfetta per Viterbo, gia' a Civitavecchia non e' piu' tanto perfetta, ed a Grosseto e' ancora piu' approssimativa ;-) soluzione *buona*: usare i grigliati: cioe' un set ragionevolmente denso di punti calibrati con elevata precesione che formano una griglia. quando caschi a meta' strada tra due nodi puoi interpolare le matrici relative ai nodi piu' vicini, senza introdurre errori eccessivi. diciamo che realisticamente puoi arrivare al millimetro/centimetro. n.b.: dato che i grigliati introducono di per se una correzione +towgs84, le nuove definizioni 4.8 che gia' includono un termine +towgs84 al loro interno rischiano di rendere impossibile l'uso dei grigliati soluzione *a spanne*: usi le 4 macro-regioni (sicilia, sardegna, penisola est, penisola ovest), ciascuna con la sua matrice +towgs84. n.b.: non e' affatto una correzione rigorosa; avrai comunque errori dell'ordine di qualche metro (probabilmente poco rilevanti e quindi accettabili per molti casi d'uso normali e poco sofisticati). soluzione *as is*: usi la definizione base nuda e cruda; nei casi peggiori puoi anche avere errori di decine o centinaia di metri. quindi, come vedi, usare le macro-regioni rappresenta semplicemente un approssimazione un pelo meno schifosa. ma non e' sicuramente la panacea. mettiti infine nei panni di chi deve p.es. gestire sia civitavecchia che la sardegna nella stessa mappa (diciamo per studiare i traghetti etc): evidentemente, in questo caso l'approccio per macro-regioni non funzionera' mai ;-) se tiri la coperta sul lazio, padelli la sardegna; e viceversa. ciao Sandro -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
Il 21/05/2012 15:21, a.furi...@lqt.it ha scritto: n.b.: dato che i grigliati introducono di per se una correzione +towgs84, le nuove definizioni 4.8 che gia' includono un termine +towgs84 al loro interno rischiano di rendere impossibile l'uso dei grigliati Per info: il nostro (RER+Faunalia) plugin per QGIS strippa towgs84 e ci mette tutto il necessario a funzionare con le griglie, dunque non dovrebbe avere nessuna conseguenza (e menomale!). Saluti. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
capisco, ma non dare i parametri di correzione e' comunque un danno per gli utenti; alternative? Non condivido. I parametri di proiezione variano a seconda del livello di precisione che si richiede. Inserirli può essere fuorviante, soprattutto per un utente medio, perché potrebbero indurlo a pensare che siano esatti o corretti, quando invece sono soltanto un'approssimazione a scala di macroregioni, oltretutto solo valida per un'area nel caso del +towgs84 introdotto da Proj 4.8). giovanni saluti. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ 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 ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
Il 21/05/2012 15:54, G. Allegri ha scritto: Non condivido. I parametri di proiezione variano a seconda del livello di precisione che si richiede. Inserirli può essere fuorviante, soprattutto per un utente medio, perché potrebbero indurlo a pensare che siano esatti o corretti, quando invece sono soltanto un'approssimazione a scala di macroregioni resta il fatto che operativamente e' molto meglio averli che non averli, e che sono soddisfacenti per molti scopi. non a caso GRASS li ha inseriti da anni. alternative? saluti, e grazie. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
Il 21/05/2012 15:54, Paolo Cavallini ha scritto: resta il fatto che operativamente e' molto meglio averli che non averli, e che sono soddisfacenti per molti scopi. non a caso GRASS li ha inseriti da anni. salve. qualcuno dei piu' esperti di proiezioni potrebbe aprire un ticket su proj, se non e' stato gia' fatto? Grazie. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
Esiste una zona in Italia in cui la trasformazione diretta ( senza towgs84 ) produce un risultato corretto? no, non e' matematicamente ammissibile. Infatti, la mia domanda era oziosa. Resta da chiedersi: cosa serve avere due codici che non servono a nulla, se non ad ottenere risultati errati ? Perche' non dichiararli obsoleti ? ;) Saluti ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
On Sun, 20 May 2012 12:06:24 +0200, a.furi...@lqt.it wrote: Proj.4 v.3.7.0 (vecchia versione, ancora molto diffusa) Proj.4 v.3.8.0 (rilascio recentissimo, 6 marzo u.s.) ovviamente prima ho sbagliato i riferimenti: leggasi correttamente Proj v.4.7.0 e v.4.8.0 (e grazie mille all'anonimo socio che se ne e' solertemente accorto facendomelo tempestivamente notare) ;-) ciao Sandro -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
2012/5/20 a.furi...@lqt.it On Sun, 20 May 2012 12:13:03 +0200, Margherita Di Leo wrote: 2012/5/20 Proj.4 v.3.7.0 (vecchia versione, ancora molto diffusa) --**- Proj.4 v.3.8.0 (rilascio recentissimo, 6 marzo u.s.) forse intendevi v.4.7.0 e 4.8.0 rispettivamente? assolutamente SI (scusate per la paperella) ;-) ciao Sandro -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -- Ing. Margherita Di Leo, Ph.D. ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
Il 20/05/2012 12.06, a.furi...@lqt.it ha scritto: non mi pare che fosse mai girata in precedenza ... stavo provando un KML ottenuto da dati di partenza GB (srid=3003) quando ho casualmente scoperto di avere ottenuto uno snap semplicemente perfetto fin dal primo colpo e senza nessuna cautela speciale ... se vi ricordate, in precedenza non era affatto cosi': almeno sulla Toscana si vedevano dei brutti disallineamenti durante la conversione da GB a WGS84 lat/lon. ed ecco cosa ho scoperto dopo velocissimo debugging: Proj.4 v.3.7.0 (vecchia versione, ancora molto diffusa) --- srid=3003: +proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=150 +y_0=0 \ +ellps=intl +units=m +no_defs Proj.4 v.3.8.0 (rilascio recentissimo, 6 marzo u.s.) srid=3003: +proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=150 +y_0=0 \ +ellps=intl +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 \ +units=m +no_defs come potete vedere, la versione piu' recente incorpora direttamente la matrice Bursa-Wolfe (+towgs84) ottimizzata per l'italia centrale. sicuramente un'ottima notizia per tutti i Toscani: non necessariamente tale anche per Sardi, Liguri e Piemontesi :-P La medesima modifica e' presente anche sul fuso Est (3004) Occhio alla penna: il passaggio alla nuova Proj 3.8.0 potrebbe causare qualche problema di retro-compatibilita' Caro Sandro, grazie per averci fatto notare la cosa. A mio modesto avviso, e' una cialtroneria questa. La definizione rigorosa di EPSG:3003-4 non prevede l'uso dei parametri +towgs84, anche perche' i parametri per l'Italia peninsulare non sono gli unici applicabili, come tu stesso affermi. Cosa dovrebbero fare gli amici sardi e siciliani qualora intendessero applicare correttamente i loro parametri? Oppure chi volesse utilizzare un grigliato? Applicare prima una trasformazione che annulli quella introdotta cosi' maldestramente? Anche QGIS mi pare affetto da questo bug, in quanto io lo considererei come tale. 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
On Sun, 20 May 2012 12:43:59 +0200, Antonio Falciano wrote: grazie per averci fatto notare la cosa. A mio modesto avviso, e' una cialtroneria questa. La definizione rigorosa di EPSG:3003-4 non prevede l'uso dei parametri +towgs84 esattissimo, vedi anche qua: http://spatialreference.org/ref/epsg/3003/proj4/ la definizione *ufficiale* di EPSG non reca traccia del +towgs anche perche' i parametri per l'Italia peninsulare non sono gli unici applicabili, come tu stesso affermi. Cosa dovrebbero fare gli amici sardi e siciliani qualora intendessero applicare correttamente i loro parametri? Oppure chi volesse utilizzare un grigliato? sicuramente con la 4.8.0 diventa molto piu' complicato e macchinoso :-( ... questo bug, in quanto io lo considererei come tale. diciamo che come cittadino del Granducato di Toscana ringrazio sentitamente. la nuova 4.8.0 personalmente mi semplifica al vita e la trovo deliziosa: Toskana ueber alles :-D come presidente di un'associazione nazionale non posso che darti ovviamente ragione: era sicuramente meglio prima, la definizione piu' saggia e' quella standard EPSG, e quindi quella della vecchia 4.7.0 ciao Sandro -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. ___ 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
Re: [Gfoss] GaussBoaga / Proj4 v.3.8.0
Condivido, la definizione del CRS non dovrebbe prevedere i parametri di trasformazione, e inoltre ci troviamo ad un fork delle definizioni epsg Proj4 rispetto a quelle ufficiali, che potrebbe generare non pochi mal di testa e inconsistenze... giovanni Il 20 maggio 2012 13:03, a.furi...@lqt.it ha scritto: On Sun, 20 May 2012 12:43:59 +0200, Antonio Falciano wrote: grazie per averci fatto notare la cosa. A mio modesto avviso, e' una cialtroneria questa. La definizione rigorosa di EPSG:3003-4 non prevede l'uso dei parametri +towgs84 esattissimo, vedi anche qua: http://spatialreference.org/ref/epsg/3003/proj4/ la definizione *ufficiale* di EPSG non reca traccia del +towgs anche perche' i parametri per l'Italia peninsulare non sono gli unici applicabili, come tu stesso affermi. Cosa dovrebbero fare gli amici sardi e siciliani qualora intendessero applicare correttamente i loro parametri? Oppure chi volesse utilizzare un grigliato? sicuramente con la 4.8.0 diventa molto piu' complicato e macchinoso :-( ... questo bug, in quanto io lo considererei come tale. diciamo che come cittadino del Granducato di Toscana ringrazio sentitamente. la nuova 4.8.0 personalmente mi semplifica al vita e la trovo deliziosa: Toskana ueber alles :-D come presidente di un'associazione nazionale non posso che darti ovviamente ragione: era sicuramente meglio prima, la definizione piu' saggia e' quella standard EPSG, e quindi quella della vecchia 4.7.0 ciao Sandro -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. ___ 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 ___ 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
