[Gfoss] Quale formato?

Andrea Peri aperi2007 a gmail.com
Mar 11 Nov 2014 07:00:33 CET


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,  <a.furieri a lqt.it> 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
>
> _______________________________________________
> Gfoss a 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



-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------


Maggiori informazioni sulla lista Gfoss