[Gfoss] QGIS: differenze nella esportazione in shapefiles da spatialite

Local Chapters GFOSS.it
1

Salve,

ho completato i confronti che volevo fare e ho rilevato un importante
differenza che potrebbe incidere negativamente nel lavoro in casi
particolari.

Per cui riporto il caso di uso affinche' chi sia interessato trovi
aiuto in questa spiegazione.

Il caso di uso e' i seguente:

Esportazione di shapefile da uno spatialite, che a volte risulta
esseredi dimensione X (es: 700Mbytes) in altre circostanze lo stesso
shapefile sempre prodotto per esportazione dallo spatialite era di
3Gbytes.

Dopo una serie di indagini si e' scoperto che la causa e' dovuta al
software usato per tale esportazione.

La faccio breve:

se si esporta una tabella spatialite in shapefile usando la
Spatialite-GUI di spatialite si otterriene nel nostro caso uno
shapefile di 700Mbytes circa.
Mentre se si esporta la medesima tabella del medesimo spatialite
usando QGIS si ottiene uno shapefile di circa 3Gbytes.

Ilperche' e' duvoto alla dimensione dei campi.
Infatti QGIS usa gdal e gdal sembra che allochi sempre la massima dimensione.
Per cui i campi testo sono sempre di 255 caratteri, idem per i campi
numerici, e cosi' via.

Mentre la spatialite-GUI effettua sempre una indagine preventiva
misurando record per record la dimensione dei campi e allocando quindi
la miima dimensione necessaira perospitare i avalori ivi contenuti.

Tradotto in soldoni:

IL medesimo campo del medesimo record se esportato da spatialite-GUI
potrebbe essere di 1 carattere se dentro ci sta il valore "A".
Mentre il medesimo campo del medesimo record esportato da qgis si
rotrvera' smepre con il valore "A", ma in un cmapo di dimensione 255
caratteri.

Per cui potenzialmente potrebbe arrivare a essere 255 volte maggiore.
:slight_smile:

Ovviamente quesot non e' un errore.
Non ci sono ticket da aprire, perche' in certi casi e' preferibile la
minima dimensione, in altri e' preferibile la massima.

Pero' e' importante saperlo, perche' se poi a causa di questi dettalgi
lo shapefile supera i 2Gbyte, perde la compatibilita' con i softwares
ESRI e questo crea un problema, non per i professionisti che ovviamnte
gli importa il giusto di esri, ma per chi lavora nel pubblico che
vorrebbe generare degli shapefile che siano compatibili con tutti
quanti.

Il problema nasce con archivi grossi ovviamente, quanto il rischio di
sforre i 2Gbyte si fa' concreto.

A.

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

2

Avevo dimenticato un dettaglio.

Ritengo che questo prolemaci sarebbe anche con i dati esportati da
postgis/postgres.

Quando si esporta in shapefile da QGIS una tabella postgis, poiche'
viene usato sempre gdal, mi aspetto che anche in quel caso metta i
cami testo a 255 caratteri , aumentando smodatamente la dimensione
della compoennete DBF dello shapefile.

Non avendo postgis non posso provare, ma sono abbastanza convinto di questo.
Al solito come dicevo non e' un bug, ma un comportamento indotto
volutamente e quindi occorre conoscerlo e conviverci.

La differenza sarebbe che mentre con satialite abbiam un software
spatialite-gui che permette digenerare degli shapefile ai miimi
temrini, con postgres penso che analogo software non ci sia , ma qui
forse qualcuno piu' a dentro a postgis potrebbe fornire maggiori
informazioni.

A.

Il 12 novembre 2015 10:02, Andrea Peri <aperi2007@gmail.com> ha scritto:

Salve,

ho completato i confronti che volevo fare e ho rilevato un importante
differenza che potrebbe incidere negativamente nel lavoro in casi
particolari.

Per cui riporto il caso di uso affinche' chi sia interessato trovi
aiuto in questa spiegazione.

Il caso di uso e' i seguente:

Esportazione di shapefile da uno spatialite, che a volte risulta
esseredi dimensione X (es: 700Mbytes) in altre circostanze lo stesso
shapefile sempre prodotto per esportazione dallo spatialite era di
3Gbytes.

Dopo una serie di indagini si e' scoperto che la causa e' dovuta al
software usato per tale esportazione.

La faccio breve:

