Quale formato?
Locked
12
12
 
|
Nell'apportare modifiche mediante excel sul file dbf, occorre anche
fare attenzione ai character-set. Excel ignora i character-sets. Per cui temo che usando excel si rischia anche di fare mescoloni con character-set differenti nel medesimo dbf. Non riesco a fare un caso di uso che dimostri questa cosa fuori di ogni dubbio. Ma personalmente sono convinto che succede anche questo usando exel. Se qualcuno ne sa' qualcosa di piu' potrebbe spiegare per favore ? A. Il 10 novembre 2014 23:06, Marco <[hidden email]> ha scritto: > Sieradz wrote >> Premesso che le chiavi hardware viaggiavano su porta parallela (e non >> seriale) > > [OT] > OOps ...hai ragione ...parallela. > [OT] > > Sto seguendo questa bellissima e stimolante discussione su i pro e i contro > dei vari formati e > volevo inserirmi, in punta di piedi e a bassa voce, solo per rappresentare > anche l'aspetto "affettivo" della questione. > Per chi come me si è abituato alla semplicità e all'intuitività dello > shapefile (anch'io, ad esempio, trovo molto comodo poter integrare o > modificare il file dbf con un foglio elettronico, rispettando però sempre la > bidirezionalità con il file shp) sarà doloroso (anche se inevitabile) > abbandonare il mitico "uno e trino" shapefile per altri formati sicuramente > più performanti. Tutto qui. > > > > > -- > View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Quale-formato-tp7590196p7590252.html > Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com. > _______________________________________________ > [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. > 666+40 iscritti al 5.6.2014 -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
|
|
In reply to this post by Andrea Peri
On Mon, 10 Nov 2014 23:18:05 +0100, Andrea Peri wrote:
> ===== > Lista difetti dello SpatiaLite > giusto per doverosa informazione tecnica peramente oggettiva :-) > .) overhead dimensionale non trascurabile (4mb) che limita il suo > impiego quando i dati sono pochi. > mica e' vero che l'ovehead deve essere necessariamente "pesante" test 1) ------- sqlite3 pippo1.sqlite SELECT load_extension('mod_spatialite'); SELECT InitSpatialMetadata(1); .quit questa e' l'inizializzazione "by default" e carica circa 4,800 SRS dentro a "spatial_ref_sys" (cioe' tutto il dataset EPSG integrale). size: 4.75 MB test 2) ------- sqlite3 pippo2.sqlite SELECT load_extension('mod_spatialite'); SELECT InitSpatialMetadata(1, 'WGS84'); .quit questa invece e' l'inizializzazione "leggera"; dentro a "spatial_ref_sys" ci finiscono solo 130 righe, cioe' tutta la famiglia WGS84: 4326 + tutti i fusi dal 32601 fino al 32766. size: 256 KB test 3) ------- sqlite3 pippo3.sqlite SELECT load_extension('mod_spatialite'); SELECT InitSpatialMetadata(1, 'NONE'); SELECT InsertEpsgSrid(3003); .quit infine questa e' l'inizializzazione "ultra-light"; "spatial_ref_sys" viene creato ma resta assolutamente vuoto !!! a seguire, tramite una o piu' chiamate a InsertEpsgSrid() e' poi possibile inserire selettivamente solo quegli SRID che servono a quello specifico DB (nell'esempio: solomente Roma 1940 Gauss Boaga Ovest) size: 120 KB SpatiaLite mette a disposizione tutte le funzioni SQL che servono per modulare a piacere l'inizializzazione nel modo piu' flessbilie e senza nessun vincolo imposto. il fatto che ancora ad oggi nessun client / app supporti quanto e' gia' disponibile almeno da due o tre anni a questa parte non e' certo un difetto imputabile al DBMS in quanto tale. > > .) non consente la rinomina o la cancellazione di una colonna > > dif: 1 nodif: 1 > verissimo: e' un limite strutturale intrinseco dell'architettura di SQLite. e non e' neppure ipotizzabile che venga modificato in un futuro piu' o meno vicino perche' implicherebbe rivoluzionare radicamente tutta la struttura fisica di basso livello del DB-file. detto questo: anche moltissimi altri DBMS non sono minimamente capaci di modificare i nomi/tipi/vincoli delle colonne una volta che siano state create. ma aggirano elegantemente il problema "simulando" a livello puramente formale una ALTER TABLE che in effetti compie (sotto al cofano, in modo silenzioso ed invisibile) la seguente catena di operazioni: 1) attivare una transazione - BEGIN 2) modificare il nome della tavola di partenza 3) creare una nuova tavola con il vecchio nome ma sopprimendo (o modificando) le definizioni delle singole colonne cosi' come richiesto dall'utente. 4) copiare i dati dalla tavola vecchia alla nuova 5) DROP della vecchia tavola 6) consolidare la transazione - COMMIT SQLite non supporta nulla di simile: ma nulla vieta che un client o una app si implementino autonomamente una funzionalita' di questo tipo. p.es. SpatiaLite-GUI la supporta pienamente fin da tempi assai remoti. nulla vieta (almeno in teoria) che anche ulteriori client "di buona volonta'" supportino questa funzionalita' in modo del tutto trasparente (cioe' senza che l'utente neppure se ne accorga). ciao Sandro _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
|
|
In reply to this post by Andrea Peri
On Mon, 10 Nov 2014 23:21:25 +0100, Andrea Peri wrote:
> Nell'apportare modifiche mediante excel sul file dbf, occorre anche > fare attenzione ai character-set. > Excel ignora i character-sets. Per cui temo che usando excel si > rischia anche di fare mescoloni con character-set differenti nel > medesimo dbf. > > > Non riesco a fare un caso di uso che dimostri questa cosa fuori di > ogni dubbio. > Ma personalmente sono convinto che succede anche questo usando exel. > > Se qualcuno ne sa' qualcosa di piu' potrebbe spiegare per favore ? > per quanto mi risulta personalmente, tutte le versioni piu' recenti di MS Excel (Office 2007 / Office 2010) hanno definitivamente abbandonato il supporto per i DBF da quel che leggo sul WEB forse esiste qualche add-on di terze parti (ma non riesco a trovare nessuna notizia certa); comunque il supporto ufficiale Microsoft e' sicuramente cessato. le versioni precedenti immagino che usassero "by default" il charset nazionale dell'installazione base di Win, quindi in Italia dovrebbe essere sempre CP1252 aka Windows Latin-1 non metterei la mano sul fuoco per qualche PC installato nelle zone germanofone dell'Altro Adige; la magari potrebbere usare piuttosto CP1250 Windows Central Europe il miglior tool "generico" per taroccare/torturare i DBF resta a mio avviso Calc di Open/Libre Office; che almeno supporta liberamente tutti i possibili charsets senza nessun limite imposto dall'esterno. ciao Sandro _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
|
|
In reply to this post by a.furieri
Ciao Alessandro.
In effetti avevo imenticato una altro potenziale difetto di spatialite, nell'ottica di un formato di interscambio. Ce ne sono troppe versioni. :) Lo so' che e' un difetto di cui soffrono molti formati. Ma e' indubbiamente un difetto. Piccolo magari , ma lo e'. Sicuramente mitigato dal fatto che le API di spatialite (quelle ufficiali, non quelle tarocche) supportano tutte le versioni. Pero' ricordiamoci che lipotesi e l'obiettivo e' il trasporto di dati tra due sistemi. In questo caso due potenziali limit che dobbiamo capire se lo sono: il primo il poter creare un db che abbia n numero di sistemi di riferimento ridotti. Che potrebbe in teoria creare un limite al transito. Chiaramente questa vale in uno scenario in cui si ipotizza di trasportare i dati in sistemi differenti. Se lo e' o no , dipende dai punti di vista. Se spetta all'ambiente di esportazione (o di importazione) farsi carico delle trasformazioni di sistema di riferimento. Il secondo e' che evoluzioni successive del formato milgiorano determinate caratteristiche anche di precisione e di informazioni associate. Questo e' un argomento difficile e che dovrebbe essere esaminato meglio. Eventualmente oggi se ci riesco ci ritorno sopra e vedo di esploderlo meglio. Un sottocaso che pero' voglio fin da subitocitare e' quello delle geometrie compresse. So' che SL puo comprimee internamente i dati per contenere le dimensioni. Feature questa molto apprezzata (immagino) da chi lavora con i cellulari smartphone. Anche se forse lo era di piu' agli albori quando i cellulari avevano poca ram. Ora che ne hanno mediamente 32 GB non credo che cifacciano molto caso. Fatto sta che SL consente di comprimere la parte geometrica riducendo il numero di decimali. E questo temo che comporta una perdita di precisione. Al solito . si tratta di cose che se uno usa lo fa conscio di cio' che sta fancedo. Ma in una lofgica di interscambio si pensa sempre a due parti in cui l'unica coa che le collega e' il dato che si sposta da A a B e niente scambio di informazioni tra di loro. Per cui se uno pensa di comprimere un db perche' cosi lo spedisce meglio per email. Poi dall'altra parte arriva qualcosa di compresso/ridotto come precisione. A. Il 11 novembre 2014 00:11, <[hidden email]> ha scritto: > On Mon, 10 Nov 2014 23:18:05 +0100, Andrea Peri wrote: >> >> ===== >> Lista difetti dello SpatiaLite >> > > giusto per doverosa informazione tecnica peramente oggettiva :-) > >> .) overhead dimensionale non trascurabile (4mb) che limita il suo >> impiego quando i dati sono pochi. >> > > mica e' vero che l'ovehead deve essere necessariamente "pesante" > > test 1) > ------- > sqlite3 pippo1.sqlite > SELECT load_extension('mod_spatialite'); > SELECT InitSpatialMetadata(1); > .quit > > questa e' l'inizializzazione "by default" e carica circa 4,800 SRS > dentro a "spatial_ref_sys" (cioe' tutto il dataset EPSG integrale). > size: 4.75 MB > > > test 2) > ------- > sqlite3 pippo2.sqlite > SELECT load_extension('mod_spatialite'); > SELECT InitSpatialMetadata(1, 'WGS84'); > .quit > > questa invece e' l'inizializzazione "leggera"; dentro a "spatial_ref_sys" > ci finiscono solo 130 righe, cioe' tutta la famiglia WGS84: 4326 + tutti > i fusi dal 32601 fino al 32766. > size: 256 KB > > > test 3) > ------- > sqlite3 pippo3.sqlite > SELECT load_extension('mod_spatialite'); > SELECT InitSpatialMetadata(1, 'NONE'); > SELECT InsertEpsgSrid(3003); > .quit > > infine questa e' l'inizializzazione "ultra-light"; "spatial_ref_sys" > viene creato ma resta assolutamente vuoto !!! > a seguire, tramite una o piu' chiamate a InsertEpsgSrid() e' poi possibile > inserire selettivamente solo quegli SRID che servono a quello specifico > DB (nell'esempio: solomente Roma 1940 Gauss Boaga Ovest) > size: 120 KB > > > SpatiaLite mette a disposizione tutte le funzioni SQL che servono > per modulare a piacere l'inizializzazione nel modo piu' flessbilie > e senza nessun vincolo imposto. > il fatto che ancora ad oggi nessun client / app supporti quanto e' > gia' disponibile almeno da due o tre anni a questa parte non e' > certo un difetto imputabile al DBMS in quanto tale. > > >> >> .) non consente la rinomina o la cancellazione di una colonna >> >> dif: 1 nodif: 1 >> > > verissimo: e' un limite strutturale intrinseco dell'architettura di > SQLite. e non e' neppure ipotizzabile che venga modificato in un > futuro piu' o meno vicino perche' implicherebbe rivoluzionare > radicamente tutta la struttura fisica di basso livello del DB-file. > > detto questo: anche moltissimi altri DBMS non sono minimamente > capaci di modificare i nomi/tipi/vincoli delle colonne una volta > che siano state create. > ma aggirano elegantemente il problema "simulando" a livello puramente > formale una ALTER TABLE che in effetti compie (sotto al cofano, in > modo silenzioso ed invisibile) la seguente catena di operazioni: > > 1) attivare una transazione - BEGIN > 2) modificare il nome della tavola di partenza > 3) creare una nuova tavola con il vecchio nome ma sopprimendo > (o modificando) le definizioni delle singole colonne cosi' > come richiesto dall'utente. > 4) copiare i dati dalla tavola vecchia alla nuova > 5) DROP della vecchia tavola > 6) consolidare la transazione - COMMIT > > SQLite non supporta nulla di simile: ma nulla vieta che un client > o una app si implementino autonomamente una funzionalita' di questo > tipo. p.es. SpatiaLite-GUI la supporta pienamente fin da tempi > assai remoti. > nulla vieta (almeno in teoria) che anche ulteriori client "di buona > volonta'" supportino questa funzionalita' in modo del tutto > trasparente (cioe' senza che l'utente neppure se ne accorga). > > ciao Sandro > > _______________________________________________ > [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. > 666+40 iscritti al 5.6.2014 -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
|
|
In reply to this post by Luca Lanteri-3
On Mon, 10 Nov 2014 22:14:05 +0100, Luca Lanteri wrote:
> Concordo in pieno! Lo shapefile ormai dovrebbe essere messo al bando > per tutti i motivi che Andrea ha ben elencato. > > Anche per me i GeoDB al momento rimangono la migliore alternativa > perché sono quelli che offrono maggiori potenzialità. Tra tutti > Splite mi pare l'unico papabile su filesystem (ma magari mi sto > perdendo qualche altro formato che non conosco). > Di GeoPackage (che mi pare si basi fortemente su Splite) non ho ben > capito cosa lo stia tenendo fermo al palo. > Luca, la storia del GeoPackage la conosco molto da vicino, visto che a suo tempo sono stato membro del comitato OGC che ha messo a punto lo standard; e visto pure che gli unici due nomi italiani citati nel documento ufficiale OGC con le specifiche formali sono quelli di Andrea Peri e dell'umile sottoscritto. fase 1 ------ GPKG nasce a seguito di un requisito specifico dell'US Army Geospatial Center: lo scopo e' quello di definire formalmente un formato standard che consenta di veicolare cartografie molto ricche e complete sotto tutti gli aspetti. e che quindi sia in grado di memorizzare all'interno di unico contenitore monolitico sia vectors che rasters con tutti i relativi metadati ISO-19115 di accompagnamento. la tecnologia di base che viene identificata e' quella di un DBMS con pieno supporto per Spatial SQL che deve essere sempre e comunque presente anche in totale assenza di qualsiasi applicazione GIS gli scopi dei militari non sono affatto difficili da identificare: - mandare definitivamente in pensione formati storici come Shapefile, GML e GeoTIFF - svincolarsi (almeno in parte) da tutto l'armamentario GIS tradizionale - favorire la nascita' di un ecosistema GeoSpatial moderno ed allineato alle tecnologie piu' avanzate, largamente basato su terminali portatili capillarmente diffusi (p.es. Android) che siano facilmente utilizzabili direttamente sul campo anche da parte di personale poco specializzato ed in condizioni operative possibilmente molto severe. fase 2 ------ l'idea trova consensi c/o altre agenzie federali come l'U.S. National Geospatial Intelligence Agency (quelli che gesticono i satelliti spia) ed c/o altri alleati del blocco occidentale (NATO, Australia). visto che probabilmente e' un'idea potenzialmente molto appetibile anche per il mercato civile a questo punto i militari decidono di aprire il progetto alle universita', agli enti di ricerca e pure alle aziende. ed e' proprio a questo punto che GPKG finisce sotto l'ombrello OGC fase 3 ------ il comitato OGC inizia a lavorare ed in meno di un anno mette a punto lo Standard Candidate. a questo punto GPKG e' integralmente basato su SQLite e su SpatiaLite; in pratica e' uno SpatiaLite con l'aggiunta di un visibilio di nuove tavole a supporto di una metainformazione completa ed esaustiva, tutto rigidamente incasellato dentro ad una serie di specifiche formali minuziosamente formalizzate e rigorosissime. l'uso a piene mani del supporto integrato Spatial SQL e' il pilastro qualificante dell'intera architettura. fase 4 ------ a questo punto le regole OGC prevedono che lo Standard Candidate prima di ricevere l'approvazione definitiva passi attraverso tutta una serie di votazioni a maggioranza; da qui in avanti non contano piu' solo gli aspetti tecniciv, iniziano anche a pesare gli equilibri "politici". finalmente scende in campo la ben nota multinazionale che da sempre ha una posizione dominante sul mercato GIS, e che era stata completamente assente durante tutti i passaggi precedenti. il panorama si ribalta completamente nel giro di poche settimane: tutte le aziende che lavorano nel settore difesa finiscono per coalizzarsi con Big Brother, e riescono pure a farsi appoggiare da non pochi autorevoli esponenti del mondo GFOSS (sic) i militari rimangono completamente isolati a difendere SpatiaLite e lo Spatial SQL (conservano giusto l'appoggio di qualche Universita'), e finiscono regolarmente sotto in tutte le votazioni. lo Standard Candidate viene rovesciato come un calzino: quel che resta alla fine e' un DB SQLite con un sacco di tavole e con un numero impressionante di regole e regolette formali. ma nel frattempo e' sparito qualsiasi riferimento a SpatiaLite (anzi: si e' fatto tutto quel che era materialmente possibile per garantire che GPKG e SpatiaLite non possano mai essere direttamente compatibili). addirittura anche lo Spatial Indexing e' diventato un optional previsto ma non strettamente indispensabile. last but not least: e' completamente sparito il supporto Spatial SQL, che era invece il requisito base di partenza che teneva in piedi tutta l'architettura cosi' come ipotizzata inizialmente; formalmente Spatial SQL rimane, ma solo ai livelli piu' elevati dello standard, quelli che non e' obbligatorio supportare: di fatto e' morto e sepolto. insomma, non e' piu' un formato che possa venire usato realisticamente in condizioni d'uso impegnative per gestire grandi moli di dati; ormai e' diventato un puro formato di scambio per trasferire i dati. fase 5 ------ nel giro di pochi mesi moltissimi packages GFOSS iniziano a supportare GPKG: GDAL, GeoTools, GeoServer, OpenJump, SpatiaLite etc esiste pure una libreria FLOSS di Luciad che consente di gestire tutte le operazioni di lettura/scrittura in modo abbastanza facile e snello. buona ultima arriva ESRI che dall'estate 2014 supporta GPKG su ArcGis 10.2.2 (sia server che desktop) e 10.3 (solo desktop); su Android e' supportato da ArcGis 10.2.4 runtime for Java. a questo punto tutto si puo' dire meno che GPKG soffra di supporto scarso e carente: forse e' ancora troppo presto per tirare le somme, ma se (come molti iniziano a temere) finira' per rivelarsi un flop i motivi piu' profondi vanno ricercati proprio nella storia decisamente sofferta e molto travagliata che ha portato al rilascio della specifica finale. almeno a mio modestissima opinione personale: * l'idea iniziale dei militari (definire rigorosamente uno Spatial DBMS universale, altamente formalizzato e capace di raffinate capacita' di elaborazione autonome) conteneva molte idee radicalmente innovative: poteva anche risultare attraente. * lo standard finale e' poco piu' di una "minestrina riscaldata"; ok, sicuramente e' un ottimo formato di scambio ed e' sicuramente migliore dei vecchi shapefiles. ma molto difficilmente potra' mai prestarsi a rimpiazzare un vero e proprio Spatial DBMS: sia perche' non e' abbastanza potente sia perche' e' stato volutamente castrato dalla totale mancanza di un appropriato supporto Spatial SQL esterno a qualsiasi specifica applicazione. * insomma, cosi' com'e' finisce per non essere ne carne ne pesce. ed anche considerando tutte le numerose potature ed amputazioni che ha subito durante la laboriosa messa a punto finale resta pur sempre un attrezzo decisamente molto complesso e complicato. purtroppo forte complessita' e scarsa potenza combinate assieme non sembrano affatto una ricetta vincente. ciao Sandro _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Grazie Alessandro per l'interessantissimo resoconto. Il 11/11/2014 10:42, [hidden email] ha scritto: > il panorama si ribalta completamente nel giro di poche settimane: > tutte le aziende che lavorano nel settore difesa finiscono per > coalizzarsi con Big Brother, e riescono pure a farsi appoggiare da > non pochi autorevoli esponenti del mondo GFOSS (sic) Si possono fare i nomi, o almeno i cognomi? Credo sia importante. Saluti. - -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRh20MACgkQ/NedwLUzIr6xUgCeNf9k0UDVzi+DYEAxmXPGN9vN 16MAn1jBORITAxWQygGKsc2dE6oil8R7 =w3sW -----END PGP SIGNATURE----- _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
|
|
On Tue, 11 Nov 2014 10:47:48 +0100, Paolo Cavallini wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Grazie Alessandro per l'interessantissimo resoconto. > > Il 11/11/2014 10:42, [hidden email] ha scritto: > >> il panorama si ribalta completamente nel giro di poche settimane: >> tutte le aziende che lavorano nel settore difesa finiscono per >> coalizzarsi con Big Brother, e riescono pure a farsi appoggiare da >> non pochi autorevoli esponenti del mondo GFOSS (sic) > > Si possono fare i nomi, o almeno i cognomi? Credo sia importante. > visto che ormai e' passato un bel po' di tempo temo che la memoria possa giocarmi qualche brutto scherzo. ma fortunatamente tutti i nomi dei partecipanti sono riportati in modo assolutamente trasparente nel documento ufficale dello standard: http://www.geopackage.org/spec/ se non erro, in quella lista ci trovo me medesimo, Brad Hards (i due developers storici di spatialite) e l'ottimo Even Rouault di GDAL che tenne sempre un atteggiamento equlibrato e molto propositivo. ah, piu' sotto leggo anche due nomi di OpenGeo: Paul Ramsey e Chris Holmes; e non mi pare che vedessero particolarmente di buon occhio l'inclusione di splite nello standard. Chris era pure un membro votante (a differenza di tutti gli altri). comunque ad ogni buon conto, Chris ha avvertito in seguito l'esigenza di motivare pubblicamente le proprie scelte, come si puo' leggere qua: http://cholmes.wordpress.com/ ciao Sandro _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
|
|
Era meglio se se ne stava zitto. Stupenda la motivazion che spatialite no perche libera per un formato che non richiedesse per la compilazione qualche opzione particolare. E poi a che formato pensava ? Il bello è che alla fine è nato un formato che non serve a un bel niente. Complimenti signor Holmes o dovrei dire A. Il 11/nov/2014 11:19 <[hidden email]> ha scritto:
On Tue, 11 Nov 2014 10:47:48 +0100, Paolo Cavallini wrote: _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
|
|
In reply to this post by Andrea Peri
Ho aggiornato la lista dei difetti aggingendo a SL le troppe versioni
e a GeoJSON la mancanza di un accesso random (non eè un difetto usualemente per lo scambio dati, ma come difetto di per se' appare significativo e vale la pena tenerne conto in alcuni ragionamenti) --------- ----------------------------------------------- dif = "e' difetto per" nodif = "non è difetto per" ------------------------------------- Lista difetti del formato ESRI Shapefile .)non prevede l'indicazione del CharacterSet dif: 1 nodif: 0 .)e' limitato nella dimensione del record dif: 1 nodif: 0 .)limita di 10 caratteri al nome di un campo dif: 1 nodif: 0 .)non supporta geometrie complesse (solamente punti linee e poligoni, simple e multi) dif: 1 nodif: 0 .)ha un limite di 2GB per la parte alfanumerica (file dbf) dif: 1 nodif: 0 .)ha un limite di 2 GB per la parte geometrica dif: 1 nodif: 0 .)le geometrie sono in doppia-precisione (nel senso di una definizione del numeor di tipo binario ad aritmetica finita) dif: 1 nodif: 1 .)non possiede l'indicazione del NULL nei valori alfanumerici dif:1 nodif: 0 .)non ha standardizzato l'indice spaziale dif: 1 nodif: 0 .)la presenza di formati leggermene difformi sul dbf impatta anche sullo shapefile dif: 1 nodif: 0 .)la separazione fisica tra shp e dbf fa' si' che un editing separato (mediante excel ad esempio) del dbf provoca la perdita del link con la geometria corrispondente dif: 1 nodif: 1 .) mancanza di un vero formato data e time dif: 1 nodif: 1 .) manca un formato blob interno (solo esterno tramite un file acessorio) dif: 2 nodif: 0 .) la geometria non ha lo srid definito (solo un file prj esterno ma opzionale e non standardizzato) dif: 2 nodif: 0 .) la geometria non definisce in maniera chiara e inequivocabile l'exterior ring e gli holes dif: 1 nodif: 1 .) composto di 3 files distinti e indipendenti dif: 1 nodif: 1 .) il campo testo e' limitato a 255 caratteri dif: 1 nodif: 0 ===== Lista difetti del GeoJSON .) non supporta indici spaziali (poco efficiente per grandi moli di dati) dif: 2 .) non ha un accesso random al dato (spiegazione: questo non appare essere usualmente un difetto per un formato di scambio, ma potrebbe esserlo in alcuni casi limite.) ===== Lista difetti dello SpatiaLite .) overhead dimensionale non trascurabile (4mb) che limita il suo impiego quando i dati sono pochi. dif: 1 nodif: 1 .) non consente la rinomina o la cancellazione di una colonna dif: 1 nodif: 1 .) gli attuali software gis che lo supportano in scrittura (qgis only) non permettono un agevole salvataggio su di esso. dif: 1 nodif: 1 .) A giro ci sono troppe versioni. (spiegazione: sebbene le api piu' recenti consentano di leggersi i formati piu' vecchi. In uno scambio di dati non è detto che si vada da vecchio verso nuovo. Ci sono anche dei tools di trasformazione, ma questo esula dall'obiettivo di un formato di scambio che non deve richiedere ulteriori trattamenti per consentire il trasporto ei dati) dif: 2 nodif: 0 ------------- FINE (per ora). -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
|
|
Giusto una nota a valle di tutta la discussione. GeoJSON e gli altri formati testuali soffrono, a mio avviso, di un difetto ancora maggiore: che i dati sono testuali, appunto. giovanni http://tools.ietf.org/html/rfc7159.html#section-6 Il 11/nov/2014 22:02 "Andrea Peri" <[hidden email]> ha scritto:
Ho aggiornato la lista dei difetti aggingendo a SL le troppe versioni _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
|
|
Grazie giohappy per il contributo su GeoJSON.
Sospettavo una cosa di tale genere, ma conosco solo superficialmente il json e per ninete il geojson. Per cui non potevo essere sicuro della cosa. Sicuramente un forato testuale deve permettere di definire in qualche modo il character-set che e' stato impiegato per costruirlo (almeno uno se ci si vuole limitare a definire il Character-set del dataset. Meglio sarebbe poter definire un CS per ogni record. Csa che allieverebbe molto il problema del copia/incolla da fonti differenti. Quindi aggiungo l GeoJSON la mancanza di un character-set definibile. Conrocdo anche sulla pesantezza a livello di memoria. In effetti il GeoJAON se opera come il JSON (non vedrei ragioni perche' faccia differente) deve essere caricato completamente prima di poter passare al parsing e estrarre anche un solo record. Questa non è una caratteristica di accesso random. Ma bensi' e' una feature importante in un caricamento sequenziale. Ovvero se il dispositivo di destinazione non è in grado di caricare l'intero dataset tutto in un colpo solo dovrebbe potersi gestire il caricamento a pezzettoni. 1 primi 1000 records, poi i secondi 1000, e cosi' via, per gestire un caricamento sequnziale ma a pezzetti. Una cosa di tale genere e' importante in uno scambio di dati. quindi aggiungo questi due difetti alla lista. -------------------------------------- dif = "e' difetto per" nodif = "non è difetto per" ------------------------------------- Lista difetti del formato ESRI Shapefile .)non prevede l'indicazione del CharacterSet dif: 1 nodif: 0 .)e' limitato nella dimensione del record dif: 1 nodif: 0 .)limita di 10 caratteri al nome di un campo dif: 1 nodif: 0 .)non supporta geometrie complesse (solamente punti linee e poligoni, simple e multi) dif: 1 nodif: 0 .)ha un limite di 2GB per la parte alfanumerica (file dbf) dif: 1 nodif: 0 .)ha un limite di 2 GB per la parte geometrica dif: 1 nodif: 0 .)le geometrie sono in doppia-precisione (nel senso di una definizione del numeor di tipo binario ad aritmetica finita) dif: 1 nodif: 1 .)non possiede l'indicazione del NULL nei valori alfanumerici dif:1 nodif: 0 .)non ha standardizzato l'indice spaziale dif: 1 nodif: 0 .)la presenza di formati leggermene difformi sul dbf impatta anche sullo shapefile dif: 1 nodif: 0 .)la separazione fisica tra shp e dbf fa' si' che un editing separato (mediante excel ad esempio) del dbf provoca la perdita del link con la geometria corrispondente dif: 1 nodif: 1 .) mancanza di un vero formato data e time dif: 1 nodif: 1 .) manca un formato blob interno (solo esterno tramite un file acessorio) dif: 2 nodif: 0 .) la geometria non ha lo srid definito (solo un file prj esterno ma opzionale e non standardizzato) dif: 2 nodif: 0 .) la geometria non definisce in maniera chiara e inequivocabile l'exterior ring e gli holes dif: 1 nodif: 1 .) composto di 3 files distinti e indipendenti dif: 1 nodif: 1 .) il campo testo e' limitato a 255 caratteri dif: 1 nodif: 0 ===== Lista difetti del GeoJSON .) non supporta indici spaziali (poco efficiente per grandi moli di dati) dif: 2 nodif: 0 .) non ha un accesso random al dato (spiegazione: questo non appare essere usualmente un difetto per un formato di scambio, ma potrebbe esserlo in alcuni casi limite.) .) non permette di definire un Character-set (ne' a livello di dataset, ne' a livello di singolo record) dif: 2 nodif: 0 .) richiede necessariamwnte la lettura dell'intero dataset (l'intero file) prima di poterne decodificare i contenuti. dif: 2 nodif: 0 ===== Lista difetti dello SpatiaLite .) overhead dimensionale non trascurabile (4mb) che limita il suo impiego quando i dati sono pochi. dif: 1 nodif: 1 .) non consente la rinomina o la cancellazione di una colonna dif: 1 nodif: 1 .) gli attuali software gis che lo supportano in scrittura (qgis only) non permettono un agevole salvataggio su di esso. dif: 1 nodif: 1 .) A giro ci sono troppe versioni. (spiegazione: sebbene le api piu' recenti consentano di leggersi i formati piu' vecchi. In uno scambio di dati non è detto che si vada da vecchio verso nuovo. Ci sono anche dei tools di trasformazione, ma questo esula dall'obiettivo di un formato di scambio che non deve richiedere ulteriori trattamenti per consentire il trasporto ei dati) dif: 2 nodif: 0 ------------- FINE (per ora). Il 11 novembre 2014 22:36, G. Allegri <[hidden email]> ha scritto: > Giusto una nota a valle di tutta la discussione. GeoJSON e gli altri formati > testuali soffrono, a mio avviso, di un difetto ancora maggiore: che i dati > sono testuali, appunto. > A parte la conseguente pesantezza in termini di memoria richiesta, tutti i > dati numerici soffrono di problemi di interpretazione e di interoperabilità > [1]. > > giovanni > > http://tools.ietf.org/html/rfc7159.html#section-6 > -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
|
|
In reply to this post by Andrea Peri
...ooooora l'ho capita!!! ....tardi, ma l'ho capita ;-) |
|
|
In reply to this post by a.furieri
Il giorno 11 novembre 2014 00:11, <[hidden email]> ha scritto: On Mon, 10 Nov 2014 23:18:05 +0100, Andrea Peri wrote: Bella questa, no la conoscevo ! Io in genere creo i db da spatialite-gui. Posso creare un DB con tutti i SR e poi eliminare quelli che non mi servono o in questo modo si crea qualche problema ?
Assolutamente no. Come gia dicevo tempo fa un campo su cui c'è molto da fare è proprio migliorare l'integrazione di SL con i client GIS, visto che poi è la modalità di accesso di buona parte degli utenti medi. Con una buona integrazione SL potrebbe veramente diventare lo shapefile del futuro, visto che le potenzialità di un DBMS sono infinitamente più ampie.
Se ci sono relazioni con altre tavole ci possono essere problemi in questo workaround ? SQLite non supporta nulla di simile: ma nulla vieta che un client +1 ciao Sandro Grazie delle solite ottime dritte. a presto Luca
_______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
|
|
On Tue, 18 Nov 2014 09:25:45 +0100, Luca Lanteri wrote:
>> test 2) >> ------- >> sqlite3 pippo2.sqlite >> SELECT load_extension('mod_spatialite'); >> SELECT InitSpatialMetadata(1, 'WGS84'); >> .quit >> >> questa invece e' l'inizializzazione "leggera"; dentro a >> "spatial_ref_sys" >> ci finiscono solo 130 righe, cioe' tutta la famiglia WGS84: 4326 + >> tutti >> i fusi dal 32601 fino al 32766. >> size: 256 KB > > Bella questa, no la conoscevo ! > Io in genere creo i db da spatialite-gui. Posso creare un DB con > tutti > i SR e poi eliminare quelli che non mi servono o in questo modo si > crea qualche problema ? > certo che puoi eliminare tutti i CRS che non utilizzi e che non prevedi di utilizzare mai. in fondo l'effetto e' sempre il medesimo: sia che tu applichi una "inizializzazione leggera" tanto che tu faccia la classica "inizializzazione completa" e poi elimini tutti hgli SRID che non usi caschi sempre nel solito posto. magari dopo avere eliminato gli SRIDridondanti ricordati sempre di fare VACUUM per compattare fisicamente il DB-file. le conseguenze di eliminare uno o piu' CRS sono queste due qua: a) per potere creare una nuova geometria occorre che lo SRID che dichiari sia presente in "spatial_ref_sys"; se manca ti dara' un errore fatale. b) idem per la ST_Transform(): se non trova la definizione dello SRID anche questa ti da' errore. insomma, se tu sei ben sicuro che nei tuoi db-file ci andranno sempre e solo dati piemontesi, non ti serve poi a molto tenerti nel db tutti gli SRID relativi agli USA o all'oceano pacifico ;-) > .) non consente la rinomina o la cancell > >> ' un limite strutturale intrinseco dell'architettura di >> SQLite. e non e' neppure ipotizzabile che venga modificato in un >> futuro piu' o meno vicino perche' implicherebbe rivoluzionare >> radicamente tutta la struttura fisica di basso livello del DB-file. >> >> detto questo: anche moltissimi altri DBMS non sono minimamente >> capaci di modificare i nomi/tipi/vincoli delle colonne una volta >> che siano state create. >> ma aggirano elegantemente il problema "simulando" a livello >> puramente >> formale una ALTER TABLE che in effetti compie (sotto al cofano, >> in >> modo silenzioso ed invisibile) la seguente catena di operazioni: >> >> 1) attivare una transazione - BEGIN >> 2) modificare il nome della tavola di partenza >> 3) creare una nuova tavola con il vecchio nome ma sopprimendo >> (o modificando) le definizioni delle singole colonne cosi' >> come richiesto dall'utente. >> 4) copiare i dati dalla tavola vecchia alla nuova >> 5) DROP della vecchia tavola >> 6) consolidare la transazione - COMMIT >> >> Se ci sono relazioni con altre tavole ci possono essere problemi in >> questo workaround ? > certamente si: e pure se hai gia' definito qualche VIEW potrebbe saltare perche' i nomi non combaciano piu'. idem dicasi se hai definito qualche Trigger customizzato. funziona sicuramente bene nel caso di tavole semplici che non siano coinvolte in troppe ulteriori ramificazioni; nei casi piu' complessi non funziona. ciao Sandro _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
|
|
In reply to this post by a.furieri
Grazie per il dettaglio report da fonte interna! Quindi alla fine il geopackage è diventato un ibrido che alla fine a poco serve perché invece di prendere il meglio di tutto fa l'esatto contrario e perde la cosa che a me pareva più interessante, cioè il supporto geoDB. Torno a pensare che il futuro, se gestito bene, possa essere in SL in quanto uno dei formati maggiormente flessibili e completi sia per lo scambio dati che per il lavoro. Luca Il giorno 11 novembre 2014 10:42, <[hidden email]> ha scritto: On Mon, 10 Nov 2014 22:14:05 +0100, Luca Lanteri wrote: _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
|
|
eh...
pero ti manca il dettaglio piu' "ganzo". Infatti se guardi un po' piu' a fondo scopri che spatialite e' dottor jekill-&-mr-hide. Infatti se vai a dare una occhiata alla lista delle funzioni di spatialit: http://www.gaia-gis.it/gaia-sins/spatialite-sql-4.2.0.html vedrai che ci sono delle funzioni chiamate: gpk.... es: gpkgCreateBaseTables sono funzioni che a partire da un DB spatialite vuoto, lo izializzano come fosse un geopackage. con tabelle geopackage e tutto il suo armamentario. DOpo di che ti ritrovi con un db sqlite che dentro e' un geopackage. Ovvero senza l'ambiente di lavoro che te riconosci (come me del resto) molto utile e opportuno. Quindi , siamo a un passaggio che io ho sempre trovato incomprensibile. Le API di spatialite che a seconda di cosa si invoca generano uno spatialite vero e proprio oppure un geopackage. Che bada bene non e' neanche compatibile a livellobinario con spatialite. Misono sempre chiesto che senso avesse tenere nelle stesse API questo doppio comportamento. E lo ho considerato sempre foriero di grande confusione . Perhce' se un utente si scarica la GUI di spatialite e con essa genera un geopackage , come puo' non pensare che non stia lavorando su uno spatialite ? In fondo usa la GUI di spatialite (oppure la CLI, idem, stesso discorso...). E' qui il grande casino della vicenda secondo me. Spatialite che ha accettato al suo intenro di avere due formati , uno noto come spatialite-patialite e l'altro che corrispinde a uno spatialite-geopackage. Furieri me lo ha spiegato 100 volte il perche' , ma io duro come le pine verdi, continuo a non capire.... 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. A. Il 18 novembre 2014 14:33, Luca Lanteri <[hidden email]> ha scritto: > Grazie per il dettaglio report da fonte interna! > Quindi alla fine il geopackage è diventato un ibrido che alla fine a poco > serve perché invece di prendere il meglio di tutto fa l'esatto contrario e > perde la cosa che a me pareva più interessante, cioè il supporto geoDB. > > Torno a pensare che il futuro, se gestito bene, possa essere in SL in quanto > uno dei formati maggiormente flessibili e completi sia per lo scambio dati > che per il lavoro. > > Luca > > > Il giorno 11 novembre 2014 10:42, <[hidden email]> ha scritto: > >> On Mon, 10 Nov 2014 22:14:05 +0100, Luca Lanteri wrote: >>> >>> Concordo in pieno! Lo shapefile ormai dovrebbe essere messo al bando >>> per tutti i motivi che Andrea ha ben elencato. >>> >>> Anche per me i GeoDB al momento rimangono la migliore alternativa >>> perché sono quelli che offrono maggiori potenzialità. Tra tutti >>> Splite mi pare l'unico papabile su filesystem (ma magari mi sto >>> perdendo qualche altro formato che non conosco). >>> Di GeoPackage (che mi pare si basi fortemente su Splite) non ho ben >>> capito cosa lo stia tenendo fermo al palo. >>> >> >> Luca, >> >> la storia del GeoPackage la conosco molto da vicino, visto che a suo >> tempo sono stato membro del comitato OGC che ha messo a punto lo standard; >> e visto pure che gli unici due nomi italiani citati nel documento >> ufficiale OGC con le specifiche formali sono quelli di Andrea Peri e >> dell'umile sottoscritto. >> >> >> fase 1 >> ------ >> GPKG nasce a seguito di un requisito specifico dell'US Army Geospatial >> Center: lo scopo e' quello di definire formalmente un formato standard >> che consenta di veicolare cartografie molto ricche e complete sotto >> tutti gli aspetti. >> e che quindi sia in grado di memorizzare all'interno di unico contenitore >> monolitico sia vectors che rasters con tutti i relativi metadati ISO-19115 >> di accompagnamento. >> la tecnologia di base che viene identificata e' quella di un DBMS con >> pieno supporto per Spatial SQL che deve essere sempre e comunque presente >> anche in totale assenza di qualsiasi applicazione GIS >> gli scopi dei militari non sono affatto difficili da identificare: >> - mandare definitivamente in pensione formati storici come Shapefile, >> GML e GeoTIFF >> - svincolarsi (almeno in parte) da tutto l'armamentario GIS tradizionale >> - favorire la nascita' di un ecosistema GeoSpatial moderno ed allineato >> alle tecnologie piu' avanzate, largamente basato su terminali portatili >> capillarmente diffusi (p.es. Android) che siano facilmente utilizzabili >> direttamente sul campo anche da parte di personale poco specializzato >> ed in condizioni operative possibilmente molto severe. >> >> >> fase 2 >> ------ >> l'idea trova consensi c/o altre agenzie federali come l'U.S. National >> Geospatial Intelligence Agency (quelli che gesticono i satelliti spia) >> ed c/o altri alleati del blocco occidentale (NATO, Australia). >> visto che probabilmente e' un'idea potenzialmente molto appetibile anche >> per il mercato civile a questo punto i militari decidono di aprire il >> progetto alle universita', agli enti di ricerca e pure alle aziende. >> ed e' proprio a questo punto che GPKG finisce sotto l'ombrello OGC >> >> >> fase 3 >> ------ >> il comitato OGC inizia a lavorare ed in meno di un anno mette a punto >> lo Standard Candidate. >> a questo punto GPKG e' integralmente basato su SQLite e su SpatiaLite; >> in pratica e' uno SpatiaLite con l'aggiunta di un visibilio di nuove >> tavole a supporto di una metainformazione completa ed esaustiva, tutto >> rigidamente incasellato dentro ad una serie di specifiche formali >> minuziosamente formalizzate e rigorosissime. >> l'uso a piene mani del supporto integrato Spatial SQL e' il pilastro >> qualificante dell'intera architettura. >> >> >> fase 4 >> ------ >> a questo punto le regole OGC prevedono che lo Standard Candidate prima >> di ricevere l'approvazione definitiva passi attraverso tutta una serie >> di votazioni a maggioranza; da qui in avanti non contano piu' solo >> gli aspetti tecniciv, iniziano anche a pesare gli equilibri "politici". >> >> finalmente scende in campo la ben nota multinazionale che da sempre ha >> una posizione dominante sul mercato GIS, e che era stata completamente >> assente durante tutti i passaggi precedenti. >> il panorama si ribalta completamente nel giro di poche settimane: tutte >> le aziende che lavorano nel settore difesa finiscono per coalizzarsi con >> Big Brother, e riescono pure a farsi appoggiare da non pochi autorevoli >> esponenti del mondo GFOSS (sic) >> i militari rimangono completamente isolati a difendere SpatiaLite e >> lo Spatial SQL (conservano giusto l'appoggio di qualche Universita'), >> e finiscono regolarmente sotto in tutte le votazioni. >> >> lo Standard Candidate viene rovesciato come un calzino: quel che resta >> alla fine e' un DB SQLite con un sacco di tavole e con un numero >> impressionante di regole e regolette formali. >> ma nel frattempo e' sparito qualsiasi riferimento a SpatiaLite (anzi: si >> e' fatto tutto quel che era materialmente possibile per garantire che >> GPKG e SpatiaLite non possano mai essere direttamente compatibili). >> addirittura anche lo Spatial Indexing e' diventato un optional previsto >> ma non strettamente indispensabile. >> last but not least: e' completamente sparito il supporto Spatial SQL, >> che era invece il requisito base di partenza che teneva in piedi tutta >> l'architettura cosi' come ipotizzata inizialmente; formalmente Spatial >> SQL rimane, ma solo ai livelli piu' elevati dello standard, quelli che >> non e' obbligatorio supportare: di fatto e' morto e sepolto. >> insomma, non e' piu' un formato che possa venire usato realisticamente >> in condizioni d'uso impegnative per gestire grandi moli di dati; ormai >> e' diventato un puro formato di scambio per trasferire i dati. >> >> >> fase 5 >> ------ >> nel giro di pochi mesi moltissimi packages GFOSS iniziano a supportare >> GPKG: GDAL, GeoTools, GeoServer, OpenJump, SpatiaLite etc >> esiste pure una libreria FLOSS di Luciad che consente di gestire tutte >> le operazioni di lettura/scrittura in modo abbastanza facile e snello. >> buona ultima arriva ESRI che dall'estate 2014 supporta GPKG su ArcGis >> 10.2.2 (sia server che desktop) e 10.3 (solo desktop); su Android e' >> supportato da ArcGis 10.2.4 runtime for Java. >> >> a questo punto tutto si puo' dire meno che GPKG soffra di supporto >> scarso e carente: forse e' ancora troppo presto per tirare le somme, >> ma se (come molti iniziano a temere) finira' per rivelarsi un flop >> i motivi piu' profondi vanno ricercati proprio nella storia decisamente >> sofferta e molto travagliata che ha portato al rilascio della specifica >> finale. >> >> almeno a mio modestissima opinione personale: >> * l'idea iniziale dei militari (definire rigorosamente uno Spatial DBMS >> universale, altamente formalizzato e capace di raffinate capacita' di >> elaborazione autonome) conteneva molte idee radicalmente innovative: >> poteva anche risultare attraente. >> * lo standard finale e' poco piu' di una "minestrina riscaldata"; ok, >> sicuramente e' un ottimo formato di scambio ed e' sicuramente migliore >> dei vecchi shapefiles. >> ma molto difficilmente potra' mai prestarsi a rimpiazzare un vero e >> proprio Spatial DBMS: sia perche' non e' abbastanza potente sia perche' >> e' stato volutamente castrato dalla totale mancanza di un appropriato >> supporto Spatial SQL esterno a qualsiasi specifica applicazione. >> * insomma, cosi' com'e' finisce per non essere ne carne ne pesce. >> ed anche considerando tutte le numerose potature ed amputazioni che >> ha subito durante la laboriosa messa a punto finale resta pur sempre >> un attrezzo decisamente molto complesso e complicato. >> purtroppo forte complessita' e scarsa potenza combinate assieme non >> sembrano affatto una ricetta vincente. >> >> ciao Sandro >> >> >> _______________________________________________ >> [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. >> 666+40 iscritti al 5.6.2014 > > > > _______________________________________________ > [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. > 666+40 iscritti al 5.6.2014 -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
|
|
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 _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
|
|
Vediamo se riesco a comprwndere appieno. Il 18/nov/2014 15:44 <[hidden email]> ha scritto:
On Tue, 18 Nov 2014 14:47:51 +0100, Andrea Peri wrote: _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
|
|
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 _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
|
|
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 <[hidden email]>: > 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 > > _______________________________________________ > [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. > 666+40 iscritti al 5.6.2014 [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. 666+40 iscritti al 5.6.2014 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |