[Gfoss] QGIS: differenze nella esportazione in shapefiles da spatialite

Gio 19 Nov 2015 01:01:15 CET

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" <aperi2007 at 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.furieri at 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20151119/4a3e6193/attachment-0001.html>