[Gfoss] Raccolta fondi per una PROJ evoluta

[a.furieri a lqt.it]

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