<div dir="ltr">Grazie per il dettaglio report da fonte interna!<div>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.</div><div><br></div><div>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.</div><div><br></div><div>Luca</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">Il giorno 11 novembre 2014 10:42,  <span dir="ltr"><<a href="mailto:a.furieri@lqt.it" target="_blank">a.furieri@lqt.it</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 10 Nov 2014 22:14:05 +0100, Luca Lanteri wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Concordo in pieno! Lo shapefile ormai dovrebbe essere messo al bando<br>
per tutti i motivi che Andrea ha ben elencato.<br>
<br>
Anche per me i GeoDB al momento rimangono la migliore alternativa<br>
perché sono quelli che offrono maggiori potenzialità. Tra tutti<br>
Splite mi pare l'unico papabile su filesystem (ma magari mi sto<br>
perdendo qualche altro formato che non conosco). <br>
Di GeoPackage (che mi pare si basi fortemente su Splite) non ho ben<br>
capito cosa lo stia tenendo fermo al palo. <br>
<br>
</blockquote>
<br></span>
Luca,<br>
<br>
la storia del GeoPackage la conosco molto da vicino, visto che a suo<br>
tempo sono stato membro del comitato OGC che ha messo a punto lo standard;<br>
e visto pure che gli unici due nomi italiani citati nel documento<br>
ufficiale OGC con le specifiche formali sono quelli di Andrea Peri e<br>
dell'umile sottoscritto.<br>
<br>
<br>
fase 1<br>
------<br>
GPKG nasce a seguito di un requisito specifico dell'US Army Geospatial<br>
Center: lo scopo e' quello di definire formalmente un formato standard<br>
che consenta di veicolare cartografie molto ricche e complete sotto<br>
tutti gli aspetti.<br>
e che quindi sia in grado di memorizzare all'interno di unico contenitore<br>
monolitico sia vectors che rasters con tutti i relativi metadati ISO-19115<br>
di accompagnamento.<br>
la tecnologia di base che viene identificata e' quella di un DBMS con<br>
pieno supporto per Spatial SQL che deve essere sempre e comunque presente<br>
anche in totale assenza di qualsiasi applicazione GIS<br>
gli scopi dei militari non sono affatto difficili da identificare:<br>
- mandare definitivamente in pensione formati storici come Shapefile,<br>
  GML e GeoTIFF<br>
- svincolarsi (almeno in parte) da tutto l'armamentario GIS tradizionale<br>
- favorire la nascita' di un ecosistema GeoSpatial moderno ed allineato<br>
  alle tecnologie piu' avanzate, largamente basato su terminali portatili<br>
  capillarmente diffusi (<a href="http://p.es" target="_blank">p.es</a>. Android) che siano facilmente utilizzabili<br>
  direttamente sul campo anche da parte di personale poco specializzato<br>
  ed in condizioni operative possibilmente molto severe.<br>
<br>
<br>
fase 2<br>
------<br>
l'idea trova consensi c/o altre agenzie federali come l'U.S. National<br>
Geospatial Intelligence Agency (quelli che gesticono i satelliti spia)<br>
ed c/o altri alleati del blocco occidentale (NATO, Australia).<br>
visto che probabilmente e' un'idea potenzialmente molto appetibile anche<br>
per il mercato civile a questo punto i militari decidono di aprire il<br>
progetto alle universita', agli enti di ricerca e pure alle aziende.<br>
ed e' proprio a questo punto che GPKG finisce sotto l'ombrello OGC<br>
<br>
<br>
fase 3<br>
------<br>
il comitato OGC inizia a lavorare ed in meno di un anno mette a punto<br>
lo Standard Candidate.<br>
a questo punto GPKG e' integralmente basato su SQLite e su SpatiaLite;<br>
in pratica e' uno SpatiaLite con l'aggiunta di un visibilio di nuove<br>
tavole a supporto di una metainformazione completa ed esaustiva, tutto<br>
rigidamente incasellato dentro ad una serie di specifiche formali<br>
minuziosamente formalizzate e rigorosissime.<br>
l'uso a piene mani del supporto integrato Spatial SQL e' il pilastro<br>
qualificante dell'intera architettura.<br>
<br>
<br>
fase 4<br>
------<br>
a questo punto le regole OGC prevedono che lo Standard Candidate prima<br>
di ricevere l'approvazione definitiva passi attraverso tutta una serie<br>
di votazioni a maggioranza; da qui in avanti non contano piu' solo<br>
gli aspetti tecniciv, iniziano anche a pesare gli equilibri "politici".<br>
<br>
finalmente scende in campo la ben nota multinazionale che da sempre ha<br>
una posizione dominante sul mercato GIS, e che era stata completamente<br>
assente durante tutti i passaggi precedenti.<br>
il panorama si ribalta completamente nel giro di poche settimane: tutte<br>
le aziende che lavorano nel settore difesa finiscono per coalizzarsi con<br>
Big Brother, e riescono pure a farsi appoggiare da non pochi autorevoli<br>
esponenti del mondo GFOSS (sic)<br>
i militari rimangono completamente isolati a difendere SpatiaLite e<br>
lo Spatial SQL (conservano giusto l'appoggio di qualche Universita'),<br>
e finiscono regolarmente sotto in tutte le votazioni.<br>
<br>
lo Standard Candidate viene rovesciato come un calzino: quel che resta<br>
alla fine e' un DB SQLite con un sacco di tavole e con un numero<br>
impressionante di regole e regolette formali.<br>
ma nel frattempo e' sparito qualsiasi riferimento a SpatiaLite (anzi: si<br>
e' fatto tutto quel che era materialmente possibile per garantire che<br>
GPKG e SpatiaLite non possano mai essere direttamente compatibili).<br>
addirittura anche lo Spatial Indexing e' diventato un optional previsto<br>
ma non strettamente indispensabile.<br>
last but not least: e' completamente sparito il supporto Spatial SQL,<br>
che era invece il requisito base di partenza che teneva in piedi tutta<br>
l'architettura cosi' come ipotizzata inizialmente; formalmente Spatial<br>
SQL rimane, ma solo ai livelli piu' elevati dello standard, quelli che<br>
non e' obbligatorio supportare: di fatto e' morto e sepolto.<br>
insomma, non e' piu' un formato che possa venire usato realisticamente<br>
in condizioni d'uso impegnative per gestire grandi moli di dati; ormai<br>
e' diventato un puro formato di scambio per trasferire i dati.<br>
<br>
<br>
fase 5<br>
------<br>
nel giro di pochi mesi moltissimi packages GFOSS iniziano a supportare<br>
GPKG: GDAL, GeoTools, GeoServer, OpenJump, SpatiaLite etc<br>
esiste pure una libreria FLOSS di Luciad che consente di gestire tutte<br>
le operazioni di lettura/scrittura in modo abbastanza facile e snello.<br>
buona ultima arriva ESRI che dall'estate 2014 supporta GPKG su ArcGis<br>
10.2.2 (sia server che desktop) e 10.3 (solo desktop); su Android e'<br>
supportato da ArcGis 10.2.4 runtime for Java.<br>
<br>
a questo punto tutto si puo' dire meno che GPKG soffra di supporto<br>
scarso e carente: forse e' ancora troppo presto per tirare le somme,<br>
ma se (come molti iniziano a temere) finira' per rivelarsi un flop<br>
 i motivi piu' profondi vanno ricercati proprio nella storia decisamente<br>
sofferta e molto travagliata che ha portato al rilascio della specifica<br>
finale.<br>
<br>
almeno a mio modestissima opinione personale:<br>
* l'idea iniziale dei militari (definire rigorosamente uno Spatial DBMS<br>
  universale, altamente formalizzato e capace di raffinate capacita' di<br>
  elaborazione autonome) conteneva molte idee radicalmente innovative:<br>
  poteva anche risultare attraente.<br>
* lo standard finale e' poco piu' di una "minestrina riscaldata"; ok,<br>
  sicuramente e' un ottimo formato di scambio ed e' sicuramente migliore<br>
  dei vecchi shapefiles.<br>
  ma molto difficilmente potra' mai prestarsi a rimpiazzare un vero e<br>
  proprio Spatial DBMS: sia perche' non e' abbastanza potente sia perche'<br>
  e' stato volutamente castrato dalla totale mancanza di un appropriato<br>
  supporto Spatial SQL esterno a qualsiasi specifica applicazione.<br>
* insomma, cosi' com'e' finisce per non essere ne carne ne pesce.<br>
  ed anche considerando tutte le numerose potature ed amputazioni che<br>
  ha subito durante la laboriosa messa a punto finale resta pur sempre<br>
  un attrezzo decisamente molto complesso e complicato.<br>
  purtroppo forte complessita' e scarsa potenza combinate assieme non<br>
  sembrano affatto una ricetta vincente.<br>
<br>
ciao Sandro<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
<a href="mailto:Gfoss@lists.gfoss.it" target="_blank">Gfoss@lists.gfoss.it</a><br>
<a href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss" target="_blank">http://lists.gfoss.it/cgi-bin/<u></u>mailman/listinfo/gfoss</a><br>
Questa e' una lista di discussione pubblica aperta a tutti.<br>
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.<br>
666+40 iscritti al 5.6.2014</div></div></blockquote></div><br></div>