Embed Size (px)
Citation preview
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 <[email protected]>
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
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.
