Experimento de ShadeMap para calcular hasta las sombras de los árboles con LiDAR
(tedpiotrowski.svbtle.com)- ShadeMap ha venido calculando sombras con datos de elevación basados en radar que son fáciles de conseguir en todo el mundo, pero en zonas con muchos árboles la predicción de luz solar directa podía fallar mucho
- LiDAR permite reflejar con mayor precisión no solo el terreno, sino también la altura de objetos como árboles y edificios, haciendo posible simular sombras de vegetación según la estación y la hora del día
- Gracias al dataset de LiDAR público del estado de Washington, fue posible experimentar con renderizados que incluyen sombras de árboles en regiones reales como el área metropolitana de Seattle
- Para aplicarlo en un servicio real, surgen tareas de conversión para transformar GeoTIFF de tamaño de 100 GB en imágenes en mosaico para navegador, además de límites de memoria y problemas de almacenamiento
- Incluso la conversión del área metropolitana de Seattle solo iba por la mitad después de 12 horas y los mosaicos superaron los 15 GB, así que la publicación abierta quedó limitada a una demo pequeña por el costo
Por qué ShadeMap no tenía sombras de árboles
- ShadeMap simula sombras usando datos de elevación, y los datasets de elevación fáciles de conseguir a nivel global son datos basados en radar como SRTM
- El radar funciona incluso de noche y puede atravesar las nubes, por lo que los satélites pueden recopilar datos desde el espacio las 24 horas del día
- En una comparación de renderizados de Bainbridge Island a las 7:09 a. m. del 9 de julio, los datos basados en radar no reflejaban suficientemente la vegetación, por lo que faltaba una parte importante de las sombras
- Sobre la explicación inicial de que el radar solo se refleja en el suelo, un usuario de HN señaló que el radar también se refleja en superficies como la vegetación, y luego se añadió una corrección
- Como el dataset de radar SRTM se cita como fuente de datos de elevación del terreno, de ahí surgió esa suposición
- En cambio, LiDAR es más preciso, pero debe recopilarse con aviones o drones y no puede atravesar niebla ni nubes
- Su recolección requiere mucho tiempo y dinero, por lo que cada gobierno local debe asumir el costo del levantamiento
La carga de convertir datos LiDAR en mosaicos para navegador
- El estado de Washington ofrece un dataset de LiDAR que cubre una región amplia, y aprovecharlo puede mejorar la simulación de sombras de árboles en ShadeMap
- Los datos originales están en formato GeoTIFF, pensado para software GIS tradicional, así que están lejos de ser tan adecuados para carga rápida en navegador como JPG o PNG
- El proceso de conversión consiste en cortar archivos GeoTIFF de cientos de GB con valores de punto flotante y unidades en pies imperiales en pequeños mosaicos de imagen, y codificar valores en metros del sistema métrico en valores de píxeles rojo, verde y azul
- Durante el proceso se compró un disco duro de 1 TB y se fue avanzando consultándole a ChatGPT cómo hacer la conversión
- Con 16 GB de RAM era difícil cargar archivos de datos grandes de una sola vez, así que hubo que reescribir el código de conversión para procesar áreas pequeñas en lugar de todo el mapa
- Incluso convirtiendo solo el área metropolitana de Seattle, después de 12 horas apenas se había completado aproximadamente la mitad, y los mosaicos generados seguían creciendo después de superar los 15 GB
- El resultado es impresionante, pero el costo de alojar públicamente los datos es una carga, así que por ahora solo se ofrece una pequeña demo
- Después de la actualización, shademap.app ahora puede ofrecer datos LiDAR en bloques de 1 kilómetro cuadrado para grandes partes de la Tierra
1 comentarios
Comentarios en Hacker News
La demo es increíblemente genial y rápida. Ahora mismo estoy construyendo un gran repositorio/plataforma para analizar mapas históricos y fotografías aéreas (https://pastmaps.com - todavía está en una etapa muy temprana, así que no la juzguen demasiado duro) y he estado trabajando bastante con pipelines de teselado y GeoTIFF
Me pasó algo parecido usando archivos GeoTIFF originales como fuente, y pude evitar la necesidad de teselar creando un hook de teselado personalizado dentro de MapLibre con solicitudes HTTP de rango sobre archivos estáticos subidos a S3. Eso empuja el cálculo al cliente, pero funcionaba bastante rápido incluso en dispositivos móviles viejos
Si te interesa el soporte de fuentes GeoTIFF en MapLibre, podría compartir el código base o parte de ese trabajo como open source. Pensé que yo era el único loco en internet metido en estas cosas :D
En mi caso, los GeoTIFF LiDAR están en pies imperiales con precisión de coma flotante de 32 bits. Si tomas el rango de elevación desde el nivel del mar hasta el Everest en metros (8848) y lo guardas en int16, puedes obtener una precisión de 0.2 m. Para ShadeMap eso es suficiente, así que si conviertes float32 a int16, en teoría el almacenamiento en la nube se reduce a la mitad, y podría reducirse aún más considerando la compresión PNG
https://www.cogeo.org/
OpenLayers lo soporta: https://openlayers.org/en/latest/examples/cog.html
Según entiendo, MapLibre y Leaflet no tienen soporte integrado
Me interesa muchísimo esta área y estoy pensando incluso en apoyar financieramente algunos proyectos. Ya le envié un correo a Ted, pero me gustaría hablar con cualquiera que esté haciendo este tipo de trabajo. Mi correo está en el perfil
Por suerte es un nicho lo bastante pequeño como para no preocuparme de que explote la bandeja de entrada
Necesito aprender más sobre dónde está exactamente el problema en el formato GeoTIFF. Tal vez ayudaría compartir infraestructura de pipeline de conversión pura entre los dos proyectos
Si ya son dos, puede que haya más personas chocando contra la misma pared
La explicación de que “el radar se pierde claramente el 90% de las sombras que produce la vegetación, porque no la incluye. El radar solo rebota en el suelo, así que objetos como árboles y edificios no son visibles” no parece correcta
El radar puede ver a través del follaje en ciertas bandas, lo que se conoce como FOPEN. No sé bien si, a las distancias y velocidades de cobertura necesarias para el mapeo topográfico, el radar puede ver a través de edificios
La Shuttle Radar Topography Mission mencionada en el artículo probablemente usó radar de banda C o X, y ambos deberían producir reflejos en vegetación y edificios
Sin investigar más, las razones por las que no aparecen sombras de vegetación y edificios en los datos de radar podrían ser: 1) la resolución de los datos de radar era demasiado baja (decenas de metros o más), 2) se eliminaron durante el posprocesamiento de pasadas de radar con varias geometrías, o 3) debido al bajo ángulo de incidencia del radar, en primer lugar casi no se generaban sombras
Sobre si el radar muestreó las copas de los árboles o el suelo, la FAQ explica que no pudo penetrar un dosel vegetal denso. Puede que haya entrado un poco en el dosel, pero en general siguió la parte superior del dosel
La cuestión era si la señal de radar rebotó en las copas de los árboles, en el terreno, o en una combinación de ambos. A los geodestas les interesa el terreno, y a los investigadores forestales la altura del dosel
La longitud de onda de 5.6 cm que se usó no penetraba bien la vegetación, así que en vegetación moderada a densa se mapeó cerca de la parte superior del dosel. Estudios comparados con altímetros láser mostraron algo de penetración, pero no hasta el suelo. Cuando la vegetación era escasa o no tenía hojas, podían obtenerse reflejos del suelo. El Vegetation Canopy Lidar, planeado como parte del Earth Observing System, podría ofrecer esta capacidad y permitir comparaciones interesantes entre conjuntos de datos
https://www2.jpl.nasa.gov/srtm/faq.html
Las sombras montañosas realmente son un problema. Algunas versiones incluyen áreas vacías, sobre todo cerca del Himalaya, donde no hubo retorno del radar. Si te interesa, hay bastantes artículos sobre el relleno de vacíos en datos SRTM
Si se va a preprocesar el GeoTIFF y ya existe un pipeline que entrega elevación del terreno al usuario, quizá se podría codificar en los tiles solo la diferencia entre LiDAR y radar para superponer únicamente los datos de árboles sobre los datos de terreno existentes. El objeto a codificar y la precisión necesaria podrían caber incluso en unos 4 bits, y como habría muchos ceros, probablemente desaparecerían con compresión. Es más una idea de lluvia de ideas
height = -10000 + ((R * 256 * 256 + G * 256 + B) * 0.1)[mapbox/maptiler]height = (R * 256 + G + B / 256) - 32768[mapzen terrarium]Si solo se necesita elevación sobre el nivel del mar (0~8848 m), se pueden guardar los datos en 2 bytes manteniendo una precisión de 0.13 m. La precisión de Mapbox es de 0.1 m
height = (R * 256 + B) / (256 * 256) * 8848[shademap]Planeo usar esta codificación. Ya la probé y ahorra espacio. No tengo claro el tiempo de procesamiento
La mejor codificación sería poner en el encabezado la elevación mínima de todo el tile y guardar solo el valor diferencial entre esa elevación mínima y la elevación de cada píxel. Es la más eficiente en espacio, pero obliga a cargar en memoria todos los datos del tile para encontrar la elevación mínima, y es menos eficiente que codificar haciendo streaming píxel por píxel
Me gustaría que me dijeran qué estudiar para volverme competente en ciencia de datos topológicos
Me gusta Shademaps. Ojalá el producto mío que usa esto hubiera tenido más éxito, pero Ted y Shademaps son geniales. Agregar árboles es muy práctico. Muchas de las zonas que usan esta herramienta sí son urbanas, pero cuando no lo son, los datos de árboles casi siempre importan más que los edificios o la elevación. Ontario es bastante plano, y el 99% de mis usuarios está ahí
Suena a pregunta de entrevista para una empresa GIS: “Si tuvieras datos de radar y LiDAR y quisieras fusionarlos en un equipo con memoria limitada, ¿cómo lo harías?”
El servicio cartográfico francés empezó la captura LiDAR HD de toda Francia, y una parte ya está disponible: https://geoservices.ign.fr/lidarhd está más abajo
Me pregunto si tienes pensado incluir estos datos en la app algún día
El principal obstáculo ahora mismo es que mi prometida está de vacaciones de verano (es maestra), así que salimos mucho, y además es difícil encontrar datasets LiDAR en línea
Creo que los datos de Washington llevaban bastante tiempo ahí, pero no supe de su existencia hasta hace unas semanas
Espero algún día publicar un ASK HN sobre datasets LiDAR y lograr hacer crowdsourcing de la mayor cantidad posible de datos
Excelente proyecto
¿Qué tal hospedar los datos en un bucket de S3 con Requestor Pays activado? Así solo tendrías que cubrir el costo de almacenamiento
Ya no se permitiría acceso anónimo (igual que con compartir por Dropbox), pero reduciría mucho los costos
https://docs.aws.amazon.com/AmazonS3/latest/userguide/Reques...
Como es de solo lectura, probablemente no haga falta un frontend SQL dedicado, y hay varias formas de hacer que SQLite acceda a una base de datos en un bucket de S3. Por ejemplo: https://github.com/michalc/sqlite-s3-query
El demo se ve muy bien, pero la mayor parte de la salida tiene poco valor. Eso se debe a que las sombras se están calculando desde la parte superior de la copa de los árboles, no desde el suelo. Por eso incluso en bosques densos parece que entra luz del sol al amanecer
Aun así, podría ser muy útil para varios casos de uso, como bordes de bosque o vegetación urbana. En esos casos, los tiles del mapa podrían ser mucho más pequeños, y quizá los datos LiDAR podrían traerse y transformarse solo cuando hicieran falta
¿No se podría convertir a una base de datos SQLite y servirlo como un archivo estático de mucho menor costo?
https://news.ycombinator.com/item?id=27016630
La magia clave está en las solicitudes de rango de HTTP, pero esa parte ya está “resuelta”
Hoy en día es una aproximación cercana al “estándar de facto” en la industria, pero para un desarrollador pequeño, o sea alguien como yo, todavía tiene desventajas
Primero, hay que operar un servidor de tiles aparte que reciba solicitudes de tiles y por dentro las convierta en consultas SQL o solicitudes mbtile. No me gusta mucho aumentar la cantidad de piezas móviles
Segundo, habría que procesar todos los GeoTIFF, que ya pasan de 10 TB y siguen creciendo, para convertirlos a mbtiles, y eso tiene un costo computacional alto y toma mucho tiempo real
Tercero, los mbtiles resultantes quedan, en el mejor de los casos, de un tamaño similar al de los GeoTIFF originales, y en el peor, mucho más grandes. Se obtienen solicitudes más rápidas, pero aumentan los costos de hosting y transferencia. Si te interesa, hay un buen texto que explica de forma sencilla la optimización de compresión de GeoTIFF: https://blog.cleverelephant.ca/2015/02/geotiff-compression-f...
Ted seguramente tendrá sus propias ideas, pero esta es más o menos la conclusión a la que llegué después de meterme de lleno en este campo durante los últimos meses
Bueno
Desde la perspectiva de alguien de la vieja escuela que trabajó en tecnología geoespacial, para contar una historia un poco relacionada y quizá aburrida: desde los años 2000, los gobiernos locales empezaron a encargar levantamientos aéreos LiDAR por zonas o subzonas, e incluso surgió una tendencia a poner los datos digitales resultantes a disposición del público
Desde hace más de 10 años, técnicos del sector privado recibían rutinariamente grandes conjuntos de datos LiDAR de ciudades completas y los usaban para análisis de pequeña escala, mapas y planos
Las políticas de datos abiertos de los gobiernos locales variaban mucho según la región, y probablemente aún varían, pero a veces los datos LiDAR se entregaban en varias capas, como “terreno de la superficie”, “edificios” y “cobertura arbórea”. Ese era el resultado de lo que el operador de LiDAR había capturado y calculado inicialmente con distintas frecuencias
El personal técnico de oficina encontraba y ejecutaba procedimientos para ajustar los datos según lo solicitado. Normalmente producían entregables pequeños con software comercial y rutinas, y servicios como el análisis de soleamiento/sombreado y el análisis de visibilidad, muy parecidos a lo que se trata aquí, ya se encargaban en ese entonces
En trabajos a escala de vecindarios pequeños, empezaron a filtrarse al sector privado los primeros intentos de incluir LiDAR de cobertura arbórea, pero seguía siendo algo nuevo y poco común. Ver que ahora este tipo de trabajo se realiza a gran escala resulta alentador
No tengo mucha experiencia jurásica en eso de ofrecer grandes volúmenes de datos en línea, pero trabajar con conjuntos de datos geoespaciales brutos de mayor escala siempre ha sido un desafío central en este campo. Al final, todo el trabajo termina reduciéndose a traducir o abstraer esas fuentes en salidas eficientes, fáciles de entender y enfocadas en el propósito
En ese sentido, lo que realmente impulsa la implementación práctica de innovaciones como esta a gran escala es la informática, y más específicamente la ciencia de datos