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 > Hydrology > Flow Accumulation 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, 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

Related posts:

1. Modelos Digitais de Elevação e Hidrologia 2
2. Metadata #1

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.

LogHandler Class

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

Related posts:

1. Usando Python e o Geoprocessing Framework #1
2. #Python – pt2
3. OOP com python – Uma breve introdução.

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

Related posts:

1. gvSIG 1.9 Portable
2. Monografia: WebMapping – gvSIG – Alov Map
3. Conheça melhor o TerraView

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

Related posts:

1. MNT – O que é? Para que serve?
2. O Geoprocessamento e Suas Tecnologias – Parte 2
3. Produção de Mapas Interativos em CD-ROM

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.

Gerenciamento de Atividades de Agricultura Familiar Sustentável com Base em Técnicas de Geoprocessamento, no Município de João Pessoa - PB

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

Related posts:

1. Monografias Geoprocessamento – IFPB
2. O Geoprocessamento e Suas Tecnologias – Parte 2
3. O Geoprocessamento e Suas Tecnologias – Parte 1

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

Related posts:

1. Modelos Digitais de Elevação e Hidrologia
2. GESTAO DOS RECURSOS HIDRICOS – Utilizando o ArcMap para a delimitacao de bacias hidrograficas e a extracao de redes de drenagem
3. Análise Espacial: tipos de análise

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

Related posts:

1. Padrões Open Geospatial Consortium – Parte 1
2. O Geoprocessamento e Suas Tecnologias – Parte 2
3. Metadata #3

Olá Pessoal!

Hoje vou abordar um tema de extremo interesse para quem trabalha com Geotecnologias, livres ou não: Os padrões do Open Geospatial Consortium (OGC). Nesta primeira parte da série vamos entender o que é o OGC e os padrões WMS, WFS e WCS.

O Open Geospatial Consortium (OGC)

Desde seus primórdios em 1994 a instituição, que se chamava OpenGis Consortium, tem o com o objetivo de criar especificações de interfaces e padrões de intercâmbio de dados geoespaciais.

O OGC é hoje uma entidade internacional com mais de 350 companhias, agências governamentais e universidades, que tem o intuito de promover o desenvolvimento de tecnologias que facilitem a interoperabilidade entre diferentes sistemas que trabalhem com informação e  localização espacial.

Asim, o OGC define especificações, ou padrões (como o WMS, WFS, WCS, etc) aos quais produtos e serviços precisam se adequar para que a interação entre diversas fontes de dados e informações espaciais seja facilitada, independente de fatores como a plataforma utilizada. A partir de agora vamos começar a compreender três das especificações do OGC.

Web Map Service (WMS)

O padrão WMS define um serviço para a produção de mapas que serão apenas uma representação visual dos dados espaciais e não os dados em si. Estas representações serão geradas no formato de imagem, como JPEG, PNG e GIF ou em formato vetorial, como o Scalable Vector Graphics (SVG).

Este padrão especifica como o cliente deve requisitar as informações para o servidor e como este deve responder ao cliente. As operações WMS podem ser realizadas a partir de um navegador comum que fará a submissão das requisições sob a forma de uma URL.

É importante destacarmos que o conteúdo da URL dependerá da operação solicitada. Em outras palavras, através da URL, indica-se qual a informação que deve ser exibida (região geográfica e dado de interesse), bem como o sistema de referência espacial, além das características da imagem de saída (altura e largura).

Web Feature Service (WFS) e Web Coverage Service (WCS)

A especificação de serviço WFS define um serviço para que clientes possam recuperar feições especiais em formato GML (você terá mais detalhes sobre GML na segunda parte desta série sobre o OGC).  O WFS pode ser implementado pelo servidor em duas versões:

• Básica - Neste caso, basicamente funções de consulta ficam disponíveis, ou

• Transacional - Implementa o serviço completo, incluindo operações de inserção, deleção, edição e, claro, consulta à objetos espaciais.

Assim, podemos afirmar que o WFS apresenta maior interatividade que o WMS, pois este primeiro possibilita não apenas a visualização das feições geográficas, mas também sua manipulação.

Já o padrão WCS define o acesso aos dados que representam fenômenos com variação contínua no espaço. Este serviço é especificado para
tratamento de dados modelados como geocampos.

Breves Comparações entre WMS, WFS e WCS

