ShadeMap-Experiment berechnet mit LiDAR sogar Baumschatten

• ShadeMap berechnete Schatten bisher mit weltweit leicht verfügbaren radarbasierten Höhendaten, konnte aber in baumreichen Gebieten bei der Vorhersage direkter Sonneneinstrahlung deutlich danebenliegen
• LiDAR kann nicht nur den Boden, sondern auch die Höhe von Objekten wie Bäumen und Gebäuden präziser abbilden und ermöglicht so die Simulation von Vegetationsschatten nach Jahreszeit und Tageszeit
• Dank des öffentlichen LiDAR-Datensatzes des US-Bundesstaats Washington konnten Renderings für reale Gebiete wie die Seattle metropolitan area inklusive Baumschatten erprobt werden
• Für den Einsatz im realen Service kommen Konvertierungsaufwand von GeoTIFFs im 100-GB-Bereich in browsergeeignete Bild-Tiles sowie Speichergrenzen und Speicherplatzprobleme hinzu
• Auch die Konvertierung der Seattle metropolitan area war nach 12 Stunden erst etwa zur Hälfte abgeschlossen; die Tiles überschritten 15 GB, sodass die öffentliche Bereitstellung aus Kostengründen auf eine kleine Demo beschränkt bleibt

---

Warum es in ShadeMap keine Baumschatten gab

• ShadeMap simuliert Schatten mithilfe von Höhendaten; weltweit leicht verfügbare Höhendatensätze sind radarbasierte Daten wie SRTM
• Radar funktioniert auch nachts und kann Wolken durchdringen, sodass Satelliten rund um die Uhr Daten aus dem All sammeln können
• Beim Rendering-Vergleich für Bainbridge Island am 9. Juli um 7:09 Uhr spiegelten die radarbasierten Daten die Vegetation nicht ausreichend wider, wodurch ein erheblicher Teil der Schatten fehlte
  • Zur ursprünglichen Erklärung, Radar werde nur vom Boden reflektiert, wies ein HN-Nutzer darauf hin, dass Radar auch von Oberflächen wie Vegetation reflektiert wird; später wurde eine Korrektur ergänzt
  • Da der SRTM-Radardatensatz als Quelle für Bodenhöhendaten zitiert wird, entstand diese Annahme
• LiDAR ist dagegen genauer, muss aber per Flugzeug oder Drohne erfasst werden und kann Nebel und Wolken nicht durchdringen
• Die Erfassung ist zeit- und kostenintensiv, sodass jeweils lokale Behörden die Vermessungskosten tragen müssen

Der Aufwand, LiDAR-Daten in Browser-Tiles zu konvertieren

• Der US-Bundesstaat Washington stellt einen großflächigen LiDAR-Datensatz bereit; damit lässt sich die Simulation von Baumschatten in ShadeMap verbessern
• Die Rohdaten liegen im auf klassische GIS-Software ausgelegten GeoTIFF-Format vor und sind damit weit von schnell im Browser ladbaren JPGs oder PNGs entfernt
• Bei der Konvertierung werden GeoTIFF-Dateien mit Hunderten GB, Gleitkommazahlen und Einheiten in imperial feet in kleine Bild-Tiles zerschnitten; Werte in metric meters werden in rote, grüne und blaue Pixelwerte codiert
• Im Verlauf der Arbeit wurde eine 1-TB-Festplatte gekauft und ChatGPT nach dem Konvertierungsverfahren gefragt
• Mit 16 GB RAM war es schwierig, große Datendateien auf einmal zu laden; der Konvertierungscode musste daher so umgeschrieben werden, dass er nicht die gesamte Karte, sondern kleine Bereiche verarbeitet
• Selbst bei der Konvertierung nur der Seattle metropolitan area war nach 12 Stunden erst etwa die Hälfte fertig, und die erzeugten Tiles hatten bereits mehr als 15 GB erreicht und wuchsen weiter
• Das Ergebnis ist beeindruckend, doch die Kosten für das öffentliche Hosting der Daten sind hoch; derzeit wird nur ein kleiner Bereich als Demo bereitgestellt
• Nach dem Update kann shademap.app für große Teile der Erde LiDAR-Daten in Blöcken von 1 Quadratkilometer bereitstellen

[GN⁺]

Hacker-News-Kommentare

• Die Demo ist unglaublich cool und schnell. Ich baue gerade ein großes Repository/eine Plattform zur Analyse historischer Karten und Luftbilder (https://pastmaps.com – noch sehr früh, also bitte nicht zu hart urteilen) und arbeite dabei ziemlich viel mit Tiling-Pipelines und GeoTIFFs.
  Ich hatte ein ähnliches Problem damit, die originalen GeoTIFF-Dateien als Quelle zu verwenden, und konnte den Bedarf an Tiling umgehen, indem ich HTTP-Range-Requests auf statische Dateien in S3 angewendet und in MapLibre einen benutzerdefinierten Tiling-Hook gebaut habe. Das verlagert zwar die Berechnung auf den Client, lief aber selbst auf älteren Mobilgeräten ziemlich schnell.
  Falls Interesse an GeoTIFF-Source-Support für MapLibre besteht, kann ich den Basis-Code oder Teile dieser Arbeit als Open Source teilen. Ich dachte, ich wäre der Einzige im Internet, der an so etwas herumbastelt :D

  • Ah, ich war nicht auf die Idee gekommen, Byte-Offsets on the fly berechnen zu können. Bevor ChatGPT aufkam, war es schwer, Tile-Erzeugungswerkzeuge und Optionen zu verstehen, und online gab es auch nicht viele Informationen, deshalb finde ich im Allgemeinen, dass es besser ist, eher zu viel zu teilen.
    In meinem Fall haben die LiDAR-GeoTIFFs britische Fuß als Einheit und 32-Bit-Gleitkommapräzision. Wenn man den Höhenbereich von Meereshöhe bis Everest in Metern (8848) ansetzt und in int16 speichert, erhält man 0,2 m Präzision. Das reicht für ShadeMap aus, daher könnte die Umwandlung von float32 zu int16 den Cloud-Speicherplatz theoretisch halbieren, und mit PNG-Kompression vielleicht noch stärker reduzieren.
  • Wenn du den „Bedarf an Tiling umgangen hast, indem du HTTP-Range-Requests auf statische Dateien in S3 angewendet hast“, würde mich interessieren, ob du dir auch das Format Cloud Optimized GeoTIFF angesehen hast.
    https://www.cogeo.org/
    OpenLayers unterstützt es: https://openlayers.org/en/latest/examples/cog.html
    Soweit ich weiß, haben MapLibre und Leaflet keine eingebaute Unterstützung.
  • https://geoblaze-gsoc.vercel.app und die zugrunde liegenden Bibliotheken sind ebenfalls sehenswert. Auch sie verwenden Range-Requests für GeoTIFFs.
    Ich interessiere mich sehr für dieses Feld und denke auch darüber nach, einige Projekte finanziell zu unterstützen. Ich habe Ted bereits eine E-Mail geschickt, würde aber gern mit jedem sprechen, der an solcher Arbeit beteiligt ist. Die E-Mail-Adresse steht im Profil.
    Zum Glück ist das Gebiet nischig genug, dass ich mir keine Sorgen um eine explodierende Inbox machen muss.
  • Du bist jetzt nicht mehr die „seltsamste Person“. Trotzdem seid ihr beide immer noch ziemlich speziell. Es scheint, als könnte es gut funktionieren, wenn ihr euch austauscht, miteinander in Kontakt tretet und euch gegenseitig unterstützt.
    Ich muss noch mehr darüber lernen, wo genau die Probleme im GeoTIFF-Format liegen. Vielleicht wäre es hilfreich, Infrastruktur für eine reine Transformations-Pipeline zwischen den beiden Projekten zu teilen.
    Wenn es euch schon zu zweit gibt, gibt es vielleicht noch mehr Leute, die gegen dieselbe Wand gelaufen sind.
  • Ich finde es auch wirklich cool. Das erinnert mich daran, wie ich vor 8 Jahren den zentralen Event-Handling- und SVG-Rendering-Code von Leaflet refaktoriert habe. Es ist schön zu wissen, dass meine Open-Source-Beiträge zu solchen coolen Dingen beigetragen haben.

• Die Erklärung „Radar verpasst eindeutig 90 % der entstehenden Schatten, weil es keine Vegetation einschließt. Radar reflektiert nur vom Boden, daher sind Objekte wie Bäume und Gebäude nicht sichtbar“ scheint nicht zu stimmen.
  Radar kann in bestimmten Bändern durch Blätter hindurchsehen, das sogenannte FOPEN. Ob Radar bei den für Geländekartierung nötigen Distanzen und Flächenabdeckungsraten durch Gebäude hindurchsehen kann, weiß ich nicht genau.
  Die im Artikel erwähnte Shuttle Radar Topography Mission dürfte Radar im C-Band oder X-Band verwendet haben, und beide sollten Reflexionen von Vegetation und Gebäuden liefern.
  Ohne tiefer eingestiegen zu sein, könnte der Grund, warum in den Radardaten keine Vegetations- und Gebäudeschatten auftauchen, sein, dass 1) die Auflösung der Radardaten zu gering war (mehrere Dutzend Meter oder mehr), 2) sie bei der Nachbearbeitung mehrerer Radarüberflüge mit unterschiedlichen geometrischen Bedingungen entfernt wurden oder 3) aufgrund des geringen Einfallswinkels des Radars von vornherein kaum Schatten entstanden.

  • Laut SRTM-FAQ ist die Logik des Artikels umgekehrt.
    Auf die Frage, ob das Radar Baumwipfel oder den Boden abgetastet hat, erklärt die FAQ, dass es dichte Vegetationskronen nicht durchdringen konnte. Es könnte etwas in das Kronendach eingedrungen sein, folgte aber im Allgemeinen eher dem oberen Bereich der Baumkronen.
    Das Problem war, ob das Radarsignal von den Baumwipfeln, vom Gelände oder aus einer Mischung von beidem reflektiert wurde. Geodäten interessieren sich für das Gelände, Forstforscher für die Höhe des Kronendachs.
    Die verwendete Wellenlänge von 5,6 cm dringt nicht gut durch Vegetation, deshalb wurde bei mittlerer bis dichter Vegetation der obere Bereich des Kronendachs kartiert. In Studien mit Vergleichen zu Laser-Altimetern zeigte sich eine gewisse Penetration, aber nicht bis zum Boden. Bei spärlicher Vegetation oder fehlenden Blättern konnten Bodenreflexionen auftreten. Ein als Teil des Earth Observing System geplantes Vegetation Canopy Lidar könnte diese Fähigkeit bieten und interessante Vergleiche zwischen Datensätzen ermöglichen.
    https://www2.jpl.nasa.gov/srtm/faq.html
  • Gute Ergänzung. So wie ich es verstehe, waren in den SRTM-Daten Gebäude oder Vegetation nicht enthalten. Vermutlich wurde alles außer den niedrigsten Höhenwerten herausgefiltert. Aber das ist keine Eigenschaft von „Radar“ im Allgemeinen.
  • SRTMv3 deckt Breiten von ±60° mit 30 m/Pixel ab. Die erste Veröffentlichung hatte 90 m/Pixel, und es gab auch Releases mit 30 m innerhalb der USA und 90 m außerhalb.
    Bergschatten sind tatsächlich ein Problem. In manchen Releases gibt es leere Bereiche, besonders rund um den Himalaya, wo es keine Radarreflexion gab. Falls dich das interessiert: Es gibt einige Arbeiten zum Auffüllen fehlender Bereiche in SRTM-Daten.

