[Gfoss] Quale formato?

[a.furieri a lqt.it]

On Mon, 10 Nov 2014 22:14:05 +0100, Luca Lanteri wrote:
> Concordo in pieno! Lo shapefile ormai dovrebbe essere messo al bando
> per tutti i motivi che Andrea ha ben elencato.
>
> Anche per me i GeoDB al momento rimangono la migliore alternativa
> perché sono quelli che offrono maggiori potenzialità. Tra tutti
> Splite mi pare l'unico papabile su filesystem (ma magari mi sto
> perdendo qualche altro formato che non conosco). 
> Di GeoPackage (che mi pare si basi fortemente su Splite) non ho ben
> capito cosa lo stia tenendo fermo al palo. 
>

Luca,

la storia del GeoPackage la conosco molto da vicino, visto che a suo
tempo sono stato membro del comitato OGC che ha messo a punto lo 
standard;
e visto pure che gli unici due nomi italiani citati nel documento
ufficiale OGC con le specifiche formali sono quelli di Andrea Peri e
dell'umile sottoscritto.


fase 1
------
GPKG nasce a seguito di un requisito specifico dell'US Army Geospatial
Center: lo scopo e' quello di definire formalmente un formato standard
che consenta di veicolare cartografie molto ricche e complete sotto
tutti gli aspetti.
e che quindi sia in grado di memorizzare all'interno di unico 
contenitore
monolitico sia vectors che rasters con tutti i relativi metadati 
ISO-19115
di accompagnamento.
la tecnologia di base che viene identificata e' quella di un DBMS con
pieno supporto per Spatial SQL che deve essere sempre e comunque 
presente
anche in totale assenza di qualsiasi applicazione GIS
gli scopi dei militari non sono affatto difficili da identificare:
- mandare definitivamente in pensione formati storici come Shapefile,
   GML e GeoTIFF
- svincolarsi (almeno in parte) da tutto l'armamentario GIS 
tradizionale
- favorire la nascita' di un ecosistema GeoSpatial moderno ed allineato
   alle tecnologie piu' avanzate, largamente basato su terminali 
portatili
   capillarmente diffusi (p.es. Android) che siano facilmente 
utilizzabili
   direttamente sul campo anche da parte di personale poco specializzato
   ed in condizioni operative possibilmente molto severe.


fase 2
------
l'idea trova consensi c/o altre agenzie federali come l'U.S. National
Geospatial Intelligence Agency (quelli che gesticono i satelliti spia)
ed c/o altri alleati del blocco occidentale (NATO, Australia).
visto che probabilmente e' un'idea potenzialmente molto appetibile 
anche
per il mercato civile a questo punto i militari decidono di aprire il
progetto alle universita', agli enti di ricerca e pure alle aziende.
ed e' proprio a questo punto che GPKG finisce sotto l'ombrello OGC


fase 3
------
il comitato OGC inizia a lavorare ed in meno di un anno mette a punto
lo Standard Candidate.
a questo punto GPKG e' integralmente basato su SQLite e su SpatiaLite;
in pratica e' uno SpatiaLite con l'aggiunta di un visibilio di nuove
tavole a supporto di una metainformazione completa ed esaustiva, tutto
rigidamente incasellato dentro ad una serie di specifiche formali
minuziosamente formalizzate e rigorosissime.
l'uso a piene mani del supporto integrato Spatial SQL e' il pilastro
qualificante dell'intera architettura.


fase 4
------
a questo punto le regole OGC prevedono che lo Standard Candidate prima
di ricevere l'approvazione definitiva passi attraverso tutta una serie
di votazioni a maggioranza; da qui in avanti non contano piu' solo
gli aspetti tecniciv, iniziano anche a pesare gli equilibri "politici".

finalmente scende in campo la ben nota multinazionale che da sempre ha
una posizione dominante sul mercato GIS, e che era stata completamente
assente durante tutti i passaggi precedenti.
il panorama si ribalta completamente nel giro di poche settimane: tutte
le aziende che lavorano nel settore difesa finiscono per coalizzarsi 
con
Big Brother, e riescono pure a farsi appoggiare da non pochi autorevoli
esponenti del mondo GFOSS (sic)
i militari rimangono completamente isolati a difendere SpatiaLite e
lo Spatial SQL (conservano giusto l'appoggio di qualche Universita'),
e finiscono regolarmente sotto in tutte le votazioni.

lo Standard Candidate viene rovesciato come un calzino: quel che resta
alla fine e' un DB SQLite con un sacco di tavole e con un numero
impressionante di regole e regolette formali.
ma nel frattempo e' sparito qualsiasi riferimento a SpatiaLite (anzi: 
si
e' fatto tutto quel che era materialmente possibile per garantire che
GPKG e SpatiaLite non possano mai essere direttamente compatibili).
addirittura anche lo Spatial Indexing e' diventato un optional previsto
ma non strettamente indispensabile.
last but not least: e' completamente sparito il supporto Spatial SQL,
che era invece il requisito base di partenza che teneva in piedi tutta
l'architettura cosi' come ipotizzata inizialmente; formalmente Spatial
SQL rimane, ma solo ai livelli piu' elevati dello standard, quelli che
non e' obbligatorio supportare: di fatto e' morto e sepolto.
insomma, non e' piu' un formato che possa venire usato realisticamente
in condizioni d'uso impegnative per gestire grandi moli di dati; ormai
e' diventato un puro formato di scambio per trasferire i dati.


fase 5
------
nel giro di pochi mesi moltissimi packages GFOSS iniziano a supportare
GPKG: GDAL, GeoTools, GeoServer, OpenJump, SpatiaLite etc
esiste pure una libreria FLOSS di Luciad che consente di gestire tutte
le operazioni di lettura/scrittura in modo abbastanza facile e snello.
buona ultima arriva ESRI che dall'estate 2014 supporta GPKG su ArcGis
10.2.2 (sia server che desktop) e 10.3 (solo desktop); su Android e'
supportato da ArcGis 10.2.4 runtime for Java.

a questo punto tutto si puo' dire meno che GPKG soffra di supporto
scarso e carente: forse e' ancora troppo presto per tirare le somme,
ma se (come molti iniziano a temere) finira' per rivelarsi un flop
  i motivi piu' profondi vanno ricercati proprio nella storia 
decisamente
sofferta e molto travagliata che ha portato al rilascio della specifica
finale.

almeno a mio modestissima opinione personale:
* l'idea iniziale dei militari (definire rigorosamente uno Spatial DBMS
   universale, altamente formalizzato e capace di raffinate capacita' di
   elaborazione autonome) conteneva molte idee radicalmente innovative:
   poteva anche risultare attraente.
* lo standard finale e' poco piu' di una "minestrina riscaldata"; ok,
   sicuramente e' un ottimo formato di scambio ed e' sicuramente 
migliore
   dei vecchi shapefiles.
   ma molto difficilmente potra' mai prestarsi a rimpiazzare un vero e
   proprio Spatial DBMS: sia perche' non e' abbastanza potente sia 
perche'
   e' stato volutamente castrato dalla totale mancanza di un appropriato
   supporto Spatial SQL esterno a qualsiasi specifica applicazione.
* insomma, cosi' com'e' finisce per non essere ne carne ne pesce.
   ed anche considerando tutte le numerose potature ed amputazioni che
   ha subito durante la laboriosa messa a punto finale resta pur sempre
   un attrezzo decisamente molto complesso e complicato.
   purtroppo forte complessita' e scarsa potenza combinate assieme non
   sembrano affatto una ricetta vincente.

ciao Sandro