Raccolta fondi per una PROJ evoluta
Locked
 
|
vi segnalo una iniziativa decisamente strategica e degna
di essere sostenuta che puo' portare significativi miglioramenti a tutto il sw GFOSS nel suo insieme. https://gdalbarn.com/ se si raggiungera' la cifra totale di 125.000 USD i fondi raccolti verranno impiegati a partire dal 4 giugno p.v. per sostenere lo sviluppo di una implementazione piu' moderna e completa del supporto per i Sistemi di Riferimento Spaziale delle Coordinate (CRS/SRS) e delle relative trasformazioni. i pacchetti/librerie che beneficieranno direttamente della nuova implementazione sono GDAL, PROJ, libgeotiff, PostGIS e SpatiaLite. considerando l'uso praticamente universale di GDAL, PROJ e degli Spatial DBMS praticamente tutte le applicazioni GFOSS (QGIS, MapServer, GeoServer, Grass GIS etc) finirano per trarre indirettamente significativi benefici dall'operazione. qualche dettaglio tecnico sui principali scopi che si prefigge l'iniziativa: 1. superare gli attuali files CSV utilizzati per la definizione dei CRS definiti dal dataset EPSG, che verranno rimpiazzati da un database SQLite. 2. supporto completo per lo standard internazionale OGC WKT2 (che tra l'altro prevede anche la gestione delle coordinate 4D: classiche coordinate spaziali XYZ + Tempo). 3. superare l'approccio attuale adotatto da PROJ che si basa su matrici di trasformazione a 7 parametri "+towgs84" per la trasformazione intermedia delle coordinate su WGS84 (metodo non sempre applicabile a tutte le trasformazioni e che puo' implicare margini di errore di qualche metro). ciao Sandro _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
Re: Raccolta fondi per una PROJ evoluta
|
|
Ciao Sandro.
A scanso i equivoci penso che converrebbe chiarire meglio un passaggio del tuo discorso. Te scrivi: >i pacchetti/librerie che beneficieranno direttamente della >nuova implementazione sono GDAL, PROJ, libgeotiff, PostGIS >e SpatiaLite. >considerando l'uso praticamente universale di GDAL, PROJ e >degli Spatial DBMS praticamente tutte le applicazioni GFOSS >(QGIS, MapServer, GeoServer, Grass GIS etc) finirano per >trarre indirettamente significativi benefici dall'operazione. Io non o alcun dubbio che il giorno dopo che fosse disponibile una tale proj, te la adotteresti seduta stante nel tuo spatialite. Ma occorrerebbe capire se avverrebbe lo stesso anche su tutti glialtri prodotti che citi. gdal, libgeotiff, postgis, qgis, mapserver,geoserver,grass, etc... Io immagino che quanto meno dovrebbero partire ulteriori raccolte fondi per l'adeguamento di molti di tali prodotti. Il che non vuol dire che non pensi che sia opportuno aggiornare la proj, ma piuttosto che la tua affermazione "beneficeranno direttamente" potrebbe un po' fuorviare qualcuno. Facendogli credere un automatismo che in realta' non vi e'. Correggimi se mi sbaglio. A. Il giorno 15 maggio 2018 07:18, <[hidden email]> ha scritto: > vi segnalo una iniziativa decisamente strategica e degna > di essere sostenuta che puo' portare significativi > miglioramenti a tutto il sw GFOSS nel suo insieme. > > https://gdalbarn.com/ > > se si raggiungera' la cifra totale di 125.000 USD i fondi > raccolti verranno impiegati a partire dal 4 giugno p.v. per > sostenere lo sviluppo di una implementazione piu' moderna e > completa del supporto per i Sistemi di Riferimento Spaziale > delle Coordinate (CRS/SRS) e delle relative trasformazioni. > > i pacchetti/librerie che beneficieranno direttamente della > nuova implementazione sono GDAL, PROJ, libgeotiff, PostGIS > e SpatiaLite. > considerando l'uso praticamente universale di GDAL, PROJ e > degli Spatial DBMS praticamente tutte le applicazioni GFOSS > (QGIS, MapServer, GeoServer, Grass GIS etc) finirano per > trarre indirettamente significativi benefici dall'operazione. > > qualche dettaglio tecnico sui principali scopi che si prefigge > l'iniziativa: > > 1. superare gli attuali files CSV utilizzati per la > definizione dei CRS definiti dal dataset EPSG, che > verranno rimpiazzati da un database SQLite. > > 2. supporto completo per lo standard internazionale > OGC WKT2 (che tra l'altro prevede anche la gestione > delle coordinate 4D: classiche coordinate spaziali > XYZ + Tempo). > > 3. superare l'approccio attuale adotatto da PROJ che > si basa su matrici di trasformazione a 7 parametri > "+towgs84" per la trasformazione intermedia delle > coordinate su WGS84 (metodo non sempre applicabile > a tutte le trasformazioni e che puo' implicare > margini di errore di qualche metro). > > ciao Sandro > _______________________________________________ > [hidden email] > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > Questa e' una lista di discussione pubblica aperta a tutti. > I messaggi di questa lista non hanno relazione diretta con le posizioni > dell'Associazione GFOSS.it. > 796 iscritti al 28/12/2017 -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
Re: Raccolta fondi per una PROJ evoluta
|
|
Anzi mi correggo parzialmente.
Non ho dubbi che te (su spatialite) paul ramsey (su postgis) e even rouault su (gdal) adotterebbero subito questa nuova implmentazione. Qualche dubibo lo avrei su altri prodotti gfoss di enorme diffusione. Come sai, uno dei problemi che io sollevo da tempo e' il rischio che svriati prodotti gfoss, adottando, librerie differenti, possano produrre riultati differenti. Qui pero' si apre un altro vaso di pandora. Infatti per chi lavora nei GIS e usa prodotti gfoss, e' essenziale la univocita' del risultato indipendentemente dal prodotto che usa. Questo e' garantito se e' altresi' garantito l'utilizzo delle medesime librerie. A. Il giorno 15 maggio 2018 07:28, Andrea Peri <[hidden email]> ha scritto: > Ciao Sandro. > > A scanso i equivoci penso che converrebbe chiarire meglio un passaggio del > tuo discorso. > > Te scrivi: > > >i pacchetti/librerie che beneficieranno direttamente della > >nuova implementazione sono GDAL, PROJ, libgeotiff, PostGIS > >e SpatiaLite. > >considerando l'uso praticamente universale di GDAL, PROJ e > >degli Spatial DBMS praticamente tutte le applicazioni GFOSS > >(QGIS, MapServer, GeoServer, Grass GIS etc) finirano per > >trarre indirettamente significativi benefici dall'operazione. > > Io non o alcun dubbio che il giorno dopo che fosse disponibile una tale > proj, te la adotteresti seduta stante nel tuo spatialite. > > Ma occorrerebbe capire se avverrebbe lo stesso anche su tutti glialtri > prodotti che citi. > gdal, libgeotiff, postgis, qgis, mapserver,geoserver,grass, etc... > > Io immagino che quanto meno dovrebbero partire ulteriori raccolte fondi > per l'adeguamento di molti di tali prodotti. > > Il che non vuol dire che non pensi che sia opportuno aggiornare la proj, > ma piuttosto che la tua affermazione > > "beneficeranno direttamente" potrebbe un po' fuorviare qualcuno. > > Facendogli credere un automatismo che in realta' non vi e'. > > Correggimi se mi sbaglio. > > A. > > > > > Il giorno 15 maggio 2018 07:18, <[hidden email]> ha scritto: > >> vi segnalo una iniziativa decisamente strategica e degna >> di essere sostenuta che puo' portare significativi >> miglioramenti a tutto il sw GFOSS nel suo insieme. >> >> https://gdalbarn.com/ >> >> se si raggiungera' la cifra totale di 125.000 USD i fondi >> raccolti verranno impiegati a partire dal 4 giugno p.v. per >> sostenere lo sviluppo di una implementazione piu' moderna e >> completa del supporto per i Sistemi di Riferimento Spaziale >> delle Coordinate (CRS/SRS) e delle relative trasformazioni. >> >> i pacchetti/librerie che beneficieranno direttamente della >> nuova implementazione sono GDAL, PROJ, libgeotiff, PostGIS >> e SpatiaLite. >> considerando l'uso praticamente universale di GDAL, PROJ e >> degli Spatial DBMS praticamente tutte le applicazioni GFOSS >> (QGIS, MapServer, GeoServer, Grass GIS etc) finirano per >> trarre indirettamente significativi benefici dall'operazione. >> >> qualche dettaglio tecnico sui principali scopi che si prefigge >> l'iniziativa: >> >> 1. superare gli attuali files CSV utilizzati per la >> definizione dei CRS definiti dal dataset EPSG, che >> verranno rimpiazzati da un database SQLite. >> >> 2. supporto completo per lo standard internazionale >> OGC WKT2 (che tra l'altro prevede anche la gestione >> delle coordinate 4D: classiche coordinate spaziali >> XYZ + Tempo). >> >> 3. superare l'approccio attuale adotatto da PROJ che >> si basa su matrici di trasformazione a 7 parametri >> "+towgs84" per la trasformazione intermedia delle >> coordinate su WGS84 (metodo non sempre applicabile >> a tutte le trasformazioni e che puo' implicare >> margini di errore di qualche metro). >> >> ciao Sandro >> _______________________________________________ >> [hidden email] >> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss >> Questa e' una lista di discussione pubblica aperta a tutti. >> I messaggi di questa lista non hanno relazione diretta con le posizioni >> dell'Associazione GFOSS.it. >> 796 iscritti al 28/12/2017 > > > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty àèìòù > ----------------- > -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
Re: Raccolta fondi per una PROJ evoluta
|
|
In reply to this post by Andrea Peri
E' sicuramente vero che ogni adeguamento richieda sempre del lavoro per gli sviluppatori, anche quelli di spatialite, ma tendenzialmente le nuove release di qualsiasi SW GFOSS tendono ad accogliere gli aggiornamenti delle librerie PROJ e GDAL, quindi a mio parere non c'è nulla di fuorviante nell'affermazione di Sandro.
My 2 cents. R Eng. Roberto Marzocchi, PhD GIS Project Coordinator Gter srl (Unige spin-off) Piazza De Marini 3/61 - 16123 Genova P.IVA/CF 01998770992 ph: 010-8694830 - mob: 349-8786575 E-mail: [hidden email] skype: roberto.marzocchi84 www.gter.it -- Gter social www.twitter.com/Gteronline - www.facebook.com/Gteronline - https://plus.google.com/+GterIt/posts www.linkedin.com/company/gter-srl-innovazione-in-geomatica-gnss-e-gis ----------------------------------------------------------------- Please consider the environment before printing this email! ---- On mar, 15 mag 2018 07:28:31 +0200 Andrea Peri <[hidden email]> wrote ---- Ciao Sandro. A scanso i equivoci penso che converrebbe chiarire meglio un passaggio del tuo discorso. Te scrivi: >i pacchetti/librerie che beneficieranno direttamente della >nuova implementazione sono GDAL, PROJ, libgeotiff, PostGIS >e SpatiaLite. >considerando l'uso praticamente universale di GDAL, PROJ e >degli Spatial DBMS praticamente tutte le applicazioni GFOSS >(QGIS, MapServer, GeoServer, Grass GIS etc) finirano per >trarre indirettamente significativi benefici dall'operazione. Io non o alcun dubbio che il giorno dopo che fosse disponibile una tale proj, te la adotteresti seduta stante nel tuo spatialite. Ma occorrerebbe capire se avverrebbe lo stesso anche su tutti glialtri prodotti che citi. gdal, libgeotiff, postgis, qgis, mapserver,geoserver,grass, etc... Io immagino che quanto meno dovrebbero partire ulteriori raccolte fondi per l'adeguamento di molti di tali prodotti. Il che non vuol dire che non pensi che sia opportuno aggiornare la proj, ma piuttosto che la tua affermazione "beneficeranno direttamente" potrebbe un po' fuorviare qualcuno. Facendogli credere un automatismo che in realta' non vi e'. Correggimi se mi sbaglio. A. Il giorno 15 maggio 2018 07:18, <[hidden email]> ha scritto: > vi segnalo una iniziativa decisamente strategica e degna > di essere sostenuta che puo' portare significativi > miglioramenti a tutto il sw GFOSS nel suo insieme. > > https://gdalbarn.com/ > > se si raggiungera' la cifra totale di 125.000 USD i fondi > raccolti verranno impiegati a partire dal 4 giugno p.v. per > sostenere lo sviluppo di una implementazione piu' moderna e > completa del supporto per i Sistemi di Riferimento Spaziale > delle Coordinate (CRS/SRS) e delle relative trasformazioni. > > i pacchetti/librerie che beneficieranno direttamente della > nuova implementazione sono GDAL, PROJ, libgeotiff, PostGIS > e SpatiaLite. > considerando l'uso praticamente universale di GDAL, PROJ e > degli Spatial DBMS praticamente tutte le applicazioni GFOSS > (QGIS, MapServer, GeoServer, Grass GIS etc) finirano per > trarre indirettamente significativi benefici dall'operazione. > > qualche dettaglio tecnico sui principali scopi che si prefigge > l'iniziativa: > > 1. superare gli attuali files CSV utilizzati per la > definizione dei CRS definiti dal dataset EPSG, che > verranno rimpiazzati da un database SQLite. > > 2. supporto completo per lo standard internazionale > OGC WKT2 (che tra l'altro prevede anche la gestione > delle coordinate 4D: classiche coordinate spaziali > XYZ + Tempo). > > 3. superare l'approccio attuale adotatto da PROJ che > si basa su matrici di trasformazione a 7 parametri > "+towgs84" per la trasformazione intermedia delle > coordinate su WGS84 (metodo non sempre applicabile > a tutte le trasformazioni e che puo' implicare > margini di errore di qualche metro). > > ciao Sandro > _______________________________________________ > [hidden email] > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > Questa e' una lista di discussione pubblica aperta a tutti. > I messaggi di questa lista non hanno relazione diretta con le posizioni > dell'Associazione GFOSS.it. > 796 iscritti al 28/12/2017 -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
Re: Raccolta fondi per una PROJ evoluta
|
|
Questo non e' un aggiornamento, ma una nuova implementazione.
Non e' come quando si aggiorna dalla 4.9.2 alla 4.9.3 di proj che basta ricompilare e tutto va a posto. In qgis, ad esempio, Non e' escludibile a priori che forse su qgis dovrebbero rivedere anche le api python di conseguenza i plugins che ne facessero uso. Ma ribadisco , lo scrivo giusto per chiarezza. A. Il giorno 15 maggio 2018 08:36, Roberto Marzocchi <[hidden email] > ha scritto: > E' sicuramente vero che ogni adeguamento richieda sempre del lavoro per > gli sviluppatori, anche quelli di spatialite, ma tendenzialmente le nuove > release di qualsiasi SW GFOSS tendono ad accogliere gli aggiornamenti delle > librerie PROJ e GDAL, quindi a mio parere non c'è nulla di fuorviante > nell'affermazione di Sandro. > > My 2 cents. > > R > > > > Eng. Roberto Marzocchi, PhD > GIS Project Coordinator > Gter srl (Unige spin-off)Piazza De Marini 3 <https://maps.google.com/?q=Piazza+De+Marini+3&entry=gmail&source=g>/61 - 16123 GenovaP.IVA/CF 01998770992 > ph: 010-8694830 - mob: 349-8786575 > E-mail: [hidden email] > skype: roberto.marzocchi84www.gter.it > > -- > Gter socialwww.twitter.com/Gteronline - www.facebook.com/Gteronline - https://plus.google.com/+GterIt/posts www.linkedin.com/company/gter-srl-innovazione-in-geomatica-gnss-e-gis > > ----------------------------------------------------------------- > Please consider the environment before printing this email! > > > > > ---- On mar, 15 mag 2018 07:28:31 +0200 *Andrea Peri <[hidden email] > <[hidden email]>>* wrote ---- > > Ciao Sandro. > > A scanso i equivoci penso che converrebbe chiarire meglio un passaggio del > tuo discorso. > > Te scrivi: > > >i pacchetti/librerie che beneficieranno direttamente della > >nuova implementazione sono GDAL, PROJ, libgeotiff, PostGIS > >e SpatiaLite. > >considerando l'uso praticamente universale di GDAL, PROJ e > >degli Spatial DBMS praticamente tutte le applicazioni GFOSS > >(QGIS, MapServer, GeoServer, Grass GIS etc) finirano per > >trarre indirettamente significativi benefici dall'operazione. > > Io non o alcun dubbio che il giorno dopo che fosse disponibile una tale > proj, te la adotteresti seduta stante nel tuo spatialite. > > Ma occorrerebbe capire se avverrebbe lo stesso anche su tutti glialtri > prodotti che citi. > gdal, libgeotiff, postgis, qgis, mapserver,geoserver,grass, etc... > > Io immagino che quanto meno dovrebbero partire ulteriori raccolte fondi per > l'adeguamento di molti di tali prodotti. > > Il che non vuol dire che non pensi che sia opportuno aggiornare la proj, ma > piuttosto che la tua affermazione > > "beneficeranno direttamente" potrebbe un po' fuorviare qualcuno. > > Facendogli credere un automatismo che in realta' non vi e'. > > Correggimi se mi sbaglio. > > A. > > > > > Il giorno 15 maggio 2018 07:18, <[hidden email]> ha scritto: > > > vi segnalo una iniziativa decisamente strategica e degna > > di essere sostenuta che puo' portare significativi > > miglioramenti a tutto il sw GFOSS nel suo insieme. > > > > https://gdalbarn.com/ > > > > se si raggiungera' la cifra totale di 125.000 USD i fondi > > raccolti verranno impiegati a partire dal 4 giugno p.v. per > > sostenere lo sviluppo di una implementazione piu' moderna e > > completa del supporto per i Sistemi di Riferimento Spaziale > > delle Coordinate (CRS/SRS) e delle relative trasformazioni. > > > > i pacchetti/librerie che beneficieranno direttamente della > > nuova implementazione sono GDAL, PROJ, libgeotiff, PostGIS > > e SpatiaLite. > > considerando l'uso praticamente universale di GDAL, PROJ e > > degli Spatial DBMS praticamente tutte le applicazioni GFOSS > > (QGIS, MapServer, GeoServer, Grass GIS etc) finirano per > > trarre indirettamente significativi benefici dall'operazione. > > > > qualche dettaglio tecnico sui principali scopi che si prefigge > > l'iniziativa: > > > > 1. superare gli attuali files CSV utilizzati per la > > definizione dei CRS definiti dal dataset EPSG, che > > verranno rimpiazzati da un database SQLite. > > > > 2. supporto completo per lo standard internazionale > > OGC WKT2 (che tra l'altro prevede anche la gestione > > delle coordinate 4D: classiche coordinate spaziali > > XYZ + Tempo). > > > > 3. superare l'approccio attuale adotatto da PROJ che > > si basa su matrici di trasformazione a 7 parametri > > "+towgs84" per la trasformazione intermedia delle > > coordinate su WGS84 (metodo non sempre applicabile > > a tutte le trasformazioni e che puo' implicare > > margini di errore di qualche metro). > > > > ciao Sandro > > _______________________________________________ > > [hidden email] > > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > > Questa e' una lista di discussione pubblica aperta a tutti. > > I messaggi di questa lista non hanno relazione diretta con le posizioni > > dell'Associazione GFOSS.it. > > 796 iscritti al 28/12/2017 > > > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty àèìòù > ----------------- > _______________________________________________ > [hidden email] > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > Questa e' una lista di discussione pubblica aperta a tutti. > I messaggi di questa lista non hanno relazione diretta con le posizioni > dell'Associazione GFOSS.it. > 796 iscritti al 28/12/2017 > > > > -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
Re: Raccolta fondi per una PROJ evoluta
Administrator
|
In reply to this post by a.furieri
leggo nelle note sulla nuova versione di GDAL/OGR 2.3.0 [1]:
Update to EPSG v9.2 (#7125) Add support for PROJ.5 new API (requires proj 5.0.1 or later). PROJ 4.X is still supported [1] https://trac.osgeo.org/gdal/wiki/Release/2.3.0-News s. -- Sent from: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/ _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
|
|
In reply to this post by Andrea Peri
On Tue, 15 May 2018 08:58:56 +0200, Andrea Peri wrote:
> Questo non e' un aggiornamento, ma una nuova implementazione. > > Non e' come quando si aggiorna dalla 4.9.2 alla 4.9.3 di proj che > basta ricompilare e tutto va a posto. > Andrea, c'e' del vero in tutto quel che dici, ma a me pare che si tratti di problemi inevitabili quando si introduce qualsiasi novita' rilevante e significativa che va a toccare in modo sostanziale meccanismi ben consolidati. non e' un problema specifico del FLOSS, e' un problema piu' generale che interessa tutto il sw, sia quello free che quello proprietario. ci sara' sempre chi si adegua prima e chi ci mettera' un po' piu' di tempo ... ma prima o poi tutti finiranno per adeguarsi. e' un po' come un'onda che si propaghi con differenti velocita' nelle varie direzioni; alla fine giungera' comunque dappertutto. certo, nel periodo intermedio di transizione e' molto verosimile che si possano creare conflitti o pasticcetti vari causati dalla coabitazione tra vecchie e nuove versioni. ma a me pare che sia qualcosa che e' praticamente impossibile evitare anche nei contesti del sw proprietario "closed source". vedi per confronto cosa e' successo regolarmente in tutte le grandi organizzazioni ogni volta che MS Office ha introdotto qualche nuovo formato che non era compatibile con le versioni precedenti. ... babele assicurata per un bel po' di tempo, almeno fino a quando tutte le postazioni di lavoro non vengono aggiornate alla versione piu' recente e tutto va finalmente a posto... ma in genere ci vogliono svariati mesi, se non anni. ;-) ciao Sandro _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
|
|
In reply to this post by stefano campus
On Tue, 15 May 2018 00:00:19 -0700 (MST), stefano campus wrote:
> leggo nelle note sulla nuova versione di GDAL/OGR 2.3.0 [1]: > > Update to EPSG v9.2 (#7125) > Add support for PROJ.5 new API (requires proj 5.0.1 or later). PROJ > 4.X is > still supported > qulche dettaglio tecnico aggiuntivo per aiutare tutti a capire meglio. IL "PROBLEMONE" DI FONDO ======================== la libreria PROJ ha radici molto antiche; le primissime versioni risalgono addirittura agli anni '80 (cioe' a svariati secoli fa, in termini di sviluppo informatico). per definire le caratteristiche dei vari CRS la PROJ ha sempre utilizzato un formato tutto suo basato sulle "stringhe di parametri geodetici". p.es. lo SRID=3003 Gauss-Boaga Ovest e' definito come: ---------------------- +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 ---------------------- in anni molto piu' recenti OGC ha pero' definitivamente formalizzato lo standard WKT per descrivere i CRS. p.es. questa e' la definizione WKT del solito SRID=3003: ---------------------- PROJCS["Monte Mario / Italy zone 1", GEOGCS["Monte Mario", DATUM["Monte_Mario", SPHEROID["International 1924",6378388,297, AUTHORITY["EPSG","7022"]], AUTHORITY["EPSG","6265"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.01745329251994328, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4265"]], UNIT["metre",1, AUTHORITY["EPSG","9001"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",9], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",1500000], PARAMETER["false_northing",0], AUTHORITY["EPSG","3003"], AXIS["X",EAST], AXIS["Y",NORTH]] ---------------------- come salta subito all'occhio, i due formati sono del tutto dissimili; ed e' evidente che il WKT e' decisamente piu' raffinato, completo e preciso del "rozzo" formato adottato da PROJ in anni molto precedenti. non solo: OGC WKT e' uno standard internazionale, mentre invece il formato PROJ e' qualcosa che solo la stessa PROJ e' in grado di interpretare. insomma, e' uno di quei rari casi in cui il sw FLOSS non si adegua agli standard ma pretende invece di imporre un proprio formato decisamente fuori standard. chiaramente e' un punto critico di sofferenza per tutto il sw GFOSS, che prima o poi andava sanato. l'iniziativa del fund raising va esattamente in questa direzione, ed ecco perche' e' cosi' importante. LE ULTIME NOVITA' INTRODOTTE DA PROJ v.5 ======================================== scommetto che molti di voi sono convinti che il nome corretto della libreria sia PROJ.4 nulla di piu' sbagliato; la libreria si chiama semplicemente PROJ; ma la versione 4 e' rimasta sostanzialmente fossilizzata per oltre 20 anni, fino al punto che ha finito per diventare parte integrante del nome :-D il recente rilascio della versione 5 ha finalmente sbloccato la situazione; la PROJ ha iniziato un percorso di transizione che non e' ancora completo. intanto e' stato introdotto un nuovo meccanismo "pipelined" per gestire le catene di trasformazione, cosi' come ora sono supportate le trasformazioni di tipo spazio-temporale. pero' queste nuove funzionalita' non sono compatibili con le vecchie stringhe di parametri geodetici. non solo: le API della libreria sono state radicalmente stravolte, e non hanno piu' nulla in comune con quelle tradizionali. giusto per addolcire la pillola la v.5 e' ancora in grado di supportare le vecchie API v.4 (in soldoni; e' possibile continuare ad utilizzare la 5 esattamente come se fossa la 4, senza dovere adattare il codice). ma e' chiaro che continuando ad usare le vecchie API v.4 non e' possibile godere di nessuno dei benefici introdotti dalla v.5 nota bene: il supporto delle vecchie API e' transitorio, e cessera' definitivamente con il rilascio della v.7 chi ha orecchie per intendere intenda: ancora per qualche anno sara' possibile continuare ad utilizzare la PROJ nel modo tradizionale, ma prima o poi si imporra' comunque una radicale revisione del codice da parte di tutte le librerie / applicazioni basate sulla PROJ; farlo passo-passo sara' verosimilmente meno traumatico. TIRANDO LE SOMME ================ in questo periodo c'e' un gran ribollire di iniziative attorno alla PROJ; il quadro finale e' ancora un po' confuso, ma certamente andiamo verso un'implementazione finalmente del tutto conforme agli standard internazionali, che verosimilmente sara' molto migliore dell'attuale. la transizione sara' per quanto possibile morbida e relativamente indolore, ma un ciclo di sviluppo ventennale (su cui eravamo un po' pigramente adagiati) si e' definitivamente chiuso ed apre la strada per novita' decisamente eccitanti ma anche in qualche modo "rivoluzionarie". e come diceva Lenin (che di rivoluzioni se ne intendeva): "Per fare una frittata bisogna pur rompere qualche uovo" :-) ciao Sandro _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
Re: Raccolta fondi per una PROJ evoluta
|
|
On 5/15/18, [hidden email] <[hidden email]> wrote:
> On Tue, 15 May 2018 00:00:19 -0700 (MST), stefano campus wrote: >> leggo nelle note sulla nuova versione di GDAL/OGR 2.3.0 [1]: grazie per questa ennesima dissertazione che ho prontamente provveduto a stampare ed ad aggiungere alla mia collezione :-) una richiesta se posso: non sono riuscito a capire dove la nuova definizione documenta i parametri: > ...... +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 \ > ciao Sandro grazie, saluti, giuliano _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
|
|
On Tue, 15 May 2018 10:41:16 +0200, Giuliano Curti wrote:
> una richiesta se posso: non sono riuscito a capire dove la nuova > definizione documenta i parametri: >> ...... +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 \ > ciao Giuliano, se per "nuova definizione" intendi quella WKT la risposta e' molto semplice. - la matrice a 7 parametri "+towgs94" e' esattamente uno di quegli elementi "fuori standard" esclusivi della PROJ che si intendono eliminare. n.b.: quando effettui una riproiezione p.es. dal 3003 al 32632 la PROJ in effetti applica due trasformazioni: - la prima dal 3003 al 4326 (WGS84) - la seconda dal 4326 al 32632 ecco perche' la PROJ usa a man bassa il +towgs84; perche' le e' strettamente indispensabile per riproiettare dal piano all'ellissoide e viceversa. ma purtroppo "doppia trasformazione" significa anche "doppio errore" (arrotondamenti, troncamenti etc). - l'approccio WKT e' del tutto differente. come si capisce senza troppa fatica, vengono definiti in modo minuzioso l'ellissoide di riferimento, il datum, il meridiano fondamentale, l'orientazione degli assi, eventuali "false easting" e "false northing", le unita' di misura, fattori di scala etc e quidi, essendo noti tutti i parametri su entrambi i lati della trasformazione, non e' piu' richesta la "doppia trasformazione"; puoi andare sparato da un CRS all'altro in modo diretto, a tutto vantaggio della precisione dei calcoli. - ma non finisce neppure qua: leggo che tra le novita' proposte per la nuova PROJ c'e' pure un meccanismo abbastanza raffinato che dovrebbe verificare dove cade esattamente l'area della geometria da trasformare rispetto ai BBOXes dei due CRS, in modo tale da potere compensare automaticamente quei fattori di distorsione che si verificano inevitabilmente quando ci si allontano in modo sensibile dal centro del fuso di riferimento ... almeno sulla carta, decisamente notevole ;-) ciao Sandro _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
Re: Raccolta fondi per una PROJ evoluta
|
|
On 5/15/18, [hidden email] <[hidden email]> wrote:
> On Tue, 15 May 2018 10:41:16 +0200, Giuliano Curti wrote: >> una richiesta se posso: non sono riuscito a capire dove la nuova >> definizione documenta i parametri: >>> ...... +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 \ >> > > ciao Giuliano, ciao, > > se per "nuova definizione" intendi quella WKT la risposta > e' molto semplice. >..... grazie (anche questa nella collezione :-) ) > ciao Sandro ciao, giuliano _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
Re: Raccolta fondi per una PROJ evoluta
|
|
In reply to this post by a.furieri
Il 15/05/2018 11:05, [hidden email] ha scritto: > On Tue, 15 May 2018 10:41:16 +0200, Giuliano Curti wrote: >> una richiesta se posso: non sono riuscito a capire dove la nuova >> definizione documenta i parametri: >>> ...... +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 \ >> > > ciao Giuliano, > > se per "nuova definizione" intendi quella WKT la risposta > e' molto semplice. > > - la matrice a 7 parametri "+towgs94" e' esattamente uno > di quegli elementi "fuori standard" esclusivi della PROJ > che si intendono eliminare. > n.b.: quando effettui una riproiezione p.es. dal 3003 al > 32632 la PROJ in effetti applica due trasformazioni: > - la prima dal 3003 al 4326 (WGS84) > - la seconda dal 4326 al 32632 > ecco perche' la PROJ usa a man bassa il +towgs84; perche' > le e' strettamente indispensabile per riproiettare dal > piano all'ellissoide e viceversa. > ma purtroppo "doppia trasformazione" significa anche > "doppio errore" (arrotondamenti, troncamenti etc). > > - l'approccio WKT e' del tutto differente. > come si capisce senza troppa fatica, vengono definiti > in modo minuzioso l'ellissoide di riferimento, il datum, > il meridiano fondamentale, l'orientazione degli assi, > eventuali "false easting" e "false northing", le unita' > di misura, fattori di scala etc > e quidi, essendo noti tutti i parametri su entrambi i > lati della trasformazione, non e' piu' richesta la > "doppia trasformazione"; puoi andare sparato da un > CRS all'altro in modo diretto, a tutto vantaggio della > precisione dei calcoli. > > - ma non finisce neppure qua: leggo che tra le novita' > proposte per la nuova PROJ c'e' pure un meccanismo > abbastanza raffinato che dovrebbe verificare dove > cade esattamente l'area della geometria da trasformare > rispetto ai BBOXes dei due CRS, in modo tale da potere > compensare automaticamente quei fattori di distorsione > che si verificano inevitabilmente quando ci si > allontano in modo sensibile dal centro del fuso > di riferimento ... almeno sulla carta, decisamente > notevole ;-) > > ciao Sandro > ciao Sandro, quel che che scrivi è giusto ma forse incompleto. La definizione WKT che riporti nel post precedente definisce il datum e basta, non definisce la relazione che quel datum ha con altri datum, come invece fa la stringa dei 7 parametri. Con la wkt che mostri tu si hanno solo le informazioni dell'ellissoide e della proiezione associata: questi dati bastano per passare da coordinate ellissoidiche e coordinate piane e viceversa (le formule di gauss sono in letteratura). Mi sembra che nella definizione completa della wkt sia ancora presente il parametro towgs84. In parole povere: definendo i due datum non siamo a niente. Bisogna definire in che relazione stanno se abbiamo bisogno di passare ad altri datum, i quali non hanno una relazione matematica tra di loro. Il passaggio si fa solo in modo statistico. I 7 parametri realizzano un sistema di passaggio "medio" tra i sistemi. Senza quelli non si va da nessuna parte. Quindi credo che in realtà un meccanismo simile sia implementato anche nella nuova versione della libreria. Come sappiamo in Italia l'IGM ha realizzato, attraverso la conoscenza delle coordinate di alcuni (molti) punti nei sistemi "nostrani" (ED50, ETRF89, ETRF2000, ROMA40) un meccanismo di passaggio più raffinato dei 7 parametri, che ci permette di ottenere scarti minori perché calibrato sulla relazione delle realizzazzioni delle reti trigonometriche esistenti, dove per per realizzazione si intende materializzare sul terreno un sistema di riferimento. I famosi "grigliati", scritti in un formato ascii definito da IGM, esistono anche nel formato NTv2 forse più idoneo ad essere implementato in software "general purpose". Fai riferimento al BBOX ed alla compensazione di distorsioni locali. Bene, ma rimane sempre da capire che tipo di informazioni di maggior dettaglio saranno contenute per distinte zone geografiche. Da dove provengono? Chi le fornisce? Sarà utile, al momento giusto, sfruttare e integrare le capacità e le competenze di chi sa leggere il codice, da una parte, e di chi si intende si sistemi di riferimento dall'altra per capire l'effettiva valenza e potenza della libreria. saluti marco -- Marco Guiducci - 055 4383194 SITA - Sistema informativo territoriale e ambientale Regione Toscana - Via di Novoli 26 - 50127 Firenze _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
|
|
In reply to this post by Giuliano Curti
ultimissimi aggiornamenti.
Even Rouault ha appena comunicato sulla ML di gdal-dev che il fund raising ha gia' raggiunto il traguardo, e quindi lo sviluppo iniziera' al piu' presto. la prima libreria che verra' modificata sara' proprio la PROJ, che gia' con la prossima v.6 dovrebbe essere in grado di supportare adeguatamente tutti i nuovi requisiti. a seguire sara' il turno di GDAL che in prospetiva cessera' di implementare internamente le operazioni relative ai CRS; la prossima v.2.4 richiedera' quindi il supporto obbligatorio della PROJ v.6 (cioe' in buona sostanza, molti pezzi di codice oggi disponibili solo su GDAL verranno trasferiti dentro alla PROJ, razionalizzando e semplificando cosi' tutto lo scenario complessivo di riferimento). ciao Sandro _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
Re: Raccolta fondi per una PROJ evoluta
|
Administrator
|
ESRI e FME hanno donato 30'000 € ciascuno.
bella sinergia tra mondo free e mondo proppietario a prescindere dal modello di business scelto! s. -- Sent from: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/ _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
Re: Raccolta fondi per una PROJ evoluta
|
|
Ottima notizia.
Visto che entrambi utilizzano da tempo le librerie open GDAL, mi pare giusto e onesto che ne supportino un importante sviluppo. Stefano --------------------------------------------------- 41.95581N 12.52854E http://www.linkedin.com/in/stefanoiacovella http://twitter.com/#!/Iacovellas Il giorno 16 maggio 2018 09:07, stefano campus <[hidden email]> ha scritto: > ESRI e FME hanno donato 30'000 € ciascuno. > bella sinergia tra mondo free e mondo proppietario a prescindere dal > modello > di business scelto! > > s. > > -- > Sent from: http://gfoss-geographic-free-and-open-source-software- > italian-mailing.3056002.n2.nabble.com/ > _______________________________________________ > [hidden email] > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > Questa e' una lista di discussione pubblica aperta a tutti. > I messaggi di questa lista non hanno relazione diretta con le posizioni > dell'Associazione GFOSS.it. > 796 iscritti al 28/12/2017 > [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
Re: [INFO] Raccolta fondi per una PROJ evoluta
|
|
In reply to this post by a.furieri
On Tue, May 15, 2018 at 07:18:02AM +0200, [hidden email] wrote:
>3. superare l'approccio attuale adotatto da PROJ che > si basa su matrici di trasformazione a 7 parametri > "+towgs84" per la trasformazione intermedia delle > coordinate su WGS84 (metodo non sempre applicabile > a tutte le trasformazioni e che puo' implicare > margini di errore di qualche metro). > Di tutte le proposte questa mi pare la più significativa. E a nasometro mi pare anche quella forse meno impattante in relazione ai prodotti terzi, considerando che il descrittore proj4 è generalmente usato come black-box in molti casi. Non è propriamente vero che si usi solo l'equazione a 3/7 parametri, ma comunque ... -- Francesco P. Lovergine _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |