<div dir="ltr"><div><div><div>Bom dia,<br><br>Sobre esta matéria acho que há 3 pontos a considerar para futuros 'benchmarks':<br><br></div>- Testar a performance de 3 softwares com base em apenas uma rotina é no mínimo redutor. Já para não falar que poderá derivar resultados contraditórios. Ver <a href="http://www.donmeltz.com/arcgis-vs-qgis-clipping-contest-rematch/">aqui</a> e <a href="http://courses.neteler.org/arcgis-vs-qgis-etc-clipping-contest-rematch-revisited/">aqui</a>. Se era um dos principais focos do documento, deveria haver mais investimento aqui.<br><br></div>- Um bom técnico de SIG, para além de utilizar as técnicas tem de conhecer minimamente o software que utiliza. Assim, no enquadramento do Pedro Venâncio, deveria haver algum sentido crítico na escolha da técnica utilizada...ou em alternativa, as várias técnicas que no QGis existem disponíveis para realizar tarefas de 'clipping' e respectivos tempos.<br><br></div><div>- O mérito deste documento é que revela a necessidade da existência de testes de performance sobre os softwares SIG, sendo que estes poderão ser essenciais na tomada de decisão sobre a sua 'aquisição'/utilização. No passado lembro-me de haver também algum 'ruído' relativo a um bechmark entre PostGIS/Oracle.<br><br><br></div><div>Cumprimentos,<br></div><div>Fernando Ribeiro<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">No dia 24 de Setembro de 2014 às 01:19, duartecarreira <span dir="ltr"><<a href="mailto:dncarreira@gmail.com" target="_blank">dncarreira@gmail.com</a>></span> escreveu:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Boa noite a todos. Grande debate!<br>
<br>
Eu posso afirmar com toda a certeza que consigo "encravar" todos os<br>
programas sig que uso, desde o qgis, ao arcgis, ao autocad map. Todos. E não<br>
é preciso muito esforço...<br>
<br>
"Ainda sou do tempo..." em que se avaliavam os programas seguindo uma<br>
colecção enorme de operações. Isso sim é que eram avaliações profundas, tão<br>
profundas que até se perdia de vista o objectivo - escolher a ferramenta que<br>
melhor servia as nossas necessidades. O produto A tinha 39 pontos, o produto<br>
B tinha 30. Ganhava o produto A mesmo que fosse pior nas funções que se<br>
usavam em 99% das vezes. Enfim...<br>
<br>
Isto para dizer que comparações destas são sempre informativas, mas também<br>
são quase sempre injustas. Se tivéssemos comparado a velocidade de fazer um<br>
merge de um conjunto enorme de ortos, ganhava o qgis de longe. Mas isso<br>
faria do qgis "o melhor" produto?<br>
<br>
Se não tiver dinheiro para software, esperar 30min se calhar não é assim tão<br>
mau... se tiver €, e optar por uma estratégia assente em open source, então<br>
posso aplicar esse € na diminuição desses 30min. Se optar por uma estratégia<br>
assente em closed source, então posso aplicar esse € em licenças (claro que<br>
nesta lista esta opção não se coloca ;) e rezar para não descobrir um bug<br>
bloqueante.<br>
<br>
Por outro lado, se um técnico que tem a função de decidir qual o melhor<br>
produto para a sua organização se fica pela comparação de um clip vectorial,<br>
então estará a fazer um mau serviço. E os maus serviços mais cedo ou mais<br>
tarde têm um preço...<br>
<br>
Ricardo, eu acho que tu colocas as coisas de forma um pouco rude, o que é<br>
contraproducente. No fim, não percebo onde queres chegar, qual é a mensagem<br>
que queres passar...<br>
Não percebo para que foi a observação dos cores usados no qgis para<br>
geoproc... dos produtos em análise, algum faz geoproc com mais de 1 core?<br>
que eu saiba não... mandar trabalhos de casa para os devs também não serve<br>
de nada, são apenas tiros para o ar e ruído. Para seres/sermos útil o ideal<br>
seria ajudares a resolver esse (ou outro) problema, quer com donativos,<br>
contratação de serviços, ou programação. No mínimo, qualquer um pode ajudar<br>
a identificar as causas para cada problema. Dizer que não faz sentido ter<br>
multithread no display e não no geoproc é um pouco rude e no limite absurdo.<br>
As coisas avançam por etapas, não aparece tudo feito por magia... na v2.2<br>
não havia multithread em nada. na v2.4 há no display, and so on. haja fé,<br>
irmão!<br>
<br>
Venham mais estudos e análises. Somos todos informados, e podemos fazer<br>
sugestões de melhoria, investigar problemas detectados, propor novos<br>
estudos, etc., etc.<br>
<br>
Agora, convinha tirar daqui alguma coisa útil... e já estão todos a<br>
discutir. Afinal, qual é o problema? a dimensão dos dados? está<br>
identificado? em que ticket? qual é o tamanho dos dados que geralmente é a<br>
barreira? o que podem os utilizadores fazer nesses casos (partir em pedaços<br>
mais pequenos?)? está agendada uma solução ou não é para já?<br>
<br>
Live long and prosper.<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://osgeo-org.1560.x6.nabble.com/1as-Jornadas-Lusofonas-CTIG-2014-Coimbra-11-a-13-Setembro-2014-tp5162210p5163615.html" target="_blank">http://osgeo-org.1560.x6.nabble.com/1as-Jornadas-Lusofonas-CTIG-2014-Coimbra-11-a-13-Setembro-2014-tp5162210p5163615.html</a><br>
<span class="im HOEnZb">Sent from the QGIS-pt mailing list archive at Nabble.com.<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div>Fernando Ribeiro</div></div>
</div>