• Wenn GeoTIFFs vorverarbeitet werden und es bereits eine Pipeline gibt, die Nutzern Geländehöhen liefert, könnte man in den Tiles vielleicht nur den Unterschied zwischen LiDAR und Radar kodieren und die Baumdaten einfach auf die bestehenden Geländedaten aufsetzen. Die zu kodierenden Objekte und die nötige Präzision könnten vielleicht schon in 4 Bit passen, und wegen der vielen Nullen würde das durch Kompression vermutlich weitgehend verschwinden. Eher ein Brainstorming-Gedanke.

  • Gute Idee. Es gibt zwei weit verbreitete Verfahren, um Höhendaten in RGB-Tiles zu kodieren. Beide müssen auch negative Höhen für die Kartierung des Meeresbodens enthalten und sind daher im Hinblick auf den Wertebereich nicht optimal kompakt.
    height = -10000 + ((R * 256 * 256 + G * 256 + B) * 0.1) [mapbox/maptiler]
    height = (R * 256 + G + B / 256) - 32768 [mapzen terrarium]
    Wenn man nur Höhen über dem Meeresspiegel (0–8848 m) braucht, kann man die Daten in 2 Byte unterbringen und dabei eine Präzision von 0,13 m beibehalten. Die Präzision von Mapbox liegt bei 0,1 m.
    height = (R * 256 + B) / (256 * 256) * 8848 [shademap]
    Diese Kodierung soll verwendet werden. Ich habe sie bereits getestet, und sie spart Platz. Wie es bei der Verarbeitungszeit aussieht, weiß ich noch nicht.
    Die beste Kodierung wäre, die niedrigste Höhe des gesamten Tiles im Header zu speichern und nur den Differenzwert zwischen der niedrigsten Tile-Höhe und der Höhe jedes Pixels abzulegen. Das ist am platzsparendsten, erfordert aber, die gesamten Tile-Daten in den Speicher zu laden, um die niedrigste Höhe zu finden, und ist weniger effizient, als die Pixel einzeln im Stream zu kodieren.
  • Ich würde über dieses Gebiet wirklich gern mehr lernen. Ich suche gerade nach dem Thema, auf das ich mich als Nächstes konzentrieren will, und die Begriffe hier treffen genau die Art von Wissen, zu der ich hinmöchte.
    Es wäre toll, wenn jemand sagen könnte, was man lernen sollte, um in der Topografischen Datenwissenschaft wirklich fit zu werden.

