[Gfoss] malfunzionamento snap in qGis 2.8 win

[Alessandro Pasotti]

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