Differenze tra Spatialite e Geopackage

[pierluigi de rosa-2]

Ciao a tutti,

come da oggetto non riesco bene a capire le differenze tra Geopackage e SL.
Quale è la esatta differenza tra i due?

A quanto mi sembra potrebbe essere
- SL: permette archiviazione di vettori e raster, degli stili (per chi usa
QGIS) ma ha tutte le funzioni tipiche di un geodb (geoprocessing ecc)
- Geopackage come SL tranne che per le funzioni tipiche di un geodb

Mi confermate? se si allora perchè è stato fatto il geopackage? ci deve
essere un motivo che non so
Grazie a chi mi risponderà

Pierluigi

--
Ing. Pierluigi De Rosa (PhD in Earth Science)
Contract Professor of Geographic Information System at University of Perugia
cel: 3497558268 / fax: [phone]
skype: pierluigi.derosa
_______________________________________________
[hidden email]
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.
808 iscritti al 07/03/2017

[a.furieri]

On Fri, 23 Jun 2017 12:13:31 +0200, pierluigi de rosa wrote:
> Ciao a tutti,
>
> come da oggetto non riesco bene a capire le differenze tra Geopackage
> e SL.
> Quale è la esatta differenza tra i due?
>

Ciao Pierluigi,

SpatiaLite e GeoPackage sono apparentemente molto simili
piu' che altro per un motivo.
Entrambe cercano di implementare il modello geometrico
standard OGC su base SQLite.
Ma da questa vaga ispirazione di fondo poi le due
implementazioni sono radicalmente diverse; non a caso
e' immediatamente possibile distinguere in modo facile
ed asolutamente certo i DB "stile GPKG" da quelli
"stile SpatiaLite".


> A quanto mi sembra potrebbe essere
> - SL: permette archiviazione di vettori e raster, degli stili (per
> chi usa
> QGIS) ma ha tutte le funzioni tipiche di un geodb (geoprocessing ecc)
> - Geopackage come SL tranne che per le funzioni tipiche di un geodb
>

si, hai centrato perfettamente il punto.
SpatiaLite cerce di essere un vero e proprio Spatial DBMS; cioe'
e' piu' o meno l'equivalente su base SQLite di quel che e' PostGIS
su base PostgreSQL. insomma, e' un potente strumento del tutto
autonomo che consente lo Spatial Processing di basi dati anche di
grandi dimensioni e molto complesse tramite il linguaggio SQL
con le relative estensioni Spatial.

GeoPackage invece e' semplicemente un formato di file standard
privo di qualsivoglia capacita' elaborativa autonoma.
cioe', in altri termini, puoi usare GPKG per memorizzare i tuoi
dati; ma se li vuoi elaborare devi necessariamente usare qualche
altro sw GIS-like (ESRI, QGIS o magari la stessa SpatiaLite).

andando all'osso: GPKG ambirebbe a diventare una specie di
"super-shapefile", cioe' un formato standard che consenta lo
scambio dati tra applicazioni di diversi produttori in modo
ragionevolmente sicuro ed affidabile, che pero' richiedera'
sempre un qualche altro tool per essere concretamente
usabile visto che di suo non offre nessun supporto Spatial
SQL.


> Mi confermate? se si allora perchè è stato fatto il geopackage? ci
> deve
> essere un motivo che non so
>

la storia dell''evoluzione della specifica GPKG e' tutto
sommato liscia e lineare:
- inizialmente GPKG doveva semplicemente essere SpatiaLite
   elevato al rango di standard OGC
- poi hanno iniziato a sgomitare "le grandi aziende" (indovinate
   quale in particolare) che alla fine sono riuscite ad eliminare
   uno per uno tutti i riferimenti a SpatiaLite.
- il capolavoro finale e' stata l'adozione di una codifica
   binaria per le geometrie che e' sostanzalmente analoga a
   quella gia' adottata da SpatiaLite ma che pero' e'
   volutamente incompatibile.

alla fine quello che e' rimasto nella specifica GPKG e' appunto
un "formato file" nudo e crudo volutamente privo di qualsiasi
capacita' elaborativa autonoma basata su Spatial SQL.

concludendo:
- al di la della somiglianza superficiale dovuta alla comune
   derivazione da SQLite si tratta di due oggetti assolutamente
   diversi, che servono per due scopi nettamente distinti.
- SpatiaLite e' e resta uno Spatial DBMS che offre un supporto
   esteso di tipo Spatial SQL. Puo' anche essere eventualmente
   utilizzata come formato per lo scambio dati, ma non e' certo
   quello lo scopo principale del progetto.
