[Gfoss] Quale formato?

a.furieri a lqt.it a.furieri a lqt.it
Mar 18 Nov 2014 15:43:50 CET


On Tue, 18 Nov 2014 14:47:51 +0100, Andrea Peri wrote:
> Furieri me lo ha spiegato 100 volte il perche' , ma io duro come le
> pine verdi, continuo a non capire....
>

e facciamo 101 :-D


> Ecco perche' continuo a dire che di spatialite ce ne sono troppi e
> differenti tra di loro.
> Perfino spatialite stesso ha due formati differenti e incompatibli al
> suo intenro....
>
> e uno dei due non ha l'ambiente di interrogazione utile per 
> lavorarci.
> Per me e' assurdo, incomprensibile.
>
> boh.
>

SpatiaLite ha un unico ambiente di elaborazione (ed uno solo): quello
assicarato dallo Spatial SQL standard.
e SpatiaLite ha un unico layout del DB: il suo nativo, che ovviamente
evolve (leggermente) nel tempo via via che vengono introdotte nuove
funzionalita'.

pero' SQLite offre un'opzione decisamente interessante, e SpatiaLite
da parte sua cerca di sfruttarla al massimo.
basta sviluppare un apposito driver che supporti una VirtualTable per
potere operare su qualsiasi data source esterna proprio come se dal
punto di vista formale fosse una tavola nativa del DB.
ci pensa la logica interna della Virtual Table a farsi trasparentemente
carico di tutte le operazioni di conversione di formato eventualmente
richieste.

ovviamente e' una specie di camuffamento puramente cosmetico; in 
termini
funzionali e prestazionali una data source esterna per quanto camuffata
da una VirtualTable non operera' mai con la medesima efficienza offerta
da una "vera" tavola nativa.
e spesso potrebbero presentarsi ulteriori limitazioni funzionali; p.es.
molte VirtualTables lavorano in modalita' read-only e non supportano
nessun tipo di accesso in scrittura: dipende caso per caso.

SpatiaLite offre svariati drivers VirtualTable a supporto dei formati
che piu' facilmente possono risultare interessanti in ambito 
GeoSpatial:

- VirtualShape supporta l'accesso diretto agli Shapefiles (read-only)
- VirtualDBF supporta l'accesso diretto ai DBF esterni (read-only)
- VirtualXL supporta l'accesso diretto ai fogli di calcolo .xls 
(read-only)
- VirtualPostgres supporta l'accesso diretto a PostgreSQL (read/write)

addirittura esiste VirtualOGR (implementato all'interno di GDAL) che
consente accesso diretto (R+W) a circa un centinaio di formati vector.

spatialite non e' l'unico "formato" Spatial basato su SQLite; piu' o
meno da sempre esiste FDO RFC16 (utilizzato piu' che altro all'interno
del mondo Autodesk) e recentemente si e' aggiunto pure OGC-GPKG.

dal punto di visto tecnico implementare una VirtualTable per un formato
che gia' di suo e' basato su SQLite e' decisamente banale, visto che
l' "aria di famiglia" e' sempre esattamente la solita.

SpatiaLite gia' supportava in precedenza un driver VirtualFDO; ricavare
da quella base di partenza il nuovo VirtualGPKG non ha quindi richiesto
alcuno sforzo straordinario.
ed alla fine consente comunque a SpatiaLite di potere leggere e 
scrivere
direttamente *anche* il formato GPKG, ne piu' ne mano cosi' come gia'
accadeva per Shapefile, DBF, PostgreSQL, XLS, FDO etc

a me personalmente non pare affatto che questo aumenti la confusione su
quale sia il "formato vero" supportato da SpatiaLite.
GPKG e' semplicemente un ennesimo formato di scambio che viene 
supportato
accanto a numerosi altri.
ma resta pur sempre che un conto e' GPKG e tutt'altro conto e' 
SpatiaLite:
sono e restano due formati nettamente distinti e separati.

non e' che la presenza del driver VirtualShape autorizzi ad affermare 
che
"il formato di SpatiaLite si basa sugli shapefiles", cosi' come la 
presenza
di VirtualPostgres non autorizza certo a sostenere che "il formato di
SpatiaLite si basa su PostgreSQL".
non vedo quindi perche' l'introduzione di VirtualGPKG susciti tante
preoccupazioni ... e' semplicemente un ennesimo tool di import/export

ciao Sandro


Maggiori informazioni sulla lista Gfoss