problem capturing climate data

[claudia-codeco]

Problem capturing data from stations SBGL and SBJR . I checked the wu site, and there is data in the source. At least 15 days already.

[flavioamieiro]

Por algum motivo, o processo de captura está sendo bloqueado. Quando eu tento executar o processo para só uma estação, recebo o seguinte aviso:

400
Bad Request - Blocked at Akamai

O mesmo acontece se usarmos o navegador para acessar a url que o crawler acessa: http://www.wunderground.com/history/airport/SBGL/2017/11/20/DailyHistory.html?format=1 . Se tirarmos o parâmetro de formatação o site funciona.

Ainda não consegui encontrar no site do weather underground documentação sobre a api, para ver se existe um parâmetro que permita usar a formatação que o crawler conhece. Se não existir um, talvez a solução seja fazer scraping da página mesmo.

Outro problema é que o crawler falha silenciosamente quando a captura não traz dado nenhum. Ele, no estado atual, salva um registro com o nome da estação e a data para a qual a captura deveria ter sido feita, mas com todos os outros valores em branco.

Isso está acontecendo para todas as estações desde o dia 08/09/2017, mas para algumas outras estações existem registros vazios assim pra várias datas anteriores.

Vou mudar o comportamento do crawler para não salvar mais esses registros vazios mas, enquanto o problema original na captura não for resolvido, o único efeito vai ser continuar tentando novamente as capturas para as datas anteriores.

[fccoelho]

@flavioamieiro nós não usamos a API, pois seria mais caro. Usamos uma url que retorna(va) um CSV que então parseamos. Pelo que vi no site agora, não tem nenum link para baixar o CSV diretamente.

Mas eles tem plano gratuito da API que permite até 500 chamadas por dia : https://www.wunderground.com/weather/api/d/pricing.html

Você poderia verificar quantas estações baixamos por dia? de repende nos atende. Mas teriamos que mudar o código de captura para começar a usar a API.

2017-11-20 10:09 GMT-02:00 Flávio Amieiro notifications@github.com:

Por algum motivo, o processo de captura está sendo bloqueado. Quando eu tento executar o processo para só uma estação, recebo o seguinte aviso:

400 Bad Request - Blocked at Akamai

O mesmo acontece se usarmos o navegador para acessar a url que o crawler acessa: http://www.wunderground.com/history/airport/SBGL/2017/11/ 20/DailyHistory.html?format=1 Se tirarmos o parâmetro de formatação o site funciona.

Ainda não consegui encontrar no site do weather underground documentação sobre a api, para ver se existe um parâmetro que permita usar a formatação que o crawler conhece. Se não existir um, talvez a solução seja fazer scraping da página mesmo.

Outro problema é que o crawler falha silenciosamente quando a captura não traz dado nenhum. Ele, no estado atual, salva um registro com o nome da estação e a data para a qual a captura deveria ter sido feita, mas com todos os outros valores em branco.

Isso está acontecendo para todas as estações desde o dia 08/09/2017, mas para algumas outras estações existem registros vazios assim pra várias datas anteriores.

Vou mudar o comportamento do crawler para não salvar mais esses registros vazios mas, enquanto o problema original na captura não for resolvido, o único efeito vai ser continuar tentando novamente as capturas para as datas anteriores.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/AlertaDengue/AlertaDengueCaptura/issues/28#issuecomment-345677674, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIjW7LIlKMLzbzllgpJkbr3CihPH66Bks5s4WvggaJpZM4QjFw7 .

-- Flávio Codeço Coelho

+55(21) 3799-5551 Professor Escola de Matemática Aplicada Fundação Getulio Vargas Praia de Botafogo, 190 sala 312 Rio de Janeiro - RJ 22250-900 Brasil

[flavioamieiro]

@fccoelho entendi a questão. Nós temos 177 estações cadastradas no banco. Teoricamente, isso seria o número de requisições pra API se a usarmos um endpoint da API parecido com o CSV que existia antes. Pra pegarmos o histórico (e preencher eventuais lacunas) precisaríamos de mais algumas requisições por dia às vezes. Uma coisa que teríamos que fazer é criar intervalos entre as requisições. O plano gratuito permite 500 chamadas por dia, mas só 10 por minuto. Isso é uma questão.

Eu olhei a documentação da API, e pelo que vi ela é mais centrada em localização. Os exemplos usam uma cidade e retornam os dados. Pelo que vi, isso inclui os dados de todas as estações próximas. Isso talvez facilite nossa vida por que não precisaríamos fazer uma requisição para cada estação. Talvez baste uma pra cada cidade, e os dados de todas as estações já viriam nessa resposta, mas preciso ler a documentação melhor pra ter certeza.

Uma questão importante é que a página de preços diz que o plano gratuito não inclui histórico. Isso pode ser um problema não só por que precisamos agora do histórico (temos um buraco nos dados desde Setembro) e por que pode ser que eventualmente a captura falhe para um dia específico e precisaremos consultar o histórico. Eu acho que o dado que queremos de fato é o histórico. Não parece que queremos extrair essa informação das "condições atuais" nem da previsão (mas posso estar enganado).

[ogcruz]

Basicamente usamos a temperatura dos aeroportos né? e se usássemos novamente a API da REDEMET que foi reformulada e agora permite o acesso e busca de dados até 30 dias?

https://www.redemet.aer.mil.br/?i=facilidades&p=api-redemet

abraços

O

Em 20 de novembro de 2017 11:03, Flávio Codeço Coelho < notifications@github.com> escreveu:

@flavioamieiro nós não usamos a API, pois seria mais caro. Usamos uma url que retorna(va) um CSV que então parseamos. Pelo que vi no site agora, não tem nenum link para baixar o CSV diretamente.

Mas eles tem plano gratuito da API que permite até 500 chamadas por dia : https://www.wunderground.com/weather/api/d/pricing.html

Você poderia verificar quantas estações baixamos por dia? de repende nos atende. Mas teriamos que mudar o código de captura para começar a usar a API.

2017-11-20 10:09 GMT-02:00 Flávio Amieiro notifications@github.com:

Por algum motivo, o processo de captura está sendo bloqueado. Quando eu tento executar o processo para só uma estação, recebo o seguinte aviso:

400 Bad Request - Blocked at Akamai

O mesmo acontece se usarmos o navegador para acessar a url que o crawler acessa: http://www.wunderground.com/history/airport/SBGL/2017/11/ 20/DailyHistory.html?format=1 Se tirarmos o parâmetro de formatação o site funciona.

Ainda não consegui encontrar no site do weather underground documentação sobre a api, para ver se existe um parâmetro que permita usar a formatação que o crawler conhece. Se não existir um, talvez a solução seja fazer scraping da página mesmo.

Outro problema é que o crawler falha silenciosamente quando a captura não traz dado nenhum. Ele, no estado atual, salva um registro com o nome da estação e a data para a qual a captura deveria ter sido feita, mas com todos os outros valores em branco.

Isso está acontecendo para todas as estações desde o dia 08/09/2017, mas para algumas outras estações existem registros vazios assim pra várias datas anteriores.

Vou mudar o comportamento do crawler para não salvar mais esses registros vazios mas, enquanto o problema original na captura não for resolvido, o único efeito vai ser continuar tentando novamente as capturas para as datas anteriores.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/AlertaDengue/AlertaDengueCaptura/issues/28# issuecomment-345677674, or mute the thread https://github.com/notifications/unsubscribe-auth/ AAIjW7LIlKMLzbzllgpJkbr3CihPH66Bks5s4WvggaJpZM4QjFw7 .

-- Flávio Codeço Coelho

