Experimento do ShadeMap que calcula até sombras de árvores com LiDAR

• O ShadeMap vinha calculando sombras com dados de elevação baseados em radar, fáceis de obter no mundo todo, mas em áreas com muitas árvores a previsão de luz solar direta podia ficar bastante imprecisa
• O LiDAR consegue refletir com mais precisão não só o solo, mas também a altura de objetos como árvores e edifícios, possibilitando simulações de sombras da vegetação por estação e horário
• Graças ao conjunto de dados LiDAR público do estado de Washington, foi possível experimentar renderizações incluindo sombras de árvores em regiões reais, como a área metropolitana de Seattle
• A aplicação em um serviço real traz trabalhos de conversão de GeoTIFFs na casa dos 100 GB para tiles de imagem para navegador, além de limitações de memória e problemas de armazenamento
• Até a conversão da área metropolitana de Seattle, após 12 horas, estava apenas pela metade, e os tiles já passavam de 15 GB; por causa do custo de disponibilização pública, a oferta ficou limitada a uma pequena demo

---

Por que o ShadeMap não tinha sombras de árvores

• O ShadeMap simula sombras usando dados de elevação, e os conjuntos de dados de elevação fáceis de obter globalmente são dados baseados em radar, como SRTM
• O radar funciona também à noite e consegue atravessar nuvens, permitindo que satélites coletem dados do espaço 24 horas por dia
• Em uma comparação de renderização de Bainbridge Island em 9 de julho às 7h09, os dados baseados em radar não refletiam a vegetação de forma suficiente, deixando de fora uma parte considerável das sombras
  • Um usuário do HN apontou que a explicação inicial de que o radar refletiria apenas no solo estava incorreta, já que o radar também reflete em superfícies como vegetação; depois, uma correção foi adicionada
  • Como o conjunto de dados de radar SRTM é citado como fonte de dados de elevação do terreno, essa suposição acabou surgindo
• Por outro lado, o LiDAR é mais preciso, mas precisa ser coletado por aviões ou drones e não consegue atravessar neblina e nuvens
• Como a coleta exige muito tempo e dinheiro, a estrutura acaba exigindo que cada governo local arque com os custos do levantamento

O peso de transformar dados LiDAR em tiles para navegador

• O estado de Washington oferece um conjunto de dados LiDAR que cobre uma área ampla; usando-o, é possível melhorar a simulação de sombras de árvores do ShadeMap
• Os dados originais estão no formato GeoTIFF, voltado a softwares GIS tradicionais, bem distante de JPG ou PNG, que são mais adequados para carregamento rápido no navegador
• O trabalho de conversão consiste em recortar arquivos GeoTIFF de centenas de GB, com valores de ponto flutuante em imperial feet, em pequenos tiles de imagem, e codificar valores em metric meters nos pixels vermelho, verde e azul
• Durante o processo, foi comprado um disco rígido de 1 TB e foram feitas perguntas ao ChatGPT sobre o método de conversão
• Com 16 GB de RAM, era difícil carregar grandes arquivos de dados de uma só vez, então foi necessário reescrever o código de conversão para processar pequenas áreas em vez do mapa inteiro
• Mesmo convertendo apenas a área metropolitana de Seattle, após 12 horas só cerca de metade do trabalho havia sido concluída, e os tiles gerados já passavam de 15 GB e continuavam aumentando
• O resultado é impressionante, mas o custo de hospedar publicamente os dados pesa; por isso, no momento apenas uma pequena área é oferecida como demo
• Depois da atualização, o shademap.app passou a poder oferecer dados LiDAR em blocos de 1 quilômetro quadrado para grandes partes da Terra

[GN⁺]

Comentários do Hacker News

