QGIS: differenze nella esportazione in shapefiles da spatialite

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

QGIS: differenze nella esportazione in shapefiles da spatialite

Andrea Peri
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 àèìòù
-----------------
_______________________________________________
[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.
786 iscritti al 30.9.2015
Reply | Threaded
Open this post in threaded view
|

Re: QGIS: differenze nella esportazione in shapefiles da spatialite

Andrea Peri
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 <[hidden email]> 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 àèìòù
> -----------------



--
-----------------
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.
786 iscritti al 30.9.2015
Reply | Threaded
Open this post in threaded view
|

Re: QGIS: differenze nella esportazione in shapefiles da spatialite

stefano campus
Administrator
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.
Reply | Threaded
Open this post in threaded view
|

Re: QGIS: differenze nella esportazione in shapefiles da spatialite

Andrea Peri
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 <[hidden email]> 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.
> _______________________________________________
> [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.
> 786 iscritti al 30.9.2015



--
-----------------
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.
786 iscritti al 30.9.2015
Reply | Threaded
Open this post in threaded view
|

Re: QGIS: differenze nella esportazione in shapefiles da spatialite

a.furieri
In reply to this post by Andrea Peri
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 <[hidden email]> 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 àèìòù
>> -----------------

_______________________________________________
[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.
786 iscritti al 30.9.2015
Reply | Threaded
Open this post in threaded view
|

Re: QGIS: differenze nella esportazione in shapefiles da spatialite

Andrea Peri
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,  <[hidden email]> 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 <[hidden email]> 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 àèìòù
>>> -----------------
>
>
> _______________________________________________
> [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.
> 786 iscritti al 30.9.2015



--
-----------------
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.
786 iscritti al 30.9.2015
Reply | Threaded
Open this post in threaded view
|

Re: QGIS: differenze nella esportazione in shapefiles da spatialite

mando

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" <[hidden email]> 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,  <[hidden email]> 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 <[hidden email]> 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 àèìòù
>>> -----------------
>
>
> _______________________________________________
> [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.
> 786 iscritti al 30.9.2015



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

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