[Gfoss] Quale formato?

[Andrea Peri]

Vediamo se riesco a comprwndere appieno.
Quindi virtualgpkg punterebbe a una fonte dati esterna.
Capisco che sia un geopackage.
Ma come mai è incompatibile a livello binario ?
Quando uso virtualshapefile ionminritrovo una tabella in cui leggo
la.geometria dentro sl.
Quando punto un geopkg io non penso invece di essere in grado di leggerla
direttamente perché vedo una funzione che converte da geometria spatialite
a geometria geopkg. Queste finzioni non le vedo per virtùalshapefile.
Sono queste differenze  che mi confondono le idee.
E poi nella lista delle funzioni non trovo dove dargli il percorso verso il
file.esterno geopkg. Forse manca la documentazione di qualche funzione ?
 Il 18/nov/2014 15:44 <a.furieri a lqt.it> ha scritto:

> 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
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20141118/326e8ba0/attachment.html>