#Python, parte 3

Boa noite pessoal,

Como disse anteriormente o Python é a linguagem "preferida" pela ESRI para se construir ferramentas e modelos de geoprocessamento.

Na última vez, usei um exemplo pequeno, mas até útil.

Hoje vou mostrar como se pode fazer múltiplas operações, com uma só Feature Class.

O Python é ótimo em executar tarefas tediosas e repetitivas, daquelas que gastaríamos anos para terminar se feito na mão.

Imagine que você precise converter uma série de SRTMs para pontos, juntá-los, e depois interpolar tudo isso (espero que seu computador seja bom :P)

Vamos ao exemplo:

#lembrem-se que o python faz questão de código identado, se ele não tiver identado, não funcionará.
#aqui ao invez de espaços usaremos -

#vamos importar nossas coisas
import sys, os, arcgisscripting, string

gp = arcgisscripting.create(9.3)

diretorio = raw_input("Digite o diretório que contém os rasters. Não se esqueça de duplicar as barras \\, senão não conseguirei achar o caminho...")
#aqui você pode indicar qualquer coisa, um diretório, um banco de dados SDE e até um banco de dados file/personal.
if diretorio:
----pass
else:
----print "Workspace/Espaço de trabalho inválido. Reinicie o script e tente denovo."
----exit()

gp.Workspace = diretorio

ListaRasters = gp.ListDatasets("*","Raster")
#se tivessemos escolhido "SRTM*" ao invés de "*" o Python listaria todos os rasters que começam com as letras SRTM

gp.AddToolbox("conversion") #adiciona a toolbox conversion
gp.AddToolbox("sa") #adiciona a toolbox do spatial analyst - só funciona para quem TEM a licença eim pessoal.
gp.AddToolbox("management") #adiciona management

#já temos nossas ferramentas, mãos à obra.

for Raster in ListaRasters:
----OutFeature = diretorio + "\\" + "ponto_convertido_" + Raster
----gp.RasterToPoint_conversion(Raster,OutFeature)
----print Raster + " convertido para ponto."

#vamos listar nossas feature classes de ponto. lembra do "*"?
ListaFeatureClasses = gp.ListFeatureClasses("ponto_convertido_*","POINT")
#assim garantimos que só vamos mosaicar as featureclasses convertidas e não outras perdidas no mesmo workspace, e claro só do tipo ponto :D

#a ferramenta merge exige uma lista das featureclasses a serem juntadas separadas por ponto e virgula, entao vamos dar a ela o que ela quer!

OutputMerge = gp.Workspace+"\\" + "MergeFinal"

gp.Merge_management(string.join(ListaFeatureClasses,";"),OutputMerge)
#a funcao join concatena uma lista utilizando um caractere (ou caracteres separadores) ou seja: ['shape1','shape2',shape3'] viram shape1;shape2;shape3

print "Já está tudo junto, vamos interpolar?"
print "interpolando. deve demorar, vá tomar um café..."

gp.Idw_sa(OutputMerge,"VALUE",gp.workspace+"\\"+"raster_interpolado",30,1)

print "interpolado. parabens!"

Bem pessoal, não testei o código, mas deve funcionar de acordo. O python é muito poderoso e suas funções internas se encaixam muito bem com a API da ESRI. Vejam na parte do Merge. Em outras linguagens teriamos de escrever loops e loops para concatenar as palavras daquela maneira, mas em python tudo é feito rapidinho!

Espero que gostem e que comecem a utilizar Python no seu dia a dia. É de fato um negócio muito útil. 1 hora para escrever um script, mas te salva 80mil horas de trabalho chato, cansativo e passível de erro humano.

Ahn! Não se esqueçam de consultar a documentação das funções utilizadas (join do Python, Merge_management, RasterToPoint_conversion e IDW_sa). Todas as versões do Help do ArcGIS possuem essa documentação. É só apertar F1 e correr para o help de cada ferramentinha, na última parte delas, Scripting. Se acharem algum erro no código postados, favor dar um toque que eu corrijo.

Python Rocks!

#Python parte 2 - utilizando objetos de geoprocessamento

Buenas pessoal,

Bem, Python, como expliquei no post passado é uma linguagem de alto nível e muito recomendada pela ESRI para se construir modelos de geoprocessamento (semelhantes aos construídos no ModelBuilder) e scripts para processamento de informações.

Primeiro, para quem deseja aprender Python:

python.org e python.org.br

Aqui encontramos algumas coisas fundamentais, como documentação e links para trocar idéias com a comunidade que desenvolve em Python.

Segundo: irc.freenode.net nos canais #python e #python-br . Nestes locais é possível conversar com desenvolvedores brasileiros e internacionais e resolver possíveis dúvidas.

Terceiro: este aplicado a quem quer integrar esta poderosa ferramenta aos seus métodos de trabalho - WebHelp ESRI e WebHelp Esri 2.

Não tenha medo de errar e não tenha medo de buscar ajuda.

Então vamos lá.

Para qualquer coisa que você queira fazer em python, é necessário importar o módulo que cuida dos objetos geográficos da ESRI, o arcgisscripting.

#importando o módulo arcgisscripting
import arcgisscripting

Quando um script .py contém esta instrução (ela deve ser feita no ínicio do seu script), o python deixa a sua disposição os objetos da ESRI. No webhelp você pode encontrar uma descrição ampla de TODOS eles, bem como exemplos.

Certo, mas depois que este módulo está disponível, o que fazemos para começar a mexer com o ArcGIS?

É necessário criar um objeto do tipo geoprocessing, fornecido pelo módulo arcgisscripting. Olhem o exemplo

gp = arcgisscripting.create()
#este método, sem parâmetros serve tanto para 9.2 quanto para 9.3
#para 9.3, é melhor especificar o paramêtro 9.3 e.g.: gp = arcgisscripting.create(9.3)

O que podemos fazer com o Python? Bem, em teoria, tudo o que estiver disponível dentro de uma Toolbox do ArctoolBox também está disponível para o Python. O Python na verdade, consegue fazer qualquer coisa que esteja em uma toolbox e ainda mais!

Lembre-se que o Python contém muitos módulos, como acesso à sítios remotos, módulos para gerenciar emails, matemáticos, FTP, conversores para PDF, acesso à banco de dados (MSSQL, PostgreSQL, SQLite, entre outros), manipuladores XML...ou seja, é muito flexível e extensível.

Para realizarmos operações dentro do ArcGIS, temos que utilizar o módulo sys e geralmente o módulo os, ambos nativos no Python. Hoje não falarei de como construir scripts que rodam à partir do ArcGIS, apenas scripts que rodam diretamente da shell python (alguém conhece alguma utilidade pra isso? acessar objetos geográficos sem abrir o ArcGIS?)

Bem, imaginemos que queremos Projetar ou Definir projeção de diversos itens, ao mesmo tempo:

#projetar diversos shapefiles para uma única projeção
import sys, os, arcgisscripting

Caminho = "C:\\Pasta\\Shapefiles\\"
#no Python, temos de duplicar as barras, pois uma barra \ é interpretada como alguns
#caracteres especiais, como nova linha, tabulação, entre outros

gp = arcgisscripting.create(9.3)

#vamos projetar shapefiles/featureclasses. temos de utilizar
#as toolboxes correspondentes, entao vamos adicioná-las

gp.AddToolbox("C:\\CaminhoAtéAToolbox\\Nome da Toolbox.tbx")

#podemos adicionar tantas toolboxes quanto precisarmos
#só devemos lembrar que mesmo através de scripts Python, as licensas de extensões
#SÃO CHECADAS. se você não tiver o spatial analyst, o Python irá dar um chilique

gp.Workspace = Caminho
#vamos definir o workspace. No ArcGIS + Python, muita coisa depende do workspace.
#ele é basicamente um apontamento para o diretório correto.

ListaShapefiles = gp.ListDatasets("*","ALL")
#vamos criar um objeto do tipo lista, e inserir nela todos os objetos do arcgis.
#os parametros "*" e "ALL" está dizendo para o ArcGIS inserir na lista todos
#os objetos, sem especificação de tipo (que podem ser Feature, TIN, Raster e CAD)

print ListaShapefiles
#me mostre o que será projetado

projecao = "C:\\CaminhoAteAProjecao\\Projecao.prj"

for Shapefile in ListaShapefiles:
----gp.Project_management(Shapefile,Shapefile+"_projetado",projecao)
----print "Projetei " + Shapefile

#considere os quatro - como uma identação, um toque na tecla tab (o blog está engolindo os espaços)
#fim

Este script é bem simples, deve ser salvo como .py, e ser rodado através da shell python ou com dois cliques no mesmo (desde que o Python esteja devidamente e corretamente instalado).

Algumas notas no entanto: note a forma que duplicamos as barras. Se você utilizar somente uma barra o Python não conseguirá achar os caminhos corretamente.

Os nomes de saída da função project são Shapefile_projetado.

