[Gfoss] File progetto QGIS

Local Chapters GFOSS.it
,
1

Salve a tutti!
Con l'uscita della nuova LTR e l'adozione ufficiale del nuovo formato .qgz,
letto solo dalla 3.4 e non dalla 2.18, stavo ragionando se fosse il caso o
meno di convertire alcuni miei progetti più importanti al nuovo formato.
Questi progetti sono realizzati con la 2.18 e la conversione comporterebbe
la conversione/importazione anche dei vari layout di stampa.

Secondo voi mi conviene? Potrei riscontrare incompatibilità nei tematismi e
nei layout di stampa se faccio un semplice "Save as"?

Alla faccenda della conversione associo anche un problema che ho riscontrato
già da un po'.

Ho un progetto molto importante e particolare che quando finirà vedrà
mappati 320 villaggi francesi. La particolarità sta nel fatto che non posso
usare l'Atlas perchè ogni villaggio deve per forza essere impaginato a mano
perchè, per tutta una serie di lunghissimi motivi che non vi sto a spiegare,
non può essere centrato in automatico; ad esempio spesse volte l'area di
interesse rispetto all'area di stampa è molto decentrata e deve essere
necessariamente così per non perdere particolari ed importanti riferimenti
esterni al focus. A questo si aggiunge che in funzione dell'estensione
dell'area focus ho almeno tre formati di stampa da A0 ad A2...

Fatta questa premessa vengo al problema. Già ora che siamo ad una 50ina di
villaggi sono costretto a creare almeno un paio di file progetto che si
differenziano tra loro solo per i layout di stampa perchè l'avvio del
progetto ha dei tempi davvero biblici. In un primo momento pensavo
dipendesse dal db PostGIS su cui si poggia il progetto ma ho notato che non
è così perchè riducendo i layout di stampa i tempi di apertura si riducono
pesantemente. Ho un progetto con quattro layout e gli stessissimi layer
degli altri e si apre in pochissimo tempo...secondi.

Secondo voi esiste un modo per alleggerire il caricamento di un progetto con
molto layout?
Prevedo che alla fine avrò almeno 20 file progetto che avranno gli stessi
dati da gestire e che si differenzieranno solo per i layout di stampa. Metti
caso che per un qualche motivo un solo vettore deve essere sostituito o
inserito, non solo sarò costretto ad aggiornare uno per uno tutti e venti i
progetti ma anche tutti e 320 layout di stampa.....mi viene l'ansia solo a
pensarci! Avete consigli?

-----
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/

2

Leggendo qui
https://www.qgis.org/it/site/getinvolved/development/roadmap.html
a me sembra che la mitica LTR 2.18 sarà viva e lotterà insieme a noi ancora
per qualche mese, fino al 22 febbraio 2019, quando passerà il testimone
alla 3.4 ...quindi il tuo "problema", per quanto fondato, al momento è
rimandato ...perchè preoccuparci oggi dei problemi di domani? ..." ...*Non
affannatevi dunque per il domani, perché il domani avrà già le sue
inquietudini. A ciascun giorno basta la sua pena.*" Matteo, 6,25-34 ...
:wink: ...e daaaai ...stò a scherzà! :wink:

Il giorno ven 2 nov 2018 alle ore 18:32 Massimiliano Moraca <
massimilianomoraca@gmail.com> ha scritto:

Salve a tutti!
Con l'uscita della nuova LTR e l'adozione ufficiale del nuovo formato .qgz,
letto solo dalla 3.4 e non dalla 2.18, stavo ragionando se fosse il caso o
meno di convertire alcuni miei progetti più importanti al nuovo formato.
Questi progetti sono realizzati con la 2.18 e la conversione comporterebbe
la conversione/importazione anche dei vari layout di stampa.

Secondo voi mi conviene? Potrei riscontrare incompatibilità nei tematismi e
nei layout di stampa se faccio un semplice "Save as"?

Alla faccenda della conversione associo anche un problema che ho
riscontrato
già da un po'.

Ho un progetto molto importante e particolare che quando finirà vedrà
mappati 320 villaggi francesi. La particolarità sta nel fatto che non posso
usare l'Atlas perchè ogni villaggio deve per forza essere impaginato a mano
perchè, per tutta una serie di lunghissimi motivi che non vi sto a
spiegare,
non può essere centrato in automatico; ad esempio spesse volte l'area di
interesse rispetto all'area di stampa è molto decentrata e deve essere
necessariamente così per non perdere particolari ed importanti riferimenti
esterni al focus. A questo si aggiunge che in funzione dell'estensione
dell'area focus ho almeno tre formati di stampa da A0 ad A2...

