domingo, 2 de outubro de 2016

GIS Corporativo FLEX, um novo "mundo" de oportunidades

GIS Corporativo FLEXO Brasil continua engatinhando quando o assunto é GIS Corporativo. Se avaliarmos os casos de sucesso e a dimensão do nosso país, fica fácil observar que existe um problema na evolução dos projetos de GIS que iniciam normalmente com um desktop, mas depois ficam estagnados e não conseguem chegar ao servidor de mapas (serviços OGC) ou ao banco de dados espacial corporativo. Em geral, quando o projeto inicia com software livre a possibilidade de evoluir para um projeto corporativo é maior devido principalmente à ausência do custo de licenciamento, o que torna o investimento bem aceitável.

"Soluções em software livre possuem maior facilidade em evoluir para um GIS Corporativo principalmente devido à ausência do custo de licenciamento"
Então como ficam os casos das empresas e instituições que iniciaram com o software proprietário? Para os usuários do ArcGIS Desktop, eu apresento uma novidade que irá abrir novos caminhos para uma arquitetura FLEX (híbrida, heterogênea, etc) com o software livre perfeitamente integrado com o software proprietário. O plugin desenvolvido para o ArcGIS que possibilita esta integração é o GeoCat Bridge. Ao longo de alguns dias, eu fiz inúmeros testes utilizando o ArcGIS Desktop 10.4 e o OpenGeo Suite e pude constatar a eficiência do plugin, além do excelente atendimento da equipe de suporte. 

"O GeoCat Bridge possibilita a publicação de dados do ArcGIS Desktop diretamente no GeoServer, no MapServer e no GeoNetwork"

Os meus testes foram concentrados na arquitetura apresentada a seguir. Eu utilizei inúmeros recursos do ArcGIS Desktop para verificar a robustez do GeoCat Bridge no processo de publicar elementos gráficos mais complexos, envolvendo diferentes estilos de contornos e preenchimentos, mapas temáticos em vários formatos e regras, camadas matriciais resultante de análises, etc. Os resultados superaram as minhas expectativas.



Uma das grandes vantagens na evolução para uma arquitetura flex/híbrida é aproveitar o investimento feito anteriormente em licenças e treinamentos relacionados ao ArcGIS Desktop. Desta forma, a empresa poderá colher as vantagens de incorporar o GeoServer e o PostGIS (ambos softwares livres) para montar um GIS Corporativo sem custos adicionais de licenças.  Recomendo também incorporar o QGIS pois poderá ser útil se a empresa planejar expandir os terminais com novos colaboradores.

"O suporte da empresa GeoCat também foi um ponto muito positivo"

A utilização do GeoCat Bridge foi muito simples e não houve qualquer problema em seguir o processo de instalação para ativar a extensão. Para tratar alguns pontos mais específicos da versão 10.4 do ArcGIS Desktop, eu pude interagir com o suporte da GeoCat que se mostrou muito prestativo e solícito. Avaliar o suporte é fundamental para quem trabalha com projetos corporativos.

https://media.licdn.com/mpr/mpr/AAEAAQAAAAAAAAhlAAAAJDI2NjZmNTg4LTkxYzEtNDg1My04MWU2LThjZTEyMTI0ZmMyZQ.png

Para concluir, destaco que o mercado brasileiro poderá usufruir muito desta proposta de Arquitetura Flex, pois o ArcGIS Desktop é um GIS muito utilizado e disseminado. Apesar disso, o ArcGIS Server está longe de ser popular no Brasil pois os valores praticados por aqui inviabilizam o investimento por parte da grande maioria das empresas e instituições públicas. Desta forma, o GeoCat Bridge é um caminho viável, seguro e de baixo custo para ajudar as empresas na caminhada para o GIS Corporativo. Em breve, estarei fazendo um segundo post sobre este tema, mostrando vídeos com o funcionamento prático da arquitetura. Se tiver interesse em implantar esta solução na sua empresa, você pode contatar a UTEI que disponibiliza esta arquitetura através da solução UGeo.

Deixo os meus agradecimentos para Trang Minh Pham e Anton Bakker pelo apoio técnico.

quarta-feira, 7 de maio de 2014

As Tecnologias Geoespaciais na Era da Computação em Nuvem

