[Gfoss] Quale formato?

Luca Lanteri mescal72 a gmail.com
Mar 18 Nov 2014 14:33:11 CET


Grazie per il dettaglio report da fonte interna!
Quindi alla fine il geopackage è diventato un ibrido che alla fine a poco
serve perché invece di prendere il meglio di tutto fa l'esatto contrario e
perde la cosa che a me pareva più interessante, cioè il supporto geoDB.

Torno a pensare che il futuro, se gestito bene, possa essere in SL in
quanto uno dei formati maggiormente flessibili e completi sia per lo
scambio dati che per il lavoro.

Luca


Il giorno 11 novembre 2014 10:42, <a.furieri a lqt.it> ha scritto:

> 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
>
>
> _______________________________________________
> Gfoss a 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.
> 666+40 iscritti al 5.6.2014
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20141118/c75a4b8e/attachment.html>


Maggiori informazioni sulla lista Gfoss