• A demo é incrivelmente legal e rápida. No momento estou criando um grande repositório/plataforma para análise de mapas históricos e fotos aéreas (https://pastmaps.com - ainda está bem no começo, então peguem leve), e tenho trabalhado bastante com pipelines de tiling e GeoTIFF
  De forma parecida, tive problemas ao usar arquivos GeoTIFF brutos como fonte, e consegui contornar a necessidade de tiling criando um hook de tiling customizado dentro do MapLibre com requisições HTTP de intervalo em arquivos estáticos hospedados no S3. Isso empurra o processamento para o cliente, mas ainda funcionou de forma bem rápida até em dispositivos móveis antigos
  Se houver interesse em suporte a fontes GeoTIFF no MapLibre, posso compartilhar o código-base ou parte desse trabalho como open source. Achei que eu fosse o único maluco na internet mexendo com isso :D

  • Ah, eu não tinha pensado em calcular offsets de bytes na hora. Até o ChatGPT aparecer, era difícil entender as ferramentas e opções de geração de tiles, e também não havia muito material online, então no geral acho melhor compartilhar até demais do que de menos
    No meu caso, o GeoTIFF de LiDAR usa pés imperiais e precisão de ponto flutuante de 32 bits. Se você pegar a faixa de altitude do nível do mar até o Everest em metros (8848) e armazenar isso em int16, dá para obter precisão de 0,2 m. Isso é suficiente para o ShadeMap, então converter float32 para int16 teoricamente reduziria pela metade o armazenamento em nuvem, e talvez até mais levando em conta a compressão PNG
  • Se você “contornou a necessidade de tiling com requisições HTTP de intervalo em arquivos estáticos hospedados no S3”, fico curioso se você já olhou o formato Cloud Optimized GeoTIFF
    https://www.cogeo.org/
    O OpenLayers suporta: https://openlayers.org/en/latest/examples/cog.html
    Pelo que sei, MapLibre e Leaflet não têm suporte nativo
  • Vale a pena ver também https://geoblaze-gsoc.vercel.app e as bibliotecas em que ele se baseia. Elas também usam requisições de intervalo para GeoTIFF
    Tenho muito interesse nessa área e estou até pensando em apoiar financeiramente alguns projetos. Já mandei um e-mail para o Ted, mas gostaria de conversar com qualquer pessoa que esteja fazendo esse tipo de trabalho. Meu e-mail está no perfil
    Felizmente é um nicho pequeno o bastante para eu não me preocupar com a caixa de entrada explodindo
  • Agora você não é mais “a pessoa mais excêntrica”. Mesmo assim, vocês dois continuam sendo únicos. Acho que pode dar certo se compartilharem, trocarem ideias e se apoiarem
    Preciso aprender mais sobre onde exatamente estão os problemas no formato GeoTIFF. Talvez ajudasse compartilhar uma infraestrutura de pipeline de transformação puro entre os dois projetos
    Se já existem duas pessoas, talvez haja mais gente batendo na mesma parede
  • Eu também acho isso muito legal. Isso me lembra quando refatorei o tratamento central de eventos do Leaflet e o código de renderização SVG há 8 anos. É bom saber que minhas contribuições open source ajudaram um pouco a viabilizar coisas legais assim

• A explicação de que “o radar deixa claramente de captar 90% das sombras geradas porque não inclui vegetação. O radar reflete apenas no solo, então objetos como árvores e prédios não aparecem” não parece correta
  Em certas bandas, o radar consegue enxergar através da folhagem, o chamado FOPEN. Não sei bem sobre radar enxergar através de prédios nas distâncias e velocidades de cobertura necessárias para mapeamento topográfico
  A Shuttle Radar Topography Mission mencionada no texto provavelmente usou radar em banda C ou banda X, e ambas deveriam produzir reflexos em vegetação e edifícios
  Sem investigar mais a fundo, os motivos para os dados de radar não mostrarem sombras de vegetação e edifícios podem ser: 1) a resolução dos dados de radar era baixa demais (dezenas de metros ou mais), 2) isso foi removido no pós-processamento ao combinar passagens de radar com várias geometrias, ou 3) o baixo ângulo de incidência do radar fez com que quase não houvesse sombras desde o início

  • Pela FAQ do SRTM, a lógica do texto está invertida
    Sobre se o radar amostrou o topo das árvores ou o solo, a FAQ explica que ele não conseguiu penetrar copas vegetais densas. Talvez tenha entrado um pouco na copa, mas em geral seguiu perto do topo dela
    A questão era se o sinal de radar refletia no topo das árvores, no terreno ou numa combinação dos dois. Geodesistas se interessam pelo terreno, e pesquisadores florestais se interessam pela altura da copa
    Como o comprimento de onda usado, 5,6 cm, não penetra bem a vegetação, em áreas de vegetação moderada a densa ele mapeou próximo ao topo da copa. Estudos comparando com altimetria a laser mostraram alguma penetração, mas não até o solo. Quando a vegetação era esparsa ou sem folhas, podia haver reflexão do terreno. O Vegetation Canopy Lidar, planejado como parte do Earth Observing System, poderia fornecer essa capacidade e permitir comparações interessantes entre conjuntos de dados
    https://www2.jpl.nasa.gov/srtm/faq.html
  • Boa complementação. Pelo que entendo, os dados do SRTM não incluíam edifícios nem vegetação. Talvez tenham filtrado tudo, exceto os menores valores de altitude. Mas isso não é uma característica do “radar” em geral
  • O SRTMv3 cobre latitudes de ±60° a 30 m/pixel. O lançamento inicial era de 90 m/pixel, e também houve versões com 30 m nos EUA e 90 m no resto do mundo
    Sombras de montanha são um problema real. Algumas versões têm áreas vazias, especialmente perto do Himalaia, onde não houve retorno de radar. Se tiver interesse, há vários artigos sobre preenchimento de áreas vazias nos dados do SRTM