+55(21) 3799-5551 <(21)%203799-5551> Professor Escola de Matemática Aplicada Fundação Getulio Vargas Praia de Botafogo, 190 sala 312 https://maps.google.com/?q=Praia+de+Botafogo,+190+sala+312+%0D+Rio+de+Janeiro+-+RJ&entry=gmail&source=g Rio de Janeiro - RJ 22250-900 Brasil

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/AlertaDengue/AlertaDengueCaptura/issues/28#issuecomment-345688885, or mute the thread https://github.com/notifications/unsubscribe-auth/AHQR5SyfCpG2BJPvn9sdjxh8U_lQCD9Xks5s4XgXgaJpZM4QjFw7 .

[fccoelho]

Opa, esta é uma excelente ideia. Estou viajando hoje. @flavioamieiro você pode dar uma olhada nessa API?

Em 20 de nov de 2017 17:24, "ogcruz" notifications@github.com escreveu:

Basicamente usamos a temperatura dos aeroportos né? e se usássemos novamente a API da REDEMET que foi reformulada e agora permite o acesso e busca de dados até 30 dias?

https://www.redemet.aer.mil.br/?i=facilidades&p=api-redemet

abraços

O

Em 20 de novembro de 2017 11:03, Flávio Codeço Coelho < notifications@github.com> escreveu:

@flavioamieiro nós não usamos a API, pois seria mais caro. Usamos uma url que retorna(va) um CSV que então parseamos. Pelo que vi no site agora, não tem nenum link para baixar o CSV diretamente.

Mas eles tem plano gratuito da API que permite até 500 chamadas por dia : https://www.wunderground.com/weather/api/d/pricing.html

Você poderia verificar quantas estações baixamos por dia? de repende nos atende. Mas teriamos que mudar o código de captura para começar a usar a API.

2017-11-20 10:09 GMT-02:00 Flávio Amieiro notifications@github.com:

Por algum motivo, o processo de captura está sendo bloqueado. Quando eu tento executar o processo para só uma estação, recebo o seguinte aviso:

400 Bad Request - Blocked at Akamai

O mesmo acontece se usarmos o navegador para acessar a url que o crawler acessa: http://www.wunderground.com/history/airport/SBGL/2017/11/ 20/DailyHistory.html?format=1 Se tirarmos o parâmetro de formatação o site funciona.

Ainda não consegui encontrar no site do weather underground documentação sobre a api, para ver se existe um parâmetro que permita usar a formatação que o crawler conhece. Se não existir um, talvez a solução seja fazer scraping da página mesmo.

Outro problema é que o crawler falha silenciosamente quando a captura não traz dado nenhum. Ele, no estado atual, salva um registro com o nome da estação e a data para a qual a captura deveria ter sido feita, mas com todos os outros valores em branco.

Isso está acontecendo para todas as estações desde o dia 08/09/2017, mas para algumas outras estações existem registros vazios assim pra várias datas anteriores.

Vou mudar o comportamento do crawler para não salvar mais esses registros vazios mas, enquanto o problema original na captura não for resolvido, o único efeito vai ser continuar tentando novamente as capturas para as datas anteriores.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/AlertaDengue/AlertaDengueCaptura/issues/28# issuecomment-345677674, or mute the thread https://github.com/notifications/unsubscribe-auth/ AAIjW7LIlKMLzbzllgpJkbr3CihPH66Bks5s4WvggaJpZM4QjFw7 .

-- Flávio Codeço Coelho

+55(21) 3799-5551 <(21)%203799-5551> <(21)%203799-5551> Professor Escola de Matemática Aplicada Fundação Getulio Vargas Praia de Botafogo, 190 sala 312 https://maps.google.com/?q=Praia+de+Botafogo,+190+sala+312&entry=gmail&source=g https://maps.google.com/?q=Praia+de+Botafogo,+190+sala+ 312+%0D+Rio+de+Janeiro+-+RJ&entry=gmail&source=g Rio de Janeiro - RJ 22250-900 Brasil

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/AlertaDengue/AlertaDengueCaptura/issues/28# issuecomment-345688885, or mute the thread https://github.com/notifications/unsubscribe-auth/ AHQR5SyfCpG2BJPvn9sdjxh8U_lQCD9Xks5s4XgXgaJpZM4QjFw7 .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AlertaDengue/AlertaDengueCaptura/issues/28#issuecomment-345801126, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIjW4Gzt2qfB3gJPwhsIPD5Q44WBSVPks5s4dHjgaJpZM4QjFw7 .

