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, <[email protected]> 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 <[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 -- ----------------- 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
