[Gfoss] malfunzionamento snap in qGis 2.8 win

[francesco marucci]

ciao,
si, ho provato con le tre modalità (Layer in uso, Tutti e Avanzate) e il
problema si presenta indifferentemente attivandone una.
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).

apro il ticket e vi faccio sapere, grazie a tutti.

qui mi sorge la domanda:
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?

"Grazie per la domanda", mi dirà qualcuno...

saluti,
francesco




Il giorno 9 aprile 2015 14:40, Alessandro Pasotti <apasotti a gmail.com> ha
scritto:

> Il 9 aprile 2015 14:17, francesco marucci
> <francesco.marucci a gmail.com> ha scritto:
> > gentile lista,
> > vorrei segnalarvi un "malfunzionamento" che ho notato in qGis 2.8 per
> > windows (linux non ho verificato, sorry!):
> >
> > quando mi trovo a digitalizzare il "primo vertice" in un layer di
> poligoni
> > in un progetto nel quale sia presente anche un layer particolarmente
> pesante
> > e sia stata attivata qualche modalità di snap (Layer in uso, Tutti i
> layer,
> > Avanzato) anche al layer "pesante", qGis arriva a consumare tantissima
> ram e
> > rimane bloccato per svariati minuti (il tempo necessario per il
> caricamento
> > in memoria) e soprattutto non libera la memoria fino alla chiusura del
> > progetto.
> >
> > il successivo spostamento o digitalizzazione dello stesso vertice o di
> altri
> > vertici anche di altri poligoni è poi regolare ed immediato, ma la prima
> > azione blocca qGis per veramente troppo tempo (ovviamente in comparazione
> > con le versioni precedenti di qGis, per le quali questa operazione era
> > immediata fin dal primo vertice).
> >
> > per darvi delle cifre, per le prove che abbiamo fatto stiamo parlando di
> un
> > editing di 10mila poligoni anche abbastanza piccoli ma sulla base di un
> > layer catastale con poco meno di un milione e mezzo di record (particelle
> > catastali), l'attesa è di quasi un minuto (ovviamente dipendente dalla
> > macchina) e il carico sulla ram è di circa 800Mb che poi vengono
> > "trascinati" fino alla chiusura del progetto.
> > se pensate che in emilia romagna lavoriamo con quasi 6 milioni di
> > particelle, il tempo di attesa dello startup dell'editing e
> l'occupazione di
> > memoria sono secondo me esagerati.
> >
> > la versione di qGis per la quale ho verificato il problema è la 2.8.1,
> sia
> > la versione a 32b che 64bit, sia con installer osgeo4w che l'installer
> > standalone, ma ho verificato che si presenta anche con la versione
> nightly
> > di oggi (33), mentre ovviamente non si presenta con le versioni
> precedenti
> > alla 2.8 (dove sappiamo che la finestra delle opzioni di snap è molto
> > diversa).
> >
> > se puo' essere utile, ricordo che un problema simile (spostamento
> lentissimo
> > di vertici di poligoni molto grandi) era stato segnalato (e poi risolto)
> in
> > una versione di qGis pre 2.0.
> >
> > dimenticavo di dire che i layer sono tabelle geometriche in postgis, ma
> > immagino che questo comportamento sia indipendente dall'origine del dato.
> >
> > ho cercato tra i ticket sul track di qGis e non ho trovato una
> segnalazione
> > di un problema simile.
> >
> > mi consigliate di aprire un ticket o qualcuno ha risolto in altro modo o
> ha
> > voglia di fare qualche prova piu' esaustiva delle mie, prima di
> disturbare
> > gli sviluppatori?
> >
> > grazie a tutti (se siete arrivati a leggere fin qui!)
> >
>
>
> Prego :)
>
> e si, concordo con Paolo che un ticket ci vuole, per poter riprodurre
> il problema credo che un dataset "pesante" e simile a quello su cui lo
> avete riscontrato debba essere reso disponibile insieme al bug report,
> altrimenti se prima o poi qualcuno decide di cimentarsi si ferma al
> primo gradino: "non riesco a riprodurlo".
>
> Hai provato a modificare le opzioni di snapping e determinare
> esattamente quale configurazione innesca il problema?
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20150409/e007e297/attachment.html>