<p dir="ltr">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. </p>
<div class="gmail_quote">Il 12/nov/2015 10:53, "Andrea Peri" <<a href="mailto:aperi2007@gmail.com">aperi2007@gmail.com</a>> ha scritto:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ciao Alessandro,<br>
<br>
Quello che ipotizzi potrebbe essere vero, pero' ricoridamoci che su<br>
postgres esiste anche il tipo TEXT che se ho capito bene corrisponde<br>
proprio a un tipo di stringa a lunghezza variabile non predefinita a<br>
priori.<br>
<br>
Se cosi' fosse,  e' piu' complicato, perche' nel caso del campo di<br>
tipo TEXT che cosa farebbe gdal ?<br>
<br>
Se cosi' fosse, allora il comportamento in fase di esportazione<br>
dipenderebbe , su postgres, dal tipo di campi adottati (VARCHAR vs<br>
TEXT)<br>
Il che complicherebbe ulteriormente.<br>
<br>
<br>
A.<br>
<br>
<br>
Il 12 novembre 2015 10:41,  <<a href="mailto:a.furieri@lqt.it">a.furieri@lqt.it</a>> ha scritto:<br>
> On Thu, 12 Nov 2015 10:11:30 +0100, Andrea Peri wrote:<br>
>><br>
>> Avevo dimenticato un dettaglio.<br>
>><br>
>> Ritengo che questo prolemaci sarebbe anche con i dati esportati da<br>
>> postgis/postgres.<br>
>><br>
>> Quando si esporta in shapefile da QGIS una tabella postgis, poiche'<br>
>> viene usato sempre gdal, mi aspetto che anche in quel caso metta i<br>
>> cami testo a 255 caratteri , aumentando smodatamente la dimensione<br>
>> della compoennete DBF dello shapefile.<br>
>> Non avendo postgis non posso provare, ma sono abbastanza convinto di<br>
>> questo.<br>
>> Al solito come dicevo non e' un bug, ma un comportamento indotto<br>
>> volutamente e quindi occorre conoscerlo e conviverci.<br>
>><br>
>><br>
><br>
> Andrea,<br>
><br>
> sarebbe opportuno fare una prova pratica; personalmente non sono<br>
> del tutto convinto che GDAL/PG esporti tutte le colonne testuali<br>
> lunghe 255.<br>
><br>
> notoriamente sqlite non usa datatypes "forti"; quando trovi dichiarata<br>
> una colonna TEXT potrebbe legittimamente contenere stringhe di<br>
> qualsiasi lunghezza, da 1 byte fino ad 1GB (e pure oltre, se sqlite<br>
> e' stato compilato abilitando qualche flag non-standard).<br>
> insomma, su sqlite non puoi assolutamente sapere in anticipo quale<br>
> e' la lunghezza massima reale, a meno che tu non faccia una prima<br>
> passata "preventiva" per esplorare il dataset (oppure ti appoggi<br>
> sulle statistiche, che suppergiu' ottiene lo stesso effetto).<br>
> spatialite segue sempre questa seconda strada, piu' lenta ma piu'<br>
> accurata; GDAL ed altri preferiscono andare per le spicce ed<br>
> assumono sempre una lunghezza fissa pari a 255; entrambi gli<br>
> approcci sono ragionevoli in relazione al contesto specifico<br>
> di sqlite.<br>
><br>
> invece su PostgreSQL quando trovi una colonna VARCHAR(60) sei<br>
> assolutamente certo che nessuno dei valori che incontrerai<br>
> durante il run time potra' mai superare i 60 char; e quindi<br>
> mi aspetterei che in queste condizioni GDAL crei nel DBF proprio<br>
> una colonna dimensionata per 60 ... nel contesto PG non c'e'<br>
> assolutamente nessun motivo per andare a crearne una di 255.<br>
><br>
> ciao Sandro<br>
><br>
><br>
><br>
>> La differenza sarebbe che mentre con satialite abbiam un software<br>
>> spatialite-gui che permette digenerare degli shapefile ai miimi<br>
>> temrini, con postgres penso che analogo software non ci sia , ma qui<br>
>> forse qualcuno piu' a dentro a postgis potrebbe fornire maggiori<br>
>> informazioni.<br>
>><br>
>> A.<br>
>><br>
>><br>
>> Il 12 novembre 2015 10:02, Andrea Peri <<a href="mailto:aperi2007@gmail.com">aperi2007@gmail.com</a>> ha scritto:<br>
>>><br>
>>> Salve,<br>
>>><br>
>>> ho completato i confronti che volevo fare e ho rilevato un importante<br>
>>> differenza che potrebbe incidere negativamente nel lavoro in casi<br>
>>> particolari.<br>
>>><br>
>>> Per cui riporto il caso di uso affinche' chi sia interessato trovi<br>
>>> aiuto in questa spiegazione.<br>
>>><br>
>>> Il caso di uso e' i seguente:<br>
>>><br>
>>> Esportazione di shapefile da uno spatialite, che a volte risulta<br>
>>> esseredi dimensione X (es: 700Mbytes) in altre circostanze lo stesso<br>
>>> shapefile sempre prodotto per esportazione dallo spatialite era di<br>
>>> 3Gbytes.<br>
>>><br>
>>><br>
>>> Dopo una serie di indagini si e' scoperto che la causa e' dovuta al<br>
>>> software usato per tale esportazione.<br>
>>><br>
>>> La faccio breve:<br>
>>><br>
>>> se si esporta una tabella spatialite in shapefile usando la<br>
>>> Spatialite-GUI di spatialite si otterriene nel nostro caso uno<br>
>>> shapefile di 700Mbytes circa.<br>
>>> Mentre se si esporta la medesima tabella del medesimo spatialite<br>
>>> usando QGIS si ottiene uno shapefile di circa 3Gbytes.<br>
>>><br>
>>> Ilperche' e' duvoto alla dimensione dei campi.<br>
>>> Infatti QGIS usa gdal e gdal sembra che allochi sempre la massima<br>
>>> dimensione.<br>
>>> Per cui i campi testo sono sempre di 255 caratteri, idem per i campi<br>
>>> numerici, e cosi' via.<br>
>>><br>
>>> Mentre la spatialite-GUI effettua sempre una indagine preventiva<br>
>>> misurando record per record la dimensione dei campi e allocando quindi<br>
>>> la miima dimensione necessaira perospitare i avalori ivi contenuti.<br>
>>><br>
>>> Tradotto in soldoni:<br>
>>><br>
>>> IL medesimo campo del medesimo record se esportato da spatialite-GUI<br>
>>> potrebbe essere di 1 carattere se dentro ci sta il valore "A".<br>
>>> Mentre il medesimo campo del medesimo record esportato da qgis si<br>
>>> rotrvera' smepre con il valore "A", ma in un cmapo di dimensione 255<br>
>>> caratteri.<br>
>>><br>
>>> Per cui potenzialmente potrebbe arrivare a essere 255 volte maggiore.<br>
>>> :)<br>
>>><br>
>>> Ovviamente quesot non e' un errore.<br>
>>> Non ci sono ticket da aprire, perche' in certi casi e' preferibile la<br>
>>> minima dimensione, in altri e' preferibile la massima.<br>
>>><br>
>>> Pero' e' importante saperlo, perche' se poi a causa di questi dettalgi<br>
>>> lo shapefile supera i 2Gbyte, perde la compatibilita' con i softwares<br>
>>> ESRI e questo crea un problema, non per i professionisti che ovviamnte<br>
>>> gli importa il giusto di esri, ma per chi lavora nel pubblico che<br>
>>> vorrebbe generare degli shapefile che siano compatibili con tutti<br>
>>> quanti.<br>
>>><br>
>>> Il problema nasce con archivi grossi ovviamente, quanto il rischio di<br>
>>> sforre i 2Gbyte si fa' concreto.<br>
>>><br>
>>> A.<br>
>>><br>
>>> --<br>
>>> -----------------<br>
>>> Andrea Peri<br>
>>> . . . . . . . . .<br>
>>> qwerty àèìòù<br>
>>> -----------------<br>
><br>
><br>
> _______________________________________________<br>
> <a href="mailto:Gfoss@lists.gfoss.it">Gfoss@lists.gfoss.it</a><br>
> <a href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss" rel="noreferrer" target="_blank">http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss</a><br>
> Questa e' una lista di discussione pubblica aperta a tutti.<br>
> I messaggi di questa lista non hanno relazione diretta con le posizioni<br>
> dell'Associazione GFOSS.it.<br>
> 786 iscritti al 30.9.2015<br>
<br>
<br>
<br>
--<br>
-----------------<br>
Andrea Peri<br>
. . . . . . . . .<br>
qwerty àèìòù<br>
-----------------<br>
_______________________________________________<br>
<a href="mailto:Gfoss@lists.gfoss.it">Gfoss@lists.gfoss.it</a><br>
<a href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss" rel="noreferrer" target="_blank">http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss</a><br>
Questa e' una lista di discussione pubblica aperta a tutti.<br>
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.<br>
786 iscritti al 30.9.2015</blockquote></div>