• Se o GeoTIFF for pré-processado e já existir um pipeline que forneça elevação do terreno ao usuário, talvez dê para codificar nos tiles apenas a diferença entre LiDAR e radar e sobrepor só os dados das árvores aos dados de terreno existentes. O objeto a codificar e a precisão necessária talvez caibam em algo como 4 bits, e como haveria muitos 0, isso provavelmente sumiria com compressão. É mais uma ideia de brainstorming

  • É uma boa ideia. Há duas formas amplamente usadas de codificar dados de elevação em tiles RGB. Nenhuma das duas é ideal em termos de tamanho, porque ambas precisam acomodar até elevações negativas para mapeamento do relevo submarino
    height = -10000 + ((R * 256 * 256 + G * 256 + B) * 0.1) [mapbox/maptiler]
    height = (R * 256 + G + B / 256) - 32768 [mapzen terrarium]
    Se só for necessária a elevação acima do nível do mar (0~8848 m), dá para armazenar os dados em 2 bytes mantendo precisão de 0,13 m. A precisão do Mapbox é de 0,1 m
    height = (R * 256 + B) / (256 * 256) * 8848 [shademap]
    Pretendo usar essa codificação. Já testei e ela economiza espaço. Não sei dizer quanto ao tempo de processamento
    A melhor codificação seria colocar no cabeçalho a menor elevação de todo o tile e armazenar apenas o valor diferencial entre a menor elevação do tile e a elevação de cada pixel. É a mais eficiente em espaço, mas exige carregar em memória os dados do tile inteiro para encontrar a menor elevação e é menos eficiente do que codificar em streaming, pixel por pixel
  • Eu realmente queria aprender mais sobre essa área. Estou procurando no que focar em seguida, e os termos mencionados aqui coincidem exatamente com o tipo de conhecimento a que quero chegar
    Seria ótimo saber o que estudar para ficar bom em ciência de dados topográficos

• Gosto do Shademaps. Queria que meu produto que usa isso tivesse tido mais sucesso, mas o Ted e o Shademaps são muito legais. Adicionar árvores é extremamente prático. Muitas das áreas que usam essa ferramenta são urbanas, mas quando não são, os dados de árvores quase sempre importam mais do que edifícios ou elevação. Ontario é bem plano, e 99% dos meus usuários estão lá

  • Ainda estou apanhando um pouco na parte de negócios e marketing, mas a ideia em si parece ser popular, e o trabalho é divertido e recompensador

• Parece uma pergunta de entrevista para empresa de GIS: “Se você tivesse dados de radar e LiDAR e quisesse mesclá-los em um dispositivo com memória limitada, como faria?”

  • Em certo sentido, os problemas tratados aqui foram exatamente o tipo de coisa para a qual minha formação em ciência da computação me preparou. Antes eu fazia desenvolvimento web, e quase nunca precisava me preocupar se uma página caberia na memória, nem usar mais do que uma pequena fração dos ciclos que o processador podia oferecer

• O serviço francês de mapas começou a fazer captura LiDAR em HD de toda a França, e parte disso já está disponível: https://geoservices.ign.fr/lidarhd fica mais abaixo na página
  Fiquei curioso se há planos de incluir esses dados no app algum dia

  • Com certeza. Obrigado pelo link
    No momento, o principal obstáculo é que minha noiva está de férias de verão (ela é professora), então estamos saindo bastante, e também é difícil encontrar datasets de LiDAR online
    Acho que os dados de Washington já estavam disponíveis há bastante tempo, mas eu nem sabia da existência deles até algumas semanas atrás
    Espero fazer um ASK HN sobre datasets de LiDAR algum dia e conseguir fazer crowdsourcing do máximo de dados possível

