1
Primeiro Produto Março de 2015 ADAPTAÇÃO E IMPLANTAÇÃO OPERACIONAL DO
ALGORITMO DIGITAL PARA O MAPEAMENTO AUTOMÁTICO DE ÁREAS QUEIMADAS EM IMAGENS DE MÉDIA RESOLUÇÃO DO
SATÉLITE LANDSAT-8 SENSOR OLI NA
DIVISÃO DE GERAÇÃO DE IMAGENS NO INPE
2 Arturo Emiliano Melchiori, Engo. Consultor
ADAPTAÇÃO E IMPLANTAÇÃO OPERACIONAL DO ALGORITMO DIGITAL PARA O MAPEAMENTO AUTOMÁTICO DE ÁREAS QUEIMADAS EM IMAGENS DE MÉDIA RESOLUÇÃO DO SATÉLITE LANDSAT-8 SENSOR OLI NA DIVISÃO DE GERAÇÃO DE
IMAGENS NO INPE
Desenho e implementação dos módulos de cadastro, processamento e integração, contendo as atividades realizadas, os métodos desenvolvidos e os resultados obtidos, referentes ao primeiro produto do termo de referência PN 11.9035.4-001.00, contrato GIZ 83193538, de 02/Fev/2015, desenvolvido no INPE.
São José dos Campos, Março de 2015.
________________________________ ________________________________
De acordo: Dr. Alberto W. Setzer Consultor: Arturo Emiliano Melchiori
3 SUMÁRIO
1 RESUMO EXECUTIVO ... 5
2 INTRODUÇÃO. ... 6
3 INTRODUÇÃO SISTEMA OPERACIONAL DE MAPEAMENTO DE ÁREAS QUEIMADAS ... 7
4 ÁREA DE COBERTURA DO CERRADO BRASILEIRO. ... 7
5 CALENDARIO DE RECEPÇÂO LANDSAT 8/OLI ... 9
6 MÓDULOS DO SISTEMA OPERACIONAL... 11
7 MÓDULO DE CADASTRO. ... 12
7.1 Funcionalidades do Módulo de Cadastro de Limiares. ... 14
7.1.1 Arquivo de Limiares ... 14
7.1.2 Incorporação de Limiares. ... 14
7.1.3 Módulo de modificação dos limiares. ... 15
7.1.4 Módulo de Leitura. ... 15
7.1.5 Modulo de Exclusão ... 15
7.2 Ferramenta para obtenção de limiares ótimos de extração ... 16
8 MÓDULO DE PROCESSAMENTO ... 18
8.1 Máscara de nuvens ... 20
9 MÓDULO DE INTEGRAÇÃO. ... 23
9.1 Conectividade segura entre os Módulos de Acervo e Processamento ... 24
9.2 Sob a projeção e implementação definitiva do Módulo de Integração. ... 25
10 SISTEMA DE CONTROLE DE VERSÕES DO CÓDIGO FONTE ... 25
10.1 Arquivos do código fonte. ... 26
10.2 Uso do Sistema de Controle de Versões. ... 27
10.3 Incorporação dos arquivos com código fonte. ... 27
10.4 Incorporação de mudanças no código fonte. ... 27
10.5 Verificação de mudanças no código fonte. ... 27
11 ANEXO 1 ... 28
12 BIBLIOGRAFIA ... 31
4 ÍNDICE DE FIGURAS
Figura 1. Mapa do Cerrado Brasileiro, com a grade Landsat e os polígonos das áreas de
conservação e terras indígenas. ... 8
Figura 2. Componentes e fluxo dos dados no Sistema de Captura e Produção de dados Landsat. [Imagem cortesia da USGS] ... 11
Figura 3. Diagrama de fluxo do Sistema Operacional de Mapeamento de Área Queimada ... 12
Figura 4. Diagrama de Fluxo do Módulo de Cadastro de Limiares Diferenciais ... 13
Figura 5. Rotina de cálculo de limiares de extração de área queimada. ... 16
Figura 6. Erros de Comissão e Omissão para diferentes limiares ... 17
Figura 7. Detalhe da curva de limiares dos valores obtidos pela metodologia desenvolvida ... 17
Figura 8. Circulação dos dados após uma solicitação de imagens e limiares ... 18
Figura 9. Diagrama de fluxo do processamento dos dados na obtenção de cicatrizes de área queimada e máscara de nuvens ... 19
Figura 10. Diagrama de fluxo do armazenamento dos dados pelo Módulo de Administração ... 20
Figura 11. Configuração dos bits da banda BQA do sensor Landsat 8 ... 21
Figura 12. Deslocamento de 12 posições para a direita de uma palavra de 16 bits. ... 21
Figura 13. Máscara de nuvens baseada na banda BQA do pacote de dados da USGS. ... 22
Figura 14. Banda 4 do pacote de dados da USGS... 22
Figura 15. Fluxo de dados entre os Módulos de Acervo, Integração e Processamento. ... 23
ÍNDICE DE TABELAS Tabela 1. Órbitas/ponto Landsat-8 cobrindo o Cerrado Brasileiro. ... 9
Tabela 2. Datas das primeiras órbitas sob o Cerrado para o ano 2015. ... 9
Tabela 3. Cronograma do satélite Landsat 8 para o ano 2015. ... 10
Tabela 4. Desenho da tabela de limiares no banco de dados. ... 13
Tabela 5. Valores da banda BQA para constituir uma máscara de nuvens ... 21
5 1 RESUMO EXECUTIVO
O presente documento descreve o primeiro produto do Termo de Referência PN 11.9035.4- 001.00, Contrato GIZ 83193538, de 02/Fev/2015, realizado no INPE, São José dos Campos, SP, referente ao desenvolvimento de ferramentas digitais operacionais para o mapeamento automático de cicatrizes de área queimada no Bioma Cerrado Contínuo Brasileiro utilizando imagens de média resolução espacial.
Estão resumidas a execução dos passos 1 a 3, projeto e a implementação dos módulos de cadastro, processamento diferencial e integração com os sistemas de ingestão e administração de dados do INPE - Cachoeira Paulista, realizadas pelo consultor até 31/Março/2015.
Foi projetado e implementado o Módulo de Cadastro de limiares diferenciais, com as funções de incorporação, modificação e exclusão de limiares. Os limiares se referem a índices de classificação de área queimada, e são específicos de cada cena TM e mês; eles integram um novo algoritmo de mapeamento automático de áreas queimadas que se adapta a características da vegetação e uso do solo locais conforme estes limiares. Foi estruturada uma tabela em banco de dados PostgreSQL para armazenar os 24 limiares NDVI e NBRL correspondentes a cada ano para cada uma das 112 órbitas/ponto das imagens Landsast-TM8 que cobrem a área do Bioma Cerrado Contínuo do Brasil. Foi projetada e implementada uma metodologia para gerar os limiares ótimos de extração que minimizam os erros de comissão e omissão baseados numa referência de área queimada existente.
Foi adaptado o Módulo de Processamento para utilizar os limiares diferenciais correspondentes a cada órbita/ponto, ano e mês. Foi adaptada a metodologia de geração de máscara de nuvens devido a um problema interno do sensor TIRS do satélite Landsat 8.
Foi projetada e implementada uma versão básica do Módulo de Integração devido aos Sistemas Operacionais de Ingestão e Processamento de Dados Landsat 8 do INPE em Cachoeira Paulista ainda não terem sido completados, limitando as tarefas de integração do Sistema Operacional de Mapeamento de Área Queimada.
O Sistema de Controle de Versões de código fonte Subversion é apresentado. As funcionalidades mais relevantes são comentadas e exemplificadas.
O cronograma do TdR está sendo cumprido, e espera-se concluir os trabalhos do TdR como previsto, em 08/Sept/2015. O próximo documento a ser entregue será o relatório do produto 2 em 22/Jun/2015.
6 2 INTRODUÇÃO.
O presente relatório refere-se ao primeiro produto do Termo de Referência PN 11.9035.4- 001.00, contrato GIZ vigente de 02 de Fevereiro de 2015 a 08 de Setembro de 2015, cujo objetivo é dar continuidade à produção de dados de área queimada na região do Cerrado Brasileiro com a análise de imagens de média resolução (30 metros), apoiando os desenvolvimentos que o INPE esta realizando no Projeto GIZ-MMA “Prevenção, controle e monitoramento de queimadas e incêndios florestais no Cerrado”.
As fases do contrato em andamento para a “Adaptação e implantação operacional do algoritmo digital para o mapeamento automático de áreas queimadas em imagens de média resolução do Satélite Landsat-8 sensor OLI na Divisão de Geração de Imagens no INPE” se dividem em: 1) Projeto e implementação dos módulos de cadastro, processamento e integração, 2) Projeto e implementação dos módulos de log e gravação dos resultados obtidos em bando de dados geográfico e 3) Relatório sucinto do trabalho e dos testes desenvolvidos e, publicações.
Foram previstos os seguintes passos:
1) Módulo para cadastro (inclusão, modificação e exclusão) de limiares dinâmicos que são objeto do TdR de outro consultor para as 112 órbitas/ponto do Cerrado Brasileiro;
2) Módulo de processamento, onde serão feitas adaptações para utilizar os limiares específicos dos filtros de cada órbita/ponto, ano, mês, etc;
3) Módulo de integração, para executar a comunicação com o sistema de controle da DGI/INPE, responsável pela gestão dos processos de recepção e ingestão das imagens Landsat, para determinar quando cada processamento deverá iniciar;
4) Módulo de log, onde serão registradas todas as etapas do processamento, de emissão de avisos de atenção e alertas de problemas durante a execução do sistema;
5) Módulo de gravação dos resultados, que será desenvolvido para gravar os dados diretamente em um Banco de Dados Geográficos além de gerar os arquivos shapefile;
6) Elaboração de documentos de manuais do usuário e publicações com descrição detalhada da metodologia utilizada e consolidação das informações geradas para evolução futura.
Este relatório corresponde à execução dos passos 1 a 3, projeto e implementação dos módulos de cadastro, processamento diferencial e integração com os sistemas de ingestão e administração de dados de Cachoeira Paulista, realizado pelo consultor entre 02/fevereiro/2015 e 31/Março/2015.
7 3 INTRODUÇÃO SISTEMA OPERACIONAL DE MAPEAMENTO DE ÁREAS QUEIMADAS
Um Sistema Operacional de Mapeamento de Área Queimada (SOMAQ) é um conjunto de programas que são executados de maneira autônoma em um computador, ou conjunto de computadores, sem assistência de um operador, e que realiza todas as tarefas necessárias para as atividades de classificação e extração das cicatrizes de área queimada utilizando imagens de sensoriamento remoto orbital como dados de entrada.
Considerando as atividades que podem ser atribuídas a um sistema de processamento operacional é possível mencionar a obtenção das imagens, a atualização do acervo de imagens brutas, processamento, atualização do acervo de produtos e publicação de dados.
O INPE-DGI possui, na sede de Cuiabá, MT, as antenas de recepção para a descarga das imagens diretamente do satélite Landsat 8/OLI, e em Cachoeira Paulista, SP, as estações de trabalho para produzir dados que possam ser utilizados pelo público geral. O sistema operacional desenhado, segundo os requerimentos do atual TdR, deve ser configurado para utilizar esses dados produzidos localmente, sempre que sua qualidade seja adequada para sua utilização em processos automáticos [Melchiori, 2014 a)].
Na realidade, o sistema operacional de recepção de imagens Landsat-8 e produção de produtos no INPE-DGI de Cachoeira Paulista encontra-se em fase de implementação e avaliação por parte da USGS para garantir a qualidade dos dados adquiridos e dos sub-produtos e produtos gerados pelo sistema. Os projetos e implementações realizados no marco do atual TdR na sede do INPE-CPTEC em São José dos Campos serão reproduzidas nos sistemas em Cachoeira Paulista. O desenho, utilizando máquinas virtuais [Virtual Machine 2015] administradas mediante o gestor OVirt [Ovirt 2015], permite uma rápida implementação em outra infraestrutura computacional sem mudanças significativas, unicamente modificando os endereços dos sistemas involucrados.
O SOMAQ será implementado para obter, de maneira automática, as cicatrizes de queimadas no Cerrado Brasileiro, com um total de 112 cenas do satélite Landsat 8/OLI-TIRS geradas pelos sistemas operacionais do INPE- ver Figura 1.
4 ÁREA DE COBERTURA DO CERRADO BRASILEIRO.
O Cerrado Brasileiro contínuo, com uma área superior a 2.000.000 Km2 é a maior extensão savânica do mundo, ocupando quase um quarto do território do Brasil. A área de estudo, é coberta por 112 cenas do satélite Landsat 8, começando na órbita 217 no leste da região abrangida pelo bioma, até a órbita 229 no oeste. A Figura 1 a seguir apresenta o Bioma Cerrado, a grade Landsat
8 que cobre toda a superfície do bioma e, as áreas protegidas e terras indígenas. As órbitas limites são indicadas no mapa.
A seguinte Tabela 1 apresenta a listagem total das 112 órbitas/ponto que cobrem a superfície do Cerrado Brasileiro.
Figura 1. Mapa do Cerrado Brasileiro, com a grade Landsat e os polígonos das áreas de conservação e terras indígenas.
9 Órbita 217 218 219 220 221 222 223 224 225 226 227 228 229
62 62 62
63 63 63
64 64 64 64 64
65 65 65 65 65
66 66 66 66 66
67 67 67 67 67 67 67
68 68 68 68 68 68 68 68 68 68
69 69 69 69 69 69 69 69 69 69 69 69
70 70 70 70 70 70 70 70 70 70 70 70
71 71 71 71 71 71 71 71 71 71 71
72 72 72 72 72 72 72 72 72 72
73 73 73 73 73 73 73 73 73
74 74 74 74 74 74 74 74 74 74
75 75 75 75 75 75 75 75
76 76 76 76 76 76 76
77 77 77
Tabela 1. Órbitas/ponto Landsat-8 cobrindo o Cerrado Brasileiro.
Um aspecto importante num sistema operacional é o calendário das passagens. Ele permite avaliar o processamento das imagens segundo a sua data de aquisição e alertar sob qualquer possível falha na sequencia de processos. O próximo capítulo apresenta o calendário das passagens correspondentes ao ano 2015 e, uma equação simples que permite conhecer o dia juliano de uma passagem a partir da data da primeira passagem do ano.
5 CALENDARIO DE RECEPÇÂO LANDSAT 8/OLI
O satélite Landsat 8/OLI tem um período de revisita de 16 dias, ou seja, o satélite pecorre novamente uma determinada órbita a cada 16 dias. A partir da data da primeira passagem do ano é possível conhecer as outras sucessivas passagens do satélite. A Tabela 2 a seguir apresenta as datas da primeira passagem do ano 2015 para as órbitas de interesse.
Órbita Data Dia Juliano Òrbita Data Dia Juliano
217 12/Jan 12 224 13/jan 13
218 03/Jan 03 225 04/jan 04
219 10/jan 10 226 11/jan 11
220 17/Jan 17 227 18/Jan 18
221 08/Jan 08 228 09/Jan 09
222 15/jan 15 229 16/Jan 16
223 06/Jan 06
Tabela 2. Datas das primeiras órbitas sob o Cerrado para o ano 2015.
10 Utilizando a data da primeira passagem, as datas das próximas passagens podem ser calculadas utilizando a seguinte expressão.
Onde IMax= 20 para as datas iniciais que sejam <= 15, para as datas iniciais posteriores ao dia 15, o valor de IMax= 19.
O calendário de órbitas é importante para realizar um controle sob os dados processados e publicados. A seguinte Tabela 3 apresenta os dias julianos correspondentes às passagens nas 13 órbitas que cobrem o Cerrado Brasileiro.
Órbita 217 218 219 220 221 222 223 224 225 226 227 228 229
Pas.1 12 3 10 17 8 15 6 13 4 11 18 9 16
Pas.2 28 19 26 33 24 31 22 29 20 27 34 25 32 Pas.3 44 35 42 49 40 47 38 45 36 43 50 41 48 Pas.4 60 51 58 65 56 63 54 61 52 59 66 57 64 Pas.5 76 67 74 81 72 79 70 77 68 75 82 73 80 Pas.6 92 83 90 97 88 95 86 93 84 91 98 89 96 Pas.7 108 99 106 113 104 111 102 109 100 107 114 105 112 Pas.8 124 115 122 129 120 127 118 125 116 123 130 121 128 Pas.9 140 131 138 145 136 143 134 141 132 139 146 137 144 Pas.10 156 147 154 161 152 159 150 157 148 155 162 153 160 Pas.11 172 163 170 177 168 175 166 173 164 171 178 169 176 Pas.12 188 179 186 193 184 191 182 189 180 187 194 185 192 Pas.13 204 195 202 209 200 207 198 205 196 203 210 201 208 Pas.14 220 211 218 225 216 223 214 221 212 219 226 217 224 Pas.15 236 227 234 241 232 239 230 237 228 235 242 233 240 Pas.16 252 243 250 257 248 255 246 253 244 251 258 249 256 Pas.17 268 259 266 273 264 271 262 269 260 267 274 265 272 Pas.18 284 275 282 289 280 287 278 285 276 283 290 281 288 Pas.19 300 291 298 305 296 303 294 301 292 299 306 297 304 Pas.20 316 307 314 321 312 319 310 317 308 315 322 313 320 Pas.21 332 323 330 328 335 326 333 324 331 329
Tabela 3. Cronograma do satélite Landsat 8 para o ano 2015.
Além do calendário das aquisições, é importante conhecer a sequência de processos que se seguem à ingestão das imagens. A Figura 2 apresenta um diagrama de fluxo dos dados, desde a recepção dos dados brutos até a disponibilidade das imagens prontas para o público geral.
11 As imagens são recebidas como dados brutos e, nas diferentes etapas do processamento o produto evolui para o dado em nível zero (L0) com a imagem em sua forma mais báseica, até o dado em nível L1T, com correção no terreno utilizando um Modelo Digital de Elevação e pontos de controle [Landsat Processing Details 2015]. O sistema desenvolvido neste trabalho utiliza dados no nível L1T como entrada para os processos de mapeamento de áreas queimadas.
6 MÓDULOS DO SISTEMA OPERACIONAL
O sistema operacional de mapeamento de áreas queimadas desenvolvido é composto de diferentes módulos que realizam tarefas específicas. Esses módulos foram projetados de maneira distribuída em um conjunto de computadores com o objetivo de distribuir a carga de processos.
O computador com o Acervo de Imagens tem características distintas em relação ao computador de processos, e do computador com o servidor de banco de dados. Essas características são definidas segundo os requerimentos computacionais dos processos realizados por cada componente.
Todos os componentes do sistema estão interconectados mediante uma estrutura de rede, a qual serve como meio de comunicação entre os componentes e, para transferência dos dados.
A Figura 3 a seguir apresenta um diagrama de fluxo dos componentes do sistema e das Figura 2. Componentes e fluxo dos dados no Sistema de Captura e Produção de dados Landsat.
[Imagem cortesia da USGS]
12 interconexões.
No atual TdR o primeiro módulo a ser projetado e implementado é o Módulo de Cadastro, responsável pela administração dos limiares diferenciais necessários para o processamento das 112 diferentes cenas que cobrem a área do Cerrado Brasileiro apresentadas na Figura 1 e Tabela 1.
7 MÓDULO DE CADASTRO.
O Módulo de Cadastro dos limiares dinâmicos, implementado no programa imPAAQ_CADASTRO_vOP.py, possui todas as funcionalidades que foram requeridas no TdR:
incorporação, modificação e exclusão de limiares, um para cada mês de cada ano e, para cada órbita/ponto da grade Landsat correspondente ao Cerrado Brasileiro.
Os limiares dinâmicos para cada órbita/ponto são armazenados num banco de dados PostgreSQL [PostgreSQL 2015] para facilitar as tarefas de administração e acesso aos dados.
Figura 3. Diagrama de fluxo do Sistema Operacional de Mapeamento de Área Queimada
13 Os parâmetros de conexão no banco de dados são os seguintes.
Host: monza.cptec.inpe.br User: queimadas
Pass: Cpt,Qmd,2014
DB: processamento_imagens Port: 5432
Tabela: public.limiares
A Figura 4 a seguir apresenta o diagrama de fluxo do Módulo de Cadastro de Limiares.
A tabela de limiares possui uma coluna para indicar a órbita/ponto, outra para o ano, doze para limiares do índice NDVI e, outras doze para limiares do índice NBRL. Com essa estrutura é possível considerar a utilização de um limiar para cada mês e cada ano em cada órbita/ponto. A Tabela 4 apresenta um esquema simplificado da estrutura da tabela de limiares no banco de dados.
órbita/ponto ano ndvi_01 ndvi_02 ... ndvi_12 nbrl_01 nbrl_02 ... nbrl_12 Tabela 4. Desenho da tabela de limiares no banco de dados.
Figura 4. Diagrama de Fluxo do Módulo de Cadastro de Limiares Diferenciais
14 A tabela de limiares foi criada utilizando o seguinte script de SQL.
CREATE TABLE limiares (orbita_ponto varchar, ano integer, ndvi_01 real, ndvi_02 real, ndvi_03 real, ndvi_04 real, ndvi_05 real, ndvi_06 real, ndvi_07 real, ndvi_08 real, ndvi_09 real, ndvi_10 real, ndvi_11 real, ndvi_12 real, nbrl_01 real, nbrl_02 real, nbrl_03 real, nbrl_04 real, nbrl_05 real, nbrl_06 real, nbrl_07 real, nbrl_08 real, nbrl_09 real, nbrl_10 real, nbrl_11 real, nbrl_12 real)
7.1 Funcionalidades do Módulo de Cadastro de Limiares.
Foram projetadas e implementadas as funcionalidades requeridas no TdR para o Módulo de Cadastro de Limiares: incorporação de limiares, modificação de aqueles limiares armazenados no banco de dados, e exclusão de limiares existentes. Foi incorporada uma funcionalidade para obter todos os limiares armazenados, ou aqueles correspondentes a uma órbita/ponto determinada. A seguir é descrita a estrutura de um arquivo projetado para facilitar as tarefas de inserção e modificação de limiares e, também cada um dessas funcionalidades.
7.1.1 Arquivo de Limiares
O arquivo de limiares é utilizado para facilitar as tarefas do consultor responsável pela administração e atualização da Tabela de Limiares no Banco de Dados.
O arquivo de limiares possui uma estrutura similar à da Tabela no Banco de Dados descrita acima, onde cada linha da tabela (o arquivo) corresponde aos limiares de uma órbita/ponto e ano determinados.
O arquivo de limiares, com extensão csv tem compatibilidade com editores de texto ou programas de planilhas de cálculo. O separador de campos é ponto e vírgula (;) e o separador decimal é o ponto (.). O arquivo tem uma largura fixa de 26 colunas.
A utilização de um arquivo de limiares permite ao responsável da administração e atualização dos limiares ter uma copia local dos limiares em um arquivo com formato conhecido, transferível e modificável sem necessidade de ferramentas específicas.
O responsável pelo arquivo de limiares precisa de atenção especial na modificação dos valores conteúdos no arquivo já que esses valores serão inseridos no banco de dados.
7.1.2 Incorporação de Limiares.
Os limiares dinâmicos são incorporados no banco de dados utilizando a função
“inserir_limiar” do Módulo de Cadastro. A função possui só um parâmetro correspondente à rota do arquivo de limiares descrito acima.
15 imPAAQ_CADASTRO_vOP.py inserir_limiar /rota_arquivo/arquivo_limiares.csv
Não é possível inserir duas entradas de limiares para uma mesma combinação de ano e órbita/ponto. Cada combinação deve ser única, e só é possível determinar uma nova combinação de limiares para uma órbita/ponto indicando um ano diferente. No caso que o arquivo de limiares tenha limiares já inseridos no banco, os antigos serão mantidos para referência.
7.1.3 Módulo de modificação dos limiares.
A modificação desses limiares ou índices espectrais é possível utilizando a função
“modificar_limiar” do programa Cadastro. O único parâmetro da função é um arquivo com limiares a modificar, utilizando a mesma estrutura do arquivo de limiares descrito acima.
imPAAQ_CADASTRO_vOP.py modificar_limiar /rota_arquivo/arquivo_limiares_mod.csv
Todos os limiares incluídos no arquivo indicado serão modificados.
7.1.4 Módulo de Leitura.
Foi implementada uma função de leitura “ler_limiar” para realizar a consulta do banco de dados e obter os limiares correspondentes a todas as órbitas/ponto, ou a uma órbita/ponto determinada, segundo seja requerido.
imPAAQ_CADASTRO_vOP.py ler_limiar op:221_067 ano:2014
Casos sejam requeridos todos os limiares armazenados no banco de dados, a função
“ler_limiar” utiliza o parâmetro adicional “tudos”.
Caso sejam requeridos os limiares correspondentes a uma órbita/ponto, a entrada do módulo de leitura é a órbita-ponto requerida, e a saída é um vetor com os valores dos limiares para cada índice. O módulo de leitura não possui permissões de gravação no arquivo de limiares.
7.1.5 Modulo de Exclusão
A última funcionalidade descrita é a de exclusão dos limiares armazenados no banco de dados. A função “eliminar_limiar” foi implementada para apagar os limiares correspondentes a uma determinada órbita/ponto.
imPAAQ_CADASTRO_vOP.py eliminar_limiar op:221_067 ano:2014
16 7.2 Ferramenta para obtenção de limiares ótimos de extração
Foi projetada e implementada uma ferramenta digital para obter os valores de limiares de extração de cicatrizes de área queimada que minimizam os erros de comissão e omissão na identificação dos píxeis de áreas queimadas. Os dados de entrada são as imagens de NDVI e NBRL para duas datas consecutivas, e as cicatrizes de área queimada são as obtidas mediante mapeamento com um classificador automático e imagens compostas [Jesus et al, 2015]. O procedimento tem como objetivo obter o par de limiares de extração que melhor se ajusta à referência de área queimada do classificador automático.
A ferramenta implementada explora os erros de comissão e omissão obtidos utilizando diferentes valores de limiares até encontrar aqueles que apresentam a combinação mais adequada destes erros. A sequência dos processos é a apresentada na Figura 5 a seguir.
A rotina desenhada explora uma série de valores de limiares de mudança de NDVI e NBRL, desde o valor da média das mudanças dentro das cicatrizes da referência, até um mínimo de 0,1 (10% de mudança): calcula os erros de comissão e omissão para cada par de limiares,
Figura 5. Rotina de cálculo de limiares de extração de área queimada.
17 calcula a soma desses erros e, finalmente obtém o menor valor da soma para identificar qual é o par de limiares que geram a menor combinação de erros de comissão e omissão. A seguinte Figura 6 apresenta a curva da soma de erros para diferentes valores de limiares; cada valor de soma, por sua vez, é o resultado da razão entre a soma do número de píxeis dos erros de omissão e de comissão, dividida pelo número de píxeis de área queimada no dado de referência.
A seguinte Figura 7 apresenta um detalhe da curva de erros para as combinações de limiares que produzem os menores valores de erros. Os valores determinados pela metodologia desenhada são identificados com uma linha vertical vermelha.
Figura 6. Erros de Comissão e Omissão para diferentes limiares
Figura 7. Detalhe da curva de limiares dos valores obtidos pela metodologia desenvolvida
18 Os resultados da metodologia implementada indicam que os menores valores de erros de comissão e omissão são obtidos utilizando os limiares 0,269 e 0,529 para a mudança de NDVI e NBRL, respetivamente. Os valores de erros de comissão e omissão são 4,4% e 9,0% dando um valor total de erro de 13,4%.
8 MÓDULO DE PROCESSAMENTO
O Módulo de Processamento (MP) é responsável pelo cálculo da área queimada a partir das imagens Landsat/8-OLI-TIRS utilizando limiares de extração diferenciais proporcionados pelo Módulo de Administração de Dados (MAD). O MAD possui as funcionalidades necessárias para processar os dados comprimidos e armazenados no acervo, converter os dados brutos em valores de refletância no topo da atmosfera, obter do banco de dados os limiares de extração correspondentes e, finalmente, armazenar em vários formatos os dados de saída proporcionados pelo MP.
A Figura 8 a seguir exemplifica a circulação e processamento dos dados no MAD para responder ao pedido de dados de refletância e limiares de extração solicitados pelo MP.
Figura 8. Circulação dos dados após uma solicitação de imagens e limiares
19 Os dados proporcionados pelo MAD são processados no MP com o objetivo de obter as cicatrizes de área queimada. O diagrama do fluxo do processamento de área queimada é apresentado na Figura 9 a seguir.
O módulo de processamento recebe as imagens de refletância no topo de atmosfera do módulo de administração de dados, calcula as máscaras de nuvens, calcula os índices espectrais NDVI [Gitelson et al, 1996] e NBRL [Key & Benson, 1999] para cada uma delas, calcula a mudança desses índices utilizando a fórmula descrita na Equação 1 e, finalmente calcula a máscara de área queimada [Melchiori A.E 2014 a)] utilizando a fórmula na Equação 2.
Eq. 1
Eq 2.
Figura 9. Diagrama de fluxo do processamento dos dados na obtenção de cicatrizes de área queimada e máscara de nuvens
20 A versão atual do módulo de processamento incorpora a utilização de limiares diferenciais na fórmula de extração de área queimada. A Equação 3 apresenta a fórmula atual do algoritmo de área queimada com limiares diferenciais.
Eq. 3.
Os subíndices OP,A e, M indicam que os limiares de extração dos índices NDVI e NBRL, variam segundo a órbita/ponto (OP), ano (A) e mês (M) da imagem post-fogo.
Os dados processados são enviados ao Módulo de Administração para armazenagem. O Módulo de Administração tem as funções necessárias para: escrever os diferentes formatos de imagens que são armazenados, converter as imagens em vetores e, escrever no banco de dados geográfico. A Figura 10 a seguir apresenta o diagrama de fluxo dos dados para armazenagem.
8.1 Máscara de nuvens
No presente, e segundo as informações do sitio de descarga dos arquivos Landsat [TIRS 2015], as imagens do sensor TIRS possuem valores incorretos. Devido a este problema, a USGS removeu os dados do sensor TIRS do pacote proveito ao público.
No contrato anterior com a GIZ (TdR N° 11-9035-4-001.00) foi projetada e desenvolvida uma máscara de nuvens para os sensores TM, ETM e OLI-TIRS. A máscara resultante possui uma alta dependência da banda térmica para separar as áreas com areia e solos expostos, muito comuns no Cerrado Brasileiro. O aviso da falha no sensor TIRS motivou utilizar outros dados na geração da máscara de nuvens. A solução mais aceitável foi recorrer aos dados de qualidade providos no pacote. A banda BQA - Band Quality Assessment [Landsat BQA 2015] do sensor Landsat 8 tem a seguinte descrição apresentada na Figura 11.
Figura 10. Diagrama de fluxo do armazenamento dos dados pelo Módulo de Administração
21 Os 4 bits mais significativos (MSB) da palavra de 16 bits apresentam informação relativa ao conteúdo de nuvens de cada pixel na imagem, e a confiança deste valor. O bit 15 apresenta alta confiança de nuvens, o bit 13 alta confiança de nuvens de tipo cirrus. A obtenção de uma máscara de nuvens resulta do uso desses valores, e mascarando o resto da informação.
Na linguagem Python também é possível realizar operações ao nível de bits. A operação de interesse é o deslocamento para a direita, sem rotação [Right-shift 2015]. A Figura 12 a seguir apresenta um esquema que exemplifica o deslocamento de 12 posições para a direita.
Os quatro valores MSB originais são convertidos nos bits menos significativos (LSB) na palavra resultante deslocada. Segundo as Figuras 11 e 12, os valores da máscara de nuvens estão determinados pelas combinações apresentadas na seguinte Tabela.
Bit 3 Bit 2 Bit 1 Bit 0 Valor da máscara Valor original do pixel
1 1 1 1 15 >61440
1 1 1 0 14 >57344
1 1 0 1 13 >53248
1 1 0 0 12 >49152
1 0 1 1 11 >45056
1 0 1 0 10 >40960
1 0 0 1 9 >36864
1 0 0 0 8 >32768
0 1 1 1 7 >28672
0 1 1 0 6 >24576
Tabela 5. Valores da banda BQA para constituir uma máscara de nuvens Figura 11. Configuração dos bits da banda BQA do sensor Landsat 8
Figura 12. Deslocamento de 12 posições para a direita de uma palavra de 16 bits.
22 Os valores com relevância baixa, bits 14 e 12, não são indicadores de nuvens, e precisam dos bits 15 ou 13 para ter relevância na máscara. A Figura 13 apresenta um exemplo de máscara de nuvens baseada na banda BQA do pacote de dados distribuído pela USGS.
Figura 13. Máscara de nuvens baseada na banda BQA do pacote de dados da USGS.
Figura 14. Banda 4 do pacote de dados da USGS.
23 A Figura 14, apresenta a banda 4 da imagem correspondente à máscara de nuvens da Figura 10. Pode se observar que as sombras de nuvens não são identificadas na atual versão da banda BQA. Os bits reservados para as sombras de nuvens possuem valor zero e são confundidos com a máscara de agua.
Esta falha nas imagens termais do Landsat-8 possivelmente será resolvida em futuro breve pelo USGS, que está trabalhando neste sentido (ver Anexo 1), e desta forma o algoritmo desenvolvido para a filtragem de nuvens [(Melchiori 2014 b)] será integrado ao sistema de processamento.
9 MÓDULO DE INTEGRAÇÃO.
O terceiro dos módulos projetados para o presente TdR é o Módulo de Integração. O Módulo de Integração (MI) tem a função de comunicar ao Sistema de Processamento que novos dados foram recebidos e armazenados no acervo de imagens brutas e podem ser processados.
Todas essas tarefas são realizadas sem a intervenção do usuário. O MI possui assim, uma estreita ligação com o Módulo de Atualização do Acervo (MAA) e o Módulo de Processamento (MP). A Figura 15 apresenta um esquema do fluxo de dados entre os módulos.
Considerando o calendário das passagens Landsat que foi apresentado no Capítulo 4, todas as cenas correspondentes a uma mesma órbita serão processadas no mesmo dia e os dados publicados na sequência do processamento. Ainda não é possível estabelecer qual é o tempo de demora desde a ingestão dos dados até a da disponibilidade das imagens para
Figura 15. Fluxo de dados entre os Módulos de Acervo, Integração e Processamento.
24 processar, uma vez que esta avaliação de pende de operações que ainda estão em fase de teste na DGI-INPE.
Como mencionado no Capítulo 2, o Sistema de Aquisição e Geração de Imagens Landsat 8/OLI-TIRS que está sendo instalado no INPE-Cachoeira Paulista encontra-se em fase de avaliação por parte da USGS. A avaliação consiste em testar e avaliar cada um dos dados gerados pelo sistema de ingestão e os diferentes componentes do sistema de geração de imagens, desde o dado bruto até o dado em nível L1T pronto para o processamento e distribuição ao público. No presente, a fase em avaliação é a de geração do dado bruto, prévio ao dado nível zero. A USGS deve aprovar o produto gerado para habilitar as posteriores fases da instalação e configuração do sistema. As perspectivas do responsável da DGI é que o sistema fique pronto no mês de abril ou maio de 2015.
9.1 Conectividade segura entre os Módulos de Acervo e Processamento
Na Figura 3 pode-se observar que o Módulo de Atualização do Acervo (MAA) (imPAAQ_UpdateDB_vOP) e o Módulo de Seleção dos Dados (MSD) (imPAAQ_SelectData_vOP) do MP são executados em computadores diferentes. A comunicação segura entre ambos os módulos é estabelecida mediante o MI e utilizando uma biblioteca denominada Paramiko [Paramiko 2015] para a linguagem Python.
A biblioteca Paramiko implementa o protocolo de comunicação SSHV2 [Ssh 2015]
permitindo uma conexão segura do tipo cliente-servidor entre dois computadores interconectados em uma estrutura de rede com o objetivo de executar tarefas no servidor. O cliente é representado pelo MI e o servidor pelo MP. O cliente (MI) solicita ao servidor (MP) o processamento dos dados que foram recentemente inseridos no Banco de Dados.
O cliente tem a responsabilidade de autenticar a conexão com o servidor utilizando um usuário e palavra-chave, ou uma chave pública [Chave pública 2015]. O servidor tem a responsabilidade de decidir quais usuários, palavras chaves ou chaves públicas são permitidas para estabelecer uma conexão.
A forma mais simples para estabelecer uma conexão cliente-servidor que vai requerer múltiplas sessões é provavelmente utilizando uma chave. As chaves representam certificados de autenticidade destinados a evitar a utilização de usuários e palavras chaves nas conexões. A chave é gerada no cliente e transferida ao servidor uma única vez. O servidor vai utilizar a chave transferida para verificar o cliente e permitir o acesso em cada conexão.
O comando utilizado no cliente para gerar uma chave é: “ssh-keygen –t rsa”. Após a criação da chave é necessário transferi-la ao servidor para estabelecer o vínculo entre a chave e o cliente. Esse vínculo é estabelecido utilizando o comando: “ssh-copy-id user@dir”
O próximo passo requer de testar a conexão cliente-servidor para avaliar a correta
25 recepção e registro da chave. A conexão e realizada utilizando o comando “ssh user@dir”.
Uma vez que a chave foi transferida, a biblioteca paramiko pode ser utilizada para executar o módulo de integração por parte do cliente.
O código fonte no cliente precisa de uma declaração acessando o servidor e executando o programa correspondente. A seguir, o código de acesso ao servidor é exemplificado.
import paramiko
ssh= paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) ssh.connect(“taynha.cptec.inpe.br”)
ssh.exec_command(“python /codedir/code.py”) ssh.close()
O código apresentado só funciona após a transferência da chave do cliente para o servidor; ou então, é necessário inserir o nome de usuário e password no código de conexão.
9.2 Sob a projeção e implementação definitiva do Módulo de Integração.
Até o momento não é possível realizar um projeto e implementação definitiva do MI devido à instalação do Sistema de Ingestão das imagens Landsat 8/OLI-TIRS não estar concluída na sede do INPE-Cachoeira Paulista. O caráter inovador dos sistemas utilizados na ingestão e processamento dos dados adquiridos pela antena de recepção satelital só permitem por enquanto estabelecer suposições sob a estrutura e funcionamento do sistema.
A projeção de término da instalação para o mês de Abril/Maio permite supor que antes da entrega do segundo produto do atual TdR, novas informações sob a arquitetura do sistema e do estado do MI serão disponibilizadas e devidamente descritas nos futuros relatórios.
10 SISTEMA DE CONTROLE DE VERSÕES DO CÓDIGO FONTE
O atual TdR determina que o código fonte criado fique resguardado em um Sistema de Controle de Versões para garantir o proseguimento dos avanços, e o resguardo das informações geradas. Um Sistema de Controle de Versões (SCV) representa uma ferramenta indispensável em um ambiente de desenvolvimento de programas. O SCV possui todas as funcionalidades que o desenvolvedor requer para manter organizado o código fonte criado, e registradas todas as mudanças e avanços no trabalho de programação.
Um SCV cria um repositório de código fonte para armazenagem, onde os diferentes usuários enviam as suas respectivas versões dos códigos fontes na medida dos avanços na programação. Os diferentes usuários possuem nos respectivos computadores uma versão do
26 conteúdo do repositório denominada “copia de trabalho”. Essa copia de trabalho representa a versão mais recente do código no repositório.
No presente relatório é apresentada a utilização do Sistema de Controle de Versões Subversion [Subversion 2015]. O SCV está instalado e configurado para funcionar na rede do INPE São José dos Campos e, só pode ser acedido pelos administradores do sistema e autores do código fonte.
10.1 Arquivos do código fonte.
O primeiro passo no presente TdR foi organizar o código fonte a ser utilizado para implementar as mudanças que foram requeridas. Foi utilizado o código criado no contexto de um contrato com MMA/FUNBIO para o desenvolvimento da base de uma ferramenta operacional para o mapeamento e extração das cicatrizes de área queimada em onze cenas do Cerrado Brasileiro [Melchiori 2014 c)]. A base da ferramenta operacional é o código criado no contrato anterior com a GIZ para extrair cicatrizes de áreas queimadas na cena 221/067, correspondente ao Parque Estadual do Jalapão, no estado de Tocantins.
Para diferenciar o código existente da nova versão foram renomeados os arquivos e inseridos no SVC para começar as tarefas de desenvolvimento utilizando o controle de versões.
O Módulo de Processamento foi salvo com o nome: imPAAQ_Proc_vOP_OLI_MPC.py. As diferentes componentes do nome do arquivo tem significado. O imPAAQ indica que o objeto de processamento são imagens (im) e o objetivo do programa é o Processamento Automático de Áreas Queimadas (PAAQ), Proc indica o componente de processamento per se, vOP que é a versão operacional do sistema, OLI indica que a fonte dos dados é o satélite Landsat 8/OLI e, MPC que são implementadas rotinas de processamento paralelo em múltiplos núcleos quando foram disponíveis.
O Módulo de Administração de Dados do Sistema de Processamento foi salvo com o nome imPAAQ_FileManager_OLI_MPC.py.
O Módulo de Atualização do Acervo foi salvo com o nome imPAAQ_UpdateDB_vOP.py.
O Módulo de Integração foi salvo com o nome imPAAQ_Integration_vOP.py.
O ultimo componente do Sistema de Processamento são as definições de registros utilizados pelos Módulos de Processamento e Administração. O arquivo de definições foi salvo com o nome imPAAQ_definitios.py.
Os arquivos mencionados estão armazenados no endereço /home/queimadas/scripts da máquina taynha.cptec.inpe.br na rede do INPE-São José Dos Campos.
No momento de instalar o sistema na rede do INPE-Cachoeira Paulista, os nomes dos arquivos podem-se manter sem mudança. O Módulo de Atualização do Acervo será apagado, já
27 que as funções de administração do banco de dados será responsabilidade do Sistema de Controle e Processamento da DGI.
10.2 Uso do Sistema de Controle de Versões.
O Sistema de Controle de Versões (SCV) é configurado para atender os endereços das cópias de trabalho nas máquinas abrangidas. Para realizar qualquer tarefa de controle é necessário ingressar primeiro no diretório e a partir dele executar as ferramentas do SCV.
10.3 Incorporação dos arquivos com código fonte.
Os arquivos de código fonte são incorporados no SCV utilizando o comando “svn add”.
Para os diferentes arquivos do projeto, os comandos foram:
svn add imPAAQ_Proc_vOP_OLI_MPC.py svn add imPAAQ_FileManager_OLI_MPC.py svn add imPAAQ_vOP_Man.py
svn add imPAAQ_Definitions.py
svn add imPAAQ_CADASTRO_vOP.py svn add imPAAQ_SelectData_vOP.py svn add imPAAQ_UpdateDB_vOP.py
Posteriormente ao comando “svn add” é necessário executar o comando “svn commit” com os mesmos nomes dos arquivos que foram recentemente incorporados no repositório.
10.4 Incorporação de mudanças no código fonte.
As mudanças no código fonte devem ser armazenadas no SCV para um controle das modificações que foram feitas. O comando para incorporar a nova versão do código no SCV é
“svn commit”. A rotina completa se exemplifica a seguir.
svn commit imPAAQ_Proc_vOP_OLI_MPC.py –m “Mudança dos nomes”
Recomenda-se escrever um comentário respeito das mudanças que foram realizadas no código para ter uma rápida ideia dos conteúdos dos arquivos.
10.5 Verificação de mudanças no código fonte.
O SVC possui o comando “svn status” para conhecer o estado dos arquivos no diretório de trabalho e no repositório após uma sessão de trabalho. A saída do comando pode indicar diferentes estados dos arquivos no repositório. A lista a seguir exemplifica alguns dos casos possíveis.
„‟ – Sem modificações.
A – Novo arquivo no repositório.
28 D – Arquivo eliminado
M – Arquivo modificado R – Arquivo substituído C – Arquivo em conflito
? – Arquivo sem representação no repositório
! – Arquivo perdido
~- Tipo de objeto modificado
Por exemplo, os arquivos recentemente incorporados no repositório utilizando o comando
“svn add” mostraram uma “A” após consulta quanto ao estado dos arquivos no repositório. Os arquivos que foram modificados após uma sessão de trabalho mostraram uma “M” ao lado do nome do arquivo. Essas indicações ajudam a conhecer quais arquivos precisam ser atualizados no repositório.
11 ANEXO 1
É apresentado um correio electrónico de um membro da equipe de Cooperação Técnica Internacional do Projeto Landsat, referido ao funcionamento do sensor TIRS do satélite Landsat-8 e a volta em funcionamento projetada para o mês de abril de 2015.
______________________________________________________________________________
Assunto: Landsat 8 TIRS Sensor Resumes Nominal Operations Data: Sat, 7 Mar 2015 10:54:13 -0600
De: Shaw, Jerad <jshaw@usgs.gov>
Para: undisclosed-recipients:
Greetings ICs,
The Landsat 8 Thermal Infrared Sensor (TIRS) resumed normal imaging operations on March 4, 2015, and nominal blackbody and deep space calibration data collection will resume on March 7, 2015.
Since the current anomaly associated with the scene select mirror encoder electronics forced a suspension of TIRS Level-1 data processing on December 19, 2014, an exhaustive study has been conducted to determine the root cause of the anomaly and to develop plans for reconfiguring the instrument for a return to nominal operations. During this time TIRS data
29 continued to be collected and archived, although Level-1 processing was suspended.
On March 2, 2015, the TIRS mechanism control electronics (MCE) were swapped to the redundant side (“side-B”) and TIRS data collection resumed on March 4, 2015. It will still take several weeks of commissioning the instrument with the side-B MCE and obtaining sufficient calibration data to resume Level-1 processing. Likewise, TIRS data collected December 19, 2014 through March 1, 2015 will require updated calibration parameters before these data can be processed to generate Level-1 products.
The table below summaries the dates ranges during which TIRS data have been acquired, when provisional products will become available, when reprocessing will take place, and when reprocessed data will become available.
Acquisition Date Range
Sensor Imagery Acquired
Provisional TIRS
Product Availability
Reprocessing Period
Nominal TIRS Data Product Availability
Notes
December 19, 2014 – March 1, 2015 (23:57:34 UTC)
OLI &
TIRS
N/A April 30, 2015 - May 18, 2015
May 18,2015 Several lost TIRS scenes in the period; TIRS imaging stopped in preparation for TIRS side-swap March 2, 2015
(13:53:23 UTC) - March 3, 2015 (00:40:35 UTC)
None N/A N/A N/A No TIRS or OLI
imagery acquired due to TIRS side-swap
activities
March 3, 2015 (00:40:35 UTC) - March 4, 2015 (00:02:18 UTC)
OLI N/A N/A N/A OLI imaging
resumes
March 4, 2015 (00:02:18 UTC) - March 4, 2015 (16:20
OLI &
TIRS
N/A N/A N/A TIRS
engineering imagery acquired
30 UTC)
March 4 (16:20:00 UTC) - March 7 (00:00:00 UTC)
OLI &
TIRS
N/A April 13, 2015 - April 20, 2015
April 20,2015 Mode-4 without TIRS cals
March 7 (00:00:00 UTC) - April 13, 2015 (23:59:59 UTC)
OLI &
TIRS
March 16, 2015
April 13, 2015 - April 20, 2015
April 20,2015 Nominal TIRS that includes regular BB & DS
A more comprehensive summary of the issues and impacts to TIRS data collection will be
posted on the Landsat 8 Calibration Notices web site:
http://landsat.usgs.gov/calibration_notices.php
If you have any questions, please let me or Steve Labahn know.
Best Regards, Jerad
===========================
Jerad L. Shaw
Landsat International Cooperator Technical Support Stinger Ghaffarian Technologies (SGT, Inc.)
Contractor to the U.S. Geological Survey (USGS)
Earth Resources Observation and Science (EROS) Center 47914 252nd Street, Sioux Falls, SD 57198
jshaw@usgs.gov ph: 605-594-6944 SHIPPING:
USGS/EROS ATTN: Jerad Shaw 47914 252nd Street Sioux Falls, SD USA 57198-0001
31 12 BIBLIOGRAFIA
Chave pública <http://en.wikipedia.org/wiki/Public-key_cryptography> Acesso em Fevereiro de 2015.
Jesus, S.C.; Setzer, A.; Morelli,F.; Almeida Cândido, P. and Melchiori, A.E.. Multi-temporal composites of spectral indexes to map burned areas in Brazilian Cerrado with medium resolution satellite data. Submitted Remote Sensing. 2015
Gitelson, A.A.; Kaufman, Y.J.; Merzlyak, M.N. Use of a Green Channel in Remote Sensing of Global Vegetation from EOS-MODIS. Remote Sensing of Environment. 1996. 58:289-298.
Key, C.H.; Benson, N.C. Measuring and remote sensing of burnt severity. The CBI and NBR.
Poster abstract. Proceedings Joint Fire Science Conference and Workshop. International Association of Wildland Fire. 1999
Landast BQA <http://landsat.usgs.gov/L8QualityAssessmentBand.php> Acesso em Fevereiro de 2015.
Landsat Processing Details <http://landsat.usgs.gov/Landsat_Processing_Details.php> Acesso em Fevereiro de 2015.
Melchiori A.E. a) Algoritmo digital automático para estimar áreas queimadas em imagens de média resolução espacial na região do Jalapão. Resultados Finais. Relatório GIZ. Abril de 2014.
Melchiori A.E. b) Aperfeccionamento do algoritmo digital automático para estimar áreas queimadsa em imagens de média resolução da região do Jalapão. Agosto de 2014.
Melchiori A.E. c) Rotina de mapeamento operativo para outras cenas. Relatório MMA. Novembro de 2014.
Ovirt <www.ovirt.com> Acesso em Fevereiro de 2015.
Paramiko <http://www.paramiko.org/> Acesso em Fevereiro de 2015.
PostgreSQL <http://www.postgresql.org/> Acesso em Fevereiro de 2015.
Right-shift <http://docs.scipy.org/doc/numpy/reference/generated/numpy.right_shift.html> Acesso em Fevereiro de 2015.
Ssh <http://www.openssh.com/> Acesso em Fevereiro de 2015.
Subversion <https://subversion.apache.org/> Acesso em Fevereiro de 2015.
TIRS <http://landsat.usgs.gov/mission_headlines2015.php> Acesso em Fevereiro de 2015.
Virtual Machine <http://en.wikipedia.org/wiki/Virtual_machine> Acesso em Fevereiro de 2015.