Fatta questa premessa vengo al problema. Già ora che siamo ad una 50ina di
villaggi sono costretto a creare almeno un paio di file progetto che si
differenziano tra loro solo per i layout di stampa perchè l'avvio del
progetto ha dei tempi davvero biblici. In un primo momento pensavo
dipendesse dal db PostGIS su cui si poggia il progetto ma ho notato che non
è così perchè riducendo i layout di stampa i tempi di apertura si riducono
pesantemente. Ho un progetto con quattro layout e gli stessissimi layer
degli altri e si apre in pochissimo tempo...secondi.

Secondo voi esiste un modo per alleggerire il caricamento di un progetto
con
molto layout?
Prevedo che alla fine avrò almeno 20 file progetto che avranno gli stessi
dati da gestire e che si differenzieranno solo per i layout di stampa.
Metti
caso che per un qualche motivo un solo vettore deve essere sostituito o
inserito, non solo sarò costretto ad aggiornare uno per uno tutti e venti i
progetti ma anche tutti e 320 layout di stampa.....mi viene l'ansia solo a
pensarci! Avete consigli?

-----
Ingegnere, consulente GIS e ciclista urbano
--
Sent from:
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
_______________________________________________
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.
796 iscritti al 28/12/2017

3

Eh eh pure hai ragione ma sono abituato a prevenire :stuck_out_tongue:

Hai consigli per la questione dei layout?

Il giorno ven 2 nov 2018 alle ore 22:41 Marco Spaziani <
spaziani.marco@gmail.com> ha scritto:

Leggendo qui
https://www.qgis.org/it/site/getinvolved/development/roadmap.html
a me sembra che la mitica LTR 2.18 sarà viva e lotterà insieme a noi
ancora per qualche mese, fino al 22 febbraio 2019, quando passerà il
testimone alla 3.4 ...quindi il tuo "problema", per quanto fondato, al
momento è rimandato ...perchè preoccuparci oggi dei problemi di domani?
..." ...*Non affannatevi dunque per il domani, perché il domani avrà già
le sue inquietudini. A ciascun giorno basta la sua pena.*" Matteo,
6,25-34 ... :wink: ...e daaaai ...stò a scherzà! :wink:

Il giorno ven 2 nov 2018 alle ore 18:32 Massimiliano Moraca <
massimilianomoraca@gmail.com> ha scritto:

Salve a tutti!
Con l'uscita della nuova LTR e l'adozione ufficiale del nuovo formato
.qgz,
letto solo dalla 3.4 e non dalla 2.18, stavo ragionando se fosse il caso o
meno di convertire alcuni miei progetti più importanti al nuovo formato.
Questi progetti sono realizzati con la 2.18 e la conversione comporterebbe
la conversione/importazione anche dei vari layout di stampa.

Secondo voi mi conviene? Potrei riscontrare incompatibilità nei tematismi
e
nei layout di stampa se faccio un semplice "Save as"?

Alla faccenda della conversione associo anche un problema che ho
riscontrato
già da un po'.

Ho un progetto molto importante e particolare che quando finirà vedrà
mappati 320 villaggi francesi. La particolarità sta nel fatto che non
posso
usare l'Atlas perchè ogni villaggio deve per forza essere impaginato a
mano
perchè, per tutta una serie di lunghissimi motivi che non vi sto a
spiegare,
non può essere centrato in automatico; ad esempio spesse volte l'area di
interesse rispetto all'area di stampa è molto decentrata e deve essere
necessariamente così per non perdere particolari ed importanti riferimenti
esterni al focus. A questo si aggiunge che in funzione dell'estensione
dell'area focus ho almeno tre formati di stampa da A0 ad A2...

Fatta questa premessa vengo al problema. Già ora che siamo ad una 50ina di
villaggi sono costretto a creare almeno un paio di file progetto che si
differenziano tra loro solo per i layout di stampa perchè l'avvio del
progetto ha dei tempi davvero biblici. In un primo momento pensavo
dipendesse dal db PostGIS su cui si poggia il progetto ma ho notato che
non
è così perchè riducendo i layout di stampa i tempi di apertura si riducono
pesantemente. Ho un progetto con quattro layout e gli stessissimi layer
degli altri e si apre in pochissimo tempo...secondi.

Secondo voi esiste un modo per alleggerire il caricamento di un progetto
con
molto layout?
Prevedo che alla fine avrò almeno 20 file progetto che avranno gli stessi
dati da gestire e che si differenzieranno solo per i layout di stampa.
Metti
caso che per un qualche motivo un solo vettore deve essere sostituito o
inserito, non solo sarò costretto ad aggiornare uno per uno tutti e venti
i
progetti ma anche tutti e 320 layout di stampa.....mi viene l'ansia solo a
pensarci! Avete consigli?

