Una nuova alternativa allo shapefile?
Locked
Una nuova alternativa allo shapefile?
 
|
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 p.s. ma non erano già sufficienti sqlite e rasterlite? _______________________________________________ [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. 630 iscritti al 1.12.2012 |
|
|
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 <[hidden email]> ha scritto: Qui una proposta per uno standard OGC su un nuovo formato geospaziale che racchiude dati vettoriali, raster (con tiles)... Giovanni Allegri website: http://giovanniallegri.it _______________________________________________ [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. 630 iscritti al 1.12.2012 |
|
|
In reply to this post by Luca Manganelli
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 > > 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. _______________________________________________ [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. 630 iscritti al 1.12.2012 |
Re: Una nuova alternativa allo shapefile?
|
|
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, <[hidden email]> ha scritto: On Tue, 15 Jan 2013 10:45:13 +0100, Luca Manganelli wrote: -- Cesare Gerbino _______________________________________________ [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. 630 iscritti al 1.12.2012 |
|
|
In reply to this post by giohappy
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. _______________________________________________ [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. 630 iscritti al 1.12.2012 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |