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

Caros colegas,

Decorreram na passada semana em Coimbra-Portugal, as “1as Jornadas Lusófonas de Ciências e Tecnologias de Informação Geográfica”.

Alguns links:

Site oficial:
http://ctig2014.dei.uc.pt/

Reportagem na tv-u.coimbra
http://ucv.uc.pt/ucv/podcasts/universo-uc/primeiras-jornadas-de-informacao-geografica-na-uc

O programa
http://ctig2014.dei.uc.pt/CTIG2014/downloads/CTIG2014_Programa_v17.pdf

Tive o privilégio de participar neste interessantissimo e cheio de sucesso evento, principalmente pela possibilidade de conhecer e trocar experiencias entre colegas de diferentes continentes e países, que partilham a paixão pela informação geográfica e a mesma lingua (Portugues).

A organização e os oradores estão todos de parabéns, e graças ao sucesso alcançado tudo indica que daqui a 2 anos este evento se irá repetir!

Cumprimentos,


Ricardo Pinho

Olá Ricardo,

Vão disponibilizar as apresentações?

Estou particularmente curioso por ver a da “Jangada de SIG na administração pública portuguesa”!

Obrigado!

Abraço,

Pedro

···

No dia 16 de Setembro de 2014 às 22:12, Ricardo Pinho <ricardodepinho@gmail.com> escreveu:

Caros colegas,

Decorreram na passada semana em Coimbra-Portugal, as “1as Jornadas Lusófonas de Ciências e Tecnologias de Informação Geográfica”.

Alguns links:

Site oficial:
http://ctig2014.dei.uc.pt/

Reportagem na tv-u.coimbra
http://ucv.uc.pt/ucv/podcasts/universo-uc/primeiras-jornadas-de-informacao-geografica-na-uc

O programa
http://ctig2014.dei.uc.pt/CTIG2014/downloads/CTIG2014_Programa_v17.pdf

Tive o privilégio de participar neste interessantissimo e cheio de sucesso evento, principalmente pela possibilidade de conhecer e trocar experiencias entre colegas de diferentes continentes e países, que partilham a paixão pela informação geográfica e a mesma lingua (Portugues).

A organização e os oradores estão todos de parabéns, e graças ao sucesso alcançado tudo indica que daqui a 2 anos este evento se irá repetir!

Cumprimentos,


Ricardo Pinho


QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/qgis-pt

Viva Pedro,

Está previsto os artigos serem publicados nas “Atas das I Jornadas Lusófonas de Ciências e Tecnologias de Informação Geográfica”, divulgados nas plataformas de conteúdos digitais da Imprensa da Universidade de Coimbra.

Relativamente aos slides das apresentações, não tenho informação se vai ser possivel publicá-los.

Mas é uma questão de aguardar um pouco.

Em relação a essa apresentação em particular, vou ver o que posso fazer.

Pois considero que merece uma especial atenção de todos os inscritos nesta lista… :wink:

Só foi mesmo pena o Giovanni (Faunalia) não ter podido estar presente na sessão das oficinas de trabalho prevista para apresentação das soluções QGIS. Foi uma oportunidade perdida para divulgar esta alternativa a muitos lusofonos que aparentemente não a conheciam.

Abraço,

Ricardo Pinho

···

No dia 16 de Setembro de 2014 às 22:53, Pedro Venâncio <pedrongvenancio@gmail.com> escreveu:

Olá Ricardo,

Vão disponibilizar as apresentações?

Estou particularmente curioso por ver a da “Jangada de SIG na administração pública portuguesa”!

Obrigado!

Abraço,

Pedro


QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/qgis-pt


Ricardo Pinho

No dia 16 de Setembro de 2014 às 22:12, Ricardo Pinho <ricardodepinho@gmail.com> escreveu:

Caros colegas,

Decorreram na passada semana em Coimbra-Portugal, as “1as Jornadas Lusófonas de Ciências e Tecnologias de Informação Geográfica”.

Alguns links:

Site oficial:
http://ctig2014.dei.uc.pt/