• Projeto incrível
  Que tal hospedar os dados em um bucket S3 com Requestor Pays ativado? Aí você só precisaria arcar com o custo de armazenamento
  O acesso anônimo deixaria de ser possível (assim como em compartilhamentos do Dropbox), mas os custos cairiam bastante
  https://docs.aws.amazon.com/AmazonS3/latest/userguide/Reques...
  Como é somente leitura, talvez nem precise de um frontend SQL, e há várias maneiras de fazer o SQLite acessar um banco de dados em um bucket S3. Ex.: https://github.com/michalc/sqlite-s3-query

• O demo é muito legal, mas a maior parte da saída tem pouco valor. Isso porque as sombras estão sendo calculadas no topo da copa das árvores, e não no solo. Por isso parece que entra luz do sol no amanhecer mesmo em florestas densas
  Ainda assim, pode ser bem útil para vários casos, como bordas de floresta ou vegetação urbana. Nesses usos, os tiles do mapa poderiam ser muito menores, e talvez desse para buscar e converter os dados de LiDAR sob demanda

• Será que não dá para converter para um banco SQLite e servir isso como um arquivo estático com custo muito menor?
  https://news.ycombinator.com/item?id=27016630
  O verdadeiro truque mágico está nas range requests do HTTP, mas essa parte já está “resolvida”

  • Esse foi essencialmente o caminho que o Mapbox seguiu. O Mapbox chegou a criar o formato de arquivo mbtiles, que é praticamente um banco sqlite, justamente para esse tipo de consulta no servidor de tiles
    Hoje em dia isso é quase o “estado padrão” da indústria, mas ainda há desvantagens para desenvolvedores pequenos, isto é, gente como eu
    Primeiro, é preciso operar um servidor de tiles separado, que recebe requisições de tile e internamente as converte em consultas SQL ou requisições mbtile. Não gosto muito de aumentar a quantidade de peças móveis
    Segundo, é preciso processar todos os GeoTIFFs, que já passam de 10 TB e continuam crescendo, para mbtiles, o que custa caro em computação e leva bastante tempo na prática
    Terceiro, os mbtiles resultantes ficam, na melhor das hipóteses, com tamanho parecido com o dos GeoTIFFs originais, e em muitos casos muito maiores. Você ganha requisições mais rápidas, mas paga mais em hospedagem e transferência. Se tiver interesse, há um texto que explica muito bem a otimização de compressão de GeoTIFF: https://blog.cleverelephant.ca/2015/02/geotiff-compression-f...
    O Ted talvez tenha suas próprias ideias, mas essa é mais ou menos a conclusão a que cheguei depois de mergulhar nessa área nos últimos meses

• Bom
  Falando de algo um pouco relacionado e possivelmente entediante, da perspectiva de alguém das antigas que trabalhou com tecnologia geoespacial: desde os anos 2000, governos locais passaram a contratar levantamentos aéreos LiDAR por zonas ou subzonas e, mais adiante, surgiu também uma tendência de divulgar ao público os dados digitais resultantes
  Há mais de dez anos, técnicos do setor privado já recebiam em massa conjuntos de dados LiDAR de cidades inteiras e os usavam rotineiramente em análises de pequena escala, mapas e plantas
  As políticas de compartilhamento de dados dos governos locais variavam muito de região para região, e provavelmente ainda variam, mas às vezes os dados LiDAR eram entregues em várias camadas, como “terreno de superfície”, “edificações” e “copa das árvores”. Isso vinha dos resultados inicialmente capturados e calculados pelo operador de LiDAR em diferentes frequências
  Os técnicos de escritório encontravam e executavam procedimentos para ajustar os dados conforme a solicitação. Em geral, produziam entregas de pequena escala com software comercial e rotinas, e serviços de análise de insolação/sombreamento e análise de visibilidade muito parecidos com o que está sendo tratado aqui já eram encomendados naquela época
  Os primeiros movimentos para incluir LiDAR da copa das árvores em trabalhos na escala de pequenos bairros começaram a se infiltrar no setor privado, mas ainda era algo novo e raro. É animador ver esse tipo de trabalho sendo feito hoje em grande escala
  Tenho pouca experiência jurássica com a oferta de grandes volumes de dados online, mas lidar com conjuntos maiores de dados geoespaciais brutos sempre foi um desafio central dessa área. No fim, todo o trabalho se resume a traduzir ou abstrair essas fontes em saídas eficientes, fáceis de entender e focadas no objetivo
  Nesse sentido, o que realmente dá impulso para viabilizar esse tipo de inovação em grande escala é o lado da ciência da computação, mais especificamente o de ciência de dados