A identação no trecho "gp.Project_management..." é PROPOSITAL E DEVE ESTAR LÁ. SEM ELA O SCRIPT NÃO FUNCIONARÁ. O Python usa a identação obrigatória como forma de controle de código.

Não se esqueça, tudo o que vem depois de # é considerado pelo Python um comentário, não influenciando no programa.

Note que para projetar uma pasta/set de shapefiles diferentes, temos que alterar a variável Caminho, lá em cima. O que podemos fazer para dinamizar esta questão? Como podemos perguntar ao usuário qual é a pasta que precisamos projetar? E a projeção, como definir ela dinamicamente? Essa fica de dever de casa :P

E agora senhores, o que podemos fazer com Python? Podemos utilizar todas as Toolboxes do ArcGIS para realizar milhares de operações com diversos shapes/featureclasses, e até mesmo cosntruir modelos complexos, do tipo que vemos em ModelBuilder, simulando eventos.

Vamos aprender Python?

#Python: o que é?

Olá pessoal,

Primeiro gostaria de falar sobre a Geo Rede. GeoRede é um projeto do site Geoprocessamento.net, um agregador de feeds de diversos blogs sobre Geoprocessamento/Sensoriamento Remoto em geral.

Estou lá também! Depois passem lá e deêm uma olhada. Se você não conhece o Geo.NET é mais uma coisa bacana. Fórum, seção de downloads e muito mais.

Bem, hoje falo para os usuários de ArcGIS. Vocês já devem ter notado, que durante a instalação do ArcGIS ele te pergunta/pede para instalar uma linguagem de programação chamada Python. Bem, se algum de vocês já abriram a aba dela no menu Iniciar do windows devem ter se deparado com algo bastante simples, a IDLE. A IDLE é um shell que intepreta comandos em Python. Algo como o DOS.

Bem, não dá pra fazer muita coisa pela IDLE, já que estamos limitados a "programas" de uma linha. Mas o porque estou falando de Python? O ArcGIS, felizmente, tem um ambiente customizável e permite ao usuário mais avançado a desenvolver suas próprias ferramentinhas, para executar uma infinidade de ações. Desde tarefas de "geoprocessamento" (geoprocessing) à customizar suas layers e representações.

Existem duas maneiras de se estender o ArcGIS. Uma delas é através de uma linguagem compilada .NET (ou VBA) e através do Python.

De acordo com a própria ESRI, a linguagem recomendada para se trabalhar com geoprocessing é Python. O .NET é mais fácil caso você precise estender a GUI (Graphic User Interface) e montar coisinhas mais complexas. O Python é recomendado para geoprocessing e a criação de ferramentas mais simples justamente pelo Python ser simples. A linguagem Python, criada em 1991, é considerada VHLL (Very High Level Language) e traz enormes facilidades para desenvolvedores iniciantes.

Primeiramente, ela é dinamicamente tipada (what the hell?!). Bem isso significa que não é necessário declarar com QUE tipos de variáveis queremos trabalhar antecipadamente. Você coloca alguma coisa na variável e o Python identifica o que ela é pra você. Ou seja, não existe muita confusão no momento de falar que A = 3 ou A = "spam". (neste exemplo, A = 3, representa automaticamente que A é uma variável do tipo inteiro e que em segundo momento, ela é do tipo string)

Segundamente, Python não é uma linguagem compilada. Não é necessário desenvolver um arquivo executável ou algo do tipo, ela é interpretada conforme o Python lê o código digitado. Isso traz uma perda de velocidade (nada muito importante) mas o ganho em agilidade no desenvolvimento compensa.

Python tem tipos muito flexíveis, como listas e dicionários. Não entrarei em detalhes, mas você pode com uma única expressão, criar uma lista com valores que você esteja trabalhando e de forma mais fácil ainda, ler os mesmos.

Um exemplo de lista, que sempre estão entre COLCHETES:

ListaTeste = ['spam','geoprocessamento',2,['arcigs','envi','arcsde']]

Temos na lista acima os items 'spam', 'geoprocessamento',2 e uma outra lista! aninhada, com os objetos 'arcgis','envi' e 'arcsde'. Listas são o carro-chefe do Python e devem ser aprendidas o quanto antes. Através delas podemos fazer o capeta com muito pouco código.

Agora, como integro ArcGIS com Python? A ESRI disponibiliza uma "API" própria para manipulação (de seus) objetos geográficos, como Feature Classes, Layers, Datasets, Geodatabases entres outros.

