[Gfoss] Raccolta fondi per una PROJ evoluta

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

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.furieri@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 àèìòù
-----------------

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 <aperi2007@gmail.com> 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, <a.furieri@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 àèìòù
-----------------

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

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: roberto.marzocchi@gter.it 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;aperi2007@gmail.com&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;a.furieri@lqt.it&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; Gfoss@lists.gfoss.it

&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 àèìòù

-----------------

_______________________________________________

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

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.marzocchi@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&gt;/61 - 16123 GenovaP.IVA/CF 01998770992
ph: 010-8694830 - mob: 349-8786575
E-mail: roberto.marzocchi@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 <aperi2007@gmail.com
<aperi2007@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.furieri@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 àèìòù
-----------------

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/

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. :wink:

ciao Sandro

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 :smiley:

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" :slight_smile:

ciao Sandro

On 5/15/18, a.furieri@lqt.it <a.furieri@lqt.it> 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 :slight_smile:

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

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 :wink:

ciao Sandro

On 5/15/18, a.furieri@lqt.it <a.furieri@lqt.it> 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 :slight_smile: )

ciao Sandro

ciao,
giuliano

Il 15/05/2018 11:05, a.furieri@lqt.it 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 :wink:

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

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

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/

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 <skampus@gmail.com> 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/
_______________________________________________
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

On Tue, May 15, 2018 at 07:18:02AM +0200, a.furieri@lqt.it 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