[Gfoss] 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,  <a.furieri a 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 a 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.
>>> :)
>>>
>>> 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 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.
> 786 iscritti al 30.9.2015



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