<div dir="ltr"><div><div><div>ciao,<br></div>si, ho provato con le tre modalità (Layer in uso, Tutti e Avanzate) e il problema si presenta indifferentemente attivandone una.<br></div>basta che si attivi uno snap al vertice (indicando una tolleranza maggiore di zero) e tra questi ci sia uno dei layer pesanti e qGis al primo click carica tutto in memoria. tutto cosa poi ? sembrerebbe i vertici di tutti i poligoni (il numero dei MB in ram è proporzionale al numero di records).<br><br></div><div>apro il ticket e vi faccio sapere, grazie a tutti.<br><br></div><div>qui mi sorge la domanda:<br></div><div>nel caso venga considerato un bug e venga risolto, il backport nella versione 2.8.1 è sarà automatico oppure questo canale non è stato ancora aperto?<br></div><div><br>"Grazie per la domanda", mi dirà qualcuno...<br><br></div><div>saluti,<br></div><div>francesco<br></div><div><br></div><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">Il giorno 9 aprile 2015 14:40, Alessandro Pasotti <span dir="ltr"><<a href="mailto:apasotti@gmail.com" target="_blank">apasotti@gmail.com</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Il 9 aprile 2015 14:17, francesco marucci<br>
<<a href="mailto:francesco.marucci@gmail.com">francesco.marucci@gmail.com</a>> ha scritto:<br>
<div><div class="h5">> gentile lista,<br>
> vorrei segnalarvi un "malfunzionamento" che ho notato in qGis 2.8 per<br>
> windows (linux non ho verificato, sorry!):<br>
><br>
> quando mi trovo a digitalizzare il "primo vertice" in un layer di poligoni<br>
> in un progetto nel quale sia presente anche un layer particolarmente pesante<br>
> e sia stata attivata qualche modalità di snap (Layer in uso, Tutti i layer,<br>
> Avanzato) anche al layer "pesante", qGis arriva a consumare tantissima ram e<br>
> rimane bloccato per svariati minuti (il tempo necessario per il caricamento<br>
> in memoria) e soprattutto non libera la memoria fino alla chiusura del<br>
> progetto.<br>
><br>
> il successivo spostamento o digitalizzazione dello stesso vertice o di altri<br>
> vertici anche di altri poligoni è poi regolare ed immediato, ma la prima<br>
> azione blocca qGis per veramente troppo tempo (ovviamente in comparazione<br>
> con le versioni precedenti di qGis, per le quali questa operazione era<br>
> immediata fin dal primo vertice).<br>
><br>
> per darvi delle cifre, per le prove che abbiamo fatto stiamo parlando di un<br>
> editing di 10mila poligoni anche abbastanza piccoli ma sulla base di un<br>
> layer catastale con poco meno di un milione e mezzo di record (particelle<br>
> catastali), l'attesa è di quasi un minuto (ovviamente dipendente dalla<br>
> macchina) e il carico sulla ram è di circa 800Mb che poi vengono<br>
> "trascinati" fino alla chiusura del progetto.<br>
> se pensate che in emilia romagna lavoriamo con quasi 6 milioni di<br>
> particelle, il tempo di attesa dello startup dell'editing e l'occupazione di<br>
> memoria sono secondo me esagerati.<br>
><br>
> la versione di qGis per la quale ho verificato il problema è la 2.8.1, sia<br>
> la versione a 32b che 64bit, sia con installer osgeo4w che l'installer<br>
> standalone, ma ho verificato che si presenta anche con la versione nightly<br>
> di oggi (33), mentre ovviamente non si presenta con le versioni precedenti<br>
> alla 2.8 (dove sappiamo che la finestra delle opzioni di snap è molto<br>
> diversa).<br>
><br>
> se puo' essere utile, ricordo che un problema simile (spostamento lentissimo<br>
> di vertici di poligoni molto grandi) era stato segnalato (e poi risolto) in<br>
> una versione di qGis pre 2.0.<br>
><br>
> dimenticavo di dire che i layer sono tabelle geometriche in postgis, ma<br>
> immagino che questo comportamento sia indipendente dall'origine del dato.<br>
><br>
> ho cercato tra i ticket sul track di qGis e non ho trovato una segnalazione<br>
> di un problema simile.<br>
><br>
> mi consigliate di aprire un ticket o qualcuno ha risolto in altro modo o ha<br>
> voglia di fare qualche prova piu' esaustiva delle mie, prima di disturbare<br>
> gli sviluppatori?<br>
><br>
> grazie a tutti (se siete arrivati a leggere fin qui!)<br>
><br>
<br>
<br>
</div></div>Prego :)<br>
<br>
e si, concordo con Paolo che un ticket ci vuole, per poter riprodurre<br>
il problema credo che un dataset "pesante" e simile a quello su cui lo<br>
avete riscontrato debba essere reso disponibile insieme al bug report,<br>
altrimenti se prima o poi qualcuno decide di cimentarsi si ferma al<br>
primo gradino: "non riesco a riprodurlo".<br>
<br>
Hai provato a modificare le opzioni di snapping e determinare<br>
esattamente quale configurazione innesca il problema?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Alessandro Pasotti<br>
w3:   <a href="http://www.itopen.it" target="_blank">www.itopen.it</a><br>
</font></span></blockquote></div><br></div>