Há alguns anos que o conceito de nuvem ("cloud") vem sendo bastante discutido entre os especialistas de TIC (Tecnologia da Informação e Comunicação). No segmento de geotecnologias o assunto também tem sido abordado, mas ainda existe uma visão bastante limitada sobre como o conceito pode se concretizar de forma prática numa instituição ou corporação. Eu tenho estudado o assunto desde que o conceito começou o se popularizar nos eventos e vou explanar neste post questões práticas envolvendo as tecnologias geoespaciais numa arquitetura para nuvem.

Quando abordamos o assunto de nuvem, os dois nomes que normalmente surgem no topo da lista são o Google e a AWS (Amazon Web Services). Vou focar nestes dois serviços, pois considero que realmente são os principais para o desenvolvimento de aplicações envolvendo tecnologias geoespaciais para nuvem, apesar de existirem algumas outras boas opções.

Nuvem Google para Aplicações com Tecnologias Geoespaciais


A nuvem do Google tem incorporado constantemente novos serviços. Especificamente para tecnologias geoespaciais, vou começar falando do Google Maps Engine, que possui uma versão gratuita e possibilita a montagem de mapas com uma interface bem fácil de se utilizar. Ele importa alguns formatos comuns dos softwares de geotecnologias:

  • Dados Vetoriais: ESRI Shapefiles, CSV, KML/KMZ e TAB. 
  • Dados Matriciais: JPEG, JPEG2000, GeoTIFF, TIFF, MrSID e PNG.
Mais detalhes sobre os formatos estão na página de suporte do Google sobre o Map Engine. Nas telas a seguir, eu apresento um mapa de teste que montei para apresentar a um cliente a área imobiliária.



Outra plataforma com recursos destinados aos usuários de tecnologias geoespaciais é o Fusion Tables (Google). Este recurso possui a capacidade de armazenamento de informações georreferenciadas com grande facilidade no manuseio e escalabilidade, porém com limitações em termos de tipos de dados geográficos e análises topológicas. Esta última limitação praticamente impossibilita o uso desta plataforma em aplicações mais "pesadas" envolvendo banco de dados espacial. 


Para acessar o mapa da figura acima, você deve clicar no link a seguir:


Nuvem da AWS para Aplicações com Tecnologias Geoespaciais


Um dos lançamentos mais esperados pelos profissionais do mercado de geotecnologias que trabalham com o SGBD PostgreSQL, foi o lançamento do RDS (Relational Database Service) do PostgreSQL com o suporte ao PostGIS. Nas telas a seguir, veremos como é simples a configuração de uma instância de PostgreSQL no AWS RDS.








Depois de criada a instância e o primeiro banco de dados, basta se conectar ao banco e configurar o módulo do PostGIS. A grande vantagem deste serviço é que não há limites para implementação de uma solução corporativa de GIS que exija análises topológicas mais complexas. Além disso, a simplificação do trabalho de manutenção do SGBD pode economizar muitas horas de trabalho do DBA.

Considerações Finais


Algumas das aplicações mais valorizadas lançadas recentemente foram criadas a partir de idéias geniais que, de forma direta ou indireta, utilizaram as tecnologias geoespaciais com a infraestrutura na Nuvem. Um exemplo é o aplicativo Waze que foi comprado pelo Google por um valor de 1 bilhão de dólares. Certamente ainda tem muitas aplicações que serão lançadas e novas empresas que surgirão com novos modelos de negócio que necessitarão de profissionais com um patamar de conhecimento diferenciado com base nas tecnologias para Nuvem.

Se você é um profissional que trabalha com tecnologias geoespaciais, é bom avaliar a possibilidade de se aprofundar neste novo universo.

Apresentação no MundoGEO#Connect



Imagens cortesia de  twobee Kookkai_nak e cooldesign / FreeDigitalPhotos.net

domingo, 15 de setembro de 2013

Processos de negócio com Inteligência Geográfica