Reportagem na tv-u.coimbra
http://ucv.uc.pt/ucv/podcasts/universo-uc/primeiras-jornadas-de-informacao-geografica-na-uc

O programa
http://ctig2014.dei.uc.pt/CTIG2014/downloads/CTIG2014_Programa_v17.pdf

Tive o privilégio de participar neste interessantissimo e cheio de sucesso evento, principalmente pela possibilidade de conhecer e trocar experiencias entre colegas de diferentes continentes e países, que partilham a paixão pela informação geográfica e a mesma lingua (Portugues).

A organização e os oradores estão todos de parabéns, e graças ao sucesso alcançado tudo indica que daqui a 2 anos este evento se irá repetir!

Cumprimentos,


Ricardo Pinho


QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/qgis-pt

Em relação a essa apresentação em particular, vou ver o que posso fazer.

Pois considero que merece uma especial atenção de todos os inscritos nesta
lista... :wink:

É isso Ricardo, estamos curiosos! :slight_smile:

Abraço!
Pedro

Ricardo Pinho-3 wrote

Tive o privilégio de participar neste interessantissimo e cheio de sucesso
evento, principalmente pela possibilidade de conhecer e trocar
experiencias entre colegas de diferentes continentes e países, que
partilham a paixão pela informação geográfica e a mesma lingua
(Portugues).

A organização e os oradores estão todos de parabéns, e graças ao sucesso
alcançado tudo indica que daqui a 2 anos este evento se irá repetir!

Concordo inteiramente, para mim também foi um privilégio participar neste
evento, foi bom regressar às minhas antigas salas de aula e renovar e
adquirir conhecimentos e melhor ainda o convívio lusófono!

Há que congratular todos, desde a organização, aos oradores, passando pelos
participantes e "apoiantes"!

Os temas foram interessantes e falou-se muito de open source e OSM o que
considero um bom sinal.

Ricardo Pinho-3 wrote

Só foi mesmo pena o Giovanni (Faunalia) não ter podido estar presente na
sessão das oficinas de trabalho prevista para apresentação das soluções
QGIS. Foi uma oportunidade perdida para divulgar esta alternativa a muitos
lusofonos que aparentemente não a conheciam.

Sim, também tive muita pena... havia muita curiosidade e seria uma boa
oportunidade de divulgação.

Mas como disse o tema foi falado muitas vezes apenas não houve uma
apresentação tão dirigida!
A apresentação "Jangada de SIG na administração pública portuguesa" foi uma
das que mais gerou "discussão" e o tempo foi curto para todos os que
desejavam colocarem as suas questões ou opiniões.

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/1as-Jornadas-Lusofonas-CTIG-2014-Coimbra-11-a-13-Setembro-2014-tp5162210p5162397.html
Sent from the QGIS-pt mailing list archive at Nabble.com.

Caros,

Embora esteja garantido que esta informação será publicada futuramente pela Univ. Coimbra, decidiu-se, com a aprovação do Prof. Dr. José Gomes, antecipar a disponibilização ao grupo QGIS dos textos finais e os slides do artigo:
“Jangada de SIG na Administração Pública Portuguesa”
https://dl.dropboxusercontent.com/u/1236917/jangada/Jangada%20de%20SIG_final.pdf
https://dl.dropboxusercontent.com/u/1236917/jangada/Jangada%20de%20SIG%20APP.odp

Considero que este deve ser visto como um pontapé de saída de um debate que deve ser contínuo, na escolha entre soluções de software livre e software proprietário.

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.

Saliento o teste comparativo de geoprocessamento que se realizou entre diversas soluções:

a) Proprietário “X” (versão 10.2);
b) QuantumGIS, futuramente designada apenas por “QGIS” (versão 2.2);
c) gvSIG (versão 2.0);
d) PostgreSQL/PostGIS.

Lanço aqui algumas perguntas para lançar o debate:

  • Será que se poderia alcançar melhor desempenho com o QGIS?

  • Não seria preferível fazer um exercicio diferente para medir o desempenho?

  • Porque o desempenho do software proprietário em alguns testes ficou tão acima do desempenho do software livre?

Abraço,