[flavioamieiro]

Eu dei uma olhada na API. O acesso a ela parece ser bem simples: um GET com o curl já é o suficiente.

Eu não conheço o código que usa esses dados (mesmo com esse código aqui que captura os dados eu só entrei em contato para corrigir bugs bem pontuais), então não tenho muita certeza de todas as informações que precisamos.

O que fiz foi olhar a tabela no banco para ver o que guardamos atualmente. Encontrei os seguintes campos:

temp_min, temp_max, temp_med, umid_min, umid_med, umid_max, pressao_min, pressao_med, pressao_max

Além disso, encontrei uma página que descreve os dados METAR.

A primeira diferença óbvia entre o que capturamos do WU e o que está disponível na API da redemet é que no primeiro tínhamos um resumo do dia enquanto na redemet, pelo que pude entender, recebemos os dados por hora. Para extrair os dados de mínima, máxima e média de temperatura, por exemplo, teríamos que buscar todos os dados do dia e calcular esses valores. Isso não parece ser um problema muito grande, por que a API permite buscar todos os dados de um período de 24h em uma só requisição.

Acho que a única informação que existe no nosso banco e não está disponível diretamente na API é a umidade, mas talvez seja possível calcular esse valor a partir da temperatura e do ponto de orvalho (que também está nos dados).

Resumindo: acho que podemos usar sim essa API, mas vamos precisar mudar o scraper para ler esse novo formato e fazer as agregações dos valores do nosso lado. Eu só não sei se isso implica em alguma questão metodológica (um exemplo: podemos pegar a temperatura média só fazendo uma média aritmética dos valores observados de hora em hora?).

[claudia-codeco]

Dei uma pesquisada http://www.sbagro.org.br/anais_congresso_2009/cba2009/408.pdf aqui e não é muito padronizada a forma de calcular a média da temperatura, utiliza-se 2, 3, 4 valores ou todos. Como as estações automáticas usam todos, sugiro usarmos todos mesmo, uma vez que as contas mais simples a gente recupera da informação de tmax e tmin.

A umidade dá mesmo para calcular a partir dos outros dados, mas teremos que criar uma nova variavel para o ponto de orvalho.

2017-11-21 11:28 GMT-02:00 Flávio Amieiro notifications@github.com:

Eu dei uma olhada na API. O acesso a ela parece ser bem simples: um GET com o curl já é o suficiente.

Eu não conheço o código que usa esses dados (mesmo com esse código aqui que captura os dados eu só entrei em contato para corrigir bugs bem pontuais), então não tenho muita certeza de todas as informações que precisamos.

O que fiz foi olhar a tabela no banco para ver o que guardamos atualmente. Encontrei os seguintes campos:

temp_min, temp_max, temp_med, umid_min, umid_med, umid_max, pressao_min, pressao_med, pressao_max

Além disso, encontrei uma página que descreve os dados METAR https://www.redemet.aer.mil.br/?i=facilidades&p=decodificacao-metar.

A primeira diferença óbvia entre o que capturamos do WU e o que está disponível na API da redemet é que no primeiro tínhamos um resumo do dia enquanto na redemet, pelo que pude entender, recebemos os dados por hora. Para extrair os dados de mínima, máxima e média de temperatura, por exemplo, teríamos que buscar todos os dados do dia e calcular esses valores. Isso não parece ser um problema muito grande, por que a API permite buscar todos os dados de um período de 24h em uma só requisição.

Acho que a única informação que existe no nosso banco e não está disponível diretamente na API é a umidade, mas talvez seja possível calcular esse valor a partir da temperatura e do ponto de orvalho (que também está nos dados).

