<div dir="ltr"><div>Boa noite,</div><div><br></div>Já dei uma leitura "pela rama" ao artigo. E tenho de concordar com o Ricardo quando diz que testar o software e compará-lo também é uma forma de contribuir. Agora, creio que comparar o desempenho de um software baseado em apenas no desempenho de 2 ferramentas, é um bocado limitador para depois se tirar conclusões válidas, e nisso acho que o artigo peca bastante. Sei que era só um exemplo, mas até que ponto as entidades públicas dependem do desempenho do Clip e em que aspecto poderá isso influenciar a decisão de optar ou não pelo OS?<div><br></div><div>Também achei estranho a permissa de que não seriam usadas ferramentas "externas" e plugins. O qgis depende em muito de plugins que mais do que contribuições isoladas da comunidade respondem a necessidades específicas de conjuntos de utilizadores, mas que estão bastante acessíveis. Vejo isso como uma vantagem, uma vez que o utilizador apenas instala os plugins que necessita, ao contrário do ArcGIS em que tens centenas de ferramentas instaladas que a maioria dos utilizadores nunca vão usar mas depois para fazer uma operação tão simples como uma diferença (Erase no arcgis) é necessário ter a  versão mais cara.</div><div><br><div>Não sei se está pensado uma continuação deste estudo, mas seria interessante uma comparação do software de uma forma mais robusta, incluindo, para além do desempenho, a disponibilidade de ferramentas, a facilidade de utilização ou user experience.</div><div><br></div><div>Para isso imagino definir umas quantas tarefas comuns a praticamente toda a gente necessita num SIG Desktop (e.g. adição, visualização e simbologia de dados geográficos de diferentes formatos; edição de dados vectoriais tanto as geometrias como os atributos; análise espacial (um processo como a definição da CRIF que implica diversos passos), algebra de mapas, preparação de layouts e impressão). Depois, para cada uma das tarefas averiguar o desempenho, a possibilidade ou não de desempenhar a tarefa e a facilidade de o fazer (medindo por exemplo o número de passos ou cliques necessários).</div><div><br></div><div>Depois então completar com a avaliação de custos. Que deveriam incluir o preço do software, da manutenção e da formação.</div><div><br></div><div>Obviamente cada entidade precisaria de fazer os seu próprio estudo baseado nas suas necessidades específicas, mas serviria para provar (ou não) se o software open source tem ou não capacidade para resolver grande parte das necessidades e com que consequências.</div><div><br></div><div>Será que algum aluno que fazer tese de mestrado sobre este assunto?</div><div><br></div><div>Cumprimentos,</div><div><br></div><div>Alexandre Neto</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-09-23 22:21 GMT+01:00 Pedro Venâncio <span dir="ltr"><<a href="mailto:pedrongvenancio@gmail.com" target="_blank">pedrongvenancio@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div>Olá Ricardo,<br><br></div>Deve haver algum engano na TAREFA A (Recorte do raster (CRIF) com base no limite administrativo do distrito de Coimbra)<span class=""><br><br>2) QGIS (Algoritmo desenvolvido em Python):<br>Menu Vector > Ferramentas de geoprocessamento > Cortar > Configurar e executar<br><br></span></div>Esta ferramenta do QGIS serve para fazer o recorte de vectores, que no fundo foi o que fizeram na TAREFA B.<br><br></div>Qual foi a ferramenta que realmente usaram? <br><br></div>Não é novidade que as ferramentas do menu Vector do QGIS têm problemas de performance. Como sabes, estas ferramentas pertenciam originalmente a um plugin denominado fTools, desenvolvido em Python. Creio que entretanto já foi feito o port para c++, mas não sei se foi de todas as ferramentas. Sei que estas ferramentas foram bastante refinadas numa versão empresarial do QGIS, mantida pela <span>Sourcepole, mas ainda não foi feito o backport </span><span><span>dessas melhorias </span>para o QGIS master. Talvez o developer meeting que se avizinha traga novidades nessa matéria.<br><br></span></div><span>Contudo, eu diria que o QGIS tem, neste momento, 3 ou 4 vias alternativas para cada uma das operações "básicas" de geoprocessamento, o que dá uma grande flexibilidade aos utilizadores. Concretamente para o recorte de rasters, tendo vectores como base, estou a ver:<br></span></div><span> - Clip raster by mask (usa o GDAL);<br></span></div><span> - Clip Grid with Polygon (usa as ferramentas do SAGA)<br></span></div><span> - Diversas formas através das ferramentas do GRASS (r.mask, r.resample, r.mapcalc)<br></span><div><div><div><div><div><span><br></span><div><div>Eu pessoalmente costumo usar <span>o Clip Grid with Polygon, que é bastante rápido. Mas não consigo descarregar os dados que vocês usaram, para testar.<br><br><br></span></div><div><span>Abraço,<br></span></div><div><span>Pedro Venâncio<br><br></span></div></div></div></div></div></div></div></div>
<br>_______________________________________________<br>
QGIS-pt mailing list<br>
<a href="mailto:QGIS-pt@lists.osgeo.org">QGIS-pt@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/qgis-pt" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/qgis-pt</a><br>
<br></blockquote></div><br></div>