Ricardo Pinho

···

No dia 17 de Setembro de 2014 às 00:42, Pedro Venâncio <pedrongvenancio@gmail.com> escreveu:


QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/qgis-pt


Ricardo Pinho

Em relação a essa apresentação em particular, vou ver o que posso fazer.

Pois considero que merece uma especial atenção de todos os inscritos nesta lista… :wink:

É isso Ricardo, estamos curiosos! :slight_smile:

Abraço!

Pedro

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.

Saliento o teste comparativo de geoprocessamento que se realizou entre
diversas soluções:

a) Proprietário “X” (versão 10.2);
b) QuantumGIS, futuramente designada apenas por “QGIS” (versão 2.2);
c) gvSIG (versão 2.0);
d) PostgreSQL/PostGIS.

Lanço aqui algumas perguntas para lançar o debate:
- Será que se poderia alcançar melhor desempenho com o QGIS?
- Não seria preferível fazer um exercicio diferente para medir o desempenho?
- Porque o desempenho do software proprie

eu repondo com perguntas... :slight_smile:

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

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

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

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:

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

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”** 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

Olá Ricardo,

Deve haver algum engano na TAREFA A (Recorte do raster (CRIF) com base no limite administrativo do distrito de Coimbra)

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

Esta ferramenta do QGIS serve para fazer o recorte de vectores, que no fundo foi o que fizeram na TAREFA B.

Qual foi a ferramenta que realmente usaram?

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 Sourcepole, mas ainda não foi feito o backport dessas melhorias para o QGIS master. Talvez o developer meeting que se avizinha traga novidades nessa matéria.

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:

  • Clip raster by mask (usa o GDAL);

  • Clip Grid with Polygon (usa as ferramentas do SAGA)

  • Diversas formas através das ferramentas do GRASS (r.mask, r.resample, r.mapcalc)

Eu pessoalmente costumo usar o Clip Grid with Polygon, que é bastante rápido. Mas não consigo descarregar os dados que vocês usaram, para testar.

Abraço,

Pedro Venâncio

Boa noite,

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?

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.

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.

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

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.

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.

Será que algum aluno que fazer tese de mestrado sobre este assunto?

Cumprimentos,

Alexandre Neto

···

2014-09-23 22:21 GMT+01:00 Pedro Venâncio <pedrongvenancio@gmail.com>:

Olá Ricardo,

Deve haver algum engano na TAREFA A (Recorte do raster (CRIF) com base no limite administrativo do distrito de Coimbra)

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

Esta ferramenta do QGIS serve para fazer o recorte de vectores, que no fundo foi o que fizeram na TAREFA B.

Qual foi a ferramenta que realmente usaram?

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 Sourcepole, mas ainda não foi feito o backport dessas melhorias para o QGIS master. Talvez o developer meeting que se avizinha traga novidades nessa matéria.

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:

  • Clip raster by mask (usa o GDAL);

  • Clip Grid with Polygon (usa as ferramentas do SAGA)

  • Diversas formas através das ferramentas do GRASS (r.mask, r.resample, r.mapcalc)

Eu pessoalmente costumo usar o Clip Grid with Polygon, que é bastante rápido. Mas não consigo descarregar os dados que vocês usaram, para testar.

Abraço,

Pedro Venâncio


QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/qgis-pt

Boas,

Achei muito interessante esta iniciativa do Ricardo Pinho (e dos restantes elementos do grupo), principalmente pq nos encontramos numa fase em que diversas Associações de Municípios e/ou Municípios com eventuais contratos de manutenção caducados ou em vias de renovação e que dadas as circunstâncias ponderam desistir do habitual SOFTWARE PROPRIETÁRIO, começam a reflectir sobre o que fazer e para tal investigam sobre a experiência de outros…

Um estudo como este, tv mais completo, tal como diz o André (incluindo custos), aliado a isso a partilha de experiência de elementos de autarquias (identificação de casos de sucesso) e de outros utilizadores de OS, poderá ser uma mais valia para aquilo que estamos aqui a defender (neste caso o QGIS e o OS em geral)