Resumindo: acho que podemos usar sim essa API, mas vamos precisar mudar o scraper para ler esse novo formato e fazer as agregações dos valores do nosso lado. Eu só não sei se isso implica em alguma questão metodológica (um exemplo: podemos pegar a temperatura média só fazendo uma média aritmética dos valores observados de hora em hora?).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AlertaDengue/AlertaDengueCaptura/issues/28#issuecomment-346026469, or mute the thread https://github.com/notifications/unsubscribe-auth/AD0dhtSDIzDl1hUG9AAskA-VGdpMo_-aks5s4tAVgaJpZM4QjFw7 .

[flavioamieiro]

Ótimo!

Vou começar então a rascunhar as mudanças no scraper e isso vai me dar uma noção melhor dos detalhes e vai deixar claro se tem alguma coisa que eu deixei de considerar por enquanto.

[ogcruz]

Eu tenho em algum lugar um script em R que criar humidade a partir do ponto de orvalho. eu fazia isso para o METAR antes de bloquearem.

Vai ser bom ter as temperaturas por horas pois ai podemos criar novos indicadores, por exemplo numa de horas entre XX e YY graus, crio que essa variável se correlaciona melhor que temp min ou máxima !

[flavioamieiro]

@ogcruz Se você puder compartilhar esse script, seria ótimo!

Sobre ter a temperatura por hora: podemos começar a guardar os dados assim, mas isso implica em mudar a estrutura do banco de dados (e por consequência todo o código que acessa esse banco). Não quero dizer que acho isso uma ideia ruim (pelo contrário).

Podemos, talvez, criar uma outra tabela com os dados mais granulares, e manter a tabela que já temos com os dados na mesma estrutura (com min/max/média por dia). Assim o código que já depende da estrutura atual pode continuar usando esses dados mas também mantemos toda a informação que recebemos da API e podemos usar onde fizer sentido.

Além disso, talvez faça sentido trocar o nome das tabelas, pra deixarem de fazer referência ao weather underground (mas isso implica em mudar isso em todo o código que acessa o banco).

O que acham @claudia-codeco @fccoelho @ogcruz ?

[ogcruz]

Acho ótimo, mas podemos ir fazendo isso em etapas!

No meu ponto de vista, não faz sentido guardar as variáveis diárias, mas sim um agregado semanal, como medidas sumarias. Mas precisamos pensar quais seriam essas variáveis agregadas. quanto meu script vou tentar achar e posto assim que achar! o da semana epidemiológica já achei, posto onde? em que projeto?

[fccoelho]

Oswaldo, pode anexar na issue corretamente.

Em 21 de nov de 2017 14:18, "ogcruz" notifications@github.com escreveu:

Acho ótimo, mas podemos ir fazendo isso em etapas!

No meu ponto de vista, não faz sentido guardar as variáveis diárias, mas sim um agregado semanal, como medidas sumarias. Mas precisamos pensar quais seriam essas variáveis agregadas. quanto meu script vou tentar achar e posto assim que achar! o da semana epidemiológica já achei, posto onde? em que projeto?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AlertaDengue/AlertaDengueCaptura/issues/28#issuecomment-346078756, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIjWy6v2JIvYg3mPrAwlBEsXqHm4fwtks5s4vfygaJpZM4QjFw7 .

[fccoelho]

@flavioamieiro, podemos planejar este refactoring em etapas pois vai afetar muitos subprojetos. No final podemos criar uma view que recrie tabela clima_wu, a partir dos dados horários, para compatibilidade.

Em 21 de nov de 2017 14:57, "Flavio Coelho" fccoelho@gmail.com escreveu:

Oswaldo, pode anexar na issue corretamente.

Em 21 de nov de 2017 14:18, "ogcruz" notifications@github.com escreveu:

Acho ótimo, mas podemos ir fazendo isso em etapas!

No meu ponto de vista, não faz sentido guardar as variáveis diárias, mas sim um agregado semanal, como medidas sumarias. Mas precisamos pensar quais seriam essas variáveis agregadas. quanto meu script vou tentar achar e posto assim que achar! o da semana epidemiológica já achei, posto onde? em que projeto?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AlertaDengue/AlertaDengueCaptura/issues/28#issuecomment-346078756, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIjWy6v2JIvYg3mPrAwlBEsXqHm4fwtks5s4vfygaJpZM4QjFw7 .