Nestes últimos anos, experimentamos uma grande revolução relacionada às tecnologias geoespaciais. Vários dispositivos pessoais e corporativos incorporaram algum tipo de processamento envolvendo dados espaciais. Apesar desta revolução, o verdadeiro potencial continua inexplorado pois as empresas continuam raciocinando os processos de negócio sem inteligência geográfica. Esta evolução não é tão simples pois envolve uma grande mudança de paradigma. Vou dar um exemplo desta dificuldade com uma situação que ocorreu quando eu participava do processo de análise do projeto OPUS do Exército. Quando se discutia como entrar com a solicitação do pedido de obra, a primeira abordagem dos analistas de requisitos foi propor uma ficha eletrônica. Esta é uma abordagem bem comum no processo de análise da maioria dos sistemas corporativos desenvolvidos atualmente. Depois desta abordagem "tradicional" dos analistas, eu fiz a minha intervenção para construir um novo processo pensado com a inteligência geográfica. Desta forma, a primeira entrada passou a ser a seleção da entidade geográfica a qual estaria atrelado todo o processo de gestão de obras do Exército. Como a obra é uma estrutura física que existe numa determina posição geográfica, este novo processo era bastante lógico para quem já tinha experiência em análise de processos com inteligência geográfica, porém para um analista sem esta experiência, esta dedução não é nada trivial. Este projeto foi o primeiro grande sistema do governo federal, no qual trabalhei, a ter o processo de modelagem e desenvolvimento totalmente orientado à inteligência geográfica.

Figura 1 - Interface inicial do OPUS para solicitação de obras (resultado de uma análise com inteligência geográfica).

Figura 2 - Interface com a ficha cadastral que é apresentada após a seleção da entidade geográfica ao qual a obra será associada.

A parte mais complexa que envolve a modelagem orientada à entidade geográfica não é percebida pela maioria dos usuários. Muitos analisam o resultado final e acabam achando que o sistema se trata de um SIG (Sistema de Informação Geográfica), quando na realidade estamos falando de um outro conceito que eu denomino de Sistema de Gestão com Inteligência Geográfica (SGIG). Após a etapa de modelagem de processos com base na inteligência geográfica, é preciso que todo o processo de análise e desenvolvimento também sejam adequados a este novo conceito. Isto implica em ter artefatos repensados para refletir as regras de negócios neste novo paradigma orientado ao espaço geográfico. As figuras a seguir exemplificam um modelo de Caso de Uso que foi construído dentro desta concepção mais moderna de desenvolvimento de sistemas com inteligência geográfica.

Figura 3 - Exemplo de Caso de Uso com especificações para um Sistema de Gestão com Inteligência Geográfica.

Figura 4 - Exemplo de Caso de Uso com especificações para um Sistema de Gestão com Inteligência Geográfica.

Figura 5 - Exemplo de Caso de Uso com especificações para um Sistema de Gestão com Inteligência Geográfica.

Destaquei alguns pontos importantes sobre a análise de processos de negócio envolvendo a inteligência geográfica. Existe uma grande demanda adormecida em várias empresas e esta situação continuará assim pois o mercado enfrenta um falta de profissionais especializados com conhecimentos sólidos na área de análise de projetos envolvendo tecnologias geoespaciais. Ao longo dos projetos que coordenei, eu tive que formar os profissionais que integraram as minhas equipes. Sempre evitei depender de profissionais já formados pelo mercado brasileiro, pois existe uma carência muito grande neste sentido. Quem desejar se especializar nesta área, também encontrará dificuldade em encontrar tal formação no meio acadêmico. Enfim, a internet continua sendo a fonte principal de conhecimento nesta área para quem deseja iniciar os estudos. A experiência prática é o que realmente irá formar um bom profissional.

Imagem cortesia de Stuart Miles / FreeDigitalPhotos.net

terça-feira, 10 de setembro de 2013

A evolução das tecnologias geoespaciais livres no Brasil

Para comemorar os dez anos do grupo MapServer Brasil, vou fazer um post especial sobre a evolução das tecnologias geoespaciais livres (open source) no Brasil. Eu particularmente iniciei meus primeiros estudos envolvendo software livre para Sistemas de Informação Geográfica (SIG) em 2001. Nesta mesma época, talvez um pouco antes, uma equipe da Univali já trabalhava no desenvolvimento do módulo de conexão do MapServer com o Oracle Spatial. Neste período, também já se ouvia falar do projeto TerraLib conduzido pelo INPE.
Em 2002, eu e uma pequena equipe da 5ª Divisão de Levantamento colocamos no ar um servidor com MapServer e PostGIS para dar acesso ao público externo à Cartografia produzida pelo próprio Exército Brasileiro. Este projeto foi apresentado no Congresso de Cartografia com o título de SERVIDOR DE PRODUTOS CARTOGRÁFICOS DIGITAIS. Dentro do Exército, eu pude conviver com pessoas favoráveis ao software livre, porém, também lidei com pessoas que investiam bastante tempo na depreciação das tecnologias abertas. Tenho acompanhado que a nova geração de Engenheiros Cartógrafos tem ajudado a Diretoria de Serviço Geográfico (DSG) a investir no software livre.
Após a apresentação do projeto SePCaD, várias pessoas começaram a me procurar com dúvidas sobre as melhores opções em software livre para soluções envolvendo inteligência geográfica, eu resolvi criar o Grupo MapServer Brasil que completou 10 anos ontem (09/09/2013). Neste período, eu ainda era oficial do Exército e trabalhava na 5ª DL. Este grupo cresceu e hoje conta com mais de 1.300 associados.


O cenário atual das geotecnologias livres no Brasil merece destaque quando comparado a outros países. Temos grandes casos de sucesso passando pelas 3 esferas governamentais (Federal, Estadual e Municipal), inclusive na iniciativa privada. Eu tive o privilégio de participar ativamente para que o software livre estivesse numa situação de destaque com casos de sucessos premiados.
Para concluir este post, indico o vídeo do projeto GIGFER que recebeu 2 prêmios ao longo do seu desenvolvimento. Este foi o projeto mais recente que participei e um dos mais complexos que já trabalhei.


Quem desejar contribuir com comentários sobre fatos relevantes na história do software livre para área de geotecnologias no Brasil, pode ficar à vontade para fazer comentários neste post. Eu agradeço todas as colaborações.

Imagem cortesia de Stuart MilesFreeDigitalPhotos.net

terça-feira, 3 de setembro de 2013

Os desafios dos projetos envolvendo inovação e tecnologias geoespaciais

Já estou há mais de 6 anos envolvido com projetos que conjugam simultaneamente 3 características:  inovação (as funcionalidades que envolvem o projeto não são encontradas em outras outras soluções, nem mesmo em outros países), escopo muito grande (cronograma físico de alguns anos e orçamento na faixa de milhões de reais) e tecnologias geoespaciais (o coração da solução se baseia num banco de dados espacial).

Ao longo destes projetos, uma das minhas principais preocupações estava relacionada à equipe técnica. Além da seleção e da formação, a garantia da contínua motivação da equipe estava sempre me "tirando o sono". A motivação influencia diretamente a produtividade e confesso que tive dificuldades em garantir esta motivação com um mercado de TI cuja rotatividade de profissional é muito alta.

No decorrer da minha carreira, eu tive a oportunidade de coordenar alguns projetos que me permitiram fazer algumas análises sobre a motivação da equipe de analistas de requisitos e desenvolvedores. Neste ponto, posso afirmar que as tecnologias geoespaciais trouxeram inovação e, consequentemente, desafios que se converteram numa excelente "engrenagem de motivação". Quanto maior o desafio, maior era o comprometimento da equipe. Apesar da inovação ter introduzido esta "engrenagem" nos projetos, o fato negativo é: quanto maior a inovação, maiores são as incertezas com relação ao cronograma físico e, consequentemente, o financeiro do projeto também entra numa área de incertezas.

Dos meus trabalhos mais recentes, um projeto que colocou à prova toda a equipe envolvida foi na área de agronegócios. Neste projeto, na parte referente à Engenharia, eu tive que criar modelos matemáticos a partir das medidas relativas a cada máquina agrícola para poder gerar mapas temáticos de forma automática. A estratégia definida foi organizar o processamento em 2 passos, através de uma arquitetura  capaz de processar, em tempo real, um grande volume de dados. Esta arquitetura foi o primeiro grande desafio que envolveu toda a equipe na concepção e refinamento da mesma. No primeiro passo, os dados brutos do protocolo de cada máquina eram processados para gerar um conjunto de tabelas no banco de dados espacial com feições geográficas mais simples que serviriam como base para o processamento final de cada tipo de mapa. No segundo passo, o servidor de mapas (MapServer, mapserver.org) executava uma query para gerar o modelo final dos mapas temáticos em tempo real.

Outro grande desafio foi a implementação dos algoritmos dos modelos matemáticos integrados com o MapServer, mais especificamente foi utilizado o PHP/MapScript, a interface PHP para acesso aos recursos (API) do MapServer. Neste ponto, trabalhei integrado com os programadores para avaliar continuamente os resultados gerados em cada algoritmo. Era necessário ter a certeza da qualidade final dos mapas gerados, afinal de contas, é por isso que eu assino o Atestado Responsabilidade Técnica (ART, registrado junto ao CREA) de cada projeto que sou responsável. Nos gráficos a seguir, eu apresento as etapas da criação dos mapas temáticos automatizados.