Uma diferença marcante entre o WMS e o WCS é que este último retorna ao usuário dados sobre a semântica original dos fenômenos representados, ao invés de imagens. Em outras palavras, o WCS fornece os dados disponíveis de imagens, juntamente com detalhes descritivos sobre as mesmas, como a grade.

Já em uma comparação entre o WFS e o WCS notamos que o primeiro retorna os chamados geo-objetos, já no caso do WCS retorna geocampos, conforme mencionado anteriormente.

Assim, chegamos a conclusão de que o serviço WCS pode ser utilizada para enquadrar aplicações do Sensoriamento Remoto (pois em geral o SR está relacionado com geocampos) no contexto da interoperabilidade.

Conclusão e o que vem por ai

Dessa nossa breve análise sobre estes três dos diversos padrões do OGC podemos notar que cada um terá sua aplicabilidade, sendo interpretado e explorado de maneira diferente dependendo dos objetivos de seu projeto.

Programas como o gvSIG e o Udig permitem interações com webservices que sigam as especificações WMS, WFS e WCS.

Na segunda parte desse post veremos mais sobre as padrões da OGC, com ênfase nas especificações GML, SLD e KML.

Fiquem na expectativa...

--

Anderson Maciel Lima de Medeiros

Tecnólogo em Geoprocessamento

Related posts:

1. Padrões Open Geospatial Consortium – Parte 2
2. O Geoprocessamento e Suas Tecnologias – Parte 2
3. Monografias Geoprocessamento – IFPB

Vamos responder aqui a duas perguntas comuns sobre os MNT e suas aplicações em Geoprocessamento.

O que é um MNT?

A sigla MNT significa Modelo Numérico do Terreno, mas este tipo de dado também é conhecido como MDT (vindo do inglês Digital Terrain Model).

Trata-se de uma representação matemática da distribuição espacial de uma determinada característica relacionada à uma superfície. Esta superfície é, em geral contínua.

Quais suas aplicações?

Dentre as diversas aplicações dos produtos de MNT, podemos destacar algumas vinculadas ao SIG:

• Armazenamento de dados de altimetria para gerar mapas topográficos;
• Análises de corte-aterro para projeto de estradas e barragens;
• Elaboração de mapas de declividade e exposição para apoio a ánalise de geomorfologia e erodibilidade;Análise de variáveis geofísicas e geoquímicas;
• Apresentação tridimensional (em combinação com outras variáveis);
• Predição e mapeamento de processos de salinização do solo em escala local, regional e subcontinental;
• Predição e mapeamento do risco de erosão do solo, em escala de bacias hidrográficas;
• Modelação e mapeamento espaçotemporal do ciclo hidrológico sob diversos aspectos;
• Modelação e mapeamento da evapotranspiração;
• Classificação de paisagens;
• Predição e mapeamento da migração e acumulação de agentes poluentes.

Você já tem o SPRING instalado em seu computador?

Caso tenha, não deixe de acessar e ler o menu de ajuda deste programa, que é bastante completo, pois aborda não apenas sobre a utilização do software, mas também conceitos teóricos sobre Geoprocessamento. O download do SPRING pode ser feito acessando este link.

Se você ainda não tem, deixo o incentivo de fazê-lo. Você pode acessar a ajuda online do SPRING, clicando aqui.

Em posts futuros vamos comentar um pouco sobre os produtos de MNT, bem como falar sobre outros aspectos relevantes dos dados geográficos.

Um Abraço e até o proximo post.
--
Anderson Medeiros
Tecnólogo em Geoprocessamento

Related posts:

1. Conheça melhor o TerraView
2. Monografias Geoprocessamento – IFPB
3. O Geoprocessamento e Suas Tecnologias – Parte 2

Hoje passei apenas para dar uma notícia rápida e feliz:

Saiu a versão portável do gvSIG 1.9! E tem mais: já vem com a extensão Sextante inclusa.

Isso significa que você pode rodar o gvSIG direto de um pen drive sem a necessidade de instalação (Windows Vista e 7).

Para baixar o arquivo de 121 MB, clique aqui.

Um Abraço!

Anderson Maciel Lima de Medeiros

Consultor em Geotecnologias Livres

--

Fonte:

Portal gvSIG

Processamento Digital

Related posts:

1. Monografia: WebMapping – gvSIG – Alov Map
2. Blog Oficial do Projeto gvSIG
3. O Geoprocessamento e Suas Tecnologias – Parte 2