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 <[email protected]> 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.
:)
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 àèìòù
-----------------
_______________________________________________
[email protected]
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
