malfunzionamento snap in qGis 2.8 win
Locked
malfunzionamento snap in qGis 2.8 win
 
|
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. 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!) saluti, francesco _______________________________________________ [hidden email] 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. 750 iscritti al 18.3.2015 |
|
|
Ciao.
Il 09/04/2015 14:17, francesco marucci ha scritto: > 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? a me pare che l'analisi sia gia' sufficientemente esaustiva, e che l'apertura di un ticket sia ragionevole. Se vuoi essere piu' scrupoloso, chiedi prima in lista qgis-dev, ma non lo ritengo indispensabile. una difficolta' e' la replicabilita' del bug; se puoi, metti a disposizione da qualche parte il set di dati con cui riscontri il problema. Saluti, e grazie. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html _______________________________________________ [hidden email] 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. 750 iscritti al 18.3.2015 |
Re: malfunzionamento snap in qGis 2.8 win
|
|
In reply to this post by francesco marucci-2
Il 9 aprile 2015 14:17, francesco marucci
<[hidden email]> 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 _______________________________________________ [hidden email] 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. 750 iscritti al 18.3.2015 |
Re: malfunzionamento snap in qGis 2.8 win
|
|
ciao, si, ho provato con le tre modalità (Layer in uso, Tutti e Avanzate) e il problema si presenta indifferentemente attivandone una.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 <[hidden email]> ha scritto: Il 9 aprile 2015 14:17, francesco marucci _______________________________________________ [hidden email] 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. 750 iscritti al 18.3.2015 |
|
|
Il 09/04/2015 14:49, francesco marucci ha scritto:
> 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? Il backport non e' mai automatico, perche' va valutata la possibilita' che il fix causi altri guai (solo i fix considerati sicuri possono essere backportati). In ongi caso, la cosa richiede del lavoro in piu', quindi sta al buon cuore di chi sistema il bug (o di chi lo finanzia). Saluti. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html _______________________________________________ [hidden email] 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. 750 iscritti al 18.3.2015 |
|
|
In reply to this post by francesco marucci-2
Ciao Francesco,
hai poi aperto il ticket? Hai novita'? Saluti, e grazie. Il 09/04/2015 14:49, francesco marucci ha scritto: > 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? Il backport non e' mai automatico, perche' va valutata la possibilita' che il fix causi altri guai (solo i fix considerati sicuri possono essere backportati). In ongi caso, la cosa richiede del lavoro in piu', quindi sta al buon cuore di chi sistema il bug (o di chi lo finanzia). Saluti. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html _______________________________________________ [hidden email] 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. 750 iscritti al 18.3.2015 |
Re: malfunzionamento snap in qGis 2.8 win
|
|
ciao, a presto, _______________________________________________ [hidden email] 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. 750 iscritti al 18.3.2015 |
|
|
Il 14/04/2015 20:02, francesco marucci ha scritto:
> ciao, > scusate ma non l'ho ancora aperto, non ho ancora trovato il tempo di > cercare un dataset da inviare per riprodurre quel comportamento, il > catasto non posso inviarlo. > domattina dovrei riuscire e vi mando il ticket. Grazie, faresti un favore. Saluti. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html _______________________________________________ [hidden email] 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. 750 iscritti al 18.3.2015 |
|
In reply to this post by francesco marucci
Aprire il ticket senza dubbio !
Ma sarebbe utile comunque da verificare, se il problema si presenta anche sotto Linux. Quindi se mandi un dataset posso darci un'occhiata. Ciao ! |
Re: malfunzionamento snap in qGis 2.8 win
|
|
ciao, finalmente ho aperto il ticket:Bug report #12578 con un po' di immaginazione fate le proporzioni... potete trovarlo qui: http://mappegis.regione.emilia-romagna.it/gstatico/documenti/fra/snapping_issue.zip ditemi se il ticket si capisce. grazie. Il giorno 15 aprile 2015 08:52, nformica <[hidden email]> ha scritto: Aprire il ticket senza dubbio ! _______________________________________________ [hidden email] 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. 750 iscritti al 18.3.2015 |
|
|
Il 15/04/2015 11:54, francesco marucci ha scritto:
> ciao, > finalmente ho aperto il ticket: > Bug report #12578 > > ovviamente non ho potuto inviare il dataset con il quale ho scoperto > questo problema (particelle catastali di una provincia intera), ma ho > inviato un dataset molto piu' piccolo che comunque mi produce una > occupazione di memoria di 300Mb (per cui qGis si blocca solo per pochi > secondi). > con un po' di immaginazione fate le proporzioni... non e' meglio se generi dati random, oppure usi dati pubblici, che replichino con certezza il problema? se bastano punti, e' facilissimo generarne a piacere, altrimenti forse basta anche un grigliato suffientemente esteso e fitto. > potete trovarlo qui: > http://mappegis.regione.emilia-romagna.it/gstatico/documenti/fra/snapping_issue.zip > > ditemi se il ticket si capisce. Vedo commenti dubbiosi sul ticket, meglio se aggiungi le tue considerazioni. Grazie mille. Saluti. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html _______________________________________________ [hidden email] 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. 750 iscritti al 18.3.2015 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |