Totò, giustamente dice “Quando si lavora con molti shapefile, prima o poi, nasce l’esigenza di utilizzare un database spatialite per evitare, quanto meno, il numero esagerato di file e lavorare con uno solo.”
La domanda che mi (vi) pongo ora è questa. A sentimento, sulla base della vostra esperienza empirica e lavorativa, qual’è la soglia, il “limite” di shape file oltre la quale è conveniente lavorare con un DB spatialite piuttosto che un classico Progetto QGIS?
Vi chiedo questo perchè io lavoro, senza alcun problema, con Progetti di QGIS contenenti mediamente non meno di una decina di shape file (layer vettoriali) più svariati layer raster, ma non di rado arrivo anche al doppio e, in ogni caso, non ho nessun problema ne in fase di processing ne di analisi spaziale e/o numerica fra i vari layer (sia vettoriali che raster) ne tantomeno in fase di editing e stampa (grazie al magico Compositore di stampe e ad Atlas).
Intuisco però, pur non essendone un “praticante”, che l’uso del DB Spatialite fornisce delle potenzialità e delle capacità di gestione dei dati che con un progetto di QGIS non si possono neanche immaginare.
La “question” è questa. Per andare da Roma a Milano in autostrada, prendereste un trattore o una BMW ultimo modello? Per andare, in aperta campagna, dal campo di grano al campo di mais passando per il pantano delle ranocchie, prendereste il trattore o una BMW ultimo modello? …insomma, …secondo voi, qual’è il limite di “dati spaziali” da dover gestire (shape file) per cui diventa conveniente abbandonare il buon Progetto QGIS e migrare su un DB Spatialite?
Una precisazione.
Ovviamente, lavorare in QGIS con un DB Spatialite non significa non utilizzare un Progetto.
Temo di aver usato impropriamente il termine Progetto
Nel mio post di prima per Progetto intendevo l’uso “sfuso”, semplice e banale, di decine di shape file, incolonnati come layer nella TOC, contrapposto all’uso “smart” di un DB Spatialite che racoglie in un unico file tutte le tabelle della multitudine di shape file di prima.
Diciamo che forse il termine Progetto che ho usato in precedenza è veramente inappropriato e fuorviante, …ma l’importante è che ci siamo capiti
Totò, giustamente dice “Quando si lavora con molti shapefile, prima o poi, nasce l’esigenza di utilizzare un database spatialite per evitare, quanto meno, il numero esagerato di file e lavorare con uno solo.”
La domanda che mi (vi) pongo ora è questa. A sentimento, sulla base della vostra esperienza empirica e lavorativa, qual’è la soglia, il “limite” di shape file oltre la quale è conveniente lavorare con un DB spatialite piuttosto che un classico Progetto QGIS?
Vi chiedo questo perchè io lavoro, senza alcun problema, con Progetti di QGIS contenenti mediamente non meno di una decina di shape file (layer vettoriali) più svariati layer raster, ma non di rado arrivo anche al doppio e, in ogni caso, non ho nessun problema ne in fase di processing ne di analisi spaziale e/o numerica fra i vari layer (sia vettoriali che raster) ne tantomeno in fase di editing e stampa (grazie al magico Compositore di stampe e ad Atlas).
Intuisco però, pur non essendone un “praticante”, che l’uso del DB Spatialite fornisce delle potenzialità e delle capacità di gestione dei dati che con un progetto di QGIS non si possono neanche immaginare.
La “question” è questa. Per andare da Roma a Milano in autostrada, prendereste un trattore o una BMW ultimo modello? Per andare, in aperta campagna, dal campo di grano al campo di mais passando per il pantano delle ranocchie, prendereste il trattore o una BMW ultimo modello? …insomma, …secondo voi, qual’è il limite di “dati spaziali” da dover gestire (shape file) per cui diventa conveniente abbandonare il buon Progetto QGIS e migrare su un DB Spatialite?
credo che il buon Totò si riferisce, non tanto all'"appesantimento" del
progetto o della TOC (o di qualsiasi altra operazione dentro QGIS), ma
piuttosto al delirio del numero (e dei nomi!) dei file all'interno delle
cartelle del pc.
L'aggravante del formato shape è che per funzionare si porta dietro una
vagonata di altri formati (dbf, shx, prj, ecc) e appena fai una
qualunque operazione spaziale che crea un nuovo layer, ecco che il
numero dei file aumenta senza che te ne accorgi.
Un DB (SpatiaLite in questo caso) ti permette di avere un singolo file
che contiene tutti i file con cui stai lavorando. E questo, alla lunga
ti risolve svariati problemi di gestione di file (passaggio ad altre
persone, mantenimento ecc..)
Il limite impostalo tu ;), con 5 shape file hai almeno almeno 15 file in
una cartella (con i file di proiezione arriviamo a 25 in un attimo)
Giustissimo. Come archiviazione gli shape file sono veramente “pesanti” da gestire rispetto ad uno “smart” DB Spatialite (insisto con SpatiaLite perchè è l’unico con cui ho un po’ smanettato). Ultimamente abbiamo lavorato alla elaborazione del perimetro di un SIN che comprendeva 18 comuni. Il contenuto degli shape file per ogni comune era banale, (una decina di poligoni con associate tabelle attributi al massimo di due Campi), ma in un attimo, per tutti e 18 i comuni, considerando che per ogni comune necessitavano circa venti shape file diversi, alla fine, come dici tu, tra SHP, DBF, ecc…, siamo arrivati a dover gestire cartelle di archiviazione, nel PC, di oltre mille singoli file …in quel caso sicuramente un buon DB Spatialite avrebbe semplificato risolto tutto alla grande.
credo che il buon Totò si riferisce, non tanto all’“appesantimento” del
progetto o della TOC (o di qualsiasi altra operazione dentro QGIS), ma
piuttosto al delirio del numero (e dei nomi!) dei file all’interno delle
cartelle del pc.
L’aggravante del formato shape è che per funzionare si porta dietro una
vagonata di altri formati (dbf, shx, prj, ecc) e appena fai una
qualunque operazione spaziale che crea un nuovo layer, ecco che il
numero dei file aumenta senza che te ne accorgi.
Un DB (SpatiaLite in questo caso) ti permette di avere un singolo file
che contiene tutti i file con cui stai lavorando. E questo, alla lunga
ti risolve svariati problemi di gestione di file (passaggio ad altre
persone, mantenimento ecc…)
Il limite impostalo tu ;), con 5 shape file hai almeno almeno 15 file in
una cartella (con i file di proiezione arriviamo a 25 in un attimo)
2017-06-14 11:47 GMT+02:00 Marco Spaziani <spaziani.marco@gmail.com>:
Giustissimo. Come archiviazione gli shape file sono veramente "pesanti" da
gestire rispetto ad uno "smart" DB Spatialite (insisto con SpatiaLite perchè
è l'unico con cui ho un po' smanettato). Ultimamente abbiamo lavorato alla
elaborazione del perimetro di un SIN che comprendeva 18 comuni. Il contenuto
degli shape file per ogni comune era banale, (una decina di poligoni con
associate tabelle attributi al massimo di due Campi), ma in un attimo, per
tutti e 18 i comuni, considerando che per ogni comune necessitavano circa
venti shape file diversi, alla fine, come dici tu, tra SHP, DBF, ecc...,
siamo arrivati a dover gestire cartelle di archiviazione, nel PC, di oltre
mille singoli file ...in quel caso sicuramente un buon DB Spatialite avrebbe
semplificato risolto tutto alla grande.
Il giorno 14 giugno 2017 11:35, matteo <matteo.ghetta@gmail.com> ha scritto:
Ciao Marco,
credo che il buon Totò si riferisce, non tanto all'"appesantimento" del
progetto o della TOC (o di qualsiasi altra operazione dentro QGIS), ma
piuttosto al delirio del numero (e dei nomi!) dei file all'interno delle
cartelle del pc.
L'aggravante del formato shape è che per funzionare si porta dietro una
vagonata di altri formati (dbf, shx, prj, ecc) e appena fai una
qualunque operazione spaziale che crea un nuovo layer, ecco che il
numero dei file aumenta senza che te ne accorgi.
Un DB (SpatiaLite in questo caso) ti permette di avere un singolo file
che contiene tutti i file con cui stai lavorando. E questo, alla lunga
ti risolve svariati problemi di gestione di file (passaggio ad altre
persone, mantenimento ecc..)
Il limite impostalo tu ;), con 5 shape file hai almeno almeno 15 file in
una cartella (con i file di proiezione arriviamo a 25 in un attimo)
ciao a tutti.
ho bisogno di un suggerimento (se si può fare)!
Ho un file di punti (km di una strada) che vorrei trasformare in una linea. Facile.
Nella trasformazione il kilometraggio (es. km 15)
che oggi è assegnato al cartello stradale di inizio
dovrebbe essere assegnato all’intero tratto che va dal km 15 al 16,
perchè vorrei assegnare una caratteristica del bordo stradale
(ambiente circostante) all’intero tratto.
grazie in anticipo per i suggerimenti
giuseppe puddu
Con Mobile Open 7 GB a 9 euro/4 sett navighi veloce con 7 GB di Internet e hai 200 minuti ed SMS a 15 cent. Passa a Tiscali Mobile! http://tisca.li/Open7GB0617
Concordo con Luigi, se si comincia ad avere l’abitudine di non usare più gli shapefile (tranne casi semplicissimi) è meglio.
Certo lo shapefile è un formato storico diffusissimo che difficilmente scomparirà in poco tempo, ma è ormai vecchiotto!!
I vantaggi di passare a SpatiaLite sono molto più che avere tutto in un unico file e non sta a me elencarli qui !!
Cari saluti
Nino
···
Il 14 giu 2017 12:11 PM, “Luigi Pirelli” <luipir@gmail.com> ha scritto:
il limite e’ semplicemente 0 => NON usare Shapefile
Luigi Pirelli
Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
Giustissimo. Come archiviazione gli shape file sono veramente “pesanti” da
gestire rispetto ad uno “smart” DB Spatialite (insisto con SpatiaLite perchè
è l’unico con cui ho un po’ smanettato). Ultimamente abbiamo lavorato alla
elaborazione del perimetro di un SIN che comprendeva 18 comuni. Il contenuto
degli shape file per ogni comune era banale, (una decina di poligoni con
associate tabelle attributi al massimo di due Campi), ma in un attimo, per
tutti e 18 i comuni, considerando che per ogni comune necessitavano circa
venti shape file diversi, alla fine, come dici tu, tra SHP, DBF, ecc…,
siamo arrivati a dover gestire cartelle di archiviazione, nel PC, di oltre
mille singoli file …in quel caso sicuramente un buon DB Spatialite avrebbe
semplificato risolto tutto alla grande.
credo che il buon Totò si riferisce, non tanto all’“appesantimento” del
progetto o della TOC (o di qualsiasi altra operazione dentro QGIS), ma
piuttosto al delirio del numero (e dei nomi!) dei file all’interno delle
cartelle del pc.
L’aggravante del formato shape è che per funzionare si porta dietro una
vagonata di altri formati (dbf, shx, prj, ecc) e appena fai una
qualunque operazione spaziale che crea un nuovo layer, ecco che il
numero dei file aumenta senza che te ne accorgi.
Un DB (SpatiaLite in questo caso) ti permette di avere un singolo file
che contiene tutti i file con cui stai lavorando. E questo, alla lunga
ti risolve svariati problemi di gestione di file (passaggio ad altre
persone, mantenimento ecc…)
Il limite impostalo tu ;), con 5 shape file hai almeno almeno 15 file in
una cartella (con i file di proiezione arriviamo a 25 in un attimo)
Concordo con Luigi, se si comincia ad avere l'abitudine di non usare più
gli shapefile (tranne casi semplicissimi) è meglio.
Certo lo shapefile è un formato storico diffusissimo che difficilmente
scomparirà in poco tempo, ma è ormai vecchiotto!!
I vantaggi di passare a SpatiaLite sono molto più che avere tutto in un
unico file e non sta a me elencarli qui !!
concordo. purtroppo gli svantaggi ci sono, altrimenti ci saremmo già
passati tutti da tempo.
geopackage ha anche lui i suoi vantaggi, ma il supporto non è sempre
completo, purtroppo.
Saluti.
Dai un’occhiata al plugin LRS: dopo aver calibrato le linee con i punti (dove devi avere una colonna con i dati del chilometro), crea una tabella degli eventi con l’inizio / fine ad ogni chilometro.
ciao
roberto
···
Il 14/06/2017 18:31, Giuseppe Puddu ha scritto:
ciao a tutti.
ho bisogno di un suggerimento (se si può fare)!
Ho un file di punti (km di una strada) che vorrei trasformare in una linea. Facile.
Nella trasformazione il kilometraggio (es. km 15)
che oggi è assegnato al cartello stradale di inizio
dovrebbe essere assegnato all’intero tratto che va dal km 15 al 16,
perchè vorrei assegnare una caratteristica del bordo stradale
(ambiente circostante) all’intero tratto.
grazie in anticipo per i suggerimenti
giuseppe puddu
Con Mobile Open 7 GB a 9 euro/4 sett navighi veloce con 7 GB di Internet e hai 200 minuti ed SMS a 15 cent. Passa a Tiscali Mobile! http://tisca.li/Open7GB0617
_______________________________________________
QGIS-it-user mailing list
[QGIS-it-user@lists.osgeo.org](mailto:QGIS-it-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/qgis-it-user](https://lists.osgeo.org/mailman/listinfo/qgis-it-user)
concordo. purtroppo gli svantaggi ci sono, altrimenti ci saremmo già
passati tutti da tempo.
appena puoi, ci fai una lista delle ragioni per cui non ci sei passato?
Penso possa essere utile.
grazie. purtroppo il tempo è tiranno, quindi dovrò essere rapido e
qualitativo.
la sostanza del problema, come lo vedo io, è che lo sviluppo di SL è
separato da quello di QGIS, per cui è successo già varie volte che
modifiche dell'uno non vengano sincronizzate nell'altro.
il risultato è che ogni tanto qualcosa non funziona, e chiaramente
diventa difficile consigliare, soprattutto ai neofiti, di sostituire i
loro obsoleti ed inefficienti shp, che però più o meno funzionano
sempre, con qualcosa di più sofisticato ma più fragile.
purtroppo l'avvento del geopackage ha ulteriormente complicato la
situazione, offrendo una alternativa in più.
spero di essere stato utile.
saluti.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis
la sostanza del problema, come lo vedo io, è che lo sviluppo di SL è
separato da quello di QGIS, per cui è successo già varie volte che
modifiche dell'uno non vengano sincronizzate nell'altro.
Ah, ok. Quindi non è il formato in sé, ma dipende dalle scelte di sviluppo
di QGIS e SL.
Il 20 giugno 2017 16:15:16 CEST, aborruso aborruso@gmail.com ha scritto:
Paolo Cavallini wrote
> la sostanza del problema, come lo vedo io, è che lo sviluppo di SL è
> separato da quello di QGIS, per cui è successo già varie volte che
> modifiche dell'uno non vengano sincronizzate nell'altro.
Ah, ok. Quindi non è il formato in sé, ma dipende dalle scelte di sviluppo
di QGIS e SL.
Grazie!
--
View this message in context: [http://osgeo-org.1560.x6.nabble.com/Quand-e-che-conviene-migrare-al-DB-Spatialite-tp5324139p5324869.html](http://osgeo-org.1560.x6.nabble.com/Quand-e-che-conviene-migrare-al-DB-Spatialite-tp5324139p5324869.html)
Sent from the QGIS Italian User mailing list archive at [Nabble.com](http://Nabble.com).
---
QGIS-it-user mailing list
QGIS-it-user@lists.osgeo.org
[https://lists.osgeo.org/mailman/listinfo/qgis-it-user](https://lists.osgeo.org/mailman/listinfo/qgis-it-user)
Esatto. Per l’utente finale un formato deve valere l’altro, quindi la scelta è trasparente. Sono i malfunzionamenti a fare la differenza.
Saluti.
Ciao a tutti.
Ho bisogno di un suggerimento facile.
Devo replicare la vista di uno stesso shape più volte per comporre una mappa,
perchè ogni volta devo mostrare un ambito diverso dello stesso file.
s0no più particelle catastali sparse su un territorio
che voglio ingrandire/inquadrare su uno stessa cartina,
con tanti riquadri zoom.
grazie in anticipo
giuseppe
Con Mobile Open 7 GB a 9 euro/4 sett navighi veloce con 7 GB di Internet e hai 200 minuti ed SMS a 15 cent. Passa a Tiscali Mobile! http://tisca.li/Open7GB0617
Ciao a tutti.
Ho bisogno di un suggerimento facile.
Devo replicare la vista di uno stesso shape più volte per comporre una mappa,
perchè ogni volta devo mostrare un ambito diverso dello stesso file.
s0no più particelle catastali sparse su un territorio
che voglio ingrandire/inquadrare su uno stessa cartina,
con tanti riquadri zoom.
grazie in anticipo
giuseppe
Con Mobile Open 7 GB a 9 euro/4 sett navighi veloce con 7 GB di Internet e hai 200 minuti ed SMS a 15 cent. Passa a Tiscali Mobile! http://tisca.li/Open7GB0617
una soluzione potrebbe essere creare tanti riquadri in composizione stampa quanti te ne occorrono e denominarli opportunamente (es col numero della particella e/o del foglio io per prova ho messo M1, M2, ecc), poi tematizzare con regola lo shape (io ho messo "FOGLIO" = 3 AND @map_id ='M1',"FOGLIO" = 4 AND @map_id ='M2' ecc ) in maniera da evidenziare ogni foglio a seconda del riquadro di stampa in colore diverso dagli altri.
Infine agendo sui singoli riquadri ho centrato e messo in scala ciascuno.
Funziona, però c'è da considerare il numero di entità da visualizzare che comporta altrettanti riquadri.