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.furi...@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@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 >
_______________________________________________ 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. 666+40 iscritti al 5.6.2014
