[Gfoss] Una nuova alternativa allo shapefile?

Mar 15 Gen 2013 12:07:11 CET

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 a 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)...
>>
>>
>> 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.
>
> ______________________________**_________________
> Gfoss a lists.gfoss.it
> 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
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20130115/88830c04/attachment.html>