-----
Ingegnere, consulente GIS e ciclista urbano
--
Sent from:
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
_______________________________________________
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.
796 iscritti al 28/12/2017

4

Io e le mie domande da un milione di euro....

-----
Ingegnere, consulente GIS e ciclista urbano
--
Sent from: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/

5

Massimiliano Moraca wrote

Salve a tutti!
Con l'uscita della nuova LTR e l'adozione ufficiale del nuovo formato
.qgz,
letto solo dalla 3.4 e non dalla 2.18, stavo ragionando se fosse il caso o
meno di convertire alcuni miei progetti più importanti al nuovo formato.
Questi progetti sono realizzati con la 2.18 e la conversione comporterebbe
la conversione/importazione anche dei vari layout di stampa.

Secondo voi mi conviene? Potrei riscontrare incompatibilità nei tematismi
e
nei layout di stampa se faccio un semplice "Save as"?

Alla faccenda della conversione associo anche un problema che ho
riscontrato
già da un po'.

Ho un progetto molto importante e particolare che quando finirà vedrà
mappati 320 villaggi francesi. La particolarità sta nel fatto che non
posso
usare l'Atlas perchè ogni villaggio deve per forza essere impaginato a
mano
perchè, per tutta una serie di lunghissimi motivi che non vi sto a
spiegare,
non può essere centrato in automatico; ad esempio spesse volte l'area di
interesse rispetto all'area di stampa è molto decentrata e deve essere
necessariamente così per non perdere particolari ed importanti riferimenti
esterni al focus. A questo si aggiunge che in funzione dell'estensione
dell'area focus ho almeno tre formati di stampa da A0 ad A2...

Fatta questa premessa vengo al problema. Già ora che siamo ad una 50ina di
villaggi sono costretto a creare almeno un paio di file progetto che si
differenziano tra loro solo per i layout di stampa perchè l'avvio del
progetto ha dei tempi davvero biblici. In un primo momento pensavo
dipendesse dal db PostGIS su cui si poggia il progetto ma ho notato che
non
è così perchè riducendo i layout di stampa i tempi di apertura si riducono
pesantemente. Ho un progetto con quattro layout e gli stessissimi layer
degli altri e si apre in pochissimo tempo...secondi.

Secondo voi esiste un modo per alleggerire il caricamento di un progetto
con
molto layout?
Prevedo che alla fine avrò almeno 20 file progetto che avranno gli stessi
dati da gestire e che si differenzieranno solo per i layout di stampa.
Metti
caso che per un qualche motivo un solo vettore deve essere sostituito o
inserito, non solo sarò costretto ad aggiornare uno per uno tutti e venti
i
progetti ma anche tutti e 320 layout di stampa.....mi viene l'ansia solo a
pensarci! Avete consigli?

Ciao Massimiliano,
esiste una ML dedicata solo a QGIS, qui potrebbero non rispondere alcune
persone.

il formato .qgz è nato nella 3.0 anche se usato opzionalmente; è diventano
il nuovo formato dalla 3.2 in poi.

L'aggiornamento dei file di progetto verso le nuove versione è caldamente
suggerito dagli sviluppatori e non dovrebbe accadere nulla per un salto di
una versione, nel tuo caso si parla di un salto da 2.18 a 3.4, cioè un salto
triplo: se hai usato tematizzazioni particolari e layout particolari
potresti avere delle brutte sorprese, anche perché il compositore di stampe
è stato totalmente riscritto nella 3.x.

Per quanto riguarda il tuo progetto in QGIS 2.18:
se devi completare il lavoro senza la necessità di usare le nuove feature
delle nuove versioni, ti consiglierei di proseguire utilizzando la 2.18; la
2.18 non sarà più supportata da gen 2019, ma questo non significa che non
funzionerà più. Quindi puoi completare il tuo progetto utilizzando sempre la
2.18.

Per quanto riguarda il tempo di apertura di QGIS con layout grossi, è un
problema noto.

saluti

-----
https://pigrecoinfinito.wordpress.com/
--
Sent from: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/

6

Grazie Salvatò, mi indicheresti la Mailing List di QGIS?

Il giorno sab 3 nov 2018 alle ore 18:43 pigreco <pigrecoinfinito@gmail.com>
ha scritto:

Massimiliano Moraca wrote
> Salve a tutti!
> Con l'uscita della nuova LTR e l'adozione ufficiale del nuovo formato
> .qgz,
> letto solo dalla 3.4 e non dalla 2.18, stavo ragionando se fosse il caso
o
> meno di convertire alcuni miei progetti più importanti al nuovo formato.
> Questi progetti sono realizzati con la 2.18 e la conversione
comporterebbe
> la conversione/importazione anche dei vari layout di stampa.
>
> Secondo voi mi conviene? Potrei riscontrare incompatibilità nei tematismi
> e
> nei layout di stampa se faccio un semplice "Save as"?
>
> Alla faccenda della conversione associo anche un problema che ho
> riscontrato
> già da un po'.
>
> Ho un progetto molto importante e particolare che quando finirà vedrà
> mappati 320 villaggi francesi. La particolarità sta nel fatto che non
> posso
> usare l'Atlas perchè ogni villaggio deve per forza essere impaginato a
> mano
> perchè, per tutta una serie di lunghissimi motivi che non vi sto a
> spiegare,
> non può essere centrato in automatico; ad esempio spesse volte l'area di
> interesse rispetto all'area di stampa è molto decentrata e deve essere
> necessariamente così per non perdere particolari ed importanti
riferimenti
> esterni al focus. A questo si aggiunge che in funzione dell'estensione
> dell'area focus ho almeno tre formati di stampa da A0 ad A2...
>
> Fatta questa premessa vengo al problema. Già ora che siamo ad una 50ina
di
> villaggi sono costretto a creare almeno un paio di file progetto che si
> differenziano tra loro solo per i layout di stampa perchè l'avvio del
> progetto ha dei tempi davvero biblici. In un primo momento pensavo
> dipendesse dal db PostGIS su cui si poggia il progetto ma ho notato che
> non
> è così perchè riducendo i layout di stampa i tempi di apertura si
riducono
> pesantemente. Ho un progetto con quattro layout e gli stessissimi layer
> degli altri e si apre in pochissimo tempo...secondi.
>
> Secondo voi esiste un modo per alleggerire il caricamento di un progetto
> con
> molto layout?
> Prevedo che alla fine avrò almeno 20 file progetto che avranno gli stessi
> dati da gestire e che si differenzieranno solo per i layout di stampa.
> Metti
> caso che per un qualche motivo un solo vettore deve essere sostituito o
> inserito, non solo sarò costretto ad aggiornare uno per uno tutti e venti
> i
> progetti ma anche tutti e 320 layout di stampa.....mi viene l'ansia solo
a
> pensarci! Avete consigli?

Ciao Massimiliano,
esiste una ML dedicata solo a QGIS, qui potrebbero non rispondere alcune
persone.

il formato .qgz è nato nella 3.0 anche se usato opzionalmente; è diventano
il nuovo formato dalla 3.2 in poi.

L'aggiornamento dei file di progetto verso le nuove versione è caldamente
suggerito dagli sviluppatori e non dovrebbe accadere nulla per un salto di
una versione, nel tuo caso si parla di un salto da 2.18 a 3.4, cioè un
salto
triplo: se hai usato tematizzazioni particolari e layout particolari
potresti avere delle brutte sorprese, anche perché il compositore di stampe
è stato totalmente riscritto nella 3.x.

Per quanto riguarda il tuo progetto in QGIS 2.18:
se devi completare il lavoro senza la necessità di usare le nuove feature
delle nuove versioni, ti consiglierei di proseguire utilizzando la 2.18; la
2.18 non sarà più supportata da gen 2019, ma questo non significa che non
funzionerà più. Quindi puoi completare il tuo progetto utilizzando sempre
la
2.18.

Per quanto riguarda il tempo di apertura di QGIS con layout grossi, è un
problema noto.

saluti

-----
https://pigrecoinfinito.wordpress.com/
--
Sent from:
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
_______________________________________________
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.
796 iscritti al 28/12/2017

7

Massimiliano Moraca wrote

Grazie Salvatò, mi indicheresti la Mailing List di QGIS?

eccola
https://lists.osgeo.org/mailman/listinfo/qgis-it-user

saluti

-----
https://pigrecoinfinito.wordpress.com/
--
Sent from: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/

8

Grazie

Il giorno sab 3 nov 2018 alle ore 23:01 pigreco <pigrecoinfinito@gmail.com>
ha scritto:

Massimiliano Moraca wrote
> Grazie Salvatò, mi indicheresti la Mailing List di QGIS?

eccola
https://lists.osgeo.org/mailman/listinfo/qgis-it-user

saluti

-----
https://pigrecoinfinito.wordpress.com/
--
Sent from:
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
_______________________________________________
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.
796 iscritti al 28/12/2017