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

[Fernando Ribeiro]

Bom dia,

Sobre esta matéria acho que há 3 pontos a considerar para futuros
'benchmarks':

- 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 aqui
<http://www.donmeltz.com/arcgis-vs-qgis-clipping-contest-rematch/> e aqui
<http://courses.neteler.org/arcgis-vs-qgis-etc-clipping-contest-rematch-revisited/>.
Se era um dos principais focos do documento, deveria haver mais
investimento aqui.

- 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.

- 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.


Cumprimentos,
Fernando Ribeiro

No dia 24 de Setembro de 2014 às 01:19, duartecarreira <dncarreira at gmail.com
> escreveu:

> Boa noite a todos. Grande debate!
>
> Eu posso afirmar com toda a certeza que consigo "encravar" todos os
> programas sig que uso, desde o qgis, ao arcgis, ao autocad map. Todos. E
> não
> é preciso muito esforço...
>
> "Ainda sou do tempo..." em que se avaliavam os programas seguindo uma
> colecção enorme de operações. Isso sim é que eram avaliações profundas, tão
> profundas que até se perdia de vista o objectivo - escolher a ferramenta
> que
> melhor servia as nossas necessidades. O produto A tinha 39 pontos, o
> produto
> B tinha 30. Ganhava o produto A mesmo que fosse pior nas funções que se
> usavam em 99% das vezes. Enfim...
>
> Isto para dizer que comparações destas são sempre informativas, mas também
> são quase sempre injustas. Se tivéssemos comparado a velocidade de fazer um
> merge de um conjunto enorme de ortos, ganhava o qgis de longe. Mas isso
> faria do qgis "o melhor" produto?
>
> Se não tiver dinheiro para software, esperar 30min se calhar não é assim
> tão
> mau... se tiver €, e optar por uma estratégia assente em open source, então
> posso aplicar esse € na diminuição desses 30min. Se optar por uma
> estratégia
> assente em closed source, então posso aplicar esse € em licenças (claro que
> nesta lista esta opção não se coloca ;) e rezar para não descobrir um bug
> bloqueante.
>
> Por outro lado, se um técnico que tem a função de decidir qual o melhor
> produto para a sua organização se fica pela comparação de um clip
> vectorial,
> então estará a fazer um mau serviço. E os maus serviços mais cedo ou mais
> tarde têm um preço...
>
> Ricardo, eu acho que tu colocas as coisas de forma um pouco rude, o que é
> contraproducente. No fim, não percebo onde queres chegar, qual é a mensagem
> que queres passar...
> Não percebo para que foi a observação dos cores usados no qgis para
> geoproc... dos produtos em análise, algum faz geoproc com mais de 1 core?
> que eu saiba não... mandar trabalhos de casa para os devs também não serve
> de nada, são apenas tiros para o ar e ruído. Para seres/sermos útil o ideal
> seria ajudares a resolver esse (ou outro) problema, quer com donativos,
> contratação de serviços, ou programação. No mínimo, qualquer um pode ajudar
> a identificar as causas para cada problema. Dizer que não faz sentido ter
> multithread no display e não no geoproc é um pouco rude e no limite
> absurdo.
> As coisas avançam por etapas, não aparece tudo feito por magia... na v2.2
> não havia multithread em nada. na v2.4 há no display, and so on. haja fé,
> irmão!
>
> Venham mais estudos e análises. Somos todos informados, e podemos fazer
> sugestões de melhoria, investigar problemas detectados, propor novos
> estudos, etc., etc.
>
> Agora, convinha tirar daqui alguma coisa útil... e já estão todos a
> discutir. Afinal, qual é o problema? a dimensão dos dados? está
> identificado? em que ticket? qual é o tamanho dos dados que geralmente é a
> barreira? o que podem os utilizadores fazer nesses casos (partir em pedaços
> mais pequenos?)? está agendada uma solução ou não é para já?
>
> Live long and prosper.
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/1as-Jornadas-Lusofonas-CTIG-2014-Coimbra-11-a-13-Setembro-2014-tp5162210p5163615.html
> Sent from the QGIS-pt mailing list archive at Nabble.com.
> _______________________________________________
> QGIS-pt mailing list
> QGIS-pt at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/qgis-pt
>



-- 
Fernando Ribeiro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-pt/attachments/20140924/b63d4e11/attachment-0001.html>