- GPKG rappresenta l'esatto contrario: e' un formato standard
   del tutto privo di supporto Spatial SQL, ed e' nato e pensato
   apposta per delegare tutto il supporto di elaborazione
   dentro alle varie applicazioni che decideranno di
   supportare questo nuovo formato dati (magari con lo scopo
   di pensionare finalmente l'obsoleto SHP).

ciao Sandro
_______________________________________________
[hidden email]
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.
808 iscritti al 07/03/2017

[Maurizio Trevisani]

Quindi,  in sostanza,  GPCKG è da snobbare e diffidare come un cavallo di
Troia spinto dalle multinazionali negli accampamenti del GFLOSS.

Il dispiacere che all'inizio tanti guru del software libero hanno subito il
fascino di quella operazione credendola onesta e trasparente.

Ciao,
Maurizio

Il 24/giu/2017 00:08, <[hidden email]> ha scritto:

> On Fri, 23 Jun 2017 12:13:31 +0200, pierluigi de rosa wrote:
>
>> Ciao a tutti,
>>
>> come da oggetto non riesco bene a capire le differenze tra Geopackage e
>> SL.
>> Quale è la esatta differenza tra i due?
>>
>>
> Ciao Pierluigi,
>
> SpatiaLite e GeoPackage sono apparentemente molto simili
> piu' che altro per un motivo.
> Entrambe cercano di implementare il modello geometrico
> standard OGC su base SQLite.
> Ma da questa vaga ispirazione di fondo poi le due
> implementazioni sono radicalmente diverse; non a caso
> e' immediatamente possibile distinguere in modo facile
> ed asolutamente certo i DB "stile GPKG" da quelli
> "stile SpatiaLite".
>
>
> A quanto mi sembra potrebbe essere
>> - SL: permette archiviazione di vettori e raster, degli stili (per chi usa
>> QGIS) ma ha tutte le funzioni tipiche di un geodb (geoprocessing ecc)
>> - Geopackage come SL tranne che per le funzioni tipiche di un geodb
>>
>>
> si, hai centrato perfettamente il punto.
> SpatiaLite cerce di essere un vero e proprio Spatial DBMS; cioe'
> e' piu' o meno l'equivalente su base SQLite di quel che e' PostGIS
> su base PostgreSQL. insomma, e' un potente strumento del tutto
> autonomo che consente lo Spatial Processing di basi dati anche di
> grandi dimensioni e molto complesse tramite il linguaggio SQL
> con le relative estensioni Spatial.
>
> GeoPackage invece e' semplicemente un formato di file standard
> privo di qualsivoglia capacita' elaborativa autonoma.
> cioe', in altri termini, puoi usare GPKG per memorizzare i tuoi
> dati; ma se li vuoi elaborare devi necessariamente usare qualche
> altro sw GIS-like (ESRI, QGIS o magari la stessa SpatiaLite).
>
> andando all'osso: GPKG ambirebbe a diventare una specie di
> "super-shapefile", cioe' un formato standard che consenta lo
> scambio dati tra applicazioni di diversi produttori in modo
> ragionevolmente sicuro ed affidabile, che pero' richiedera'
> sempre un qualche altro tool per essere concretamente
> usabile visto che di suo non offre nessun supporto Spatial
> SQL.
>
>
> Mi confermate? se si allora perchè è stato fatto il geopackage? ci deve
>> essere un motivo che non so
>>
>>
> la storia dell''evoluzione della specifica GPKG e' tutto
> sommato liscia e lineare:
> - inizialmente GPKG doveva semplicemente essere SpatiaLite
>   elevato al rango di standard OGC
> - poi hanno iniziato a sgomitare "le grandi aziende" (indovinate
>   quale in particolare) che alla fine sono riuscite ad eliminare
>   uno per uno tutti i riferimenti a SpatiaLite.
> - il capolavoro finale e' stata l'adozione di una codifica
>   binaria per le geometrie che e' sostanzalmente analoga a
>   quella gia' adottata da SpatiaLite ma che pero' e'
>   volutamente incompatibile.
>
> alla fine quello che e' rimasto nella specifica GPKG e' appunto
> un "formato file" nudo e crudo volutamente privo di qualsiasi
> capacita' elaborativa autonoma basata su Spatial SQL.
>
> concludendo:
> - al di la della somiglianza superficiale dovuta alla comune
>   derivazione da SQLite si tratta di due oggetti assolutamente
>   diversi, che servono per due scopi nettamente distinti.
> - SpatiaLite e' e resta uno Spatial DBMS che offre un supporto
>   esteso di tipo Spatial SQL. Puo' anche essere eventualmente
>   utilizzata come formato per lo scambio dati, ma non e' certo
>   quello lo scopo principale del progetto.
> - GPKG rappresenta l'esatto contrario: e' un formato standard
>   del tutto privo di supporto Spatial SQL, ed e' nato e pensato
>   apposta per delegare tutto il supporto di elaborazione
>   dentro alle varie applicazioni che decideranno di
>   supportare questo nuovo formato dati (magari con lo scopo
>   di pensionare finalmente l'obsoleto SHP).
>
> ciao Sandro
> _______________________________________________
> [hidden email]
> 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.
> 808 iscritti al 07/03/2017

_______________________________________________
[hidden email]
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.
808 iscritti al 07/03/2017

[pcav]

Salve,

Il 24/06/2017 08:17, Maurizio Trevisani ha scritto:
> Quindi,  in sostanza,  GPCKG è da snobbare e diffidare come un cavallo di
> Troia spinto dalle multinazionali negli accampamenti del GFLOSS.

in che modo questo può favorire le multinazionali e danneggiare il GFOSS?

grazie

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis
_______________________________________________
[hidden email]
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.
808 iscritti al 07/03/2017

[Marco]

Sei stato chiarissimo (come al solito).
Un'ultima domanda per togliermi tutti i dubbi.
Se salvo in GPKG da ArcGIS e riapro quello stesso GPKG in QGIS, gli stili e
i simboli si conservano?
(penso a tutti quegli stili e a tutta quella simbologia standard emanata
ufficialmente dai vari enti pubblici e da dover utilizzare per fini di
protezione civile, di microzonazione sismica, ecc e che, ostinatamente,
viene ancora rilasciata, da questi enti pubblici, solo in formato leggibile
per ArcGIS ...ne abbiamo parlato tante volte anche qui)

Il giorno 24 giugno 2017 00:08, <[hidden email]> ha scritto:

> On Fri, 23 Jun 2017 12:13:31 +0200, pierluigi de rosa wrote:
>
>> Ciao a tutti,
>>
>> come da oggetto non riesco bene a capire le differenze tra Geopackage e
>> SL.
>> Quale è la esatta differenza tra i due?
>>
>>
> Ciao Pierluigi,
>
> SpatiaLite e GeoPackage sono apparentemente molto simili
> piu' che altro per un motivo.
> Entrambe cercano di implementare il modello geometrico
> standard OGC su base SQLite.
> Ma da questa vaga ispirazione di fondo poi le due
> implementazioni sono radicalmente diverse; non a caso
> e' immediatamente possibile distinguere in modo facile
> ed asolutamente certo i DB "stile GPKG" da quelli
> "stile SpatiaLite".
>
>
> A quanto mi sembra potrebbe essere
>> - SL: permette archiviazione di vettori e raster, degli stili (per chi usa
>> QGIS) ma ha tutte le funzioni tipiche di un geodb (geoprocessing ecc)
>> - Geopackage come SL tranne che per le funzioni tipiche di un geodb
>>
>>
> si, hai centrato perfettamente il punto.
> SpatiaLite cerce di essere un vero e proprio Spatial DBMS; cioe'
> e' piu' o meno l'equivalente su base SQLite di quel che e' PostGIS
> su base PostgreSQL. insomma, e' un potente strumento del tutto
> autonomo che consente lo Spatial Processing di basi dati anche di
> grandi dimensioni e molto complesse tramite il linguaggio SQL
> con le relative estensioni Spatial.
>
> GeoPackage invece e' semplicemente un formato di file standard
> privo di qualsivoglia capacita' elaborativa autonoma.
> cioe', in altri termini, puoi usare GPKG per memorizzare i tuoi
> dati; ma se li vuoi elaborare devi necessariamente usare qualche
> altro sw GIS-like (ESRI, QGIS o magari la stessa SpatiaLite).
>
> andando all'osso: GPKG ambirebbe a diventare una specie di
> "super-shapefile", cioe' un formato standard che consenta lo
> scambio dati tra applicazioni di diversi produttori in modo
> ragionevolmente sicuro ed affidabile, che pero' richiedera'
> sempre un qualche altro tool per essere concretamente
> usabile visto che di suo non offre nessun supporto Spatial
> SQL.
>
>
> Mi confermate? se si allora perchè è stato fatto il geopackage? ci deve
>> essere un motivo che non so
>>
>>
> la storia dell''evoluzione della specifica GPKG e' tutto
> sommato liscia e lineare:
> - inizialmente GPKG doveva semplicemente essere SpatiaLite
>   elevato al rango di standard OGC
> - poi hanno iniziato a sgomitare "le grandi aziende" (indovinate
>   quale in particolare) che alla fine sono riuscite ad eliminare
>   uno per uno tutti i riferimenti a SpatiaLite.
> - il capolavoro finale e' stata l'adozione di una codifica
>   binaria per le geometrie che e' sostanzalmente analoga a
>   quella gia' adottata da SpatiaLite ma che pero' e'
>   volutamente incompatibile.
>
> alla fine quello che e' rimasto nella specifica GPKG e' appunto
> un "formato file" nudo e crudo volutamente privo di qualsiasi
> capacita' elaborativa autonoma basata su Spatial SQL.
>
> concludendo:
> - al di la della somiglianza superficiale dovuta alla comune
>   derivazione da SQLite si tratta di due oggetti assolutamente
>   diversi, che servono per due scopi nettamente distinti.
> - SpatiaLite e' e resta uno Spatial DBMS che offre un supporto
>   esteso di tipo Spatial SQL. Puo' anche essere eventualmente
>   utilizzata come formato per lo scambio dati, ma non e' certo
>   quello lo scopo principale del progetto.
> - GPKG rappresenta l'esatto contrario: e' un formato standard
>   del tutto privo di supporto Spatial SQL, ed e' nato e pensato
>   apposta per delegare tutto il supporto di elaborazione
>   dentro alle varie applicazioni che decideranno di
>   supportare questo nuovo formato dati (magari con lo scopo
>   di pensionare finalmente l'obsoleto SHP).
>
> ciao Sandro
> _______________________________________________
> [hidden email]
> 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.
> 808 iscritti al 07/03/2017

_______________________________________________
[hidden email]
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.
808 iscritti al 07/03/2017

[a.furieri]

On Sat, 24 Jun 2017 09:01:15 +0200, Marco Spaziani wrote:
> Sei stato chiarissimo (come al solito).
> Un'ultima domanda per togliermi tutti i dubbi.
> Se salvo in GPKG da ArcGIS e riapro quello stesso GPKG in QGIS, gli
> stili e i simboli si conservano?
>

ciao Marco,

GPKG non si preoccupa affatto di supportare gli stili e/o i simboli.
ed e' un approccio perfettamente coerente con le premesse che
abbiamo gia' visto: "formato che deve servire solo ed esclusivamente
per memorizzare i dati nudi e crudi, lasciando tutto il resto alla
libera iniziativa delle singole applicazioni, ciascuna delle quali
si regolera' come meglio crede".

se preferisci dirla con altre parole: "GPKG e' un super-SHP;
e cosi' come il buon vecchio SHP non supportava lo styling
altrettanto non lo supportera' neppure il nuovo GPKG".



> (penso a tutti quegli stili e a tutta quella simbologia standard
> emanata ufficialmente dai vari enti pubblici e da dover utilizzare
> per
> fini di protezione civile, di microzonazione sismica, ecc e che,
> ostinatamente, viene ancora rilasciata, da questi enti pubblici, solo
> in formato leggibile per ArcGIS ...ne abbiamo parlato tante volte
> anche qui)
>

SpatiaLite prova ad affrontare il problema in altro modo
(spero piu' ragionevole ed efficace):

1. tutti gli stili e tutte le risorse grafiche (fonts, bitmaps,
    simboli SVG etc) vengono memorizzate all'interno del medesimo
    database che contiene le geometrie vettoriali ed i rasters.
2. gli stili "accettabili" sono esclusivamente quelli nei
    formati XML definiti dalle specifiche OGC SLD / SE
    (e devono necessariamente passare una validazione formale
    di conformita' rispetto agli schemi XSD pubblicati da OGC
    per potere essere accettati).
3. lo Spatial SQL e' stato ulteriormente esteso fino ad
    offrire la possibilita' di ottenere tramite banali query
    SQL delle immagini-mappa (PNG, JPEC, TIFF etc) completamente
    renderizzate secondo le regole di styling pre-definite
    all'interno del database.

ovviamente stara' poi ai vari ESRI, QGIS etc decidere se e come
supportare eventualmente queste opzioni avanzate.
ma intanto tutto la tecnologia necessaria sara' gia' direttamente
supportata all'interno delle prossime versioni di libspatialite
e di librasterlite2 il cui ciclo di rilascio iniziera' nelle
prossime settimana.

ciao Sandro
_______________________________________________
[hidden email]
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.
808 iscritti al 07/03/2017

[Marco]

Grazie di nuovo per le preziosissime informazioni.

Il giorno 24 giugno 2017 10:49, <[hidden email]> ha scritto:

> On Sat, 24 Jun 2017 09:01:15 +0200, Marco Spaziani wrote:
>
>> Sei stato chiarissimo (come al solito).
>> Un'ultima domanda per togliermi tutti i dubbi.
>> Se salvo in GPKG da ArcGIS e riapro quello stesso GPKG in QGIS, gli
>> stili e i simboli si conservano?
>>
>>
> ciao Marco,
>
> GPKG non si preoccupa affatto di supportare gli stili e/o i simboli.
> ed e' un approccio perfettamente coerente con le premesse che
> abbiamo gia' visto: "formato che deve servire solo ed esclusivamente
> per memorizzare i dati nudi e crudi, lasciando tutto il resto alla
> libera iniziativa delle singole applicazioni, ciascuna delle quali
> si regolera' come meglio crede".
>
> se preferisci dirla con altre parole: "GPKG e' un super-SHP;
> e cosi' come il buon vecchio SHP non supportava lo styling
> altrettanto non lo supportera' neppure il nuovo GPKG".
>
>
>
> (penso a tutti quegli stili e a tutta quella simbologia standard
>> emanata ufficialmente dai vari enti pubblici e da dover utilizzare per
>> fini di protezione civile, di microzonazione sismica, ecc e che,
>> ostinatamente, viene ancora rilasciata, da questi enti pubblici, solo
>> in formato leggibile per ArcGIS ...ne abbiamo parlato tante volte
>> anche qui)
>>
>>
> SpatiaLite prova ad affrontare il problema in altro modo
> (spero piu' ragionevole ed efficace):
>
> 1. tutti gli stili e tutte le risorse grafiche (fonts, bitmaps,
>    simboli SVG etc) vengono memorizzate all'interno del medesimo
>    database che contiene le geometrie vettoriali ed i rasters.
> 2. gli stili "accettabili" sono esclusivamente quelli nei
>    formati XML definiti dalle specifiche OGC SLD / SE
>    (e devono necessariamente passare una validazione formale
>    di conformita' rispetto agli schemi XSD pubblicati da OGC
>    per potere essere accettati).
> 3. lo Spatial SQL e' stato ulteriormente esteso fino ad
>    offrire la possibilita' di ottenere tramite banali query
>    SQL delle immagini-mappa (PNG, JPEC, TIFF etc) completamente
>    renderizzate secondo le regole di styling pre-definite
>    all'interno del database.
>
> ovviamente stara' poi ai vari ESRI, QGIS etc decidere se e come
> supportare eventualmente queste opzioni avanzate.
> ma intanto tutto la tecnologia necessaria sara' gia' direttamente
> supportata all'interno delle prossime versioni di libspatialite
> e di librasterlite2 il cui ciclo di rilascio iniziera' nelle
> prossime settimana.
>
> ciao Sandro
>

_______________________________________________
[hidden email]
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.
808 iscritti al 07/03/2017

[nformica]

Ciao Sandro,

Leggere i tuoi post e le tue risposte é sempre un piacere, sono chiari e
completi, delle vere "lezioni".

Per tutto questo, il mio personale GRAZIE !

Saluti
Nino

Il 24 giu 2017 10:49 AM, <[hidden email]> ha scritto:

> On Sat, 24 Jun 2017 09:01:15 +0200, Marco Spaziani wrote:
>
>> Sei stato chiarissimo (come al solito).
>> Un'ultima domanda per togliermi tutti i dubbi.
>> Se salvo in GPKG da ArcGIS e riapro quello stesso GPKG in QGIS, gli
>> stili e i simboli si conservano?
>>
>>
> ciao Marco,
>
> GPKG non si preoccupa affatto di supportare gli stili e/o i simboli.
> ed e' un approccio perfettamente coerente con le premesse che
> abbiamo gia' visto: "formato che deve servire solo ed esclusivamente
> per memorizzare i dati nudi e crudi, lasciando tutto il resto alla
> libera iniziativa delle singole applicazioni, ciascuna delle quali
> si regolera' come meglio crede".
>
> se preferisci dirla con altre parole: "GPKG e' un super-SHP;
> e cosi' come il buon vecchio SHP non supportava lo styling
> altrettanto non lo supportera' neppure il nuovo GPKG".
>
>
>
> (penso a tutti quegli stili e a tutta quella simbologia standard
>> emanata ufficialmente dai vari enti pubblici e da dover utilizzare per
>> fini di protezione civile, di microzonazione sismica, ecc e che,
>> ostinatamente, viene ancora rilasciata, da questi enti pubblici, solo
>> in formato leggibile per ArcGIS ...ne abbiamo parlato tante volte
>> anche qui)
>>
>>
> SpatiaLite prova ad affrontare il problema in altro modo
> (spero piu' ragionevole ed efficace):
>
> 1. tutti gli stili e tutte le risorse grafiche (fonts, bitmaps,
>    simboli SVG etc) vengono memorizzate all'interno del medesimo
>    database che contiene le geometrie vettoriali ed i rasters.
> 2. gli stili "accettabili" sono esclusivamente quelli nei
>    formati XML definiti dalle specifiche OGC SLD / SE
>    (e devono necessariamente passare una validazione formale
>    di conformita' rispetto agli schemi XSD pubblicati da OGC
>    per potere essere accettati).
> 3. lo Spatial SQL e' stato ulteriormente esteso fino ad
>    offrire la possibilita' di ottenere tramite banali query
>    SQL delle immagini-mappa (PNG, JPEC, TIFF etc) completamente
>    renderizzate secondo le regole di styling pre-definite
>    all'interno del database.
>
> ovviamente stara' poi ai vari ESRI, QGIS etc decidere se e come
> supportare eventualmente queste opzioni avanzate.
> ma intanto tutto la tecnologia necessaria sara' gia' direttamente
> supportata all'interno delle prossime versioni di libspatialite
> e di librasterlite2 il cui ciclo di rilascio iniziera' nelle
> prossime settimana.
>
> ciao Sandro
> _______________________________________________
> [hidden email]
> 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.
> 808 iscritti al 07/03/2017

_______________________________________________
[hidden email]
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.
808 iscritti al 07/03/2017

[Massimiliano Moraca]

Salve a tutti, permettetemi questo necroposting...

Copio un paio di paragrafi che ho preso dal sito dell'OGC[0]:
______________
/A GeoPackage is an open, standards-based, platform-independent, portable,
self-describing, compact format for transferring geospatial information. The
GeoPackage standard describes a set of conventions for storing the following
within a SQLite database:

vector features
tile matrix sets of imagery and raster maps at various scales
extensions
To be clear, a GeoPackage is the SQLite container and the GeoPackage
Encoding Standard governs the rules and requirements of content stored in a
GeoPackage container. The GeoPackage standard defines the schema for a
GeoPackage, including table definitions, integrity assertions, format
limitations, and content constraints. The required and supported content of
a GeoPackage is entirely defined in the standard.

Since a GeoPackage is a database container, it supports direct use. This
means  that  data in a GeoPackage can be accessed and updated in a "native"
storage format without intermediate format translations. GeoPackages that
comply with the requirements in the standard  and do not implement
vendor-specific extensions are interoperable across all enterprise and
personal computing environments. GeoPackages are particularly useful on
mobile devices such as cell phones and tablets in communications
environments where there is limited connectivity and bandwidth. /
____________

Se il mio inglese non mi inganna ne deduco che il GeoPackage sia un formato
dati si ma simile ad un DB. Mi riferisco in particolare alla frase "/Since a
GeoPackage is a database container, it supports direct use./".

Ho pubblicato un articolo poco fa[1] proprio sul GeoPackage e vorrei avere
dei chiarimenti.

________
[0] http://www.opengeospatial.org/standards/geopackage
[1]
http://massimilianomoraca.it/blog/il-geopackage-una-valida-alternativa-al-formato-shape/

-----
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
_______________________________________________
[e-mail]
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

[a.furieri]

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
_______________________________________________
[hidden email]
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

[Massimiliano Moraca]

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, <[hidden email]> 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
>
> _______________________________________________
> [hidden email]
> 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
>

_______________________________________________
[hidden email]
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

[a.furieri]

On Thu, 1 Mar 2018 20:11:55 +0100, Massimiliano Moraca wrote:

> 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.
>
> ------------------------ <snip> ---------------------------
>
> 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.
>

Massimiliano,

quel che dici e' sostanzialmente corretto.

un DBMS e' indiscutibilmente un software; che pero' richiede
necessariamente un suo specifico spazio di storage fisico
dove memorizzare i dati  e tutte le altre meta-strutture SQL
(tavole, viste, vincoli, relazioni, indici, triggers etc) nel
modo piu' opportuno ed efficiente.

a questo punto pero' si apre un ampio ventaglio di possibili
implementazioni, tutte ugualmente valide ma tutte radicalmente
diverse l'una dall'altra.

di norma lo storage legato ai DBMS e' qualcosa di abbastanza
"misterioso ed oscuro", ed e' spesso strettamente legato ad
una versione ben precisa del DBMS.
per trasferire lo storage da una macchina all'altra, ma spesso
anche solo per passare ad una versione piu' recente, e'
indispensabile scaricare un dump che verra' successivamente
ricaricato da zero.

------------

SQLite invece adotta un'architettura radicalmente diversa;
tanto per cominciare, non e' client-server, ma e' un
"personal" DBMS, o se preferisci un "embedded" DBMS.

questo significa che tutto il DBMS (ovvero lo SQL engine)
consiste semplicemente in una libreria (libsqlite3) che
deve necessariamente venire linkata all'interno di qualche
applicazione per potere girare (spatialite_gui, QGIS o
cosa altro ti pare).

quindi quando tu dici che "SpatiaLite GUI è una 'semplice'
gui perchè credevo piuttosto che fosse il DBMS" dici una
cosa sia vera che falsa, dipende da come la prendi.

per come la vedo io Spatialite GUI e' a tutti gli effetti
una semplice GUI che si occupa solo della visualizzazione
dei dati; tutto il "lavoro sporco" viene delegato al DBMS
sottostante, che nello specifico e' rappresentato dalle
due librerie libsqlite3 e libspatialite.
il fatto che la comunicazione tra applicazione client e DBMS
avvenga direttamente in RAM all'interno di un unico processo
passando tramite API invece che attraverso una connessione
di rete e' semplicemente un dettaglio tecnico, ma non altera
la struttura dell'architettura di fondo.

ma SQLite presenta ancora un'altra grossa specificita': lo
storage consiste in un singolo file, il DB-file, che contiene
al suo interno tutto quel che serve per memorizzare i dati
e tutte le altre cianfrusaglie assortite richieste da SQL.

a questo punto lo scenario diverge radicalmente da quelli
piu' convenzionali di MySQL, PostgreSQL etc, in cui esiste
un'unica istanza del DBMS che usa un singolo spazio di
storage, piu' o meno variamente strutturato al suo interno.

su SQLite puoi avere su di un'unica macchina centinaia e
persino migliaia di DB-files completamente indipendenti
l'uno  dall'altro; e li puoi piazzare a casaccio in qualsiasi
cartella come meglio preferisci, le regole le stabilisce
liberamente l'utente, non il DBMS.
non solo: questi DB-files li puoi anche copiare "al volo"
tra macchine diverse.
e giusto per finire, su SQLite non dovrai mai fare un
dump/reload, perche' qualsiasi versione successiva di SQLite
(e di SpatiaLite) sara' sempre sicuramente in grado di leggere
correttamente tutti i DB-files creati da una qualsiasi versione
precedente.
Naturalmente nulla assicura l'inverso; non e' sempre detto
che una versione obsoleta di SQLite e/o SpatiaLite riesca a
leggere correttamente un DB-file creato da una versione
successiva.

proprio come dici tu, un DB-file in fondo e' semplicemente
"un  insieme di dati 'fermi da qualche parte', come una
serie di raccoglitori con documenti tenuti in una
cassettiera"
ma per aprire correttamente tutti i cassetti e  recuperare
tutti i documenti occorre pur sempre passare attraverso il
DBMS, cioe' occorre chiamare le API della libsqlite3.
non e' affatto importante se la libsqlite3 e' linkata dentro
a QGIS o dentro a spatialite_gui o dentro ad un programma
Python o Java; in ogni caso tutti gli accessi fisici allo
storage passeranno comunque attraverso al solito SQL engine,
quello della libsqlite3.

tornando a bomba: e' proprio qua che si registra la
principale differenza strutturale tra GeoPackage e
SpatiaLite.

- per riuscire ad aprire un GeoPackage basta la sola
   libsqlite3 e niente altro.

- invece per riuscire ad aprire un DB-file SpatiaLite
   oltre alla libsqlite3 serve pure la libspatialite,
   che a sua volta si tira dietro a catena tante altre
   librerie: libgeos, libproj e libxml2 giusto per
   citare solo le principali.

ecco cosi' spiegato perche' GeoPackage non e' in grado
di supportare uno Spatial Processing indipendente dalla
applicazione host; perche' evidentemente si e' puntato
a realizzare un data container quanto piu' semplice
possibile che non implichi troppe dipendenze.

gli obbiettivi di SpatiaLite sono esattamente opposti,
visto che si prefigge lo scopo di offrire uno vero e
proprio Spatial DBMS in grado di supportare uno Spatial
Processing quanto piu' ricco e potente che sia possibile;
anche a costo di introdurre qualche ulteriore complessita'
strutturale.

appunto come dicevo nell'altra mail; GeoPackage e
SpatiaLite non sono affatto in concorrenza.
GeoPackage e' una ragionevole alternativa ai vecchi
Shapefiles, mentre SpatiaLite e' una ragionevole
alternativa per PostGIS o per altri Spatial DBMS
quando serve utilizzare qualcosa di potente ma
"leggero".

ciao Sandro

_______________________________________________
[hidden email]
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

[Massimiliano Moraca]

Alessandro grazie mille per la spiegazione esaustiva :)

Il giorno 1 marzo 2018 23:15, <[hidden email]> ha scritto:

> On Thu, 1 Mar 2018 20:11:55 +0100, Massimiliano Moraca wrote:
>
>> 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.
>>
>> ------------------------ <snip> ---------------------------
>>
>> 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.
>>
>>
> Massimiliano,
>
> quel che dici e' sostanzialmente corretto.
>
> un DBMS e' indiscutibilmente un software; che pero' richiede
> necessariamente un suo specifico spazio di storage fisico
> dove memorizzare i dati  e tutte le altre meta-strutture SQL
> (tavole, viste, vincoli, relazioni, indici, triggers etc) nel
> modo piu' opportuno ed efficiente.
>
> a questo punto pero' si apre un ampio ventaglio di possibili
> implementazioni, tutte ugualmente valide ma tutte radicalmente
> diverse l'una dall'altra.
>
> di norma lo storage legato ai DBMS e' qualcosa di abbastanza
> "misterioso ed oscuro", ed e' spesso strettamente legato ad
> una versione ben precisa del DBMS.
> per trasferire lo storage da una macchina all'altra, ma spesso
> anche solo per passare ad una versione piu' recente, e'
> indispensabile scaricare un dump che verra' successivamente
> ricaricato da zero.
>
> ------------
>
> SQLite invece adotta un'architettura radicalmente diversa;
> tanto per cominciare, non e' client-server, ma e' un
> "personal" DBMS, o se preferisci un "embedded" DBMS.
>
> questo significa che tutto il DBMS (ovvero lo SQL engine)
> consiste semplicemente in una libreria (libsqlite3) che
> deve necessariamente venire linkata all'interno di qualche
> applicazione per potere girare (spatialite_gui, QGIS o
> cosa altro ti pare).
>
> quindi quando tu dici che "SpatiaLite GUI è una 'semplice'
> gui perchè credevo piuttosto che fosse il DBMS" dici una
> cosa sia vera che falsa, dipende da come la prendi.
>
> per come la vedo io Spatialite GUI e' a tutti gli effetti
> una semplice GUI che si occupa solo della visualizzazione
> dei dati; tutto il "lavoro sporco" viene delegato al DBMS
> sottostante, che nello specifico e' rappresentato dalle
> due librerie libsqlite3 e libspatialite.
> il fatto che la comunicazione tra applicazione client e DBMS
> avvenga direttamente in RAM all'interno di un unico processo
> passando tramite API invece che attraverso una connessione
> di rete e' semplicemente un dettaglio tecnico, ma non altera
> la struttura dell'architettura di fondo.
>
> ma SQLite presenta ancora un'altra grossa specificita': lo
> storage consiste in un singolo file, il DB-file, che contiene
> al suo interno tutto quel che serve per memorizzare i dati
> e tutte le altre cianfrusaglie assortite richieste da SQL.
>
> a questo punto lo scenario diverge radicalmente da quelli
> piu' convenzionali di MySQL, PostgreSQL etc, in cui esiste
> un'unica istanza del DBMS che usa un singolo spazio di
> storage, piu' o meno variamente strutturato al suo interno.
>
> su SQLite puoi avere su di un'unica macchina centinaia e
> persino migliaia di DB-files completamente indipendenti
> l'uno  dall'altro; e li puoi piazzare a casaccio in qualsiasi
> cartella come meglio preferisci, le regole le stabilisce
> liberamente l'utente, non il DBMS.
> non solo: questi DB-files li puoi anche copiare "al volo"
> tra macchine diverse.
> e giusto per finire, su SQLite non dovrai mai fare un
> dump/reload, perche' qualsiasi versione successiva di SQLite
> (e di SpatiaLite) sara' sempre sicuramente in grado di leggere
> correttamente tutti i DB-files creati da una qualsiasi versione
> precedente.
> Naturalmente nulla assicura l'inverso; non e' sempre detto
> che una versione obsoleta di SQLite e/o SpatiaLite riesca a
> leggere correttamente un DB-file creato da una versione
> successiva.
>
> proprio come dici tu, un DB-file in fondo e' semplicemente
> "un  insieme di dati 'fermi da qualche parte', come una
> serie di raccoglitori con documenti tenuti in una
> cassettiera"
> ma per aprire correttamente tutti i cassetti e  recuperare
> tutti i documenti occorre pur sempre passare attraverso il
> DBMS, cioe' occorre chiamare le API della libsqlite3.
> non e' affatto importante se la libsqlite3 e' linkata dentro
> a QGIS o dentro a spatialite_gui o dentro ad un programma
> Python o Java; in ogni caso tutti gli accessi fisici allo
> storage passeranno comunque attraverso al solito SQL engine,
> quello della libsqlite3.
>
> tornando a bomba: e' proprio qua che si registra la
> principale differenza strutturale tra GeoPackage e
> SpatiaLite.
>
> - per riuscire ad aprire un GeoPackage basta la sola
>   libsqlite3 e niente altro.
>
> - invece per riuscire ad aprire un DB-file SpatiaLite
>   oltre alla libsqlite3 serve pure la libspatialite,
>   che a sua volta si tira dietro a catena tante altre
>   librerie: libgeos, libproj e libxml2 giusto per
>   citare solo le principali.
>
> ecco cosi' spiegato perche' GeoPackage non e' in grado
> di supportare uno Spatial Processing indipendente dalla
> applicazione host; perche' evidentemente si e' puntato
> a realizzare un data container quanto piu' semplice
> possibile che non implichi troppe dipendenze.
>
> gli obbiettivi di SpatiaLite sono esattamente opposti,
> visto che si prefigge lo scopo di offrire uno vero e
> proprio Spatial DBMS in grado di supportare uno Spatial
> Processing quanto piu' ricco e potente che sia possibile;
> anche a costo di introdurre qualche ulteriore complessita'
> strutturale.
>
> appunto come dicevo nell'altra mail; GeoPackage e
> SpatiaLite non sono affatto in concorrenza.
> GeoPackage e' una ragionevole alternativa ai vecchi
> Shapefiles, mentre SpatiaLite e' una ragionevole
> alternativa per PostGIS o per altri Spatial DBMS
> quando serve utilizzare qualcosa di potente ma
> "leggero".
>
> ciao Sandro
>
>

_______________________________________________
[hidden email]
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