ulteriori considerazioni tecniche tra geopackage e spatilaite in un recente post di Even Rouault
http://erouault.blogspot.fr/2014/12/gdal-geopackage-raster-support.html a presto Luigi Pirelli 2014-11-18 17:06 GMT+01:00 <a.furi...@lqt.it>: > On Tue, 18 Nov 2014 16:30:31 +0100, Andrea Peri wrote: >> >> 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. >> > > funziona esattamente identico anche per GPKG: solo che in questo caso > vedrai *due* tavole; una (quella in formato GPKG) con geometrie > incomprensibili, l'altra (quella virtualizzata) che ti scodellera' > direttamente le geometrie convertite nel formato SL. > e che dal formato SL te le convertira' automaticamente nel formato > GPKG quando fai un qualche accesso che implica scrittura. > > >> 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. >> > > su SHP non ci sono perche' tanto non riuscirai mai a leggere direttamente > dal file esterno. > per GPKG sono invece supportate perche' in fondo e' un formato di scambio > standard come tanti altri. > gia' supportiamo p.es. WKB e pure l'EWKB stile PostGIS, cosi' come > supportiamo WKT, EWKT, GML, GeoJSON, KML etc > a questo punto supportiamo anche il formato BLOB di GPKG accanto > agli altri; p.es. VirtualGPKG ovviamente chiama proprio quelle API > quando converte avanti e indietro tra i due formati. > > >> 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 ? >> > > in effetti, il barbatrucco c'e' ma non si vede. > > visto che sia VirtualFDO quanto VirtualGPKG sono completamente sqlite-based, > in questo caso non e' indispensabile lavorare su un file "esterno". > il driver VirtualTable puo' tranquillamente usare una normale connessione > SQLite per effettuare tutti gli accessi fisici richiesti. > in fondo una tavola FDO o GPKG dal punto di vista SQLite e' pure sempre > una normalissima tavola. > invece dal punto di vista di SpatiaLite e' un "oggetto buffo", visto che > contiene BLOB con codifiche binarie esotiche ed e' supportata da meta-tavole > altrettanto esotiche. > > funziona tanto sulla connessione primaria quanto su di un eventuale ATTACH > DATABASE; fortunatamente le meta-informazioni supportate rispettivamente > da SpatiaLite "vero", da GPKG e da FDO sono abbastanza ben differenziate > da permettere di capire al volo quando serve rimappare tutta la struttura > sottostante in modo Virtual. > > quando stabilisci una connessione sia spatialite CLI che spatialite_gui > sono tranquillamente in grado di riconoscere se si tratta di un DB nel > formato FDO oppure GPKG. > ed in questo caso ti creano al volo tutte le VirtualTables che fanno la > mappatura automatica nel formato nativo. > > ma anche in questo caso te ne accorgi immediatamente se stai lavorando > su un DB "spatialite doc" oppure su GPKG o FDO virtualizzati. > infatti nel secondo caso tutti gli accessi devono passare esplicitamente > attraverso il supporto delle VirtualTables che fanno il mapping trasparente > tra i due formati, altrimenti non funziona nulla. > > > ciao Sandro > > _______________________________________________ > Gfoss@lists.gfoss.it > 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. > 666+40 iscritti al 5.6.2014 _______________________________________________ Gfoss@lists.gfoss.it 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. 666+40 iscritti al 5.6.2014