Relativamente ao QGIS, eu como funcionário de uma autarquia, da experiência que tenho de outros colegas de outras câmara e/ou assoc de município é a do medo de desistir do SOFT PROP 10.2 e avançar para o QGIS por falta de confiança no seu funcionamento pleno… existe o receio daquela velha frase, “O barato sai caro”. Aliado a isso temos a influência que a empresa do SOFT 10 faz junto dos utilizadores com o seu encontro anual, com um marketing brutal…

Já que as políticas neste país não incentivam definitivamente o uso do OS, direccionando as verbas das anteriores licenças para o apoio ao desenvolvimento do OS ou desenvolvimento de apps baseadas em OS, resta-nos a nós PROMOVER O SEU USO e provar e/ou demonstrar que realmente funciona…

Atualmente o QGIS tem um suporte, quase que diria mais eficiente que o SOFT 10, graças ao esforço de alguns elementos da lista, que não vale a pena enunciar (a eles obrigado pelo esforço). Caso os potenciais utilizadores do QGIS tivessem conhecimento disso, certamente o nº de utilizadores iria aumentar.

Tal como diz o André, era interessante um trabaho profundo sobre isto, certamente não seria trabalho para um aluno…

Cumprimentos,
Pedro

···

2014-09-24 0:09 GMT+01:00 Alexandre Neto <senhor.neto@gmail.com>:

Boa noite,

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?

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.

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.

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

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.

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.

Será que algum aluno que fazer tese de mestrado sobre este assunto?

Cumprimentos,

Alexandre Neto


QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/qgis-pt

Pedro Pereira

2014-09-23 22:21 GMT+01:00 Pedro Venâncio <pedrongvenancio@gmail.com>:

Olá Ricardo,

Deve haver algum engano na TAREFA A (Recorte do raster (CRIF) com base no limite administrativo do distrito de Coimbra)

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

Esta ferramenta do QGIS serve para fazer o recorte de vectores, que no fundo foi o que fizeram na TAREFA B.

Qual foi a ferramenta que realmente usaram?

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 Sourcepole, mas ainda não foi feito o backport dessas melhorias para o QGIS master. Talvez o developer meeting que se avizinha traga novidades nessa matéria.

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:

  • Clip raster by mask (usa o GDAL);

  • Clip Grid with Polygon (usa as ferramentas do SAGA)

  • Diversas formas através das ferramentas do GRASS (r.mask, r.resample, r.mapcalc)

Eu pessoalmente costumo usar o Clip Grid with Polygon, que é bastante rápido. Mas não consigo descarregar os dados que vocês usaram, para testar.

Abraço,

Pedro Venâncio


QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/qgis-pt

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

Obrigado Pedro, pela opinião.

Devo desde já esclarecer que todo o mérito do trabalho deve ser atribuído ao Prof. Dr. JOSÉ GOMES e aos alunos:
Joaquim PATRIARCA, Sara CANILHO, João André SACRAMENTO, Ricardo CORREIA, António Padez CASTRO,Sara SANTOS. Eu apenas dei uma pequena ajuda e “apoio moral”! :wink:

É verdade que o trabalho poderia e merecia ser muito mais profundo.

Mas, e contra mim falo, eles tiveram a coragem de mesmo sabendo que não conseguiam fazer um trabalho perfeito, foram em frente e fizeram ALGUMA COISA, em vez de não fazer nada!

E já agora deixo no ar a pergunta:" Quem deveria fazer este tipo de estudo?"
e arriscaria uma resposta: O Governo? A DGT? A AMA? A ANMP? Os Municípios? a OSGEO-PT?

Uma coisa é certa, os alunos foram os que mais ficaram a ganhar, pelo envolvimento e empenho que tiveram. De certeza que esta experiencia e a participação nas Jornadas, deixaram marcas na sua aprendizagem e perceberam um pouco melhor o que é software livre. Sem ilusões e fantasias, mas compreendendo as suas vantagens e dificuldades.