• Ich mag Shademaps. Ich wünschte, mein Produkt, das das verwendet, wäre erfolgreicher gewesen, aber Ted und Shademaps sind großartig. Bäume hinzuzufügen ist extrem praktisch. Viele Orte, die dieses Tool nutzen, sind zwar urban, aber wenn das nicht der Fall ist, sind Baumdaten fast immer wichtiger als Gebäude oder Höhenangaben. Ontario ist ziemlich flach, und 99 % meiner Nutzer sind dort.

  • Mit Business und Marketing tue ich mich noch etwas schwer, aber die Idee selbst scheint beliebt zu sein, und die Arbeit macht Spaß und ist lohnend.

• Klingt wie eine Frage in einem GIS-Bewerbungsgespräch: „Wenn Sie Radar- und LiDAR-Daten haben und diese auf einem Gerät mit begrenztem Speicher zusammenführen wollen, wie würden Sie vorgehen?“

  • In gewisser Weise sind die Probleme hier genau die, auf die mich meine Informatikausbildung vorbereitet hat. Früher habe ich Webentwicklung gemacht, und da musste ich mir fast nie Sorgen machen, ob eine Webseite in den Speicher passt, oder darüber, mehr als ein paar Prozent der verfügbaren Prozessorzyklen zu verbrauchen.

• Der französische Kartendienst hat mit HD-LiDAR-Aufnahmen für ganz Frankreich begonnen, und ein Teil davon ist bereits verfügbar: https://geoservices.ign.fr/lidarhd weiter unten.
  Ich frage mich, ob geplant ist, diese Daten irgendwann in die App aufzunehmen.

  • Auf jeden Fall. Danke für den Link.
    Das Haupthindernis im Moment ist, dass meine Verlobte Sommerferien hat (sie ist Lehrerin), wir deshalb viel draußen sind und es zudem schwer ist, online LiDAR-Datensätze zu finden.
    Die Daten für Washington gab es wohl schon ziemlich lange, aber ich wusste bis vor ein paar Wochen nicht, dass sie existieren.
    Irgendwann möchte ich dazu ein ASK HN zu LiDAR-Datensätzen posten und möglichst viele Daten per Crowdsourcing zusammentragen.

• Tolles Projekt.
  Wie wäre es damit, die Daten in einem S3-Bucket mit aktiviertem Requester Pays zu hosten? Dann müsstest du nur die Speicherkosten tragen.
  Anonymer Zugriff wäre dann zwar nicht mehr möglich (bei geteilten Dropbox-Links ist das ähnlich), aber die Kosten würden stark sinken.
  https://docs.aws.amazon.com/AmazonS3/latest/userguide/Reques...
  Da es nur Lesezugriff ist, braucht man nicht zwingend ein SQL-Frontend, und es gibt verschiedene Wege, SQLite auf die Datenbank in einem S3-Bucket zugreifen zu lassen. Zum Beispiel: https://github.com/michalc/sqlite-s3-query

• Die Demo ist sehr cool, aber ein Großteil der Ausgabe ist von geringem Wert. Der Schatten wird nämlich nicht auf dem Boden, sondern an der Oberseite des Blätterdachs berechnet. Deshalb sieht es so aus, als ob selbst in dichtem Wald bei Sonnenaufgang Sonnenlicht einfällt.
  Trotzdem könnte das für viele Anwendungen sehr nützlich sein, etwa an Waldrändern oder bei städtischer Vegetation. In solchen Fällen könnten die Karten-Tiles viel kleiner sein, und man könnte LiDAR-Daten bei Bedarf holen und umwandeln.

