Qui una proposta per uno standard OGC su un nuovo formato geospaziale che racchiude dati vettoriali, raster (con tiles)...
p.s. ma non erano già sufficienti sqlite e rasterlite?
E’ una specifica per uno standard. Spatialite e rasterlite sono potenziali implementazioni di tale standar, e magari saranno i primi a esserne compliant.
Hai notato chi c’è in vetta alla lista di chi sta contribuendo alla scrittura? 
giovanni
Il giorno 15 gennaio 2013 10:45, Luca Manganelli <luca_manganelli@comune.trento.it> ha scritto:
Qui una proposta per uno standard OGC su un nuovo formato geospaziale che racchiude dati vettoriali, raster (con tiles)…
p.s. ma non erano già sufficienti sqlite e rasterlite?
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.
630 iscritti al 1.12.2012
–
Giovanni Allegri
website: http://giovanniallegri.it
GEO+ geomatica in Italia http://bit.ly/GEOplus
On Tue, 15 Jan 2013 10:45:13 +0100, Luca Manganelli wrote:
Qui una proposta per uno standard OGC su un nuovo formato geospaziale
che racchiude dati vettoriali, raster (con tiles)...p.s. ma non erano già sufficienti sqlite e rasterlite?
ciao Luca,
la situazione sta piu' o meno in questi termini:
- sqlite e' semplicemente un motore DBMS / SQL generico
- spatialite e' la corrispondente estensione Spatial (vectors)
- rasterlite infine ti consente di caricare anche i rasters
(tiled, piramidali) nel solito DB
quindi usando sqlite+spatialite+rasterlite hai a tua disposizione
un sistema di archiviazione completo per qualsiasi categoria di
dati GeoSpatial.
ma questo e' semplicemente un livello "fisico", non e' certo
sufficiente per definire uno standard di interoperabilita' universale.
la specifica OGC GeoPackage (GPKG) parte da questo livello base
offerto da sqlite+spatialite+rasterlite (che sono le implementazioni
di riferimento dello standard), ma per cosi' dire "incapsula" tutto
quanto dentro ad una specie di contenitore universale che serve per
auto-descrivere ciascun layer in modo esteso e sofisticato ...
in soldoni si tratta di un gruppo di tavole aggiuntive che espandono
ulteriormente la possibilita' di gestire un set di metadati molto
ricco e dettagliato.
dato che la specifica OGC GeoPackage parte (per ora) con un occhio di
riguardo tutto particolare per i Mobile devices (Android etc) e per i
servizi WEB, e' inoltre necessario gestire tutte le ulteriori informazioni
che possono servire per le connessioni client-server (anche in modo
intermittente, "a singhiozzo").
quindi un GPKG non e' semplicemente un database sqlite/spatialite: deve
essere accompagnato da un Manifest XML, che serve proprio per tenere
traccia del contesto client-server che ha portato alla generazione di
quel determinato GeoPackage.
per ora GPKG si limita a definire un "formato standard" (diciamo a
spanne: qualcosa che puoi scaricare in download).
ma i piani a lungo termine di OGC gia' oggi prevedono di integrare
GPKG con i servizi web, a cominciare da WFS.
quindi in uno scenario futuribile ma non troppo, un servizio WFS
di nuova generazione potrebbe anche generare "al volo" un GPKG
completo, anziche' ritornare il canonico GML.
ed in quesi nuovi scenari il Manifest XML serve per consentire le
seguenti funzionalita':
a) una volta che il client ha ricevuto il GPKG puo' tranquillamente
chiudere la connessione e lavorare autonomamente anche in totale
assenza del supporto di rete
b) ma grazie al Manifest XML il client puo' sempre contattare il
server in un secondo momento (anche dopo giorni o settimane)
ricostruendo esattamente il contesto originario, e p.es. potrebbe
sincronizzarsi ricevendo in modo incrementale tutti gli aggiornamenti
che si fossero resi disponibili nel frattempo.
c) naturalmente funziona anche nel verso opposto: il client potrebbe
eventualmente trasferire al server tutti i dati rilevati dall'operatore
sul campo (pensa ad una sorta di WFS-T "differito")
concludendo:
- qualsiasi GPKG e' sicuramete un database spatialite/rasterlite; ma
un generico database splite non puo' essere considerato di per se
un GPKG valido. servono ulteriori informazioni, ed occorre rispettare
le regole (pedanti e minuziose) imposte dallo standard.
- dire "altrernativa allo shapefile" serve sicuramente a rendere
l'idea in modo intuitivo; ma puo' anche confondere. il GPKG e' ben piu'
ambizioso e sofisticato dei vecchi SHP (che dopo tutto, sono stati
inventati circa 30 anni fa ...)
giusto a titolo di esempio: mi risulta per certo che durante i
test preliminari sono stati prodotti alcuni GPKG con dimensioni
superiori ai 150 GB, e che contenevano centinaia di layers vettoriali
e decine di coperture raster differenti; oltre a tutti i rispettivi
metadati ISO, che in alcuni casi si spingevano fino al livello di
dettaglio della singola feature o della singole tile.
... insomma, lo scenario e' un bel po' diverso da quello del buon
vecchio SHP 
ciao Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
Grazie a Sandro per l’ottima e chiara spiegazione. Possono sembrare cose ovvie ma non è detto che lo siano e comunque non fa male ribadirle con chiarezza.
Magari scriverle, estendendole, in un qualche post / articolo (non mi sembra che manchino le opportunità …) potrebbe essere interessante ed utile per ampliare la platea degli interessati.
A presto!
Il giorno 15 gennaio 2013 11:47, <a.furieri@lqt.it> ha scritto:
On Tue, 15 Jan 2013 10:45:13 +0100, Luca Manganelli wrote:
Qui una proposta per uno standard OGC su un nuovo formato geospaziale
che racchiude dati vettoriali, raster (con tiles)…p.s. ma non erano già sufficienti sqlite e rasterlite?
ciao Luca,
la situazione sta piu’ o meno in questi termini:
- sqlite e’ semplicemente un motore DBMS / SQL generico
- spatialite e’ la corrispondente estensione Spatial (vectors)
- rasterlite infine ti consente di caricare anche i rasters
(tiled, piramidali) nel solito DBquindi usando sqlite+spatialite+rasterlite hai a tua disposizione
un sistema di archiviazione completo per qualsiasi categoria di
dati GeoSpatial.
ma questo e’ semplicemente un livello “fisico”, non e’ certo
sufficiente per definire uno standard di interoperabilita’ universale.la specifica OGC GeoPackage (GPKG) parte da questo livello base
offerto da sqlite+spatialite+rasterlite (che sono le implementazioni
di riferimento dello standard), ma per cosi’ dire “incapsula” tutto
quanto dentro ad una specie di contenitore universale che serve per
auto-descrivere ciascun layer in modo esteso e sofisticato …
in soldoni si tratta di un gruppo di tavole aggiuntive che espandono
ulteriormente la possibilita’ di gestire un set di metadati molto
ricco e dettagliato.dato che la specifica OGC GeoPackage parte (per ora) con un occhio di
riguardo tutto particolare per i Mobile devices (Android etc) e per i
servizi WEB, e’ inoltre necessario gestire tutte le ulteriori informazioni
che possono servire per le connessioni client-server (anche in modo
intermittente, “a singhiozzo”).quindi un GPKG non e’ semplicemente un database sqlite/spatialite: deve
essere accompagnato da un Manifest XML, che serve proprio per tenere
traccia del contesto client-server che ha portato alla generazione di
quel determinato GeoPackage.per ora GPKG si limita a definire un “formato standard” (diciamo a
spanne: qualcosa che puoi scaricare in download).
ma i piani a lungo termine di OGC gia’ oggi prevedono di integrare
GPKG con i servizi web, a cominciare da WFS.
quindi in uno scenario futuribile ma non troppo, un servizio WFS
di nuova generazione potrebbe anche generare “al volo” un GPKG
completo, anziche’ ritornare il canonico GML.
ed in quesi nuovi scenari il Manifest XML serve per consentire le
seguenti funzionalita’:a) una volta che il client ha ricevuto il GPKG puo’ tranquillamente
chiudere la connessione e lavorare autonomamente anche in totale
assenza del supporto di rete
b) ma grazie al Manifest XML il client puo’ sempre contattare il
server in un secondo momento (anche dopo giorni o settimane)
ricostruendo esattamente il contesto originario, e p.es. potrebbe
sincronizzarsi ricevendo in modo incrementale tutti gli aggiornamenti
che si fossero resi disponibili nel frattempo.
c) naturalmente funziona anche nel verso opposto: il client potrebbe
eventualmente trasferire al server tutti i dati rilevati dall’operatore
sul campo (pensa ad una sorta di WFS-T “differito”)concludendo:
- qualsiasi GPKG e’ sicuramete un database spatialite/rasterlite; ma
un generico database splite non puo’ essere considerato di per se
un GPKG valido. servono ulteriori informazioni, ed occorre rispettare
le regole (pedanti e minuziose) imposte dallo standard.- dire “altrernativa allo shapefile” serve sicuramente a rendere
l’idea in modo intuitivo; ma puo’ anche confondere. il GPKG e’ ben piu’
ambizioso e sofisticato dei vecchi SHP (che dopo tutto, sono stati
inventati circa 30 anni fa …)giusto a titolo di esempio: mi risulta per certo che durante i
test preliminari sono stati prodotti alcuni GPKG con dimensioni
superiori ai 150 GB, e che contenevano centinaia di layers vettoriali
e decine di coperture raster differenti; oltre a tutti i rispettivi
metadati ISO, che in alcuni casi si spingevano fino al livello di
dettaglio della singola feature o della singole tile.
… insomma, lo scenario e’ un bel po’ diverso da quello del buon
vecchio SHPciao Sandro
–
Il messaggio e’ stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e’
risultato non infetto.
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.
630 iscritti al 1.12.2012
–
Cesare Gerbino
On Tue, 15 Jan 2013 10:49:28 +0100, G. Allegri wrote:
E' una specifica per uno standard. Spatialite e rasterlite sono
potenziali implementazioni di tale standar,
anche qualcosina di piu': se il candidate standard viene approvato "as is"
spatialite e' chiaramente indicata come "reference implementation" [1]
[1] http://en.wikipedia.org/wiki/Reference_implementation
e magari saranno i primi a esserne compliant.
ci stiamo lavorando; ovvio che fino a quando la specifica non
diviene definitiva la situazione e' abbastanza mutevole
comunque i piu' avventurosi / curiosi possono gia' da subito
scaricarsi i sorgenti dal repository Fossil e provare a fare
una build specificando:
./configure --enable-geopackage=yes
sorry, ma con la documentazione siamo rimasti un po' indietro
(anche perche' e' sviluppo vivo tutt'ora in corso); in sostanza
prima si crea un DB splite "normale", e poi occorre lanciare la
funzione SQL gpkgCreateBaseTables()
alla fine vi troverete nel DB tutte le tavole extra richieste
dal GPKG, nonche' un sacco ed una sporta di nuovi triggers.
--------
nota bene: "reference implementation" non significa affatto "obbligatoria";
chiunque e' assolutamente libero di scriversi la propria personale
implementazione sw a prescindere da spatialite ... basta che rispetti
le specifiche in modo rigorosamente conforme.
in sostanza, basta svilupparsi autonomamente un qualche modulo che
sia in grado di leggere e scrivere Geometries nel formato BLOB binario
adottato da spatialite.
... e piu' o meno e' quel che sta accadendo; sembra che alcuni notissimi
produttori si stanno gia' muovendo proprio in questa direzione.
ciao Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.