Começo, no título, com uma frase atribuída a Michelangelo, mas gostaria de fazer um contraponto com a frase de Bilderback: “o diabo está nos detalhes”. Em linha com esse contraste, este texto conta um pouco sobre um caso no desenvolvimento de nossa aplicação no monitoramento digital de pragas agrícolas, o Tarvos View.
Mas antes, creio que preciso fazer uma breve introdução sobre o que é esse produto e para que serve.
Tarvos View
O Tarvos View surgiu como uma necessidade para a visualização dos dados coletados por nossas armadilhas automatizadas e, aos poucos, tornou-se uma plataforma integrada de monitoramento de pragas, doenças e plantas daninhas, agregando dados de coletas manuais (via aplicativo), dados de armadilhas automatizadas e gestão de equipes de campo.
Com o Tarvos View é possível visualizar os dados de campo fornecido pelas armadilhas automatizadas, dados de coletas manuais via nosso aplicativo (seja de monitoramento manual ou de armadilhas não automatizadas) e dados climáticos, definir níveis de controle para as diferentes ocorrências, gerenciar equipes de monitoramento de pragas e enviar ordens de serviço para coleta de dados manuais e manutenção das armadilhas em campo. Enfim, o Tarvos View é uma plataforma completa, fácil e intuitiva de gerenciamento dos dados coletados em campo para o monitoramento de pragas.
No entanto, atingir essa usabilidade nem sempre é uma tarefa fácil. Sempre tivemos a preocupação de apresentar toda a informação coletada de forma clara e intuitiva para facilitar a vida do usuário. Porém, há situações em que a equipe de desenvolvimento se vê naquela famosa “sinuca de bico”, onde a implementação possível não é tão intuitiva como deveria ser. Nesses casos, como proceder? Como oferecer o melhor UX (user experience) sem perder a qualidade da informação?
Trajetória
Ao longo do desenvolvimento, ocorreram vários erros e acertos que nos fizeram chegar até aqui, mas um deles me chamou mais a atenção, talvez por subestimar sua complexidade de implementação ou por saber intuitivamente o resultado que eu esperava. É o caso do “mapa de calor”.
Em um determinado momento do desenvolvimento da solução, estávamos motivados com tudo que já havíamos feito e com todo potencial que a solução estava tomando. Pega dados daqui, joga para lá, incorpora a metodologia correta, calcula índices de infestação e, enfim, apresenta os dados para o usuário. Mas como?
A resposta foi simples, clara e dada quase em uníssono por toda a equipe: joga isso em um “mapa de calor” em cima da área monitorada, assim o usuário consegue ver os pontos onde a infestação é maior na cor vermelha e os pontos de menor infestação na cor verde. Simples!
É aqui que começa toda a odisséia!
Talvez por minha formação acadêmica, sempre foi uma preocupação grande da minha parte a precisão dos dados apresentados, mas também estava preocupado com a forma, beleza, intuitividade e todas essas coisas que uma plataforma digital precisa ter, e o “mapa de calor” parecia ser a solução ideal para todos os nossos problemas.
Empolgados com a solução proposta, partimos para o desenvolvimento e, já de cara, encontramos nosso primeiro obstáculo: todos os índices de infestação, em todas as metodologias de monitoramento, eram dados para uma área de monitoramento (o talhão). Dessa forma, o desafio agora era transformar uma informação que representa uma área em uma informação relativa a um ponto. Mas como?
Após pensar um pouco e depois de muitas xícaras de café, conseguimos chegar em uma solução interessante: bastaria ver qual a contribuição percentual do ponto na infestação do talhão. Vou deixar os detalhes e cálculos chatos para uma outra ocasião, mas a ideia é basicamente correlacionar estatisticamente um ponto com a infestação do talhão todo.
Maravilha! Essa até que foi fácil, agora era só jogar isso sobre o mapa e pronto. Mas como?
A primeira coisa que pensamos foi em utilizar alguma biblioteca pronta que gerasse o “mapa de calor” com base nos pontos e valores que fossem passados, mas, depois de muito procurar, não encontramos nenhuma que fornecesse o que a gente esperava da forma correta. Havia alguns detalhes especiais: seria preciso considerar a infestação presente no ponto, a significância daquele ponto, definir o raio de precisão daquela informação ao redor do ponto e como esse valor se mesclaria com o ponto vizinho quando houvesse interferência entre as áreas.
Você, leitor atento, deve ter percebido que até o momento eu utilizei “mapa de calor” entre aspas. Explico, agora, o motivo. Ao longo da pesquisa em busca de uma biblioteca de mapa de calor, vimos que o que queríamos apresentar não era exatamente um mapa de calor, apesar de todo mundo usar esse termo. Na realidade, o mapa de calor apresenta alguns inconvenientes para a aplicação em questão – por exemplo, não há correlação com a área espacial e a intersecção das áreas de interesse se dá pela soma das intensidades.
Parece um pouco abstrato, mas é fácil de entender. Imagine uma área com dois pontos de monitoramento, cujo valor informado foi de uma infestação média. Espera-se que qualquer ponto entre eles não apresente valor maior que o apresentado em cada um deles, no entanto, no mapa de calor, essas intensidades se somam e uma área com intensidade média poderia apresentar regiões vermelhas (intensidade alta). Isso faz muito sentido se você está analisando a quantidade de nuvens em um radar meteorológico ou coisa assim, mas no nosso caso essa soma de intensidades seria uma informação incorreta para o usuário.
E agora?
Mas qual seria o mapa correto? Qual é o mapa que é capaz de apresentar em uma área as intensidades dos pontos de coleta? Certamente essa não é uma necessidade nova e deve existir.
De fato, já existe. O nome desse tipo de mapa é mapa coroplético. De acordo com a Wikipedia, o mapa coroplético é “um tipo de mapa temático que representa normalmente uma superfície estatística por meio de áreas simbolizadas com cores, sombreamentos ou padrões, de acordo com uma escala que representa a proporcionalidade da variável estatística em causa”.
De volta à saga pela busca das bibliotecas, novamente não encontramos uma que atendesse ao padrão estético que esperávamos da ferramenta. É aí que entra o Luiz. O Luiz é nosso pesquisador de machine learning, uma pessoa super competente e que adora desafios. Bastou explicar o problema que estávamos enfrentando que ele prontamente se dispôs a ajudar: “Bora fazer uma biblioteca que faça do jeito que a gente quer!”
E foi isso que a gente fez. Depois de um tempo de programação, vários ajustes e adaptações, o Luiz nos entregou uma biblioteca linda, que faz tudo que a gente precisa: define pontos georreferenciados, apresenta de forma visual as intensidades no mapa, permite definir o raio de relevância da amostra, a interação das cores entre os pontos e muitas outras coisas que vão além do que precisávamos. Essa biblioteca hoje é disponibilizada pelo Luiz para quem quiser usar, de forma gratuita.
Depois de toda essa jornada, vocês não imaginam minha alegria ao responder à pergunta de um cliente sobre o Tarvos View: “Posso confiar nessas cores?”
Eu poderia passar horas falando de cada detalhe e porque nosso “mapa de calor” é uma solução robusta, bonita e que mostra a informação da forma correta, mas me contentei em estufar o peito e dizer: “Pode confiar!”
