Expérimentation de ShadeMap pour calculer jusqu’aux ombres des arbres avec le LiDAR
(tedpiotrowski.svbtle.com)- Jusqu’ici, ShadeMap calculait les ombres à partir de données d’altitude radar faciles à obtenir dans le monde entier, mais dans les zones très boisées, les prévisions d’ensoleillement direct pouvaient être largement erronées
- Le LiDAR permet de refléter plus précisément non seulement le sol, mais aussi la hauteur d’objets comme les arbres et les bâtiments, rendant possibles des simulations d’ombres de la végétation selon la saison et l’heure
- Grâce au jeu de données LiDAR public de l’État de Washington, il a été possible d’expérimenter des rendus intégrant les ombres des arbres dans des zones réelles comme la Seattle metropolitan area
- Une mise en production implique toutefois de convertir des GeoTIFF de l’ordre de 100 Go en tuiles d’images pour navigateur, avec à la clé des limites mémoire et des problèmes de capacité de stockage
- Même la conversion de la Seattle metropolitan area n’était réalisée qu’à moitié après 12 heures, et les tuiles dépassaient déjà 15 Go, ce qui limite la mise à disposition publique à une petite démo pour des raisons de coût
Pourquoi ShadeMap n’avait pas d’ombres d’arbres
- ShadeMap simule les ombres à partir de données d’altitude, et les jeux de données d’altitude faciles à obtenir à l’échelle mondiale sont des données radar comme SRTM
- Le radar fonctionne aussi la nuit et peut traverser les nuages, ce qui permet aux satellites de collecter des données depuis l’espace 24 heures sur 24
- Dans une comparaison de rendu de Bainbridge Island le 9 juillet à 7 h 09, les données radar ne reflétaient pas suffisamment la végétation, si bien qu’une grande partie des ombres manquait
- Dans l’explication initiale affirmant que le radar se réfléchissait uniquement sur le sol, un utilisateur de HN a fait remarquer que le radar se réfléchit aussi sur des surfaces comme la végétation, et une correction a ensuite été ajoutée
- Le jeu de données radar SRTM étant cité comme source des données d’altitude du sol, cette hypothèse en est issue
- À l’inverse, le LiDAR est plus précis, mais doit être collecté par avion ou par drone et ne peut pas traverser le brouillard ni les nuages
- Sa collecte demande beaucoup de temps et d’argent, ce qui implique que chaque administration locale doit en assumer le coût de relevé
Le poids de la conversion des données LiDAR en tuiles pour navigateur
- L’État de Washington fournit un vaste jeu de données LiDAR couvrant une large zone, qui peut servir à améliorer la simulation des ombres d’arbres de ShadeMap
- Les données source sont au format GeoTIFF, conçu pour les logiciels SIG traditionnels, et très éloigné de formats comme JPG ou PNG adaptés à un chargement rapide dans un navigateur
- La conversion consiste à découper des fichiers GeoTIFF de plusieurs centaines de Go, en virgule flottante et en feet impériaux, en petites tuiles d’image, puis à encoder des valeurs en mètres métriques dans les canaux rouge, vert et bleu des pixels
- Au cours du travail, il a fallu acheter un disque dur de 1 To et demander à ChatGPT comment effectuer la conversion
- Avec 16 Go de RAM, il était difficile de charger d’un coup de gros fichiers de données ; il a donc fallu réécrire le code de conversion pour traiter de petites zones plutôt que l’ensemble de la carte
- Même en ne convertissant que la Seattle metropolitan area, seule environ la moitié du travail était terminée après 12 heures, et les tuiles générées continuaient d’augmenter au-delà de 15 Go
- Le résultat est impressionnant, mais le coût d’hébergement public des données reste trop élevé ; pour l’instant, seule une petite démo est disponible
- Depuis la mise à jour, shademap.app peut désormais fournir des données LiDAR par blocs de 1 kilomètre carré pour une grande partie de la planète
1 commentaires
Commentaires sur Hacker News
La démo est vraiment superbe et rapide. En ce moment, je construis un grand dépôt/une plateforme pour analyser des cartes anciennes et des photos aériennes (https://pastmaps.com - c’est encore très tôt, donc merci de ne pas juger trop sévèrement), et je manipule pas mal de pipelines de tuilage et de GeoTIFF
De façon similaire, j’ai eu des problèmes en utilisant les fichiers GeoTIFF bruts comme source, et j’ai pu contourner le besoin de tuilage en ajoutant des requêtes HTTP de plage à des fichiers statiques hébergés sur S3 et en créant un hook de tuilage personnalisé dans MapLibre. Ça déporte le calcul côté client, mais ça fonctionnait quand même assez vite, même sur de vieux appareils mobiles
Si le support des sources GeoTIFF dans MapLibre t’intéresse, je peux partager le code de base ou une partie de ce travail en open source. Je pensais être le seul cinglé sur Internet à bricoler ce genre de chose :D
Dans mon cas, les GeoTIFF LiDAR sont en pieds impériaux avec une précision en virgule flottante 32 bits. Si on prend la plage d’altitude du niveau de la mer jusqu’à l’Everest en mètres (8848) et qu’on la stocke en int16, on obtient une précision de 0,2 m. C’est suffisant pour ShadeMap, donc en convertissant float32 en int16, on pourrait théoriquement réduire de moitié l’espace de stockage cloud, et peut-être davantage encore en tenant compte de la compression PNG
https://www.cogeo.org/
OpenLayers le prend en charge : https://openlayers.org/en/latest/examples/cog.html
À ma connaissance, il n’y a pas de support intégré dans MapLibre ni Leaflet
Ce domaine m’intéresse énormément, et je réfléchis notamment à soutenir financièrement quelques projets. J’ai déjà envoyé un e-mail à Ted, mais j’aimerais parler avec toute personne qui travaille sur ce genre de choses. Mon e-mail est dans mon profil
Heureusement, c’est un domaine assez niche pour que je ne craigne pas de voir ma boîte de réception exploser
Il faut que j’en apprenne davantage sur l’endroit exact où ça coince dans le format GeoTIFF. Partager une infrastructure de pipeline de conversion pur entre les deux projets pourrait peut-être aider
S’il y en a deux, il y en a peut-être d’autres qui se sont heurtés au même mur
L’explication disant que « le radar rate clairement 90 % des ombres produites parce qu’il n’inclut pas la végétation. Le radar ne se réfléchit que sur le sol, donc les objets comme les arbres et les bâtiments sont invisibles » ne me semble pas correcte
Le radar peut, dans certaines bandes, voir à travers le feuillage, ce qu’on appelle le FOPEN. Je ne sais pas vraiment si, aux distances et vitesses de couverture requises pour la cartographie du terrain, le radar peut voir à travers les bâtiments
La Shuttle Radar Topography Mission mentionnée dans l’article utilisait probablement un radar en bande C ou en bande X, et dans les deux cas il devrait y avoir des réflexions sur la végétation et les bâtiments
Sans creuser davantage, les raisons possibles de l’absence d’ombres de végétation et de bâtiments dans les données radar sont peut-être : 1) la résolution des données radar était trop faible (plusieurs dizaines de mètres ou plus), 2) elles ont été supprimées lors du post-traitement de plusieurs passes radar sous différentes géométries, ou 3) l’angle d’incidence faible du radar produisait dès le départ très peu d’ombres
À propos de savoir si le radar a échantillonné la cime des arbres ou le sol, la FAQ explique qu’il n’a pas pu voir à travers une canopée végétale dense. Il a peut-être pénétré un peu dans la canopée, mais a globalement suivi une zone proche de son sommet
La question était de savoir si le signal radar s’était réfléchi sur la cime des arbres, sur le terrain, ou sur une combinaison des deux. Les géodésiens s’intéressent au terrain, tandis que les chercheurs en foresterie s’intéressent à la hauteur de la canopée
La longueur d’onde utilisée, 5,6 cm, ne pénétrait pas bien la végétation, donc dans les zones à végétation moyenne à dense, elle cartographiait une zone proche du sommet de la canopée. Des études comparant cela à des altimètres laser ont montré une légère pénétration, mais pas jusqu’au sol. Quand la végétation était clairsemée ou sans feuilles, on pouvait obtenir des réflexions du sol. Le Vegetation Canopy Lidar, prévu dans le cadre de l’Earth Observing System, pourrait fournir cette capacité et permettre des comparaisons intéressantes entre jeux de données
https://www2.jpl.nasa.gov/srtm/faq.html
Les ombres de relief en montagne sont un vrai problème. Certaines versions comportent des zones vides, en particulier autour de l’Himalaya, là où il n’y avait pas eu de réflexion radar. Si ça t’intéresse, il existe pas mal d’articles sur le comblement des zones vides dans les données SRTM
Si l’on prétraite les GeoTIFF et qu’il existe déjà un pipeline qui fournit aux utilisateurs l’altitude du terrain, on pourrait peut-être n’encoder dans les tuiles que la différence entre LiDAR et radar, puis superposer uniquement les données d’arbres aux données de terrain existantes. L’objet à encoder et la précision nécessaire pourraient peut-être tenir sur 4 bits, et comme il y aurait beaucoup de zéros, la compression les ferait sans doute disparaître. C’est plutôt une idée lancée en brainstorming
height = -10000 + ((R * 256 * 256 + G * 256 + B) * 0.1)[mapbox/maptiler]height = (R * 256 + G + B / 256) - 32768[mapzen terrarium]Si l’on n’a besoin que des altitudes au-dessus du niveau de la mer (0~8848 m), on peut faire tenir les données sur 2 octets tout en conservant une précision de 0,13 m. La précision de Mapbox est de 0,1 m
height = (R * 256 + B) / (256 * 256) * 8848[shademap]C’est cet encodage que je compte utiliser. Je l’ai déjà testé et il économise de l’espace. Pour le temps de traitement, je ne sais pas encore
Le meilleur encodage consiste à mettre dans l’en-tête l’altitude minimale de toute la tuile, puis à ne stocker que la différence entre cette altitude minimale et l’altitude de chaque pixel. C’est le plus efficace en espace, mais il faut charger en mémoire les données de toute la tuile pour trouver l’altitude minimale, et c’est moins efficace que d’encoder les pixels en streaming un par un
J’aimerais qu’on me dise quoi étudier pour devenir compétent en science des données topologiques
J’aime beaucoup Shademaps. J’aurais aimé que mon produit qui l’utilise ait plus de succès, mais Ted et Shademaps sont formidables. Ajouter les arbres est très pratique. Beaucoup d’endroits qui utilisent cet outil sont urbains, mais quand ce n’est pas le cas, les données sur les arbres sont presque toujours plus importantes que les bâtiments ou l’altitude. L’Ontario est assez plat, et 99 % de mes utilisateurs s’y trouvent
On dirait une question d’entretien pour une entreprise GIS : « Si vous aviez des données radar et LiDAR, et que vous vouliez les fusionner sur un appareil à mémoire limitée, comment vous y prendriez-vous ? »
Le service de cartographie français a lancé une campagne LiDAR HD pour toute la France, et une partie est déjà disponible : https://geoservices.ign.fr/lidarhd en bas de page
Je me demande si vous prévoyez d’intégrer un jour ces données dans l’application
Le principal obstacle en ce moment, c’est que ma fiancée est en vacances d’été (elle est prof), donc on sort beaucoup, et qu’il est aussi difficile de trouver des jeux de données LiDAR en ligne
Les données de Washington semblaient exister depuis assez longtemps, mais je n’en ai découvert l’existence qu’il y a quelques semaines
J’espère pouvoir un jour publier un ASK HN sur les jeux de données LiDAR et en crowdsourcer autant que possible
Super projet
Que diriez-vous d’héberger les données dans un bucket S3 avec Requester Pays activé ? Vous n’auriez alors à payer que le stockage
L’accès anonyme ne serait plus possible (comme avec un partage Dropbox), mais les coûts baisseraient fortement
https://docs.aws.amazon.com/AmazonS3/latest/userguide/Reques...
Comme c’est en lecture seule, il n’y aurait pas forcément besoin d’un frontend SQL, et il existe aussi plusieurs façons de faire accéder SQLite à une base située dans un bucket S3. Par exemple : https://github.com/michalc/sqlite-s3-query
La démo est très impressionnante, mais l’essentiel de la sortie a peu de valeur. En effet, les ombres sont calculées au sommet de la canopée des arbres et non au sol. Du coup, même une forêt dense apparaît comme si elle recevait du soleil à l’aube
Cela pourrait malgré tout être très utile pour divers usages, comme les lisières de forêt ou la végétation urbaine. Dans ces cas d’usage, les tuiles de carte pourraient être bien plus petites, et il serait peut-être possible d’aller chercher les données LiDAR à la demande puis de les convertir
Ne serait-il pas possible de convertir cela en base SQLite et de le servir comme fichier statique à un coût bien plus faible ?
https://news.ycombinator.com/item?id=27016630
La magie repose surtout sur les requêtes par plage de HTTP, mais cette partie est déjà « résolue »
C’est à peu près l’approche la plus proche d’un « standard de fait » dans l’industrie aujourd’hui, mais elle a encore des inconvénients pour les petits développeurs, c’est-à-dire des gens comme moi
D’abord, il faut exploiter un serveur de tuiles séparé qui reçoit les requêtes de tuiles et les transforme en requêtes SQL ou en requêtes mbtile en interne. Je n’aime pas trop multiplier les composants mobiles
Ensuite, il faut traiter en mbtiles l’ensemble des GeoTIFF, soit plus de 10 To et en croissance continue, ce qui coûte cher en calcul et prend beaucoup de temps en pratique
Enfin, les mbtiles obtenus ont au mieux une taille similaire aux GeoTIFF d’origine, et au pire bien plus grande. On obtient des requêtes plus rapides, mais au prix de coûts d’hébergement et de transfert plus élevés. Si cela vous intéresse, il existe un bon billet très pédagogique sur l’optimisation de la compression GeoTIFF : https://blog.cleverelephant.ca/2015/02/geotiff-compression-f...
Ted a sans doute ses propres idées là-dessus, mais après m’être plongé dans ce domaine au cours des derniers mois, voilà à peu près la conclusion à laquelle je suis arrivé
Bien
Pour raconter quelque chose d’un peu lié, et possiblement ennuyeux, du point de vue d’un ancien du géospatial, à partir des années 2000, les collectivités locales ont commencé à commander des relevés aériens LiDAR à l’échelle d’une zone ou d’une partie de zone, puis à aller jusqu’à publier les données numériques obtenues pour le grand public
Depuis plus de dix ans déjà, les techniciens du secteur privé récupéraient en masse des jeux de données LiDAR couvrant des villes entières et les utilisaient couramment pour de petites analyses, des cartes et des plans
Les politiques de partage de données des collectivités variaient fortement selon les régions, et c’est probablement encore le cas aujourd’hui, mais il arrivait que les données LiDAR soient livrées sous forme de plusieurs couches, comme « terrain de surface », « bâtiments » ou « canopée arborée ». C’était le résultat de l’acquisition initiale et des calculs effectués par les opérateurs LiDAR à différentes fréquences
Les techniciens de bureau trouvaient puis exécutaient les procédures permettant d’ajuster les données selon la demande. En général, ils produisaient de petits livrables avec des logiciels commerciaux et des routines, et des analyses d’ensoleillement/ombrage ainsi que des analyses de visibilité très proches de ce qui est évoqué ici faisaient déjà partie des prestations demandées à l’époque
Un premier mouvement visant à inclure le LiDAR de canopée arborée dans des travaux à l’échelle d’un petit quartier commençait à gagner le secteur privé, mais cela restait nouveau et rare. Il est encourageant de voir ce type de travail se faire aujourd’hui à grande échelle
J’ai très peu d’expérience de dinosaure en matière de mise à disposition en ligne de données massives, mais le traitement de jeux de données géospatiales brutes de plus en plus volumineux a toujours été un enjeu central du domaine. Au bout du compte, tout ce travail revient à traduire ou abstraire efficacement ces sources en sorties compréhensibles et ciblées selon l’objectif
En ce sens, ce qui donne réellement l’impulsion pour rendre ce genre d’innovation praticable à grande échelle, c’est l’informatique, et plus précisément l’aspect science des données