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 <roberto.marzoc...@gter.it > 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: roberto.marzoc...@gter.it > 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 <aperi2...@gmail.com > <aperi2...@gmail.com>>* 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, <a.furi...@lqt.it> 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 > > _______________________________________________ > > Gfoss@lists.gfoss.it > > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > > Questa e' una lista di discussione pubblica aperta a tutti. > > I messaggi di questa lista non hanno relazione diretta con le posizioni > > dell'Associazione GFOSS.it. > > 796 iscritti al 28/12/2017 > > > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty àèìòù > ----------------- > _______________________________________________ > Gfoss@lists.gfoss.it > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > Questa e' una lista di discussione pubblica aperta a tutti. > I messaggi di questa lista non hanno relazione diretta con le posizioni > dell'Associazione GFOSS.it. > 796 iscritti al 28/12/2017 > > > > -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ Gfoss@lists.gfoss.it http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017