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, <[email protected]> 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)... >> >> >> http://slashgeo.org/2012/12/**21/OGC-Draft-GeoPackage-** >> Specification-Finally-**Shapefile-Format-Replacement<http://slashgeo.org/2012/12/21/OGC-Draft-GeoPackage-Specification-Finally-Shapefile-Format-Replacement> >> >> 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 :-D > > ciao Sandro > > -- > Il messaggio e' stato analizzato alla ricerca di virus o > contenuti pericolosi da MailScanner, ed e' > risultato non infetto. > > ______________________________**_________________ > [email protected] > http://lists.gfoss.it/cgi-bin/**mailman/listinfo/gfoss<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
_______________________________________________ [email protected] 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