[flavioamieiro]

@ogcruz acho que, como o @fccoelho disse, pode adicionar aqui o código mesmo. Eu vou provavelmente transcrever o código pra Python pra ficar mais fácil de integrar com o processo de captura atual.

@fccoelho sobre as mudanças na tabela: minha ideia é, sem dúvidas, manter ao máximo a compatibilidade retroativa.

Minha ideia original era, no processo de captura, agregar os dados de cada dia e inserir eles na tabela que já existe (Clima_wu). Assim todo o código que já existe pode, eu acredito, continuar acessando as tabelas normalmente. A origem dos dados vai ser diferente, mas eles deveriam representar a mesma coisa.

Além disso, para guardar os dados "brutos", pretendo criar uma nova tabela onde guardaremos os dados de cada hora, não agregados.

Só depois disso tudo pronto é que eu acho que seria uma boa ideia mudar o nome da tabela original. Digo isso principalmente por que ela faz referência ao weather underground no nome e nós não vamos mais usar o WU como fonte. Mas fora isso, concordo que devemos tentar manter a funcionalidade o mais próximo possível da que já temos.

[fccoelho]

Ok @flavioamieiro.

Em 21 de nov de 2017 15:59, "Flávio Amieiro" notifications@github.com escreveu:

@ogcruz https://github.com/ogcruz acho que, como o @fccoelho https://github.com/fccoelho disse, pode adicionar aqui o código mesmo. Eu vou provavelmente transcrever o código pra Python pra ficar mais fácil de integrar com o processo de captura atual.

@fccoelho https://github.com/fccoelho sobre as mudanças na tabela: minha ideia é, sem dúvidas, manter ao máximo a compatibilidade retroativa.

Minha ideia original era, no processo de captura, agregar os dados de cada dia e inserir eles na tabela que já existe (Clima_wu). Assim todo o código que já existe pode, eu acredito, continuar acessando as tabelas normalmente. A origem dos dados vai ser diferente, mas eles deveriam representar a mesma coisa.

Além disso, para guardar os dados "brutos", pretendo criar uma nova tabela onde guardaremos os dados de cada hora, não agregados.

Só depois disso tudo pronto é que eu acho que seria uma boa ideia mudar o nome da tabela original. Digo isso principalmente por que ela faz referência ao weather underground no nome e nós não vamos mais usar o WU como fonte. Mas fora isso, acho que devemos tentar manter a funcionalidade o mais próximo possível da que já temos.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/AlertaDengue/AlertaDengueCaptura/issues/28#issuecomment-346109970, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIjWyAGe0JUVV4jbNQhfqRXYDzE4Fznks5s4w-DgaJpZM4QjFw7 .

[ogcruz]

Olá

Este é o calculo da umidade que usando T (temperatura) e P (ponto de orvalho)

existem varias maneira de calcular, mas na época li varias coisa e achei esse melhor!

umid <- function(T,P) {

100(exp((17.625P ) / (243.04+P)) / exp((17.625*T)/(243.04+T))) }

[ogcruz]

resgatei e atualizei meus scripts da redmet aqui em R. uma coisa, cada consulta é limitada a 24 horas mas se pode fazer varias consultas seguidas! ou seja, acho que o ideal seria atualiza para cada semana, tipo rodar em batch no domingo pegando a semana anterior. não vejo necessidade de armazenar os dados diários .

[flavioamieiro]

Muito obrigado @ogcruz !!

Eu tinha lido que a limitação de 24 horas é só para uma requisição. Podemos mesmo fazer várias delas. De qualquer jeito, acho que podemos manter a consulta diária, com eventuais consultas extra para preencher lacunas. Acho que assim funciona bem não só pra dar um espaço maior entre as consultas (e diminuir o risco de bloqueio) mas, principalmente, por que o código já faz isso atualmente.

Vou incluir esse cálculo no scraper!