Quanto aos maus habitos dos funcionários publicos (eu tambem sou um!) é bom que comecem a livrar-se deles, por respeito ao povo portugues, que depois vai pagar a factura (com pobreza, desemprego e emigração) desse tipo de despesismos exarcebados. Hoje já ninguem tolera mais isso!

E mesmo sendo muito discutiveis os resultados do estudo, eles serviram para mais uma vez se falar sobre este assunto do software e ficarmos atentos, porque apesar da crise, parece que o software livre não tem vingado muito em Portugal, pelo contrário!!!

Deixo aqui algumas notas do testemunho de alguem que acredita na causa e tenta dar o seu contributo:
http://www.rtp.pt/play/p401/e166277/cientifica-mente
http://tek.sapo.pt/noticias/negocios/estado_gastou_24_m_em_software_de_informacao_1407609.html
http://www.revistainvest.pt/pt/Estudo-revela-que-Estado-pode-poupar-milhoes-com-software-livre/A598

E para terminar, se me perguntassem o que acho que deveria ser feito para travar esta situação. Muito simples!

AVALIAÇÂO DO RETORNO DO INVESTIMENTO DAS DESPESAS FEITAS (NO PASSADO E PRESENTE) EM SIG POR ESSE PAÍS. (espero que o tribunal de contas me esteja a ouvir)

Ir caso a caso ver quanto se gastou e o que se obteve. Valeu a pena? Não valeu? Relatar!

Só assim se garantirá que no futuro se tenha mais cuidado e se evite repetições escandalosas.

Porque esta má fama, é prejudicial a todos nós que trabalhamos nesta área e cabe a nós defender a nossa honra e ética profissional.

Cumprimentos,

RP

···

No dia 24 de Setembro de 2014 às 00:37, Pedro Pereira <pedromap@gmail.com> escreveu:

Boas,

Achei muito interessante esta iniciativa do Ricardo Pinho (e dos restantes elementos do grupo), principalmente pq nos encontramos numa fase em que diversas Associações de Municípios e/ou Municípios com eventuais contratos de manutenção caducados ou em vias de renovação e que dadas as circunstâncias ponderam desistir do habitual SOFTWARE PROPRIETÁRIO, começam a reflectir sobre o que fazer e para tal investigam sobre a experiência de outros…

Um estudo como este, tv mais completo, tal como diz o André (incluindo custos), aliado a isso a partilha de experiência de elementos de autarquias (identificação de casos de sucesso) e de outros utilizadores de OS, poderá ser uma mais valia para aquilo que estamos aqui a defender (neste caso o QGIS e o OS em geral)

Relativamente ao QGIS, eu como funcionário de uma autarquia, da experiência que tenho de outros colegas de outras câmara e/ou assoc de município é a do medo de desistir do SOFT PROP 10.2 e avançar para o QGIS por falta de confiança no seu funcionamento pleno… existe o receio daquela velha frase, “O barato sai caro”. Aliado a isso temos a influência que a empresa do SOFT 10 faz junto dos utilizadores com o seu encontro anual, com um marketing brutal…

Já que as políticas neste país não incentivam definitivamente o uso do OS, direccionando as verbas das anteriores licenças para o apoio ao desenvolvimento do OS ou desenvolvimento de apps baseadas em OS, resta-nos a nós PROMOVER O SEU USO e provar e/ou demonstrar que realmente funciona…

Atualmente o QGIS tem um suporte, quase que diria mais eficiente que o SOFT 10, graças ao esforço de alguns elementos da lista, que não vale a pena enunciar (a eles obrigado pelo esforço). Caso os potenciais utilizadores do QGIS tivessem conhecimento disso, certamente o nº de utilizadores iria aumentar.

Tal como diz o André, era interessante um trabaho profundo sobre isto, certamente não seria trabalho para um aluno…

Cumprimentos,
Pedro


QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/qgis-pt


Ricardo Pinho

2014-09-24 0:09 GMT+01:00 Alexandre Neto <senhor.neto@gmail.com>:

Boa noite,

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?

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.

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.

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

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.

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.

Será que algum aluno que fazer tese de mestrado sobre este assunto?

Cumprimentos,

Alexandre Neto


QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/qgis-pt