A primeira etapa do processo é o rascunho do modelo matemático. Normalmente faço isso no papel. Isso pode soar estranho vindo de alguém que trabalha para "eliminar o papel" dos processos de negócios dos clientes, mas ainda considero o papel o ambiente mais livre para rascunhar as primeiras ideias (peço que perdoem os meus "garranchos"). 


A segunda etapa do processo é um relatório técnico contendo todas as fórmulas a serem aplicadas, bem como o detalhamento de cada uma delas visando a implementação dos algoritmos por parte dos desenvolvedores.


O resultado final desta "matemágica" é um lindo mapa gerado automaticamente. Se uma pessoa fosse fazer este mapa de forma manual usando um Desktop GIS, por exemplo, levaria semanas. Para a equipe que participou do projeto (desenvolvedores e analistas de requisitos), a cada novo mapa gerado era um motivo de orgulho e motivação. A título de curiosidade, a arquitetura da solução que possibilitou a geração do mapa abaixo foi composta pelos seguintes componentes: PHP, PostgreSQL/PostGIS, OpenLayers e MapServer.


Em cada projeto, é preciso avaliar bem os riscos envolvidos e buscar a melhor forma de como lidar com cada um deles. Em alguns casos, os desafios promovidos pela inovação podem se converter em uma dedicação e comprometimento maior da equipe. Num projeto envolvendo desenvolvimento de sistemas, boa parte dos riscos normalmente terá uma relação direta ou indireta com a equipe técnica, pois o processo produtivo depende basicamente da capacidade criativa das mentes das pessoas envolvidas. Este processo é diretamente afetado pela forma na qual o coordenador do projeto (que pode exercer também o papel de gerente de projeto) lida com os desafios e com a equipe técnica envolvida.

Imagem cortesia de sheelamohan / FreeDigitalPhotos.net

sexta-feira, 8 de abril de 2011

Manifesto de um profissional de TIG (Tecnologia da Informação Geográfica)

Para um profissional que é formado em Física Clássica, a tentativa de usar os conceitos que ele aprendeu para explicar fenômenos no mundo quântico resultaria em interpretações limitadas e, algumas vezes, muito longe da verdadeira realidade. Fazendo um paralelo deste exemplo com o mercado de geotecnologias, um fenômeno similar está ocorrendo com frequência no Brasil onde profissionais limitados ao conceito de geoprocessamento não são capazes modelar projetos corporativos envolvendo recursos mais recentes relacionados a tecnologias geoespaciais. Esta situação tem gerado inúmeros projetos extremamente limitados e que não garantem retorno do investimento. Neste contexto, começamos a distinguir dois grupos de profissionais atuando no mercado: "geoprocessadores" e profissionais de TIG (Tecnologia da Informação Geográfica). Muitas vezes, estes dois grupos são confundidos, mas existe uma grande diferença no quesito conhecimento e no tipo de abordagem no tratamento dado às tecnologias geoespaciais.

