[Gfoss] Differenze tra Spatialite e Geopackage

Massimiliano Moraca massimilianomoraca a gmail.com
Gio 1 Mar 2018 20:11:55 CET


Ciao Alessandro, grazie per la risposta innanzitutto.

La diatriba su FB è nata da queste mie due affermazioni presenti
nell'articolo linkato prima:
1.  In realtà questo formato è un piccolo database SQLite
2.  Essendo un database possiamo...

Mi è ben chiara la distinzione tra DB e DBMS, non mi era chiaro il fatto
che un file .sqlite fosse esso stessi già un DBMS e che, ad esempio,
SpatiaLite GUI è una "semplice" gui perchè credevo piuttosto che fosse il
DBMS. Come accade quando si fa un dump da PostGIS e lo si salva in .sql,
questo file in se non può essere gestito senza reinmetterlo in un DBMS.

Nell'articolo però io non indico che il GeoPackage può funzionare
indipendentemente dal client, forse non è ben chiaro perchè lo sottintendo,
ma sono consapevole del fatto che  il .gpkg oltre ad immagazzinare dati non
fa null'altro. Un po' come un shapefile, ma molto un po' per tutte le
limitazione di quest'ultimo.

Il gpkg nella sua duttilità nei confronti del vetusto shp racchiude tutto
quell'insieme di file accessori e non che costituiscono il formato shp.
Sarebbe quindi corretto riportare nell'articolo quanto da te scritto:
*un insieme di regole e regolette che trasformano un normalissimo DBSQLite
in un formato dati standardizzato specializzato per il GIS* ?

Il fraintendimento credo sia nato dal fatto che io quando parlo di DB
intendo un insieme di dati "fermi da qualche parte", come una serie di
raccoglitori con documenti tenuti in una cassettiera. Mentre per DBMS
intendo un software che processa quei dati e per client un software che li
visualizza. Almeno così l'avevo capita io.

Il giorno 1 marzo 2018 18:00, <a.furieri a lqt.it> ha scritto:

> On Thu, 1 Mar 2018 08:22:19 -0700 (MST), Massimiliano Moraca wrote:
>
>> Se il mio inglese non mi inganna ne deduco che il GeoPackage sia un
>> formato
>> dati si ma simile ad un DB.
>>
>>
> ciao Massimiliano,
>
> hai centrato quasi perfettamente il punto, tranne che in un piccolo
> dettaglio; non e' "un formato dati simile ad un DB", ma e' piuttosto
> un insieme di regole e regolette che trasformano un normalissimo DB
> SQLite in un formato dati standardizzato specializzato per il GIS.
>
> giusto per sgombrare il campo da possibili malintesi sulla terminologia:
> - un formato file e' semplicemente uno standard formalizzato che dice
>   come deve essere codificato un determinato tipo di contenuto.
>   ne esistono centinaia e centinaia, che spaziano tra i vari formati per
>   le immagini (Jpeg, Gif, Png etc), per i suoni (mp3, Wav, Vorbis,
> RealAudio),
>   per i documenti di testo (.doc, .docx, .odt) e cosi' via.
>   i formati file sono intrisecamente "stupidi", e richiedono sempre
>   l'intermediazione di una qualche applicazione o libreria per potere
>   essere letti o scritti.
> - un DBMS invece e' un sistema sw "intelligente", perche' e' capace di
>   supportare in modo del tutto autonomo potenti capacita' di elaborazione
>   dati senza richiedere altri strumenti esterni (dopo tutto SQL e' un
>   vero e proprio linguaggio di programmazione).
>   uno Spatial DBMS e' semplicemente un DBMS specializzato capace di
>   supportare il data-type Geometry, e quindi in grado di consentire
>   un completo Spatial Processing (elaborazione di dati geografici).
>   naturalmente e' possibile interfacciare un DBMS con una qualsiasi
>   applicazione di terze parti, ma resta il fatto che l'accesso vero e
>   proprio ai dati deve sempre necessariamente passare attraverso al
>   componente DBMS.
>
> SQLite e' un vero e proprio DBMS, ma ha la caratteristica abbastanza
> anomala che tutto un intero DB consiste semplicemente in un singolo
> file che puo' essere scambiato liberamente e facilmente anche tra
> piattaforme diverse.
> Ne consegue che se si usa SQLite applicando sempre scrupolosamente
> alcune regole chiaramente codificate, allora diventa possibile
> trasformare un DB SQLite in un vero e proprio formato file.
> ed e' esattamente questa la strada scelta da GeoPackage.
>
> tuttavia GeoPackage non puo' essere assolutamente considerato uno
> Spatial DBMS, perche' le specifiche OGC non prevedono alcuna
> estensione Spatial SQL tale da consentire lo Spatial Processing.
> per visualizzare oppure per elaborare i dati geografici contenuti
> in un GeoPackage resta assolutamente indispensabile utilizzare una
> qualche applicazione esterna.
> l'unico supporto SQL disponibile e' quello nativo di SQLite, che
> e' ovviamente inadeguato per qualsiasi tipo di Spatial Processing,
> anche del piu' rudimentale.
>
> ed e' proprio sotto questo profilo che SpatiaLite e GeoPackage si
> collocano esattamente agli antipodi, pur basandosi entrambi su
> SQLite.
> SpatiaLite e' un vero e proprio Spatial DBMS capace di supportare
> uno Spatial SQL molto completo, e quindi e' possibile fare Spatial
> Processing di alto livello utilizzando esclusivamente SpatiaLite
> senza alcun bisogno di ricorrere ad altre applicazioni (una
> caratteristica che risulta estremamente appetibile per molti
> "power users", anche qua in Italia).
>
> concludendo: SpatiaLite e GeoPackage presentano una forte
> somiglianza superficiale perche' sono entrambi basati su SQLite.
> ma a parte questo, appartengono a due categorie funzionali
> assolutamente diverse.
> uno e' semplicemente un formato file; il suo concorrente naturale
> e' il vetustissimo shapefile.
> l'altro e' uno Spatial DBMS "light" ma non per questo meno
> potente, che in non poche occasioni puo' costiture una valida
> alternativa per PostgreSQL/PostGIS o per altri Spatial DBMS di
> tipo proprietario.
>
> 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.
> 796 iscritti al 28/12/2017
>


Maggiori informazioni sulla lista Gfoss