tudo o que tiver após # são considerados comentários, e não são interpretados pelo Python.

Um exemplinho simples de um script em Python (embora não muito útil) manipulando dados do ArcGIS seria:

import os, sys, arcgisscripting

gp = arcgisscripting.create(9.3) #vamos criar um objeto do tipo geoprocessing, versão 9.3

ListaCamadas = gp.ListDatasets(r"C:\teste python\geodatabase.gdb")
#pega uma lista dos featuredatasets no geodatabase.gdb

for camada in ListaCamadas: #para cada camada em ListaCamadas
print camada #imprima camada

#a resposta do Python vai ser algo assim.

>>>>['Hidrografia','Altimetria','Geologia','Transportes']

Bem, vejam como é fácil andar pelas listas e realizar operações em série. Os loops em Python são descomplicadíssimos.

Sugiro que agora, corram ao site da ESRI, e deem uma olhada nos geoprocessing Objetcs. Eles podem facilitar muito a vida de um utilizador de SIG.

Um abraço

Leituras...

Sábado feio de São Paulo...

Ontem comprei dois livros: Aprendendo Python da O'Reilly e o SQL Server 2008 para Desenvolvedores.

Tem que estudaaaar. Mas agora é hora de Antartica.

Abraços

pgRouting - funcionalidades avançadas do PostGIS

Boa noite a todos,

Venho falando muito de PostGIS e PostgreSQL, e hoje não vai ser diferente. Não falarei as history tables, que é um assunto ainda extenso, mas sim do pgRouting.

O que é pgRouting? Bem pgRouting é uma extensão para o PostGIS que vai habilitar o usuário a construir redes e utilizar algoritmos de roteirização, dentro do PostGIS.

Toda rede à ser analisada, dentro de softwares proprietários ou livres, necessitam de um bocado de informação para funcionarem corretamente, e aqui não é diferente. Com uma rede pronta (existem exemplos no site), é possível utilizar diversos alfgoritmos e aplicar pesos a cada "logradouro" ou eixo à ser percorrido, tornando toda esta história de roteirização bastante útil para se encontrar o "melhor caminho".

Os algoritmos disponíveis pelo pgRouting são:

Shortest Path Djisktra;
Shortest Path A*
Shortest Path Shooting Star;
TSP - Travelling Sales Person;
e
Driving Distance calculation;

É bom lembrar que estes algoritmos funcionam em qualquer tipo de rede organizada, seja ela de estradas, rios, de transmissão e tudo mais o que você puder pensar.

Em geral os algoritmos vão retornar ao usuário uma série de linhas, contendo os nós à serem percorridos e os eixos (nodes and edges, para os íntimos).

Esta extensão só mostrar como o PostGIS pode dar ao usuário avançado de GIS um poder que somente se consegue com um Network Analyst (sem contar o armazenamento em banco de dados, flexibilidade de armazenamento, possibilidades de publicar conteúdo na WEB e claro, preço) que custa uns R$10.000,00.

Vão lá, olhem o site e testem.

Abraço

History Tables, denovo.

Boa noite pessoal.

Uns posts atrás falei sobre uma função que permitisse e criasse automaticamente as regras e tabelas para armazenamento de registros históricos no PostGIS.

Bem, aqui vão algumas questões: O PostgreSQL nos permite lidar com este tipo de situação de duas formas: Rules e/ou Triggers.

No caso do nosso projetinho, foram utilizadas rules para lidar com o que precisamos fazer. Bem, o que deve ter um histórico de feições?

Primeiramente ele deve guardar todas as feições inseridas, atualizadas e deletadas, bem como a data, hora, nome do usuário que realizou a alteração, e uma coisa interessante, qual é a versão atual daquela feição. Desta forma podemos rastrear quais foram as alterações históricas de cada versão e caso preciso, achar a versão mais apropriada e restaurá-la para o banco de dados principal.

Além disso, temos um registro histórico de fato. Sabemos todas as alterações de uma feição. É possível entender como um lote mudou, por exemplo, ou como um animal rastreado por GPS está se movimentando. Outra coisa bacana, podemos saber como está evoluindo a cobertura vegetal de uma determinada região. Aumentou? Diminuiu? Não existe ambiguidade ou imperícia. Tudo pode ser restaurado e analisado de acordo com uma dimensão extra, o tempo.

Bem, vou postar aqui a estrutura de uma tabela histórica:

1. CREATE TABLE foo_history(
2. history_id serial not null,
3. date_created timestamp not null default now(),
4. date_deleted timestamp default null,
5. operacao varchar(20) not null,
6. usuario varchar(80) not null default current_user,
7. versao_atual varchar(80),
   
8. LIKE foo,
9. CONSTRAINT foo_history_pk PRIMARY KEY(history_id));

É mais ou menos isso. Deêm uma olhada na linha 8, a expressão LIKE foo. Ela diz ao PostgreSQL que ele deve procurar a estrutura da tabela foo, e copiar ela todinha embaixo. Legal não?

Imagine a tabela foo:

1. CREATE TABLE foo(
2. fid serial not null,
3. classe_vegetacao varchar(30) not null,
4. CONSTRAINT foo_pk PRIMARY KEY(fid));

Nossa tabela foo_history final seria:

1. CREATE TABLE foo_history(
2. history_id serial not null,
3. date_created timestamp not null default now(),
4. date_deleted timestamp default null,
5. operacao varchar(20) not null,
6. usuario varchar(80) not null default current_user,
7. versao_atual varchar(80),
   
8. fid integer,
9. classe_vegetacao varchar(30),
   
10. CONSTRAINT foo_history_pk PRIMARY KEY(history_id));

*Uma particularidade: qualquer campo do tipo SERIAL (como fid, na tabela foo) é realmente do tipo INTEGER. Quando declaramos SERIAL, o PostgreSQL entende que deve criar uma sequência específica para aquele campo e escolhe o valor padrão para aquele campo o próximo valor daquela sequência.

Bem, para começar precisamos de um código SQL que gere automaticamente este código acima. Ele precisa gerar a tabela sem que o usuário digite nada, apenas escolha a tabela que ele quer montar um registro histórico.

Nosso código também precisa montar automaticamente as regras que vão realizar a gestão desta tabelinha acima. Lembre-se que precisamos de uma regra para cada tipo de modificação na tabela, uma para INSERT, uma para UPDATE e uma para DELETE.

Cada uma tem uma particularidade, pois as alterações na tabela histórica não são as mesmas. A regra para delete, por exemplo, não deve criar novo registro na série histórica, apenas indicar que o registro foi deletado.

Não é muito complicado, mas também não é muito simples. Daqui uns dias falo deste códigozinho e dou umas dicas sobre ele.

Novo emprego, novos desafios

Boa noite fellas,

Arrumei um novo emprego, depois de alguns meses meio que parado. O novo emprego na área de mineração e já estou em São Paulo ajudando o pessoal a organizar algumas coisinhas.

Daqui uns tempos, campo! Trecho, Obra, Mato. Chamem como quiserem, mas é bão demais.

"Novas tecnologias": ArcServer, SDE e de volta ao ninho ESRI.

Vamos lá.

George

Contribuindo um pouquinho...

Boa noite pessoar!

Alguns dias atrás me cadastrei no trac da OsGeo para ver se conseguia solucionar algum tiquete em aberto.

Para quem não sabe, trac é um sistema que controla as informações sobre bugs, melhoramentos entre outras coisas à fazer, dentro de um projeto de software. Ele permite um usuário aceitar uma tarefa, postar arquivos e mensagens e receber comentários em seu trabalho.

Aceitei o tíquete #180 que pede a criação de algumas funções para criar tabelas "históricas", permitindo o usuário saber quem alterou a tabela, como alterou, quando e todas as alterações feitas. À partir daí ele tem opções de restaurar uma feição que foi deletada ou editada de forma errada, entre outras coisinhas.

Montei algumas funções em pl/pgsql puro para gerar estes códigos, e as mesma estão disponíveis no link mostrado acima. Ainda existe muita discussão à ser feita para que elas comecem a pertencer ao código "oficial" do PostGIS, mas está caminhando.

O bacana, além de aprender e conhecer gente nova, é poder devolver um pouco pra um software excelente. Uma contribuição pequena, com certeza, mas que mais pra frente pode ajudar muita gente.

George

SIG Portátil?! Isso aí.

Boa tarde pessoal,

Cruzando novamente a internet encontrei em um blog, o Computing, GIS and Archeology, escrito por Jo Cook. Ela desenvolvou um pacote com diversos softwares para GIS para serem utilizados em pen-drives, sem a necessidade de instalação de nada!

Bacana né?

Entre os softwares estão:

Desktop GIS: GRASS, gvSIG e QGIS;

Bibliotecas: GDAL e OGR;

XAMP Lite: Apache (servidor), MySQL (banco de dados) e Php (linguagem de programação);

PostgreSQL 8.2 com PostGIS 1.1