Visando evitar que alguns amigos continuem achando erroneamento que eu um geoprocessador, vou fazer uma lista com as principais diferenças para não haver dúvidas:
  • Um geoprocessador inicia um projeto na sua instituição comparando os recursos mais recentes dos principais sistemas do mercado, visando escolher o "melhor software". Um profissional de TIG analisa inicialmente quais os setores podem ser beneficiados e estabelece métricas para avaliar o impacto das possíveis soluções, sempre observando o benefício para os usuários finais (não especialistas).
  • O geoprocessador entende o "geodatabase" do ArcGIS como um banco de dados espacial e indica isso como uma possível "solução corporativa" para instituição. O profissional de TIG sabe que os SGBDs que possuem módulos espaciais (geográficos) consagrados no meio corporativo do mercado brasileiro são o PostgreSQL e o Oracle. Alguns geoprocessadores, às vezes, tentam se passar por profissionais de TIG fazendo afirmações do tipo: "Essa solução só dá para ser feita com Oracle Spatial". Isso só confirma a situação de geoprocessador, pois onde o Oracle Spatial atende, o PostGIS também atende.
  • Enquanto o geoprocessador pensa em como fazer mapas temáticos mais bonitos com os novos recursos dos desktops GIS para valorizar o seu trabalho, o profissional de TIG busca uma forma de utilizar os recursos do banco de dados espacial para gerar automaticamente os relatórios temáticos (mapas) exigidos nos processos de negócio da instituição visando potencializar o trabalho dos diversos integrantes da instituição, principalmente o do alto gestor (normalmente um leigo em relação às tecnologias geoespaciais).
  • No processo de seleção de profissionais para desenvolvimento de projetos, o geoprocessador se concentra em títulos e em experiências acadêmicas, enquanto o profissional de TIG avalia intensamente as experiências em projetos que realmente deram resultados significativos para melhoria da gestão, preferencialmente com inovação.
  • Um projeto integrado, na visão do geoprocessador, é composto essencialmente pela importação e exportação automatizada de dados do sistema de gestão da instituição com o SIG (Sistema de Informação Geográfica). Para o profissional de TIG, integração é trabalhar com a inteligência geográfica dentro do próprio sistema de gestão sem necessidade de um "módulo de geoprocessamento".
  • Quando, numa instituição, o assunto da INDE (decreto Nº 6.666, 27 de Novembro de 2008) é colocado em discussão, o geoprocessador logo indica a instalação do geonetwork (ou algum software similar) para atender ao perfil "brasileiro" de metadados. O profissional de TIG avalia inicialmente como o perfil de metadados pode melhorar os processos de negócio internos. Depois ele busca uma estratégia para integração dos metadados no contexto dos processos, dando preferência ao tratamento destes metadados dentro dos próprios sistemas corporativos, evitando a implantação de sistemas adicionais.
Com os exemplos citados acima, espero deixar claro a mudança de paradigma que está ocorrendo no mercado de geotecnologias. Eu deverei fazer outras publicações sobre o assunto e também compartilhar experiêcias práticas em relação a TIG. Em algumas consultorias que tenho coordenado no âmbito dos projetos da OpenGEO, tenho buscado internalizar os novos conceitos de forma gradativa junto aos clientes. O caminho trilhado nem sempre é tranquilo (afinal Murphy é onipresente), mas os resultados finais sempre superam as expectativas até dos mais céticos.

segunda-feira, 21 de março de 2011

Banco de Dados Espacial: muitas possibilidades, mas pouquíssimos casos de sucesso no Brasil

Existe muito marketing em torno do potencial de um banco de dados espacial (geográfico), mas efetivamente podemos observar poucos casos bem sucedidos na utilização do PostgreSQL/PostGIS (software livre) e Oracle Spatial (software proprietário), as principais referências em SGBD espacial no mercado brasileiro. São muitos cursos de geoprocessamento divulgando que ensinam banco de dados espacial, mas nenhum conhecimento é ensinado de efetivamente prático que possibilite transformar idéias em resultados.

Muitos que tentaram implantar um banco de dados espacial com algum destes SGBD's acabaram implementando um mero repositório de dados espaciais com algumas tabelas sem qualquer relacionamento (arranjo lógico) que pudesse agregar inteligência significativa aos negócios. O fato é que a maioria dos projetos de geoprocessamento subutilizam os recursos tecnológicos deste novo século utilizando conceitos limitados da década de 90 para lidar com os modernos SGBD's.


Se for feita uma simples análise das instituições públicas ou privadas que adquiriram licenças de Oracle Spatial e realmente conseguiram desenvolver algum tipo de aplicação com esta ferramenta, será possível constatar um alto índice de insucesso. Talvez muita gente discorde desta afirmação, mas vamos pensar na seguinte questão: utilizar um PostGIS ou um Oracle Spatial exatamente da mesma forma que um arquivo Shapefile pode ser considerado um caso de sucesso? Este é o ponto chave da minha análise, pois se colocarmos como fator as instituições que conseguiram implementar análises geográficas ou topológicas que viabilizaram uma melhoria significativa nos processos de negócio da instituição veremos talvez um índice inferior a 5% de sucesso.


Infelizmente os insucessos são sempre colocados para "debaixo do tapete" para que o responsável por aprovar o projeto não seja tido como um gestor fracassado. Por isso, é muito difícil de desenvolver uma pesquisa que avalie esta situação com certo grau de precisão e imparcialidade. Se fosse feita uma pesquisa avaliando a utilização do banco de dados espacial num contexto de melhorias de processos de negócios, possivelmente os resultados iriam expor um cenário alarmante que poderia desestimular o investimento neste tipo de tecnologia por parte das instituições públicas e privadas.