• Könnte man das nicht in eine SQLite-Datenbank umwandeln und als statische Datei mit deutlich geringeren Kosten bereitstellen?
  https://news.ycombinator.com/item?id=27016630
  Range Requests in HTTP sind dabei der eigentliche Zauber, aber dieser Teil ist ja bereits „gelöst“.

  • Das ist im Grunde genau der Weg, den Mapbox gegangen ist. Mapbox hat für genau solche Serverabfragen sogar das mbtiles-Dateiformat geschaffen, das praktisch eine SQLite-Datenbank ist.
    Das ist heute so etwas wie der De-facto-Standard in der Branche, hat für kleine Entwickler wie mich aber immer noch Nachteile.
    Erstens muss man einen separaten Tile-Server betreiben, der Tile-Anfragen entgegennimmt und intern in SQL-Abfragen oder mbtile-Anfragen umsetzt. Ich mag zusätzliche bewegliche Teile nicht besonders.
    Zweitens müsste ich sämtliche GeoTIFFs mit inzwischen mehr als 10 TB und weiter wachsend in mbtiles umwandeln, was sowohl rechnerisch als auch zeitlich teuer ist.
    Drittens sind die resultierenden mbtiles bestenfalls ungefähr so groß wie die ursprünglichen GeoTIFFs, im schlechtesten Fall aber deutlich größer. Man bekommt schnellere Anfragen, zahlt dafür jedoch mehr für Hosting und Datentransfer. Falls es dich interessiert, gibt es dazu eine gut geschriebene Erklärung zur GeoTIFF-Kompressionsoptimierung: https://blog.cleverelephant.ca/2015/02/geotiff-compression-f...
    Ted hat dazu sicher auch eigene Gedanken, aber das ist das Fazit, zu dem ich in den letzten Monaten gekommen bin, nachdem ich mich neu in dieses Gebiet eingearbeitet habe.

• Gut
  Um aus der Sicht eines alten Hasen zu sprechen, der früher mit Geospatial-Technologien gearbeitet hat, und dabei eine leicht verwandte und vielleicht etwas langweilige Geschichte zu erzählen: Seit den 2000er-Jahren begannen Kommunalverwaltungen, LiDAR-Luftvermessungen für ganze Bezirke oder Teilgebiete in Auftrag zu geben und darüber hinaus die entstehenden digitalen Daten öffentlich zugänglich zu machen.
  Schon seit mehr als zehn Jahren nutzten Fachleute im privaten Sektor routinemäßig große stadtweite LiDAR-Datensätze für kleinere Analysen, Karten und Pläne.
  Die Richtlinien zur Datenfreigabe der Kommunalverwaltungen unterschieden sich je nach Region stark und tun das vermutlich noch heute, aber gelegentlich wurden LiDAR-Daten in mehreren Layern wie „Geländeoberfläche“, „Gebäude“ und „Baumkronen“ bereitgestellt. Das waren Ergebnisse, die von den LiDAR-Betreibern zunächst in verschiedenen Frequenzen erfasst und anschließend berechnet wurden.
  Techniker im Büro fanden und nutzten Verfahren, um die Daten an konkrete Anforderungen anzupassen. Meist wurden mit kommerzieller Software und etablierten Routinen kleinere Ergebnisse erzeugt, und Sonnen-/Schattenanalysen sowie Sichtbarkeitsanalysen, die dem hier Behandelten sehr ähnlich sind, waren schon damals beauftragte Dienstleistungen.
  Bei Arbeiten im Maßstab kleiner Nachbarschaften begann es erste Versuche zu geben, auch Baumkronen-LiDAR in den privaten Sektor einfließen zu lassen, aber das war neu und selten. Es ist ermutigend zu sehen, dass solche Arbeiten heute in großem Maßstab stattfinden.
  Mit der Online-Bereitstellung großer Datenmengen habe ich aus meiner Dinosaurier-Perspektive kaum Erfahrung, aber der Umgang mit größeren rohen Geodatenbeständen war schon immer eine Kernaufgabe dieses Fachgebiets. Letztlich läuft jede Arbeit darauf hinaus, solche Quellen in effiziente, leicht verständliche und zweckgerichtete Ausgaben zu übersetzen oder zu abstrahieren.
  In diesem Sinne kommt der eigentliche Schub, um solche Innovationen in großem Maßstab praktisch nutzbar zu machen, aus der Informatik und genauer gesagt aus der Data Science-Perspektive.