Servidores de Mapas: MapServer, OpenLayers, TileCache, FeatureServer e o GeoServer;

É bastante coisa para colocar em um pen-drive, mas muito legal, já que desta forma não é necessário instalar nada dessa parafernália, testar tudo e além disso mostrar para os outros! Muito mais fácil de mostrar algum trabalho específico para um cliente.

Claro, não é nada para se utilizar em ambiente de produção, mas acho que vale a pena dar uma conferida.

Confiram aí também o Portable GIS.

Esta versão contém softwares mais antigos, mas já existe uma nova versão no forno, contendo todos os softwares atualizados.

Comentários?

George

Aulas gratuitas da Penn State University

Buenas noches pessoal,

Descobri hoje uma coisinha muito bacana: são as aulas de mestrado em GIS da Penn State University nos Estados Unidos. As aulas são gratuitas para qualquer um ler e ver os documentos relacionados com as aulas. Geralmente ekas são direcionadas a parte conceitual do geoprocessamento e geotecnologias em geral.

Existem muitas matérias interessantes e pra quem consegue ler em inglês pode ser uma mão na roda. As aulas são disponibilizadas através de um site chamado Open Educationl Resources.

Estes links que estou passando, se referem somente ao departamento de EMS (Earth and Mineral Sciences). Devem existir com certeza outros departamentos que disponibilizem estas aulinhas excelentes.

Aqui vão alguns exemplos de aulas que o departamento de Geografia deixou na WEB:

Department of Geography

• GEOG 482/160: Nature of Geographic Information
  Author/Instructor: David DiBiase
• GEOG 485: GIS Programming and Customization
  Author/Instructor: Jim Detwiler; Instructors: Frank Hardisty, Tim Enderlein, James O'Brien
• GEOG 583: Geospatial System Analysis and Design
  Author/Instructor: Todd Bacastow
• GEOG 585: Open Web Mapping
  Author/Instructor: Ian Turton
• GEOG 588: Planning GIS for Emergency Managment
  Author/Instructor: Anthony Robinson
• GEOG 860: Comparative GIS
  Author/Instructor: Adena Schutzberg
• GEOG 862: GPS and GNSS for Geospatial Professionals
  Author/Instructor: Jan Van Sickle
• GEOG 863: GIS Mashups for GIS Professionals
  Author/Instructor: Jim Detwiler
  

Só não dá pra fazer os exercícios. Pra isso você tem que ser aluno da Penn State. Mas enfim, fica aí a dica.

Enjoy people!

George Silva

Suporte a VBA descontinuado na versão 9.4

Finalmente a ESRI anunciou o que todo mundo já sabia:

Não iremos ter mais o tão adorado editor VBA na edição 9.4 do ArcGIS/ArcEngine.

O motivo? A própria Microsoft descontinuou o suporte ao VBA em 2008.

A solução agora é migrar todo o código em VB6/VBA para .NET o quanto antes.

A notícia na integra na página do ArcGIS Developer Blog: http://blogs.esri.com/Dev/blogs/arcobjectsdevelopment/archive/2009/03/30/VBA-and-VB6_3A00_-The-Road-Ahead.aspx

Dica: ArcUser

Olá pessoal mais uma vez,

Não sei se vocês conhecem, mas aí vai uma dica interessante:

A ESRI publica quatro vezes por ano uma revista chamada ArcUser, distribuída gratuitamente na internet e para clientes.

É uma revista muito bem editorada, com foco ESRI claro, mas contém dicas interessantes e artigos muito bem escritos.

Deêm uma olhada no artigo desta edição chamado "Speak the Same Language: Making a compelling case for GIS to business executives" - basicamente em português: "Falando a mesma língua: Construindo uma proposta comercial de GIS para executivos de negócios".

O artigo, na verdade uma entrevista com Keith Wishart, um consultor de negócios da ESRI UK descreve de forma interessante os passos para a construção da tal proposta comercial. Ele lista as maiores dificuldades e o que fazer para se dar bem.

A maior dificuldade listada por ele é o grande desconhecimento de executivos seniores da tecnologia GIS. Outro forte da entrevista é a lista de benefícios não-materiais que a implantação de um GIS traz para uma organização.

Fonte: ArcUser Spring 2009 (Speak the Same Language: Making a compelling case for GIS to business executives)

A dica está dada. Além de artigos como este a ArcUser apresenta diversos tutoriais sobre o software ESRI e mostra diversos passo-a-passos.

Aproveitem a leitura.

George Silva