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 ... ;-) ...e daaaai ...stò a scherzà! ;-)
Il giorno ven 2 nov 2018 alle ore 18:32 Massimiliano Moraca < massimilianomor...@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 _______________________________________________ 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