[Gfoss] Fwd: QGIS 2.0.1-3

a.furieri a lqt.it a.furieri a lqt.it
Mar 22 Ott 2013 01:12:58 CEST


On Mon, 21 Oct 2013 12:47:53 -0700 (PDT), Silvio Grosso wrote:
> Salve a tutti,
>
> Ho provato a connettere lo stesso  database di SpatiaLite della 
> Regione
> Emilia Romagna (565 MB) su un altro computer molto piu' potente:
>
> Qgis 2 - 64 bit installato tramite l'installer Osgeo4W (NON quello
> stand-alone appena rilasciato)
> Windows 7 - Home edition
> CPU Intel i7-2630QM 2 GHz (8 CPUs)
> 8192 MB RAM
>
> Su questo computer funziona tutto bene nel senso che dopo la 
> connessione
> (sono necessari 3 minuti circa) le geometrie vengono visualizzate 
> nella
> Vista di Qgis correttamente.
> Funziona tutto anche se *molto* lentamente (es. spostare i layer tra 
> loro)
> ma ho letto recentemente che questo e' un "bug" gia' segnalato da 
> alcuni
> utenti su Windows per SpatiaLite in Qgis.
>
> Riguardo all'installer stand-alone di Qgis 2.0.1-3 (64 bit) da me 
> testato
> sull'altro computer (con "soli" di 2 giga di RAM ed una CPU Atom) 
> penso
> quindi che il problema sia dovuto verosimilmente a questo stesso 
> computer
> poco performante utilizzato per le prove.
>
> Considerando pero' i computer utilizzati spesso negli enti pubblici 
> temo che
> questo sia comunque un problema non indifferente :-(
> Spesso sono postazioni "antiquate" con hardware molto vecchio.
> Di conseguenza, potrebbero non reggere facilmente questo tipo di
> connessioni.
> Ovviamente, questo ultimo problema non e' imputabile a Qgis stesso 
> :-)
>

Ciao Silvio,

incuriosito dal tuo post sono andato a razzolare negli archivi ed alla
fine ho ritrovato esattamente quel DB di cui parli: RER-cc-by.sqlite

si tratta di un primo test preliminare fatto in occasione del rilascio
iniziale dei GeoOpenData da parte della RER; occupa 566 MB, ergo
suppongo che si tratti esattamente del medesimo DB che hai usato tu.

N.B.: si tratta di un DB nel vecchio formato v3, e contiene 
esattamente:
- 9 province
- 348 comuni
- 6.210 localita' abitate
- e ben 1.261.526 edifici (che non sono certo poca cosa)
- tutti i layer sono supportati da uno Spatial Index

io i miei tests li ho fatti su una macchina virtuale WinXP utilizzando
l'ultimissimo QGIS 2.0.1 installato stamattina da OSGeo4W.
il mio PC monta un Intel i5 quad-core 3.47 GHz con 4 GB RAM;
la virtual machine XP comunque riesce a vedere un singolo core e
solamente 1 GB RAM; non la definirei esattamente una configurazione
ultra-potente.

eccoti qua i mei personali risultati:
- durante la prima connessione di QGIS al DB si nota un attimo di
   incertezza; e' assolutamente normale se considerei che le ultime
   versioni del data-provider si basano sulle metatavole statistiche;
   quel vecchio DB in formato v3 non le supportava, e quindi per prima
   cosa il data-provider deve crearsi le statistiche.
   cronometro alla mano, ci impiega circa 10/15 secondi: nota bene,
   questo accade solo al momento della prima connessione; per tutte
   le connessioni a seguire ormai le tavole statistiche saranno gia'
   presenti e non ci saranno quindi ulteriori perditempo.

- a questo punto ho seguito due strade diverse:

- caso A: mi sono aperto province, comuni e localita' abitate
   evitando accuratamente gli edifici.
   poi ho fatto uno zoom sul centro di Bologna e solo a quel punto ho
   caricato anche gli edifici.
   in queste condizioni gira tutto bello liscio, e direi anche veloce
   in modo molto soddisfacente; zoom e pan filano decisamente fluidi
   senza alcuna incertezza.

- caso B: ho aperto tutti quanti i layer assieme al momento della
   connessione iniziale, edifici compresi.
   in queste condizioni il povero QGIS e' costretto a tracciarsi sullo
   schermo oltre 1 milione di poligoni, uno per ciascun singolo edificio
   (anche se poi di fatto sulla mappa full-extent si vede semplicemente
   una specie di grandinina nera, causa ovvi problemi di scala).
   ovviamente in queste condizioni decisamente "mission impossible" si
   nota un forte rallentamento; ma in circa 1 minuto ce la fa comunque
   a tracciare una schermata full-extent.
   provare a fare un pan full-extent con tutti i layer accesi e' 
naturalmente
   un'operazione di lentezza esasperante; ma basta semplicemente 
assegnare
   al pesantissimo layer "edifici" una soglia dinamica di 
visualizzazione
   piu' ragionevole e tutto torna immediatamente nei binari di una 
placida
   normalita' tranquillamente soddisfacente.

N.B.: anche il problema che segnali di una notevole lentezza quando
sposti l'ordine relativo dei layers mi pare che in ultima analisi
dipende esclusivamente dal numero dei poligoni che occorre tracciare
sullo schermo. se opero ad un livello di scala "ragionevole" anche
spostare il layer edici sopra-sotto e' un'operazione assolutamente
fluida e ben veloce; se invece opero in modo full-extent tenendo gli
edifici accesi diventa ovviamente di lentezza estenuante.

Venendo infine alle prestazioni decisamente penose che hai riscontrato
sul tuo Atom.
si tratta di un processore ultra-economico disegnato appositamente
per i tablets (ha un consumo decisamente irrisorio), spesso utilizzato
anche sui netbooks ma decisamente  sconsigliato per qualsiasi
applicazione "pesante" dalla stessa Intel.
dai pochi benchmarks che ho trovato in rete i migliori Atom parrebbero
essere comunque circa 4 o 6 volte piu' lenti di un tipico Core i3
(la fascia piu' bassa consigliata da Intel per i sistemi desktop
o laptop ultra-economici).

prova un po' a vedere cosa succede utilizzando una copia del DB che
contenga gia' le statistiche correttamente alimentate (basta solo
che tu lo connetti prima sull'altro PC e poi te lo copi sull'Atom).
e stando ovviamente ben attento ad attivare il pesante layer degli
edifici solo quando ti trovi ad una scala "ragionevole" (p.es. un
singolo quartiere, o meglio ancora giusto un paio di isolati).
e poi magari fammi sapere se noti qualche miglioramento o se
comunque continua a rimanere inutilizzabile per fini pratici
causa lentezza ultra-mortale: sono abbastanza curioso.

ciao Sandro



Maggiori informazioni sulla lista Gfoss