[Gfoss] Quale formato?

Mar 18 Nov 2014 14:47:51 CET

eh...

pero ti manca il dettaglio piu' "ganzo".
Infatti se guardi un po' piu' a fondo scopri che spatialite e' dottor
jekill-&-mr-hide.
Infatti se vai a dare una occhiata alla lista delle funzioni di spatialit:

http://www.gaia-gis.it/gaia-sins/spatialite-sql-4.2.0.html

vedrai che ci sono delle funzioni chiamate:
gpk....

es:
gpkgCreateBaseTables

sono funzioni che a partire da un DB spatialite vuoto, lo izializzano
come fosse un geopackage. con tabelle geopackage e tutto il suo
armamentario.

DOpo di che ti ritrovi con un db sqlite che dentro e' un geopackage.
Ovvero senza l'ambiente di lavoro che te riconosci (come me del resto)
molto utile e opportuno.

Quindi , siamo a un passaggio che io ho sempre trovato incomprensibile.
Le API di spatialite che a seconda di cosa si invoca generano uno
spatialite vero e proprio oppure un geopackage.
Che bada bene non e' neanche compatibile a livellobinario con spatialite.

Misono sempre chiesto che senso avesse tenere nelle stesse API questo
doppio comportamento.
E lo ho considerato sempre foriero di grande confusione .
Perhce' se un utente si scarica la GUI di spatialite e con essa genera
un geopackage , come puo' non pensare che non stia lavorando su uno
spatialite ?
In fondo usa la GUI di spatialite (oppure la CLI, idem, stesso discorso...).

E' qui il grande casino della vicenda secondo me.
Spatialite che ha accettato al suo intenro di avere due formati , uno
noto come spatialite-patialite e l'altro che corrispinde a uno
spatialite-geopackage.

Furieri me lo ha spiegato 100 volte il perche' , ma io duro come le
pine verdi, continuo a non capire....

Ecco perche' continuo a dire che di spatialite ce ne sono troppi e
differenti tra di loro.
Perfino spatialite stesso ha due formati differenti e incompatibli al
suo intenro....

e uno dei due non ha l'ambiente di interrogazione utile per lavorarci.
Per me e' assurdo, incomprensibile.

boh.

A.

Il 18 novembre 2014 14:33, Luca Lanteri <mescal72 a gmail.com> ha scritto:
> 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
>
>
>
> _______________________________________________
> 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

-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------