se si esporta una tabella spatialite in shapefile usando la
Spatialite-GUI di spatialite si otterriene nel nostro caso uno
shapefile di 700Mbytes circa.
Mentre se si esporta la medesima tabella del medesimo spatialite
usando QGIS si ottiene uno shapefile di circa 3Gbytes.

Ilperche' e' duvoto alla dimensione dei campi.
Infatti QGIS usa gdal e gdal sembra che allochi sempre la massima dimensione.
Per cui i campi testo sono sempre di 255 caratteri, idem per i campi
numerici, e cosi' via.

Mentre la spatialite-GUI effettua sempre una indagine preventiva
misurando record per record la dimensione dei campi e allocando quindi
la miima dimensione necessaira perospitare i avalori ivi contenuti.

Tradotto in soldoni:

IL medesimo campo del medesimo record se esportato da spatialite-GUI
potrebbe essere di 1 carattere se dentro ci sta il valore "A".
Mentre il medesimo campo del medesimo record esportato da qgis si
rotrvera' smepre con il valore "A", ma in un cmapo di dimensione 255
caratteri.

Per cui potenzialmente potrebbe arrivare a essere 255 volte maggiore.
:slight_smile:

Ovviamente quesot non e' un errore.
Non ci sono ticket da aprire, perche' in certi casi e' preferibile la
minima dimensione, in altri e' preferibile la massima.

Pero' e' importante saperlo, perche' se poi a causa di questi dettalgi
lo shapefile supera i 2Gbyte, perde la compatibilita' con i softwares
ESRI e questo crea un problema, non per i professionisti che ovviamnte
gli importa il giusto di esri, ma per chi lavora nel pubblico che
vorrebbe generare degli shapefile che siano compatibili con tutti
quanti.

Il problema nasce con archivi grossi ovviamente, quanto il rischio di
sforre i 2Gbyte si fa' concreto.

A.

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

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

3

grazie per questo post, andrea.
effettivamente è importante saperlo, perchè chi come noi fa anche specifiche
di produzione per professionisti (semplici tracciati record, per carità) e
poi genera anche una struttura fisica vuota, potrebbe trovarsi delle
differenze di caratteristiche dei campi.

s.

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/QGIS-differenze-nella-esportazione-in-shapefiles-da-spatialite-tp7594971p7594973.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.

4

Infatti.

E aggiungo una ulteriore considerazione per far capire quanto la
problematica sia complessa e per niente banale.

La strategia che usa lo spaitalite-gui di dimensionare lo shapefile
basandosi sul minimo spazio effettivamente necessario non sempre e'
profittevole.

Faccio un esempio:

Immagina di aver progettato una tabella con un campo CATEGORIA, di 4
caratteri massimi dove il dominio dei possibili valori e' composto da
i seguenti valori:

N
A
A1
A1B
A1BC

E dove "N" significa "informazione non disponibile"

Poi vai a riempirla, con un primo impianto e nel campo in questione ci
metti "N" perche' e' una informazione che non hai.

A questo punto se lo esporti con la spatialite-GUI per darlo a un
professionista che ti deve riempire quel campo,
il professionista si trova davanti uno shapefile con il campo
CATEGORIA diesionato con 1 solo carattere, e non potr'a mai inserirci
dentro gli altri valori del dominio.

La soluzione gdal che ovviamente mette sempre 255 caratteri
sovradimensionandolo non incorre in questo problema.

Ma pero' incorre nel problema del supero della dimensione massima
ammessa per il DBF.

Quindi sono due problemi contrastanti, che vanno tenuti presente
quando si progetta un sistema e si ha presente che i dati potrebbero
dover essere veicolati anche in shapefile.

A.

Il 12 novembre 2015 10:26, stefano campus <skampus@gmail.com> ha scritto:

grazie per questo post, andrea.
effettivamente è importante saperlo, perchè chi come noi fa anche specifiche
di produzione per professionisti (semplici tracciati record, per carità) e
poi genera anche una struttura fisica vuota, potrebbe trovarsi delle
differenze di caratteristiche dei campi.

s.

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/QGIS-differenze-nella-esportazione-in-shapefiles-da-spatialite-tp7594971p7594973.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.
_______________________________________________
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.
786 iscritti al 30.9.2015

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

5

On Thu, 12 Nov 2015 10:11:30 +0100, Andrea Peri wrote:

Avevo dimenticato un dettaglio.

Ritengo che questo prolemaci sarebbe anche con i dati esportati da
postgis/postgres.

Quando si esporta in shapefile da QGIS una tabella postgis, poiche'
viene usato sempre gdal, mi aspetto che anche in quel caso metta i
cami testo a 255 caratteri , aumentando smodatamente la dimensione
della compoennete DBF dello shapefile.
Non avendo postgis non posso provare, ma sono abbastanza convinto di questo.
Al solito come dicevo non e' un bug, ma un comportamento indotto
volutamente e quindi occorre conoscerlo e conviverci.

Andrea,

sarebbe opportuno fare una prova pratica; personalmente non sono
del tutto convinto che GDAL/PG esporti tutte le colonne testuali
lunghe 255.

notoriamente sqlite non usa datatypes "forti"; quando trovi dichiarata
una colonna TEXT potrebbe legittimamente contenere stringhe di
qualsiasi lunghezza, da 1 byte fino ad 1GB (e pure oltre, se sqlite
e' stato compilato abilitando qualche flag non-standard).
insomma, su sqlite non puoi assolutamente sapere in anticipo quale
e' la lunghezza massima reale, a meno che tu non faccia una prima
passata "preventiva" per esplorare il dataset (oppure ti appoggi
sulle statistiche, che suppergiu' ottiene lo stesso effetto).
spatialite segue sempre questa seconda strada, piu' lenta ma piu'
accurata; GDAL ed altri preferiscono andare per le spicce ed
assumono sempre una lunghezza fissa pari a 255; entrambi gli
approcci sono ragionevoli in relazione al contesto specifico
di sqlite.

invece su PostgreSQL quando trovi una colonna VARCHAR(60) sei
assolutamente certo che nessuno dei valori che incontrerai
durante il run time potra' mai superare i 60 char; e quindi
mi aspetterei che in queste condizioni GDAL crei nel DBF proprio
una colonna dimensionata per 60 ... nel contesto PG non c'e'
assolutamente nessun motivo per andare a crearne una di 255.

ciao Sandro

La differenza sarebbe che mentre con satialite abbiam un software
spatialite-gui che permette digenerare degli shapefile ai miimi
temrini, con postgres penso che analogo software non ci sia , ma qui
forse qualcuno piu' a dentro a postgis potrebbe fornire maggiori
informazioni.

A.

Il 12 novembre 2015 10:02, Andrea Peri <aperi2007@gmail.com> ha scritto:

Salve,

ho completato i confronti che volevo fare e ho rilevato un importante
differenza che potrebbe incidere negativamente nel lavoro in casi
particolari.

Per cui riporto il caso di uso affinche' chi sia interessato trovi
aiuto in questa spiegazione.

Il caso di uso e' i seguente:

Esportazione di shapefile da uno spatialite, che a volte risulta
esseredi dimensione X (es: 700Mbytes) in altre circostanze lo stesso
shapefile sempre prodotto per esportazione dallo spatialite era di
3Gbytes.

Dopo una serie di indagini si e' scoperto che la causa e' dovuta al
software usato per tale esportazione.

La faccio breve:

se si esporta una tabella spatialite in shapefile usando la
Spatialite-GUI di spatialite si otterriene nel nostro caso uno
shapefile di 700Mbytes circa.
Mentre se si esporta la medesima tabella del medesimo spatialite
usando QGIS si ottiene uno shapefile di circa 3Gbytes.

Ilperche' e' duvoto alla dimensione dei campi.
Infatti QGIS usa gdal e gdal sembra che allochi sempre la massima dimensione.
Per cui i campi testo sono sempre di 255 caratteri, idem per i campi
numerici, e cosi' via.

Mentre la spatialite-GUI effettua sempre una indagine preventiva
misurando record per record la dimensione dei campi e allocando quindi
la miima dimensione necessaira perospitare i avalori ivi contenuti.

Tradotto in soldoni:

IL medesimo campo del medesimo record se esportato da spatialite-GUI
potrebbe essere di 1 carattere se dentro ci sta il valore "A".
Mentre il medesimo campo del medesimo record esportato da qgis si
rotrvera' smepre con il valore "A", ma in un cmapo di dimensione 255
caratteri.

Per cui potenzialmente potrebbe arrivare a essere 255 volte maggiore.
:slight_smile:

Ovviamente quesot non e' un errore.
Non ci sono ticket da aprire, perche' in certi casi e' preferibile la
minima dimensione, in altri e' preferibile la massima.

Pero' e' importante saperlo, perche' se poi a causa di questi dettalgi
lo shapefile supera i 2Gbyte, perde la compatibilita' con i softwares
ESRI e questo crea un problema, non per i professionisti che ovviamnte
gli importa il giusto di esri, ma per chi lavora nel pubblico che
vorrebbe generare degli shapefile che siano compatibili con tutti
quanti.

Il problema nasce con archivi grossi ovviamente, quanto il rischio di
sforre i 2Gbyte si fa' concreto.

A.

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

6

Ciao Alessandro,

Quello che ipotizzi potrebbe essere vero, pero' ricoridamoci che su
postgres esiste anche il tipo TEXT che se ho capito bene corrisponde
proprio a un tipo di stringa a lunghezza variabile non predefinita a
priori.

Se cosi' fosse, e' piu' complicato, perche' nel caso del campo di
tipo TEXT che cosa farebbe gdal ?

Se cosi' fosse, allora il comportamento in fase di esportazione
dipenderebbe , su postgres, dal tipo di campi adottati (VARCHAR vs
TEXT)
Il che complicherebbe ulteriormente.

A.

Il 12 novembre 2015 10:41, <a.furieri@lqt.it> ha scritto:

On Thu, 12 Nov 2015 10:11:30 +0100, Andrea Peri wrote:

Avevo dimenticato un dettaglio.

Ritengo che questo prolemaci sarebbe anche con i dati esportati da
postgis/postgres.

Quando si esporta in shapefile da QGIS una tabella postgis, poiche'
viene usato sempre gdal, mi aspetto che anche in quel caso metta i
cami testo a 255 caratteri , aumentando smodatamente la dimensione
della compoennete DBF dello shapefile.
Non avendo postgis non posso provare, ma sono abbastanza convinto di
questo.
Al solito come dicevo non e' un bug, ma un comportamento indotto
volutamente e quindi occorre conoscerlo e conviverci.

Andrea,

sarebbe opportuno fare una prova pratica; personalmente non sono
del tutto convinto che GDAL/PG esporti tutte le colonne testuali
lunghe 255.

notoriamente sqlite non usa datatypes "forti"; quando trovi dichiarata
una colonna TEXT potrebbe legittimamente contenere stringhe di
qualsiasi lunghezza, da 1 byte fino ad 1GB (e pure oltre, se sqlite
e' stato compilato abilitando qualche flag non-standard).
insomma, su sqlite non puoi assolutamente sapere in anticipo quale
e' la lunghezza massima reale, a meno che tu non faccia una prima
passata "preventiva" per esplorare il dataset (oppure ti appoggi
sulle statistiche, che suppergiu' ottiene lo stesso effetto).
spatialite segue sempre questa seconda strada, piu' lenta ma piu'
accurata; GDAL ed altri preferiscono andare per le spicce ed
assumono sempre una lunghezza fissa pari a 255; entrambi gli
approcci sono ragionevoli in relazione al contesto specifico
di sqlite.

invece su PostgreSQL quando trovi una colonna VARCHAR(60) sei
assolutamente certo che nessuno dei valori che incontrerai
durante il run time potra' mai superare i 60 char; e quindi
mi aspetterei che in queste condizioni GDAL crei nel DBF proprio
una colonna dimensionata per 60 ... nel contesto PG non c'e'
assolutamente nessun motivo per andare a crearne una di 255.

ciao Sandro

La differenza sarebbe che mentre con satialite abbiam un software
spatialite-gui che permette digenerare degli shapefile ai miimi
temrini, con postgres penso che analogo software non ci sia , ma qui
forse qualcuno piu' a dentro a postgis potrebbe fornire maggiori
informazioni.

A.

Il 12 novembre 2015 10:02, Andrea Peri <aperi2007@gmail.com> ha scritto:

Salve,

ho completato i confronti che volevo fare e ho rilevato un importante
differenza che potrebbe incidere negativamente nel lavoro in casi
particolari.

Per cui riporto il caso di uso affinche' chi sia interessato trovi
aiuto in questa spiegazione.

Il caso di uso e' i seguente:

Esportazione di shapefile da uno spatialite, che a volte risulta
esseredi dimensione X (es: 700Mbytes) in altre circostanze lo stesso
shapefile sempre prodotto per esportazione dallo spatialite era di
3Gbytes.

Dopo una serie di indagini si e' scoperto che la causa e' dovuta al
software usato per tale esportazione.

La faccio breve:

se si esporta una tabella spatialite in shapefile usando la
Spatialite-GUI di spatialite si otterriene nel nostro caso uno
shapefile di 700Mbytes circa.
Mentre se si esporta la medesima tabella del medesimo spatialite
usando QGIS si ottiene uno shapefile di circa 3Gbytes.

Ilperche' e' duvoto alla dimensione dei campi.
Infatti QGIS usa gdal e gdal sembra che allochi sempre la massima
dimensione.
Per cui i campi testo sono sempre di 255 caratteri, idem per i campi
numerici, e cosi' via.

Mentre la spatialite-GUI effettua sempre una indagine preventiva
misurando record per record la dimensione dei campi e allocando quindi
la miima dimensione necessaira perospitare i avalori ivi contenuti.

Tradotto in soldoni:

IL medesimo campo del medesimo record se esportato da spatialite-GUI
potrebbe essere di 1 carattere se dentro ci sta il valore "A".
Mentre il medesimo campo del medesimo record esportato da qgis si
rotrvera' smepre con il valore "A", ma in un cmapo di dimensione 255
caratteri.

Per cui potenzialmente potrebbe arrivare a essere 255 volte maggiore.
:slight_smile:

Ovviamente quesot non e' un errore.
Non ci sono ticket da aprire, perche' in certi casi e' preferibile la
minima dimensione, in altri e' preferibile la massima.

Pero' e' importante saperlo, perche' se poi a causa di questi dettalgi
lo shapefile supera i 2Gbyte, perde la compatibilita' con i softwares
ESRI e questo crea un problema, non per i professionisti che ovviamnte
gli importa il giusto di esri, ma per chi lavora nel pubblico che
vorrebbe generare degli shapefile che siano compatibili con tutti
quanti.

Il problema nasce con archivi grossi ovviamente, quanto il rischio di
sforre i 2Gbyte si fa' concreto.

A.

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

_______________________________________________
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.
786 iscritti al 30.9.2015

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

7

scusate aggiungo qui una mia mail come reminder per seguire il post e aggiungere prove dato che io mi trovo ad usare pg, sl e shp … di medesimi layer e mi ritrovo con dati di tipo diverso a seconda dei passaggi.

Il 12/nov/2015 10:53, “Andrea Peri” <aperi2007@gmail.com> ha scritto:

Ciao Alessandro,

Quello che ipotizzi potrebbe essere vero, pero’ ricoridamoci che su
postgres esiste anche il tipo TEXT che se ho capito bene corrisponde
proprio a un tipo di stringa a lunghezza variabile non predefinita a
priori.

Se cosi’ fosse, e’ piu’ complicato, perche’ nel caso del campo di
tipo TEXT che cosa farebbe gdal ?

Se cosi’ fosse, allora il comportamento in fase di esportazione
dipenderebbe , su postgres, dal tipo di campi adottati (VARCHAR vs
TEXT)
Il che complicherebbe ulteriormente.

A.

Il 12 novembre 2015 10:41, <a.furieri@lqt.it> ha scritto:

On Thu, 12 Nov 2015 10:11:30 +0100, Andrea Peri wrote:

Avevo dimenticato un dettaglio.

Ritengo che questo prolemaci sarebbe anche con i dati esportati da
postgis/postgres.

Quando si esporta in shapefile da QGIS una tabella postgis, poiche’
viene usato sempre gdal, mi aspetto che anche in quel caso metta i
cami testo a 255 caratteri , aumentando smodatamente la dimensione
della compoennete DBF dello shapefile.
Non avendo postgis non posso provare, ma sono abbastanza convinto di
questo.
Al solito come dicevo non e’ un bug, ma un comportamento indotto
volutamente e quindi occorre conoscerlo e conviverci.

Andrea,

sarebbe opportuno fare una prova pratica; personalmente non sono
del tutto convinto che GDAL/PG esporti tutte le colonne testuali
lunghe 255.

notoriamente sqlite non usa datatypes “forti”; quando trovi dichiarata
una colonna TEXT potrebbe legittimamente contenere stringhe di
qualsiasi lunghezza, da 1 byte fino ad 1GB (e pure oltre, se sqlite
e’ stato compilato abilitando qualche flag non-standard).
insomma, su sqlite non puoi assolutamente sapere in anticipo quale
e’ la lunghezza massima reale, a meno che tu non faccia una prima
passata “preventiva” per esplorare il dataset (oppure ti appoggi
sulle statistiche, che suppergiu’ ottiene lo stesso effetto).
spatialite segue sempre questa seconda strada, piu’ lenta ma piu’
accurata; GDAL ed altri preferiscono andare per le spicce ed
assumono sempre una lunghezza fissa pari a 255; entrambi gli
approcci sono ragionevoli in relazione al contesto specifico
di sqlite.

invece su PostgreSQL quando trovi una colonna VARCHAR(60) sei
assolutamente certo che nessuno dei valori che incontrerai
durante il run time potra’ mai superare i 60 char; e quindi
mi aspetterei che in queste condizioni GDAL crei nel DBF proprio
una colonna dimensionata per 60 … nel contesto PG non c’e’
assolutamente nessun motivo per andare a crearne una di 255.

ciao Sandro

La differenza sarebbe che mentre con satialite abbiam un software
spatialite-gui che permette digenerare degli shapefile ai miimi
temrini, con postgres penso che analogo software non ci sia , ma qui
forse qualcuno piu’ a dentro a postgis potrebbe fornire maggiori
informazioni.

A.

Il 12 novembre 2015 10:02, Andrea Peri <aperi2007@gmail.com> ha scritto:

Salve,

ho completato i confronti che volevo fare e ho rilevato un importante
differenza che potrebbe incidere negativamente nel lavoro in casi
particolari.

Per cui riporto il caso di uso affinche’ chi sia interessato trovi
aiuto in questa spiegazione.

Il caso di uso e’ i seguente:

Esportazione di shapefile da uno spatialite, che a volte risulta
esseredi dimensione X (es: 700Mbytes) in altre circostanze lo stesso
shapefile sempre prodotto per esportazione dallo spatialite era di
3Gbytes.

Dopo una serie di indagini si e’ scoperto che la causa e’ dovuta al
software usato per tale esportazione.

La faccio breve:

se si esporta una tabella spatialite in shapefile usando la
Spatialite-GUI di spatialite si otterriene nel nostro caso uno
shapefile di 700Mbytes circa.
Mentre se si esporta la medesima tabella del medesimo spatialite
usando QGIS si ottiene uno shapefile di circa 3Gbytes.

Ilperche’ e’ duvoto alla dimensione dei campi.
Infatti QGIS usa gdal e gdal sembra che allochi sempre la massima
dimensione.
Per cui i campi testo sono sempre di 255 caratteri, idem per i campi
numerici, e cosi’ via.

Mentre la spatialite-GUI effettua sempre una indagine preventiva
misurando record per record la dimensione dei campi e allocando quindi
la miima dimensione necessaira perospitare i avalori ivi contenuti.

Tradotto in soldoni:

IL medesimo campo del medesimo record se esportato da spatialite-GUI
potrebbe essere di 1 carattere se dentro ci sta il valore “A”.
Mentre il medesimo campo del medesimo record esportato da qgis si
rotrvera’ smepre con il valore “A”, ma in un cmapo di dimensione 255
caratteri.

Per cui potenzialmente potrebbe arrivare a essere 255 volte maggiore.
:slight_smile:

Ovviamente quesot non e’ un errore.
Non ci sono ticket da aprire, perche’ in certi casi e’ preferibile la
minima dimensione, in altri e’ preferibile la massima.

Pero’ e’ importante saperlo, perche’ se poi a causa di questi dettalgi
lo shapefile supera i 2Gbyte, perde la compatibilita’ con i softwares
ESRI e questo crea un problema, non per i professionisti che ovviamnte
gli importa il giusto di esri, ma per chi lavora nel pubblico che
vorrebbe generare degli shapefile che siano compatibili con tutti
quanti.

Il problema nasce con archivi grossi ovviamente, quanto il rischio di
sforre i 2Gbyte si fa’ concreto.

A.

–

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

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.
786 iscritti al 30.9.2015

–

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

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.
786 iscritti al 30.9.2015