Diquinhas de ArcGIS #3
Olá pessoal,
Continuando a série de diquinhas de ArcGIS!
Algumas pessoas fazem bastante uso de ferramentas de geoprocessamento, especialmente para análise espacial. Neste quesito, a ferramenta mais utilizada do ArcMap é o ArcToolbox.
Existem processos, que invariavelmente são: rodar ferramenta de geoprocessing, conferir resultados, refinar análise, etc. São tantos arquivos gerados que podemos ficar facilmente perdidos.
Uma das coisas legais que temos no ArcToolbox (acho que a partir da versão 9.3) é o histórico de ferramentas (tanto no ArcMap, quanto no ArcCatalog). Podemos precisar de um processo de foi rodado à algumas horas e onde está o tal arquivo?
Bem, para acabar com os problemas, o histórico vem ao resgate.
Aba Results no ArcToolbox
Para cada processo que rodamos, ele guarda um registro da entrada, dos parâmetros e da saída. Através disso é possível re-rodar o processo ou então arrastar o resultado (desde que não tenha sido fisicamente deletado do PC!) par ao mapa novamente e pronto. Está lá denovo.
O post de hoje foi patrocionado pelo...silêncio.
Abraços
George Rodrigues da Cunha Silva
Volta das séries de posts sobre um paper recente em GEO
Olá pessoal,
Espero que não tenham sentido tanta falta assim das minhas séries de posts apresentando uma publicação científica recente em tema pertinente ao nosso Blog. Por motivos diversos se tornou um tanto difícil manter aquele ritmo incial que eu mantinha, com um paper por semana e quase um post por dia, ao longa da semana.
Em função disso, resolvemos mudar um pouco a ideia, mas sem deixar de trazer esse tipo conteúdo, creio eu ser pertinente e interessante. De agora em diante, a começar pela próxima semana, apresentaremos uma série mensal de posts sobre um paper recnete em GEO, com os posts distribuídos nas semanas do mês. A frequência deve ser mais ou menos de um post por semana, então.
Não percam na próxima semana o início da série. Trarei um paper sobre SensorWeb, bem interessante e bastante recente.
Até a próxima!
Por: Rodrigo Sperb
Vaga trabalho Logica
Buenas noches pessoal,
Trabalhei durante quase um ano na Logica e tive excelentes momentos. Conheci pessoas muito interessantes, fiz amigos e aprendi muita coisa durante meu período lá.
Outros ventos me levaram para outra(s) empresas, mas ainda mantenho contato com o pessoal de lá e aqui vem a boa notícia: eles estão com uma vaga aberta para um desenvolvedor ESRI. A empresa é boa, os benefícios espetaculares e os projetos desafiadores.
Segue a descrição da vaga!
Analista GIS Sênior
Þ Assistência médica e odontológica Care Plus familiar (com apartamento), sem desconto em folha
Þ Previdência Privada – Itaú Vida e Previdência S/A (com participação da empresa)
Þ Ticket Refeição de 400,00 mensais (que podem ser convertidos em Ticket alimentação)
Þ Seguro de Vida Sul América
Þ Vale transporte na forma da lei
Þ PLR (Participação nos lucros e resultados) conforme acordo coletivo da categoria
Þ Auxílio creche (R$ 200 por mês para o primeiro filho e R$ 130 para os demais) até completarem 5 anos de idade
Þ Celular da empresa
Þ Férias
Þ FGTS
Þ 13º
Þ Dissídio anual
Enviem currículos para:
Abraços
George
GESTAO DOS RECURSOS HIDRICOS – Utilizando o ArcMap para a delimitacao de bacias hidrograficas e a extracao de redes de drenagem
A utilização e disseminação de técnicas de delimitação de bacias hidrográficas e extração de redes de drenagem através das ferramentas do geoprocessamento ainda tem uma utilização de certa forma restrita aos órgãos bem estruturados tecnologicamente, o que dificulta, muitas vezes, a adoção desta unidade territorial como unidade de planejamento das atividades que ali se inserem. Além disso, a não utilização destas técnicas dificulta e até impossibilita o uso de uma série de informações que podem ser extraídas, informações estas que serão decisivas para a tomada de medidas durante a fase de planejamento e gestão das atividades inseridas na bacia hidrográfica.
A metodologia aqui utilizada para a realização da delimitação da bacia hidrográfica e a extração das redes de drenagem engloba a utilização do software Arcgis e imagens de radar do programa idealizado pela NASA (National Aeronautics and Space Administration), denominada Shuttle Radar Topography Mission (SRTM).
Ao software Arcgis estão agregados uma família de outros softwares que desempenham funções bem variadas, que vão desde a visualização e edição de mapas, dados gráficos e alfanuméricos, bem como edição de dados, análises espaciais mais complexas e geração de layouts.
Os dados SRTM resultam de uma missão espacial realizada pela NASA, NIMA (National Imagery and Mapping Agency), DLR (Agência Espacial Alemã) e ASI (Agência Espacial Italiana), cujo objetivo foi o de gerar um Modelo Digital de Elevação (MDE) da Terra usando uma técnica denominada interferometria, a qual se utiliza das respostas espectrais na faixa de microondas do espectro eletromagnético, permitindo a obtenção de informações sobre a estrutura tri-dimensional dos alvos na imagem, no caso da SRTM o relevo.
Figura 1 - (a) Direções de fluxo possíveis para um determinado pixel e (b) direção de fluxo escolhida em função da maior declividade entre o pixel central e os vizinhos.Fonte: PAZ e COLLISCHONN (2008, p. 86)
Na imagem raster gerada através das imagens SRTM, para cada pixel, além da posição geográfica “x e y”, também é atribuído um valor altimétrico “y”, o qual servirá de valor base para a extração das redes de drenagem e a delimitação da bacia hidrográfica através, principalmente, de duas ferramentas do software Arcgis: Flow direction (Direção de Fluxo) e Flow acumulation (Fluxo de acumulação).
Segundo Paz e Collischonn (2008, p. 86), as direções de fluxo constituem o plano de informações básico derivado de um MNT em formato raster para suporte a estudos hidrológicos. O procedimento mais comum consiste em considerar uma única direção de fluxo para cada pixel do MNT, sendo essa direção atribuída para um de seus 8 vizinhos (tomando uma janela 3x3). A determinação de qual direção de fluxo atribuir é feita escolhendo a direção que proporcione a maior declividade, calculada como sendo a diferença de elevação entre o pixel vizinho e o pixel central dividida pela distância entre eles (Figura 1).
Esse procedimento é conhecido como D8 ou deterministic eight neighbours (Jenson e Domingue, 1988), e é o mais comumente empregado. Aplicando a regra da maior declividade para cada pixel do MNT, obtém-se a correspondente direção de fluxo e, ao final do processo, gera-se uma imagem raster onde a cada pixel é atribuído um valor ou código que denota para qual dos vizinhos ele drena.
A primeira etapa a ser realizada para a delimitação da bacia hidrográfica e extração de sua rede de drenagem foi a aquisição das imagens SRTM através do site da Embrapa Monitoramento por Satélite (http://www.relevobr.cnpm.embrapa.br/download/index.htm), onde se encontram disponíveis as imagens SRTM, articuladas em folhas topográficas do IBGE. Para a área de estudo foram necessárias duas folhas: SE-23-V-C e SE-23-Y-A.
Figura 2 - Site da Embrapa Brasil em Relevo. Fonte: http://www.relevobr.cnpm.embrapa.br/download/index.htm
De posse destas imagens, foram iniciados os procedimentos metodológicos para a delimitação da bacia hidrográfica e a extração das redes de drenagem. Inicialmente as imagens SRTM, em formato raster, foram transformadas para o formato GRID, através do comando Data > Export Data.
Figura 3 – Transformação da Imagem SRTM em formato raster para formato GRID. Fonte: Software ArcGis.
Na janela que se abrirá, em Location escolha o local de destino do novo arquivo, em Format selecione GRID e em Name dê um nome ao arquivo. Criado o arquivo formato GRID, abra o ArcToolbox e siga o caminho Spatial Analyst Tools > Hydrology > Fill, onde aparecerá a janela Fill. Insira o arquivo GRID gerado em Input surface raster e em Output surface raster dê um destino ao novo arquivo Fill gerado.
Figura 4 – Transformando o arquivo GRID para arquivo Fill. Fonte: Software ArcGis.
O próximo passo é gerar uma imagem com a direção do fluxo, seguindo o caminho Spatial Analyst Tools > Hydrology > Flow Direction. Na janela Flow Direction insira o arquivo Fill gerado na etapa anterior em Input surface raster e em Output surface raster dê um destino ao novo arquivo que será gerado.
Figura 5 – Gerando direção de fluxo. Fonte: Software ArcGis.
A etapa de geração do arquivo de direção de fluxo é uma das etapas mais importantes para a extração da rede de drenagem e delimitação da bacia hidrográfica, uma vez que é onde são realizados os cálculos dás áreas de maior declividade, por onde o fluxo de drenagem é direcionado no meio ambiente, naturalmente. É sabido, na hidrologia, que a água flui naturalmente pelo caminho de menor esforço, sendo assim quanto maior a declividade existente, menor será o esforço “exercido” pela água e desta forma serão estes valores de célula na imagem gerada que serão selecionados como caminhos das redes drenagem.
A próxima etapa será gerar o fluxo acumulado e para executar esta etapa siga o caminho Spatial Analyst Tools > Hydrology > Flow Accumulation. Na janela Flow Accumulation, insira o arquivo de direção de fluxo gerado anteriormente e dê um destino para o novo arquivo que será gerado.
Figura 6 – Gerando fluxo acumulado. Fonte: Software ArcGis.
O próximo passo para atingirmos o objetivo proposto será gerar uma imagem raster com as drenagens extraídas, para tal de ser realizado os seguintes passos no ArcToolBox: siga o caminho Spatial Analyst Tools > Conditional e vá até a janela Con.
Figura 7 – Geração de imagem com as drenagens extraídas. Fonte: Software ArcGis.
Na janela Con insira o arquivo de fluxo acumulado gerado na etapa anterior e em Input true raster no Constant value digite 1. Em Output raster de um destino para o arquivo que será gerado e em Expression digite a fórmula value > 100, valor este que quanto menor for, maior será a quantidade de feições de drenagem a serem geradas de forma automática.
A próxima etapa será a de gerar a rede de drenagens em formato vetorial (shapefile), para tal no ArcToolBox siga o caminho Spatial Analyst Tools > Hydrology > Stream to Feature, insira o arquivo Con gerado na etapa anterior em Input stream raster, o arquivo de direção de fluxo em Input flow direction e dê um destino ao novo arquivo shape que será gerado em formato vetorial com a rede de drenagem extraída.
Figura 8 – Geração de drenagem em formato vetorial. Fonte: Software ArcGis.
Para a delimitação da bacia hidrográfica, inicialmente foi criado um shape de pontos para localizarmos na rede de drenagem o exutório da referida área de drenagem, sendo assim, foi criado o shape de ponto determinando o exutório da referida bacia.
Figura 9 – Determinação do exutório. Fonte: Software ArcGis.
Após a determinação do exutório local, abra o ArcToolBox e siga o caminho Spatial Analyst Tools > Hydrology > Watershed, em Input flow direction raster insira o arquivo flow direction gerado anteriormente e em Input raster or feature pour point data insira o shape do exutório.
Figura 10 – Delimitação da bacia hidrográfica. Fonte: Software ArcGis.
O arquivo gerado com a delimitação da bacia hidrográfica está em formato imagem raster, sendo assim após a obtenção da delimitação, ainda em formato de imagem, deve-se transformar o arquivo para formato shape, como polígono, para que se possam extrair algumas informações úteis, como área da bacia, perímetro, dentre outros dados de grande relevância.
Figura 11 – bacia hidrográfica delimitada. Fonte: Software ArcGis.
Com a delimitação da bacia hidrográfica e a extração da rede de drenagem da referida bacia uma série de informações podem ser geradas auxiliando os estudos base de planejamento e gestão das diversas atividades realizadas na área espacial da bacia e os usos múltiplos da água direcionados às diversas atividades.
A metodologia que foi aqui descrita e aplicada para a extração da rede de drenagem e a delimitação da bacia hidrográfica, utilizou-se de ferramentas do software Arcgis e dentre elas foram duas as principais ferramentas utilizadas, a direção de fluxo (Flow direction) e o fluxo acumulado (Flow acumulation).
A ferramenta flow direction realiza, como ilustrado na figura 1, uma relação entre a célula central e as células adjacentes determinando as áreas de maior declive através dos dados de altimetria, proporcionando o traçado da direção do fluxo do canal hídrico uma vez que a água segue o caminho de menor esforço, neste caso o de maior declividade.
Já a ferramenta flow acumulation determina por onde o fluxo hídrico irá se acumular, permitindo a extração da rede de drenagem e a delimitação automática da bacia hidrográfica. Este processo compara cada célula raster com seus vizinhos e determina através dos dados do flow direction quantas células fluem para a primeira, realizando este cálculo para todas as células e determinando os canais hídricos por onde a água escoa e concentra e delimitando a bacia hidrográfica a partir das células que não recebem fluxo de água, as quais na realidade seriam as cristas e os topos de morro, divisores de bacias hidrográficas.
A gestão dos recursos hídricos em cenário nacional é delineada pela Política Nacional de Recursos Hídricos, a qual foi instituída pela Lei nº 9433, de janeiro de 1997, popularmente conhecida como “Lei das Águas” e que traz como fundamentos da gestão dos recursos hídricos dois pontos importantes para a utilização da metodologia aqui empregada, sendo o primeiro “a adoção da bacia hidrográfica como unidade territorial de implementação da Política Nacional de Recursos Hídricos” e o segundo fundamento é que “a gestão dos recursos hídricos deve ser descentralizada”, ou seja, a adoção de bacias hidrográficas menos abrangentes, ou seja, com menor unidade territorial é defendida, de forma que a participação do poder público e dos diversos usuários nas decisões locais sejam mais fortes e constantes.
A utilização desta metodologia além de permitir a delimitação da bacia hidrográfica, ainda permite extrair a rede de drenagem desta unidade territorial, facilitando o planejamento e a gestão dos usos múltiplos da água, o que também é defendido como fundamento na Política Nacional de Recursos Hídricos. Além disso a elaboração da cartografia base para a bacia hidrográfica irá permitir a utilização destes dados para a obtenção de dados de diversas naturezas e a construção de um banco de dados de informações com várias finalidades quantitativas e qualitativas que permitirá maior agilidade na tomada de decisões e facilitará o processo de planejamento e gestão de recursos hídricos.
Alfredo A. Guimarães
alfredo.arantes@gmail.com
Usando Python e o geoprocessing framework #2
Boa tarde pessoal!
Continuando naquele nosso projetinho, hoje vamos falar sobre a classe em Python que atualiza nossos dados em um determinado banco de dados. Temos algumas particularidades quando trabalhamos com ArcSDE, (registro de camadas como versionadas/não versionadas), portanto mostrarei como trabalhar com um Geodatabase local. A alteração para ArcSDE não é tão grande, e com um cadinho de pesquisa vocês conseguem fazer.
Lembre-se das outras classes que precisamos, mostradas no post anterior.
Construiremos duas classes, uma chamada GeoprocessorWrapper, um "embrulho" do objeto geoprocessor da ESRI. Isto não necessário, mas facilita, já que facilitamos algumas operações através deste "embrulho". A outra será uma tarefa, que juntará todos os dados e resultados das classes anteriores para atualizar nosso banco de dados.
Vamos começar com a mais simples, geoprocessorWrapper:
import arcgisscripting, logHandler
__toolboxAliases = [
"analysis",
"management",
"3d",
"cartography",
"arc",
"interop",
"geocoding",
"ga",
"lr",
"md",
"na",
"samples",
"sa",
"stats"]
class geoprocessorWrapperClass():
def __init__(self,workspace,toolboxList,overwriteOutput=False):
self.logs = logHandler.logHandlerClass()
# Startup logging object
self.gp = arcgisscripting.create(9.3)
# Startup ESRI geoprocessing object
self.gp.Workspace = workspace
self.gp.OverwriteOutput = overwriteOutput
# Define overwrite output. Default is to FALSE.
#lista de toolboxes disponiveis
self.toolboxList = []
self.toolboxList += toolboxList
self.buildGeoprocessorOptions(toolboxList)
def buildGeoprocessorOptions(self):
for x in self.toolboxList:
try:
if x in __toolboxAliases:
self.gp.AddToolbox(x)
except:
self.logs.newLogMessage(self, "Error in adding " + x + " toolbox to geoprocessor object. Are you sure this toolbox exists?" + self.gp.GetMessages(), "Geoprocessing Error")
# adds all toolboxes to current geoprocessing object.
def changeWorkspace(self,workspace):
self.gp.Workspace = workspace;
# changes the current workspace in geoprocessing object
def removeToolboxes(self,toolboxList):
for x in self.toolboxList:
try:
self.gp.RemoveToolbox(x)
self.toolboxList.remove(x)
self.logs.newLogMessage(self,"Removed " + x + "toolbox from geoprocessing object.","Information")
except:
self.logs.newLogMessage(self,self.gp.GetMessages(),"Geoprocessing Error")
# removes unneeded toolboxes from current geoprocessing object
Vamos começar com alguns detalhes desta classe:
Em primeiro lugar, temos os tradicionais import x. Eles são responsáveis por disponibilizar outras bibliotecas ao nosso código. Note que importamos o módulo arcgisscripting.
Logo depois, temos uma lista dos aliases que cada toolbox possui no Python. É necessário adicionar uma toolbox ao objeto geoprocessing para que se tenha acesso às ferramentas da mesma - o que pode ser feito de dois jeitos, pelo caminho da toolbox (C:\Program Files\...\ArcGis\Toolbox.tbx) ou pelo seu apelido. A primeira maneira é útil para adicionar toolboxes customizadas, que não tem apelido. A segunda maneira é mais prática para adicionar as toolboxes tradicionais.
O construtor da classe toma dois parâmetros obrigatórios e um opcional para inicializar a classe. O workspace é a pasta onde iremos trabalhar - ele poderia ser também um geodatabase, mas neste caso, uma pasta. toolboxList é uma lista com os apelidos das toolboxes que queremos adicionar ao nosso objeto de geoprocessing. O parâmetro adicional é se você deseja que os resultados do objeto geoprocessing sejam escritos por cima dos anteriores (caso tenham o mesmo nome) e é por default, falso.
O construtor é bastante simples. Ele cria um objeto geoprocessing, utilizando a versão 9.3 como opção (ajuste para sua versão caso necessário - mas não garanto que funcione na 9.2 - já que vários métodos como ListDatasets, têm uma resposta diferente do que
na versão 9.3), define qual é o workspace inicial e adiciona as toolboxes relevantes.
A forma de uso é a seguinte:
g = geoprocessorWrapper.geoprocessorWrapperClass(r"C:\",["analysis","management","lr"])
#ou
g = geoprocessorWrapper.geoprocessorWrapperClass(r"C:\",["analysis","management","lr"],true)
# para acessar o geoprocessor do nosso wrapper, use:
listaDeFeatureClasses = g.gp.ListFeatureClasses()
for x in listaDeFeatureClasses:
print x.FeatureType
Bem simples né? Temos um método também para mudar de workspace, sem necessitar de criarmos uma nova ferramenta. O outro método disponível é para remover toolboxes que não precisamos. Um método aqui poderia ser facilmente criado para adicionar novas toolboxes ao objeto. Alguém se arrisca?
Com esta classe podemos fazer quaisquer operações, mas utilizaremos uma outra classe para realizar todo o trabalho sujo. Lembra-se do código do post passado? Temos disponível em nossa máquina um arquivo .zip extraído em uma pasta qualquer, correto?
Vamos à classe geodatabaseUpdateTask.
import os, sys
class geodatabaseOperationClass():
def __init__(self,geoprocessor,inputShapefile,outputGeodatabase,outputFeatureDataset,outputFeatureClass):
self.geoprocessorWrapperClass = geoprocessor
self.inputShapefile = inputShapefile
self.outputGeodatabase = outputGeodatabase
self.outputFeatureDataset = outputFeatureDataset
self.outputFeatureClass = outputFeatureClass
self.processStage = 0
self.stages = ["Testes de conformidade",
"Deleçãoo de Feature Class",
"Cópia de Shapefile",
"Atualização Completa"]
def getProcessStage(self):
return self.stages[self.processStage]
def testGeodatabase(self):
#workspace definido pelo geoprocessor
return self.outputGeodatabase in self.geoprocessorWrapperClass.gp.ListWorkspaces(self.outputGeodatabase,"ALL")
def testFeatureDataset(self):
#adaptando workspace
self.geoprocessorWrapperClass.gp.Workspace += "\\" + self.outputGeodatabase
return self.outputFeatureDataset in self.geoprocessorWrapperClass.gp.ListDatasets(self.outputFeatureDataset,"ALL")
def testFeatureClass(self):
#adaptando workpace
self.geoprocessorWrapperClass.gp.Workspace += "\\" + self.outputFeatureDataset
return self.outputFeatureClass.gp.Workspace in self.geoprocessorWrapperClass.gp.ListFeatureClasses(self.outputFeatureClass,"ALL")
def testAllObjetcs(self):
if self.testGeodatabase() and self.testFeatureDataset() and self.testFeatureClass():
self.processStage = 1
return True
else:
self.processStage = 0
return False
def deleteFeatureClass(self,featureClass):
try:
self.geoprocessorWrapperClass.gp.Delete_management(featureClass)
except:
print self.geoprocessorWrapperClass.gp.getmessages()
def copyFeatures(self,inputShapefile,outputFeatureClass):
try:
self.geoprocessorWrapperClass.gp.CopyFeatures_management(inputShapefile,outputFeatureClass)
except:
print self.geoprocessorWrapperClass.gp.getmessages()
def updateFeatureClass(self):
try:
if self.testAllObjects:
self.processStage += 1
print self.getProcessStage()
self.deleteFeatureClass(self.outputFeatureClass)
self.processStage += 1
print self.getProcessStage()
self.copyFeatures(self.inputShapefile,self.outputFeatureClass)
self.processStage += 1
print self.getProcessStage()
except:
print self.geoprocessorWrapperClass.gp.getmessages()
Temos os tradicionais import no cabeçalho de nosso arquivo e logo depois o construtor da classe.
Nosso construtor tem os seguintes parâmetros: geoprocessor (um objeto do tipo geoprocessorWrapper), o caminho para o shapefile à ser carregado no banco de dados, o geodatabase de destino, o featureDataset de destino e a FeatureClass de destino.
Você pode ver que construí uma lista de estágios que temos de passar antes de atualizar a FeatureClass. O estágio testes de conformidade vão garantir que os objetos existam no geodatabase e não ocorram erros. Esta etapa pode ser customizada, caso a FeatureClass não exista, crie a mesma, somente importando os dados - também deixo isto para o usuário interessado! Lembre-se que temos de passar um objeto geoprocessorWrapper com um workspace, uma pasta. Neste caso em específico, deve-se passar apenas pastas, pois definimos o geodatabase em outras áreas.
Os testes cuidam da mudança de workspace e asseguram que a featureClass exista. Perceba que todo o trabalho é realizado dentro desta classe, nas funções:
- deleteFeatureClass()
- copyFeatureClass()
Uma função resume todo o processo: updateFeatureClass(). Veja que ela não tem parâmetros, pois usa os parâmetros setados no construtor. À medida que a mesma progride, atualiza o status do processo e informa ao usuário.
Forma de uso:
gp = geoprocessorWrapper.geoprocessorWrapperClass(r"C:\",['management']) geoOperation = geodatabaseOperation.geodatabaseOperationClass(gp,r"C:\shapefile.shp","teste.mdb","dnpm","dnpm_brasil") geoOperation.updateFeatureClass()
Lembrem-se que o restante do código (buscar o arquivo na net, dezipar, etc) está no post anterior. Como prometi, aqui vai a classe LogHandler.
E ae pessoal? Dúvidas?
Podem ver que o Python dá muito poder ao framework de geoprocessing do ArcGIS e é muito simples.
Um abraço
George
Blog Oficial do Projeto gvSIG
Olá Pessoal!
Hoje quero passar uma dica para quem trabalha com gvSIG: O Blog oficial do projeto.
A equipe responsável pelo projeto gvSIG lançou recentemente um espaço para divulgar as novidades e discussões sobre todos os aspectos do projeto.
O blog, que é escrito em espanhol, pode ser acessado pelo endereço neste link.
Com certeza esse blog será mais uma ferramenta de apoio à comunidade que trabalha com softwares livres para área de Geoprocessamento.
Além disso, aqui no Blog Geo.NET e no Portal ClickGeo você também encontra várias dicas e comentários sobre o gvSIG. Deixe sua opinião sobre o gvSIG nos comentários.
--
Anderson Maciel Lima de Medeiros
Consultor em Geotecnologias Livres
Conheça melhor o TerraView
Olá pessoal!
Hoje vamos começar com uma pergunta simples: Quando se fala em software de SIG brasileiro, que nome lhe vem logo à cabeça? Provavelmente a maioria pense no famoso e amplamente elogiado SPRING.
Nesse post quero deixar uma dica sobre um outro software de SIG desenvolvido pelo INPE (Instituto Nacional de Pesquisas Espaciais) e que é muito bom, mas que é menos comentado que o Spring: O TerraView.
Se a maior crítica ao Spring é por conta da sua interface não amigável, isso não acontece com o TerraView. Sua interface é bem mais intuitiva.
Esse mês foi lançada a versão 3.4.0 do TerraView. Juntamente com essa versão foi disponibilizado o plugin TerraEdit para a edição de planos de informação vetoriais, e uma nova versão do plugin TerraPrint.
Outra novidade nessa versão é que a interface de usuário agora está disponível, além de português e inglês, também em espanhol. As alterações podem ser conferidas neste link.
O Projeto TerraView
O TerraView é um aplicativo desenvolvido tendo por alicerce uma biblioteca de Geoprocessamento chamada TerraLib. De acordo com informações da página oficial do programa, sua construção tem como principais objetivos:
- Apresentar à comunidade um fácil visualizador de dados geográficos com recursos de consulta a análise destes dados.
- Exemplificar a utilização da biblioteca TerraLib.
Note que de acordo com o primeiro objetivo listado acima, a idéia original era que o TerraVIEW fosse um visualizador de dados espaciais. Com o tempo foram sendo incorporadas características de um software de SIG, como a análise espacial.
O aplicativo permite a manipulação de dados geográficos representados na forma de vetor ou matriz. O armazenamento dos dados é feito em programas de SGBD como Access, MySQL e PostgreSQL.
Download do TerraView
O TerraView é distribuído gratuitamente pelo INPE através desse endereço. Para baixar o programa é necessário fazer um breve cadastro antes.
Tutoriais sobre TerraView
O próprio INPE desenvolveu uma série de tutoriais detalhados sobre o uso do programa. Eis alguns dos temas abordados:
- Iniciando uso do TerraView
- Ferramentas de Análises Básicas
- Manipulando Tabelas
- Manipulando dados Matriciais: Grades e Imagens
- Operações Espaciais
- Plugin WMS Cliente
Clicando aqui você será direcionado para página de download desses materiais. O INPE também disponibiliza os dados usados nos procedimentos mostrados nos tutoriais neste link.
Enfim pessoal, o TerraView é mais uma opção para quem trabalha com softwares de SIG. Ele faz o que promete, é livre e gratuito e melhor, é brasileiro. Cada versão do TerraView está melhor.
Se ainda não testou, baixe já o TerraView. Se já usou ou usa esse programa deixe sua opinião sobre ele nos comentários.
Um Abraço.
--
Anderson Medeiros
Tecnólogo em Geoprocessamento
Agricultura Familiar e Geoprocessamento
Olá Pessoal!
Hoje gostaria de comentar com vocês sobre um trabalho elaborado pela também Tecnóloga em Geoprocessamento, Julie Eugênio.
Há algum tempo ela preparou um projeto de gerenciamento de atividades de agricultura familiar fazendo uso de técnicas de Geoprocessamento.
O objetivo principal da pesquisa dela foi o desenvolvimento de uma aplicação, com base em técnicas de Geoprocessamento, para apoiar as atividades de um projeto voltado à agricultura familiar sustentável denominado “Cinturão Verde”, inserido no programa de microcrédito “Empreender-JP”, no município de João Pessoa, capital do Estado da Paraíba.
O mapa abaixo mostra a localização da área de estudo.
Durante a construção da aplicação SIG integrada a um Banco de Dados Geográficos deu-se ênfase ao uso de tecnologias livres, com destaque para o Quantum Gis (QGis) e PostgreSQL/PostGis.
Na parte escrita do trabalho desenvolvido foi detalhada toda a metodologia empregada. A qual está resumida na figura abaixo.
O trabalho foi extremamente elogiado pelos responsáveis técnicos da prefeitura de João Pessoa. Você pode fazer o download do trabalho completo a partir do link abaixo, que traz o tema da monografia escrita com base nesse projeto.
Espero que tirem proveito de mais essa demonstração da potencialidade do uso de tecnologias livres para Geoprocessamento.
Abraços.
--
Anderson Medeiros
Tecnólogo em Geoprocessamento
Modelos Digitais de Elevação e Hidrologia 2
Boa tarde pessoal!
Esta é mais uma tarde em aeroporto e mais um postzinho. Desta vez, estou em Guarulhos.
Lembrando o post Modelos Digitais de Elevação e Hidrologia, deixei uma pergunta aos usuários: como um software determina vetores de curso d´água, utilizando somente o raster de fluxo acumulado?
Flow Accumulation (fonte: http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=Flow_Accumulation)
Olhe bem para esta superfície: é possível distinguir célular onde a acumulação é maior conseguimos estabelecer visualmente um caminho. Deêm uma olhada na célula amarela (na superfície do lado direito) com o número 20. Isto significa que 20 outras células deságuam nela.
Com um valor limite, o software consegue estabelecer e desenhar, à partir dos centro das células linhas, que posteriormente são vetorizadas. Simples não?
No caso acima, se definissemos o valor mínimo de 4, teríamos os seguintes vetores:
Vetor delimitado à partir de um valor limite e fluxo acumulado (fonte: modificado de ESRI)
Perceba que o limite estabelecido guia o software à encontrar as células com muito fluxo acumulado, sinalizando portanto, que ali deve ser um curso d´água. O ArcGIS não tem uma função pronta para isso, mas utilizando se a matemática de bandas é possível selecionar as células, com a expressão:
saida = con (fluxo_acumulado > 100, 1)
O que esta expressão faz? Ela diz ao ArcGIS: se a célula tem valor maior do que 100, altere seu valor para 1. Se o valor for menor do que 100, ele será setado para NoData. "Con" vem de condição ou condicional.
Neste momento, teremos um raster especial, onde todas as células são nulas, exceto as que representam um curso d´água. Uma simples conversão de raster para linha transformaria este resultado em vetores 
Nota: o resultado da fórmula acima será um raster em memória chamado "saida". Seu raster de fluxo acumulado, deve ter o nome "fluxo_acumulado". A matemática de bandas funciona com o nome das camadas no Table of Contents.
Nota 2: a revista Geo.NET está para sair. Anunciamos ela para o início de abril, mas as coisas ficaram muito mais corridas que o normal e não conseguimos lançá-la no momento previsto. Estamos todos terminando nossos artigos e em breve publicaremos.
Espero que tenham gostado.
Um abraço,
George Rodrigues da Cunha Silva
Padrões Open Geospatial Consortium – Parte 2
Hoje vamos dar sequência à postagem sobre padrões da OGC. Na primeira postagem dessa série vimos o que é o OGC e alguns comentários sobre as especificações WMS, WFS e WCS.
Agora vamos tecer algumas considerações sobre os padrões GML, KML e SLD.
Geographic Markup Language (GML)
O objetivo da GML é oferecer um conjunto de regras com as quais um usuário pode definir sua própria linguagem para descrever seus dados, assim utilização do padrão GML permite a interoperabilidade entre dados geográficos. Definindo como será o armazenamento e transporte de informações geográficas, incluindo propriedades espaciais e não espaciais das entidades geográficas.
O GML é usado também em serviços WFS para trocar feições entre clientes e servidores, servindo, portanto como suporte ao serviço WFS.
Keyhole Markup Language (KML)
A linguagem XML (eXtensible Markup Language), como o próprio nome já diz, pode ser extendida ou ampliada. O próprio padrão KML da OGC é uma extensão de um XML utilizado pelo Google para tornar possível a visualização de dados geográficos nos seus famosos programas: Google Earth e Google Maps.
A estrutura do KML é baseado em tags como ocorre com arquivos HTML e XML comuns. Estas tags do KML tem os nomes e atributos usados para objetivos de exibição específicas. Em termos simples, notamos que o Google Earth e e o Google Maps funcionam pra os arquivos KML como como navegadores.
O KML depende de outros padrões para gerar a visualização de dados geográficos, pois na sintaxe do KML proveniente de um serviço de internet existe uma requisição WMS.
Hoje, o OGC e o Google trabalham em conjunto para aprimorar a implementação do KML, além de manter a comunidade informada das atualizações e avanços em seu projeto.
Styled Layer Descriptor (SLD)
A especificação SLD se refere à um arquivo XML que representa graficamente entidades geográficas (textos, pontos, objetos lineares ou polígonos.). Na linguagem SLD podem ser definidas regras que agrupam objetos em diferentes categorias e definindo para cada grupo um estilo diferente, por exemplo a simbologia de um WMS (estabelecer cores e rótulos) a partir de regras a serem definidas.
Programas de SIG, como o Udig, geram arquivos SLD de forma automática. Para executar este processo, basta adicionar uma camada WFS à uma visualização do Udig, fazer uma requisição ao servidor através de uma URL adequada e depois criar temas e rótulos de acordo com as necessidades da aplicação.
Enfim, esta foi uma breve consideração sobre alguns dos principais padrões da OGC (WMS, WFS, WCS, GML, KML e SLD). Espero que tenham gostado. Qualquer dúvida, entre em contato deixando um comentário.
Um Abraço e até a próxima postagem
--
Anderson Medeiros
Tecnólogo em Geoprocessamento
Consultor em Geotecnologias Livres