Pedro Pereira

2014-09-23 22:21 GMT+01:00 Pedro Venâncio <pedrongvenancio@gmail.com>:

Olá Ricardo,

Deve haver algum engano na TAREFA A (Recorte do raster (CRIF) com base no limite administrativo do distrito de Coimbra)

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

Esta ferramenta do QGIS serve para fazer o recorte de vectores, que no fundo foi o que fizeram na TAREFA B.

Qual foi a ferramenta que realmente usaram?

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 Sourcepole, mas ainda não foi feito o backport dessas melhorias para o QGIS master. Talvez o developer meeting que se avizinha traga novidades nessa matéria.

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:

  • Clip raster by mask (usa o GDAL);

  • Clip Grid with Polygon (usa as ferramentas do SAGA)

  • Diversas formas através das ferramentas do GRASS (r.mask, r.resample, r.mapcalc)

Eu pessoalmente costumo usar o Clip Grid with Polygon, que é bastante rápido. Mas não consigo descarregar os dados que vocês usaram, para testar.

Abraço,

Pedro Venâncio


QGIS-pt mailing list
QGIS-pt@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/qgis-pt

Boas,

Recentemente falava com um colega de outra área sobre alguns exemplos de investimentos falhados na área dos SIG com valores superiores a 6 dígitos.
E a primeira coisa que ele me disse foi “não penses que esses erros/maus investimentos são apenas na vossa área, nem imaginas o que se passa nas obras, aquisições etc…”.

Resumindo nós somos uma gota neste mar de notas de €uros…

Concordo com o Duarte, não existe uma solução ideal (algumas são mais user friendly, outras mais acessíveis “€”, outras…).

Neste momento o QGIS acho que me satisfaz minimamente… sendo que ainda existe muita coisa a ser feita… VAMOS AJUDAR NESSAS MELHORIAS.

Cumprimentos,
Pedro

···

2014-09-24 1:19 GMT+01:00 duartecarreira <dncarreira@gmail.com>:

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 :wink: 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@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/qgis-pt

Pedro Pereira

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 e aqui. 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@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 :wink: 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@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/qgis-pt

Fernando Ribeiro

Viva,

···

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

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…

Rude? directa queres tu dizer?!.. :wink:

A postura amorfa do: “está tudo bem”, “de ficar caladinho”, “não falar nos pontos sensiveis para não ferir susceptibilidade”, e de “tentar sempre agradar a gregos e a troianos”, está provado que não funciona e só nos tem trazido ao estado em que estamos hoje.
Para uns o que temos hoje é muito bom, mas para outros é mediocre e poderiamos estar muito melhor!

Eu acredito na transparencia e no debate franco e aberto, estejamos certos ou errados, mas sem joguinhos, nem omissões que possam ferir susceptibilidades. Se alguem se sentir ofendido com alguma opinião que se defenda e mostre ao outro que deve corrigir, sem tabus. É assim que se avança e melhoram os próprios conhecimentos.

Somos todos diferentes, reconheço, respeito e espero que respeitem.

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?

Não? ok, aqui vai com mais detalhe:

Hoje todos os nossos computadores têm 2, 4 ou mais “cores”.

E o que fazem tantos “cores”? Estão 99% do tempo a dormir.

Qualquer aplicação “processor intensive” hoje em dia, é desenvolvida para usar os vários cores.

Tenta usar um render, um processador de video, compressor, etc e vê o que fazem… usam os cores, para ser 4x mais rápido!

Não seria lógico o geoprocessamento ser a primeira coisa a adaptar para multi-core? Eu acho que sim.

Mas quem sou eu para ditar alguma coisa, há quem diga que só quem financia é que tem uma palavra a dizer… :wink:

Apesar disso achei por bem deixar essa questão a debate, acho importante debater os assuntos com os utilizadores e não só entre desenvolvedores.

“Ainda sou do tempo…”

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 :wink: e rezar para não descobrir um bug
bloqueante.

Lá estás tu com paninhos quentes, chiça!!!
É claro que a questão se deve colocar! sem tabus, porque não?!

