[QGIS-pt] 1as Jornadas Lusófonas CTIG 2014 - Coimbra - 11 a 13 Setembro 2014

[Ricardo Pinho]

Viva,

No dia 23 de Setembro de 2014 às 12:42, Giovanni Manghi <
giovanni.manghi  faunalia.pt> escreveu:

> > Seria interessante que os membros deste grupo lessem com atenção este
> artigo
> > e contribuissem com sugestões e criticas construtivas para o tornar ainda
> > mais util.
>
> ainda não tive tempo de ler com atenção, no o caso iremos com certeza
> dar sugestões.
>

Não é preciso muito tempo, é muito simples:

Dados:
- *Carta de Risco de Incêndio Florestal (CRIF), 2011, em formato TIFF* (um
raster com 247MB) e em formato Shapefile (um documento vectorial com 1,33
GB e, aproximadamente, 3 500 000 de features), ambos disponíveis no endereço
http://scrif.igeo.pt/cartografiacrif/2007/crif07.htm.

- *Carta Administrativa e do Ordenamento de Portugal (CAOP), 2013, em
formato Shapefile* ( um documento vectorial com 52,4 MB e 3224 features),
disponível no endereço
http://www.dgterritorio.pt/ficheiros/cadastro/caop/caop_download/caop_2013_0/contaadcaop2013_zip

Tarefas de geoprocessamento utilizadas:

*TAREFA A)* Recorte do raster (CRIF) com base no limite administrativo do
distrito de Coimbra (depois de efectuado um dissolve das freguesias - fonte
CAOP, 2013)

Algoritmos/comandos utilizados:

1) Software Proprietário (Algoritmo desenvolvido em Python):
Toolbox > Data Management tools > Raster > Raster Processing > Clip >
Configurar e executar

2) QGIS (Algoritmo desenvolvido em Python):
Menu Vector > Ferramentas de geoprocessamento > Cortar > Configurar e
executar

3) gvSIG (Algoritmo desenvolvido em Java):

Camada Raster > Raster layer > Area of Interest (configurar com a shp
distrito) > Camada Raster > Raster Process > Filter > Mask > add mask >
seleccionar Region of Interest (ROI) previamente definida > Configurar
(assinalar "generate file") e executar

*TAREFA B)* Corte topológico do vector (CRIF) com base no limite
administrativo do distrito de Coimbra (depois de efectuado um dissolve das
freguesias - fonte CAOP, 2013)

Algoritmos/comandos utilizados:

1) Software Proprietário (Algoritmo desenvolvido em Python):
Toolbox > Analysis tools > Extract > Clip > Configurar e executar

2) QGIS (Algoritmo desenvolvido em Python):
Menu Vector > Ferramentas de geoprocessamento > Cortar > Configurar e
executar

3) gvSIG (Algoritmo desenvolvido em Java):
Toolbox (Sextante) > Tools for vector layers > Clip > Configurar e executar




*RESULTADOS:TAREFA A)*Máquina 1 Máquina 2 Máquina 3 Máquina 4 Máquina
5 Máquina 6 Máquina 7 Máquina 8 Máquina 9

Software PROPRIETÁRIO 10.2
5s 5s 8,5s 4,8s 12s 2,8s 3s 3,9s 9s
QGIS 2.2
2,5s 2,8s 4s 2,7s 7s 2s 1, 8s 2,4s 9s
gvSIG 2.0
> 30m > 30m > 30m > 30m > 30m > 30m > 30m > 30m > 30m


*TAREFA B)*Máquina 1 Máquina 2 Máquina 3 Máquina 4 Máquina 5 Máquina
6 Máquina 7 Máquina 8 Máquina 9

Software PROPRIETÁRIO 10.2
2m 4s 1m 56s 11m 35s 2m 32s 6m 1s 1m 50s 1m 40s 2m 21s 8m 51s
QGIS 2.2
> 30m > 30m > 30m > 30m > 30m > 30m > 30m > 30m > 30m
gvSIG 2.0
> 30m 28m 17s > 30m > 30m > 30m 26m 48s > 30m 29m 50s > 30m


> porque tanto esforço em avaliar/julgar o software e assim tão pouco
> para contribuir na seu efectivo melhoramento?
>

Desculpa Giovanni, mas discordo totalmente.

Para mim, testar e avaliar é um dos melhores contributos que se pode dar!
Quem dera que mais o fizessem!
O que seria dos programas e dos programadores sem os beta-testers?
Os resultados não são bons? Ainda bem, é sinal de que há muito a melhorar.
;-)

E é bom que se enquadre corretamente este estudo,
numa disciplina de um curso, feito por estudantes interessados em aprender
a usar software livre SIG.
Alguem conhece melhor forma de aprender a usar software do que a testá-lo?
Eu não conheço, foi assim que aprendi toda a minha vida.


no caso especifico, foram de facto verificar se os problemas de
> desempenho do QGIS são de apontar ao QGIS mesmo ou a uma das
> bibliotecas de base?


Não se tratou de atribuir culpas ou descobrir as causas, tratou-se de
avaliar o desempenho no ponto de vista do utilizador final.
Talvez seja tempo de acabar com o pesadelo dos "The Inmates Are Running the
Asylum
<http://www.amazon.co.uk/Inmates-Are-Running-Asylum-Products-ebook/dp/B000OZ0N62/ref=sr_1_1?ie=UTF8&qid=1411498874&sr=8-1&keywords=inmate+are+running+the>"**
e desenvolver produtos pensando no ponto de vista do utilizador. Foi isso
que levou o steve ao sucesso e livrou-nos do inmate bill !!!
Mas claro, desenvolver software simples, rápido e util de usar, tem os seus
custos.


> Por exemplo: para muitas operações de
> geoprocessamento vectorial o QGIS usa GEOS, e nalguns casos é GEOS a
> ser lento (teste: a mesma operação feita no PostGIS demora o mesmo
> tempo, pois PostGIS também usa GEOS).
>

É verdade, GEOS é usada por muitos, é livre, é lenta, talvez seja tempo de
melhorá-la...

A propósito, aqui fica também mais uma perguntinha minha:


*de que vale ter um QGIS multi-core quando nas suas operações de
geoprocessamento só é usado 1/4 de core? *

Um contributo para o debate.
Abraço,
-- 
Ricardo Pinho


*** how talented people continuously design bad software-based products and
why we need technology to work the way average people think*


> --
> Giovanni Manghi
> Faunalia.pt
> Sistemas de Informação Geográfica Open Source
> Portugal
>
> Web: http://www.faunalia.pt
> Email & Jabber: giovanni.manghi  faunalia.pt
> PGP Key available
> Tel. + 351 96 7058216
> --
> _______________________________________________
> QGIS-pt mailing list
> QGIS-pt  lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/qgis-pt
>
-------------- próxima parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.osgeo.org/pipermail/qgis-pt/attachments/20140923/44e06c1e/attachment.html>