Raccolta fondi per una PROJ evoluta

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Raccolta fondi per una PROJ evoluta

a.furieri
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
Reply | Threaded
Open this post in threaded view
|

Re: Raccolta fondi per una PROJ evoluta

Andrea Peri
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
Reply | Threaded
Open this post in threaded view
|

Re: Raccolta fondi per una PROJ evoluta

Andrea Peri
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
Reply | Threaded
Open this post in threaded view
|

Re: Raccolta fondi per una PROJ evoluta

Roberto Marzocchi
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 &lt;[hidden email]&gt; wrote ----




Ciao Sandro.



A scanso i equivoci penso che converrebbe chiarire meglio un passaggio del

tuo discorso.



Te scrivi:



&gt;i pacchetti/librerie che beneficieranno direttamente della

&gt;nuova implementazione sono GDAL, PROJ, libgeotiff, PostGIS

&gt;e SpatiaLite.

&gt;considerando l'uso praticamente universale di GDAL, PROJ e

&gt;degli Spatial DBMS praticamente tutte le applicazioni GFOSS

&gt;(QGIS, MapServer, GeoServer, Grass GIS etc) finirano per

&gt;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, &lt;[hidden email]&gt; ha scritto:



&gt; vi segnalo una iniziativa decisamente strategica e degna

&gt; di essere sostenuta che puo' portare significativi

&gt; miglioramenti a tutto il sw GFOSS nel suo insieme.

&gt;

&gt; https://gdalbarn.com/

&gt;

&gt; se si raggiungera' la cifra totale di 125.000 USD i fondi

&gt; raccolti verranno impiegati a partire dal 4 giugno p.v. per

&gt; sostenere lo sviluppo di una implementazione piu' moderna e

&gt; completa del supporto per i Sistemi di Riferimento Spaziale

&gt; delle Coordinate (CRS/SRS) e delle relative trasformazioni.

&gt;

&gt; i pacchetti/librerie che beneficieranno direttamente della

&gt; nuova implementazione sono GDAL, PROJ, libgeotiff, PostGIS

&gt; e SpatiaLite.

&gt; considerando l'uso praticamente universale di GDAL, PROJ e

&gt; degli Spatial DBMS praticamente tutte le applicazioni GFOSS

&gt; (QGIS, MapServer, GeoServer, Grass GIS etc) finirano per

&gt; trarre indirettamente significativi benefici dall'operazione.

&gt;

&gt; qualche dettaglio tecnico sui principali scopi che si prefigge

&gt; l'iniziativa:

&gt;

&gt; 1. superare gli attuali files CSV utilizzati per la

&gt; definizione dei CRS definiti dal dataset EPSG, che

&gt; verranno rimpiazzati da un database SQLite.

&gt;

&gt; 2. supporto completo per lo standard internazionale

&gt; OGC WKT2 (che tra l'altro prevede anche la gestione

&gt; delle coordinate 4D: classiche coordinate spaziali

&gt; XYZ + Tempo).

&gt;

&gt; 3. superare l'approccio attuale adotatto da PROJ che

&gt; si basa su matrici di trasformazione a 7 parametri

&gt; "+towgs84" per la trasformazione intermedia delle

&gt; coordinate su WGS84 (metodo non sempre applicabile

&gt; a tutte le trasformazioni e che puo' implicare

&gt; margini di errore di qualche metro).

&gt;

&gt; ciao Sandro

&gt; _______________________________________________

&gt; [hidden email]

&gt; http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss

&gt; Questa e' una lista di discussione pubblica aperta a tutti.

&gt; I messaggi di questa lista non hanno relazione diretta con le posizioni

&gt; dell'Associazione GFOSS.it.

&gt; 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
Reply | Threaded
Open this post in threaded view
|

Re: Raccolta fondi per una PROJ evoluta

Andrea Peri
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
Reply | Threaded
Open this post in threaded view
|

Re: Raccolta fondi per una PROJ evoluta

stefano campus
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
Reply | Threaded
Open this post in threaded view
|

Re: Raccolta fondi per una PROJ evoluta

a.furieri
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
Reply | Threaded
Open this post in threaded view
|

Re: Raccolta fondi per una PROJ evoluta

a.furieri
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
Reply | Threaded
Open this post in threaded view
|

Re: Raccolta fondi per una PROJ evoluta

Giuliano Curti
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
Reply | Threaded
Open this post in threaded view
|

Re: Raccolta fondi per una PROJ evoluta

a.furieri
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
Reply | Threaded
Open this post in threaded view
|

Re: Raccolta fondi per una PROJ evoluta

Giuliano Curti
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
Reply | Threaded
Open this post in threaded view
|

Re: Raccolta fondi per una PROJ evoluta

Marco Guiducci-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Raccolta fondi per una PROJ evoluta

a.furieri
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
Reply | Threaded
Open this post in threaded view
|

Re: Raccolta fondi per una PROJ evoluta

stefano campus
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
Reply | Threaded
Open this post in threaded view
|

Re: Raccolta fondi per una PROJ evoluta

Stefano Iacovella
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
Reply | Threaded
Open this post in threaded view
|

Re: [INFO] Raccolta fondi per una PROJ evoluta

Francesco P. Lovergine
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