QGIS: differenze nella esportazione in shapefiles da spatialite
Locked
QGIS: differenze nella esportazione in shapefiles da spatialite
 
|
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 |
Re: QGIS: differenze nella esportazione in shapefiles da spatialite
|
|
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 |
Re: QGIS: differenze nella esportazione in shapefiles da spatialite
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. |
Re: QGIS: differenze nella esportazione in shapefiles da spatialite
|
|
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 |
|
|
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 |
Re: QGIS: differenze nella esportazione in shapefiles da spatialite
|
|
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 |
|
|
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, _______________________________________________ [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 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |