Buongiorno a tutti,
ho scritto un semplice plugin python per QGIS che ha il compito di traslare un layer vettoriale, dato un valore di shift in ingresso.
Di seguito il codice.
delta_x = 0.1
delta_y = 0.3
vlayer = iface.activeLayer()
for fid in range(vlayer.featureCount()):
vlayer.translateFeature(fid, delta_x, delta_y)
Utilizzando questo plugin nella versione 1.8.0 di Qgis, per traslare circa 70000 features venivano impiegati 3 secondi. Nella versione 2.8.1, per traslare lo stesso numero di features utilizzando lo stesso plugin, vengono impiegati 4 minuti.
Come e’ possibile?
Qualcuno riesce ad aiutarmi?
Grazie mille.
Pietro Panzeri
2015-04-22 11:06 GMT+02:00 Pietro Panzeri <pietro.panzeri@treuropa.com>:
translateFeature
il codice del translate e' piuttosto semplice [1] attualmente percio'
penso a due aspetti
1) senza andarmi a vedere il codice della 1.8 direi che prima avevi la
rob ain cache e ora no
2) in cache potenzialment enon la hay visto che usi featureCount
invece che getFeatures()
3) sconsiglio0 di usare un range su featureCount... non farei
assunzioni su quale debba essere la logica degli id delle feature
dentro QGIS => userei la classica
4) la http://qgis.org/api/qgsvectorlayereditutils_8cpp_source.html#l00174
dice che se la geometria non e' nella cache fa una getFeature ad hoc
=> fai una get feature ricreando l'iteratore ogni volta!...
for feat in vector.getFeatures():
fid = feat.id()
vlayer.translateFeature(fid, delta_x, delta_y)
prova e fai sapere
[1] http://qgis.org/api/qgsvectorlayereditutils_8cpp_source.html#l00164
a presto, Luigi Pirelli
**************************************************************************************************
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Elance: https://www.elance.com/s/edit/luigipirelli/
* GitHub: https://github.com/luipir
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**************************************************************************************************
Grazie mille per la risposta.
Ho provato ad usare il codice hai scritto e che utilizza la getFeatures(). Le cose sono effettivamente cambiate nel seguente modo:
la prima volta che faccio una traslazione ci impiega sempre 4minuti come prima mentre dalla seconda volta ci impiega 20 secondi: ha effettivamente messo in cache le geometrie.
La domanda quindi rimane aperta: come mai nella versione 1.8 gia’ la prima esecuzione ha prestazioni ottime mentre nella 2.8.1 invece e’ necessario popolare “esplicitamente” la cache con prestazioni notevolmente peggiori?
Pietro
···
2015-04-22 12:59 GMT+02:00 Luigi Pirelli <luipir@gmail.com>:
2015-04-22 11:06 GMT+02:00 Pietro Panzeri <pietro.panzeri@treuropa.com>:
translateFeature
il codice del translate e’ piuttosto semplice [1] attualmente percio’
penso a due aspetti
- senza andarmi a vedere il codice della 1.8 direi che prima avevi la
rob ain cache e ora no
- in cache potenzialment enon la hay visto che usi featureCount
invece che getFeatures()
- sconsiglio0 di usare un range su featureCount… non farei
assunzioni su quale debba essere la logica degli id delle feature
dentro QGIS => userei la classica
- la http://qgis.org/api/qgsvectorlayereditutils_8cpp_source.html#l00174
dice che se la geometria non e’ nella cache fa una getFeature ad hoc
=> fai una get feature ricreando l’iteratore ogni volta!..
for feat in vector.getFeatures():
fid = feat.id()
vlayer.translateFeature(fid, delta_x, delta_y)
prova e fai sapere
[1] http://qgis.org/api/qgsvectorlayereditutils_8cpp_source.html#l00164
a presto, Luigi Pirelli
–
Pietro Panzeri
Software Development Manager
Tele-Rilevamento Europa - T.R.E. srl
Ripa di Porta Ticinese, 79
20143 Milano – Italia
Tel.: +39.02.4343.121 - Fax: +39.02.4343.1230
pietro.panzeri@treuropa.com - www.treuropa.com
faccio una ipotesi alla cieca, non perdendo il tempo a leggere il
codice della 1.8
che le feature fossero caricate in cache nel momento del caricameto
del layer? vedo che fai iface.activeLayer() che attualmente passa dal
QgsMapLayerRegistry per "registrare" il layer in qgis. Se ricordo bene
era cosi' anche allora... solo che ora ole feature vengono caricate
con intelligenza, cioe' solo se servono, e questo permette di gestire
vettoriali di grosse dimensioni senza incorrere in problemi di
memoria.
un'altra ottimizzazione dipende dalla complessita' delle features...
queste vengono semplificate lato provider quando la visualizzazione
non le necessita (tipo scala troppo affollata)... questo, se ricordo
bene non c'era nella 1.8 ed e' stato aggiunto con il rendering
MultiThread... morale, appena caricato il layer e visualizzato a
bassa scala (o alta?... mi confondo sempre) non e' detto che hai
effettivamente preso le features... queste vengono prese solo se ne
hai effettivamente bisogno... conta che e' un bel vantaggio in caso di
layer remoti.
morale... e' cambiato il motore di fetch dei dati che e' piu' astuto 
fai un po il confronto nel caricamento e visualizzazione del layer
nella 1.8 e 2.8
ciao e a presto, Luigi Pirelli
**************************************************************************************************
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Elance: https://www.elance.com/s/edit/luigipirelli/
* GitHub: https://github.com/luipir
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**************************************************************************************************
2015-04-22 15:14 GMT+02:00 Pietro Panzeri <pietro.panzeri@treuropa.com>:
Grazie mille per la risposta.
Ho provato ad usare il codice hai scritto e che utilizza la getFeatures().
Le cose sono effettivamente cambiate nel seguente modo:
la prima volta che faccio una traslazione ci impiega sempre 4minuti come
prima mentre dalla seconda volta ci impiega 20 secondi: ha effettivamente
messo in cache le geometrie.
La domanda quindi rimane aperta: come mai nella versione 1.8 gia' la prima
esecuzione ha prestazioni ottime mentre nella 2.8.1 invece e' necessario
popolare "esplicitamente" la cache con prestazioni notevolmente peggiori?
Pietro
2015-04-22 12:59 GMT+02:00 Luigi Pirelli <luipir@gmail.com>:
2015-04-22 11:06 GMT+02:00 Pietro Panzeri <pietro.panzeri@treuropa.com>:
> translateFeature
il codice del translate e' piuttosto semplice [1] attualmente percio'
penso a due aspetti
1) senza andarmi a vedere il codice della 1.8 direi che prima avevi la
rob ain cache e ora no
2) in cache potenzialment enon la hay visto che usi featureCount
invece che getFeatures()
3) sconsiglio0 di usare un range su featureCount... non farei
assunzioni su quale debba essere la logica degli id delle feature
dentro QGIS => userei la classica
4) la http://qgis.org/api/qgsvectorlayereditutils_8cpp_source.html#l00174
dice che se la geometria non e' nella cache fa una getFeature ad hoc
=> fai una get feature ricreando l'iteratore ogni volta!...
for feat in vector.getFeatures():
fid = feat.id()
vlayer.translateFeature(fid, delta_x, delta_y)
prova e fai sapere
[1] http://qgis.org/api/qgsvectorlayereditutils_8cpp_source.html#l00164
a presto, Luigi Pirelli
**************************************************************************************************
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Elance: https://www.elance.com/s/edit/luigipirelli/
* GitHub: https://github.com/luipir
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**************************************************************************************************
--
Pietro Panzeri
Software Development Manager
Tele-Rilevamento Europa - T.R.E. srl
Ripa di Porta Ticinese, 79
20143 Milano – Italia
Tel.: +39.02.4343.121 - Fax: +39.02.4343.1230
pietro.panzeri@treuropa.com - www.treuropa.com
Il caricamento e visualizzazione del layer sono paragonabili nelle versioni 1.8 e 2.8.1.
La 1.8 visualizza tutte le feature in un colpo solo mentre la 2.8.1 le visualizza progressivamente pero’ l’intera operazione dura 1 secondo per entrambe caricando un file locale.
Mi rimane la domanda su dove possano essere spesi i 4 minuti che la 2.8.1 impiega per la prima traslazione. La 1.8 infatti carica i dati in 1 secondo, come gia’ detto, e trasla in 4 secondi.
E’ forse necessario nella 2.8.1 fare qualche altra operazione oltre ad aprire il file ed eseguire il codice che ho scritto? Devo registrare manualmente i layer o cose simili?
Grazie mille.
Saluti.
Pietro
···
2015-04-22 15:45 GMT+02:00 Luigi Pirelli <luipir@gmail.com>:
faccio una ipotesi alla cieca, non perdendo il tempo a leggere il
codice della 1.8
che le feature fossero caricate in cache nel momento del caricameto
del layer? vedo che fai iface.activeLayer() che attualmente passa dal
QgsMapLayerRegistry per “registrare” il layer in qgis. Se ricordo bene
era cosi’ anche allora… solo che ora ole feature vengono caricate
con intelligenza, cioe’ solo se servono, e questo permette di gestire
vettoriali di grosse dimensioni senza incorrere in problemi di
memoria.
un’altra ottimizzazione dipende dalla complessita’ delle features…
queste vengono semplificate lato provider quando la visualizzazione
non le necessita (tipo scala troppo affollata)… questo, se ricordo
bene non c’era nella 1.8 ed e’ stato aggiunto con il rendering
MultiThread… morale, appena caricato il layer e visualizzato a
bassa scala (o alta?.. mi confondo sempre) non e’ detto che hai
effettivamente preso le features… queste vengono prese solo se ne
hai effettivamente bisogno… conta che e’ un bel vantaggio in caso di
layer remoti.
morale… e’ cambiato il motore di fetch dei dati che e’ piu’ astuto
fai un po il confronto nel caricamento e visualizzazione del layer
nella 1.8 e 2.8
ciao e a presto, Luigi Pirelli
2015-04-22 15:14 GMT+02:00 Pietro Panzeri <pietro.panzeri@treuropa.com>:
Grazie mille per la risposta.
Ho provato ad usare il codice hai scritto e che utilizza la getFeatures().
Le cose sono effettivamente cambiate nel seguente modo:
la prima volta che faccio una traslazione ci impiega sempre 4minuti come
prima mentre dalla seconda volta ci impiega 20 secondi: ha effettivamente
messo in cache le geometrie.
La domanda quindi rimane aperta: come mai nella versione 1.8 gia’ la prima
esecuzione ha prestazioni ottime mentre nella 2.8.1 invece e’ necessario
popolare “esplicitamente” la cache con prestazioni notevolmente peggiori?
Pietro
2015-04-22 12:59 GMT+02:00 Luigi Pirelli <luipir@gmail.com>:
2015-04-22 11:06 GMT+02:00 Pietro Panzeri <pietro.panzeri@treuropa.com>:
translateFeature
il codice del translate e’ piuttosto semplice [1] attualmente percio’
penso a due aspetti
- senza andarmi a vedere il codice della 1.8 direi che prima avevi la
rob ain cache e ora no
- in cache potenzialment enon la hay visto che usi featureCount
invece che getFeatures()
- sconsiglio0 di usare un range su featureCount… non farei
assunzioni su quale debba essere la logica degli id delle feature
dentro QGIS => userei la classica
- la http://qgis.org/api/qgsvectorlayereditutils_8cpp_source.html#l00174
dice che se la geometria non e’ nella cache fa una getFeature ad hoc
=> fai una get feature ricreando l’iteratore ogni volta!..
for feat in vector.getFeatures():
fid = feat.id()
vlayer.translateFeature(fid, delta_x, delta_y)
prova e fai sapere
[1] http://qgis.org/api/qgsvectorlayereditutils_8cpp_source.html#l00164
a presto, Luigi Pirelli
–
Pietro Panzeri
Software Development Manager
Tele-Rilevamento Europa - T.R.E. srl
Ripa di Porta Ticinese, 79
20143 Milano – Italia
Tel.: +39.02.4343.121 - Fax: +39.02.4343.1230
pietro.panzeri@treuropa.com - www.treuropa.com
–
Pietro Panzeri
Software Development Manager
Tele-Rilevamento Europa - T.R.E. srl
Ripa di Porta Ticinese, 79
20143 Milano – Italia
Tel.: +39.02.4343.121 - Fax: +39.02.4343.1230
pietro.panzeri@treuropa.com - www.treuropa.com
non mi risulta ci siano da fare ulteriori passi... se i tuoi dati non
sono protetti da qualche licenza, sarebbe utile preparere un
caso/tiket per replicarlo
a presto, Luigi Pirelli
**************************************************************************************************
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Elance: https://www.elance.com/s/edit/luigipirelli/
* GitHub: https://github.com/luipir
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**************************************************************************************************
2015-04-22 17:23 GMT+02:00 Pietro Panzeri <pietro.panzeri@treuropa.com>:
Il caricamento e visualizzazione del layer sono paragonabili nelle versioni
1.8 e 2.8.1.
La 1.8 visualizza tutte le feature in un colpo solo mentre la 2.8.1 le
visualizza progressivamente pero' l'intera operazione dura 1 secondo per
entrambe caricando un file locale.
Mi rimane la domanda su dove possano essere spesi i 4 minuti che la 2.8.1
impiega per la prima traslazione. La 1.8 infatti carica i dati in 1 secondo,
come gia' detto, e trasla in 4 secondi.
E' forse necessario nella 2.8.1 fare qualche altra operazione oltre ad
aprire il file ed eseguire il codice che ho scritto? Devo registrare
manualmente i layer o cose simili?
Grazie mille.
Saluti.
Pietro
2015-04-22 15:45 GMT+02:00 Luigi Pirelli <luipir@gmail.com>:
faccio una ipotesi alla cieca, non perdendo il tempo a leggere il
codice della 1.8
che le feature fossero caricate in cache nel momento del caricameto
del layer? vedo che fai iface.activeLayer() che attualmente passa dal
QgsMapLayerRegistry per "registrare" il layer in qgis. Se ricordo bene
era cosi' anche allora... solo che ora ole feature vengono caricate
con intelligenza, cioe' solo se servono, e questo permette di gestire
vettoriali di grosse dimensioni senza incorrere in problemi di
memoria.
un'altra ottimizzazione dipende dalla complessita' delle features...
queste vengono semplificate lato provider quando la visualizzazione
non le necessita (tipo scala troppo affollata)... questo, se ricordo
bene non c'era nella 1.8 ed e' stato aggiunto con il rendering
MultiThread... morale, appena caricato il layer e visualizzato a
bassa scala (o alta?... mi confondo sempre) non e' detto che hai
effettivamente preso le features... queste vengono prese solo se ne
hai effettivamente bisogno... conta che e' un bel vantaggio in caso di
layer remoti.
morale... e' cambiato il motore di fetch dei dati che e' piu' astuto
fai un po il confronto nel caricamento e visualizzazione del layer
nella 1.8 e 2.8
ciao e a presto, Luigi Pirelli
**************************************************************************************************
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Elance: https://www.elance.com/s/edit/luigipirelli/
* GitHub: https://github.com/luipir
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**************************************************************************************************
2015-04-22 15:14 GMT+02:00 Pietro Panzeri <pietro.panzeri@treuropa.com>:
> Grazie mille per la risposta.
> Ho provato ad usare il codice hai scritto e che utilizza la
> getFeatures().
> Le cose sono effettivamente cambiate nel seguente modo:
> la prima volta che faccio una traslazione ci impiega sempre 4minuti come
> prima mentre dalla seconda volta ci impiega 20 secondi: ha
> effettivamente
> messo in cache le geometrie.
> La domanda quindi rimane aperta: come mai nella versione 1.8 gia' la
> prima
> esecuzione ha prestazioni ottime mentre nella 2.8.1 invece e' necessario
> popolare "esplicitamente" la cache con prestazioni notevolmente
> peggiori?
>
> Pietro
>
>
>
>
>
>
> 2015-04-22 12:59 GMT+02:00 Luigi Pirelli <luipir@gmail.com>:
>>
>> 2015-04-22 11:06 GMT+02:00 Pietro Panzeri
>> <pietro.panzeri@treuropa.com>:
>> > translateFeature
>>
>>
>> il codice del translate e' piuttosto semplice [1] attualmente percio'
>> penso a due aspetti
>>
>> 1) senza andarmi a vedere il codice della 1.8 direi che prima avevi la
>> rob ain cache e ora no
>> 2) in cache potenzialment enon la hay visto che usi featureCount
>> invece che getFeatures()
>> 3) sconsiglio0 di usare un range su featureCount... non farei
>> assunzioni su quale debba essere la logica degli id delle feature
>> dentro QGIS => userei la classica
>> 4) la
>> http://qgis.org/api/qgsvectorlayereditutils_8cpp_source.html#l00174
>> dice che se la geometria non e' nella cache fa una getFeature ad hoc
>> => fai una get feature ricreando l'iteratore ogni volta!...
>>
>> for feat in vector.getFeatures():
>> fid = feat.id()
>> vlayer.translateFeature(fid, delta_x, delta_y)
>>
>> prova e fai sapere
>>
>> [1] http://qgis.org/api/qgsvectorlayereditutils_8cpp_source.html#l00164
>>
>> a presto, Luigi Pirelli
>>
>>
>>
>> **************************************************************************************************
>> * LinkedIn: https://www.linkedin.com/in/luigipirelli
>> * Elance: https://www.elance.com/s/edit/luigipirelli/
>> * GitHub: https://github.com/luipir
>> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
>> * Mastering QGIS:
>> https://www.packtpub.com/application-development/mastering-qgis
>>
>>
>> **************************************************************************************************
>
>
>
>
> --
> Pietro Panzeri
>
> Software Development Manager
>
> Tele-Rilevamento Europa - T.R.E. srl
> Ripa di Porta Ticinese, 79
> 20143 Milano – Italia
> Tel.: +39.02.4343.121 - Fax: +39.02.4343.1230
> pietro.panzeri@treuropa.com - www.treuropa.com
--
Pietro Panzeri
Software Development Manager
Tele-Rilevamento Europa - T.R.E. srl
Ripa di Porta Ticinese, 79
20143 Milano – Italia
Tel.: +39.02.4343.121 - Fax: +39.02.4343.1230
pietro.panzeri@treuropa.com - www.treuropa.com
Il giorno Wed, 22 Apr 2015 15:45:40 +0200
Luigi Pirelli <luipir@gmail.com> ha scritto:
ciao Luigi (e Pietro);
sviluppando nel recente passato alcuni plugin (vectgeoref) ho risolto
problemi di lentezza e/o crash usando la libreria gdal-ogr
(python-gdal-1.3.0-3.1 sotto wheezy) che "sembra" migliorare nettamente
le cose;
premetto che la mia esperienza risale a qualche versione fa (2.5?) e
potrebbe essere obsoleta, ma credo che la cosa andrebbe approfondita ed
eventualmente segnalata alla lista dev; purtroppo le mie nulle risorse
non mi consentono di preparare test e raffronti utili e comunque
potrebbe essere un mio errore e quindi un falso allarme, ma se hai
tempo e voglia di fare qualche prova potrebbe essere interessante;
ciao e a presto, Luigi Pirelli
ciao e grazie,
giuliano
Ho inserito una nuova segnalazione nel BugReports di Qgis (Bug report #12629) dove e’ possibile scaricare i dati su cui ho fatto i vari test.
Pietro
···
2015-04-22 17:45 GMT+02:00 giulianc51 <giulianc51@gmail.com>:
Il giorno Wed, 22 Apr 2015 15:45:40 +0200
Luigi Pirelli <luipir@gmail.com> ha scritto:
ciao Luigi (e Pietro);
sviluppando nel recente passato alcuni plugin (vectgeoref) ho risolto
problemi di lentezza e/o crash usando la libreria gdal-ogr
(python-gdal-1.3.0-3.1 sotto wheezy) che “sembra” migliorare nettamente
le cose;
premetto che la mia esperienza risale a qualche versione fa (2.5?) e
potrebbe essere obsoleta, ma credo che la cosa andrebbe approfondita ed
eventualmente segnalata alla lista dev; purtroppo le mie nulle risorse
non mi consentono di preparare test e raffronti utili e comunque
potrebbe essere un mio errore e quindi un falso allarme, ma se hai
tempo e voglia di fare qualche prova potrebbe essere interessante;
ciao e a presto, Luigi Pirelli
ciao e grazie,
giuliano
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.
750 iscritti al 18.3.2015
–
Pietro Panzeri
Software Development Manager
Tele-Rilevamento Europa - T.R.E. srl
Ripa di Porta Ticinese, 79
20143 Milano – Italia
Tel.: +39.02.4343.121 - Fax: +39.02.4343.1230
pietro.panzeri@treuropa.com - www.treuropa.com