Mas colocas as coisas erradamente: “do tempo” em que pensava que quem não tem dinheiro não faz porque não pode comprar as ferramentas para fazer (software). Só faz quem o tiver (dinherio e logo licenças de software)!

Hoje as coisas, evoluiram um bocadinho, até a lei mudou nisso!

E já agora aproveito para informar a quem não sabe e lembrar a quem anda esquecido do:
(desculpem a longa descrição mas é importante e pedagógico)

PLANO GLOBAL ESTRATÉGICO DE RACIONALIZAÇÃO E REDUÇÃO DE CUSTOS NAS TIC (PGETIC)

Desde 2012 (crise), no âmbito da aplicação do PGETIC na Administração Pública, o Decreto-Lei n.º 107/2012, de 18 de maio, regula o dever de informação e a emissão de parecer prévio relativos à aquisição de bens e à prestação de serviços no domínio das tecnologias de informação e comunicação (incluindo obviamente o software, e o parecer prévio é obrigatório acima dos 10.000€).

E claro, os Orçamentos de Estado desde então (2013 e 2014) incluem esta permissa, referindo e obrigando ao cumprimento desse dever, realçando a necessidade de utilizar software livre caso os custos da sua adopção sejam inferiores aos do software proprietário. ver pag.7056-(59) “artigo 6º” e 7056-(104)
"d) Inexistência de soluções alternativas em «software livre ou de código aberto» ou de soluções em «software livre ou de código aberto» cujo custo total de utilização da solução seja inferior à solução em software proprietário ou sujeito a licenciamento específico, sempre que a decisão de contratar seja relativa à aquisição de licenças de software previstas nas rubricas «Software informático» dos orçamentos dos serviços integrados e dos serviços e fundos autónomos"

Pois é, obriga a fazer as continhas todas e a garantir enquadramento da compra de software numa estratégia, num projeto, etc. A AMA é a entidade competente para fazer cumprir tudo isto: https://m6.ama.pt/

O dever de informação e pedido de parecer prévio (antes de lançar o procedimento) obriga a preencher um formulário bastante detalhado: https://m6.ama.pt/docs/FormularioV825Nov2013.7z

Entre os vários quadros, existe o do TOC (total cost of ownership - custo total de posse da solução) que obriga a um detalhado calculo dos custos por um periodo de 4 anos, com duas parcelas: os custos da solução proprietária e os custos da alternativa em software livre.

Ou seja, hoje em dia qualquer solução de TIC, incluindo as na área de SIG, é obrigatório por lei fazer o calculo do custo total da solução alternativa em software livre e compará-lo com o custo da solução baseada em software proprietário!

Mas atenção, a lei tem excepções à obrigatoriedade do parecer prévio (como é habital em PT, não me perguntem porque?!)

  • Em primeiro lugar, está isento de parecer prévio tudo abaixo dos 10.000€
    - As contratações cujo contrato seja declarado secreto ou a respetiva execução deva ser acompanhada de medidas especiais de segurança, bem como quando a defesa de interesses essenciais do Estado o exigir.

- As contratações cujo adjudicatário seja um serviço da administração indireta ou uma entidade do setor empresarial do Estado
- As contratações de aquisição, de manutenção ou de evolução de sistemas operacionais críticos, cuja lista é aprovada por resolução do Conselho de Ministros.

Claro que se levantam aqui muitas dúvidas:

  1. Como são feitas estas contas? Estarão a ser “manipuladas” dando custos elevados para as soluções em software livre e justificando assim a adopção do Software Proprietário?!

  2. Em que casos se adoptou software livre e em que casos se optou por software proprietário? Quem são os promotores e quais são as soluções adoptadas?

  3. A AMA não disponibiliza isto publicamente? Seria uma boa fonte para este tipo de estudos, e para percebermos efetivamente o que se está a passar.

  4. Quais são as situações de isenção do parecer prévio? e que escapam entre os dedos da AMA?!

haja fé,
irmão!

Duvido que exista pessoa com mais fé nesta matéria do que eu.

Um abraço e claro, sem ressentimentos.


Ricardo Pinho