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" <aperi2...@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.furi...@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 <aperi2...@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@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
_______________________________________________ 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
