Willkommen hier in der letzten Session auf der ForstGIS 2021 am Dienstag. In dieser Session haben wir drei Vorträge, die sich alle drei mit 3D befassen. Wir fangen an mit dem Michael

Holthausen von der Firma Terrestris, der uns die Software Cesium.js vorstellen wird. Und das lautet 3D-Geo-Applikation mit Cesium.js, Daten, Einsatzmöglichkeiten und Spezifikationen. Viel

Spaß beim Einstieg in Cesium.js. Herzlich willkommen zu meinem Vortrag über 3D-Geo-Applikation mit Cesium.js, den ich in drei Blöcke unterteilt habe. Wir starten mit einem

allgemeinen Überblick, schauen uns dann die unterschiedlichen Standards an, dabei insbesondere die 3D-Tiles. Und zum Schluss gebe ich noch einen kurzen Einblick in Daten und Einsatzmöglichkeiten. Mein Name ist Michael Holthausen und ich habe 2018 den Master of Science in Geographie an

der Uni Köln beendet und bin seitdem als Anwendungsentwickler bei Terrestris in Bonn tätig. Wir entwickeln und betreuen Open Source Geos-Projekte mit unterschiedlichen Themengebieten, unter anderem auch 3D. Starten wir mit dem ersten Block. Cesium.js

ist eine Open Source JavaScript-Bibliothek zur Erstellung von 3D-Globen und Karten. Cesium.js besitzt alles, was der Definition eines virtuellen Globos nach entspricht.

Man sich also mit einem 3D-Software-Modell die Darstellung der Erde oder auch anderer Himmelskörper betrachten kann. Dabei zeichnen sich diese Modelle dadurch aus, dass man sich frei in einer virtuellen Umgebung bewegen und jeden beliebigen Punkt ansteuern

kann. Dabei den Blickwinkel ändern kann und das Zooming über unterschiedliche Skalierungen vornimmt. Es handelt sich also wie bei einem herkömmlichen Globus um die vereinfachte Darstellung der realen Welt und wie bei bekannten 2D-Kartendarstellungen

können mithilfe der Zoom-Funktion auf einem beliebigen Punkt viel genauere Details angezeigt werden, als es mit einem herkömmlichen Globus möglich wäre. Dies und die Unterstützung zur Darstellung von aufbereiteten Daten, je nach Anforderung sogar in Echtzeit oder

per WMS über verschiedene Kartenebenen, zeigen dem Anwender dann unterschiedliche thembezogene Sachverhalte auf. Die Daten können dabei lokal, also offline vorliegen oder von einem Server gestreamt werden. Es gibt natürlich noch andere Optionen, dreidimensionale Objekte virtuell im Browser darzustellen. So hatten wir bereits vor

zwei Jahren einen Vortrag bei der Foskis im Programm, in dem einzelne Bibliotheken wie 3JS und X-Freedom miteinander verglichen wurden. Anders als mit diesen Bibliotheken können mit 3JS Objekte und Daten in ihrem geografischen Kontext visualisiert werden

und durch seinen Ursprung in der Luft- und Raumfahrt für die digitale Verfolgung von Objekten im Weltraum, wo es sehr auf Präzision ankommt, bietet 3JS eine sehr hohe Detailtreue und Genauigkeit. So wird 3JS dort verwendet, um zum Beispiel die

Position von 10.000 von Satelliten gleichzeitig zu simulieren. Und all die zuvor genannten Merkmale eines öftlichen Globus werden von 3JS dann unterstützt. Und in seiner Basisversion sieht 3JS im Browser dann folgendermaßen aus. Wir haben hier

zunächst eine kleine Hilfe integriert, sowohl für Mausbedienung als auch für Touch-Bedienung. Dann schalte ich direkt mal auf das Terrain um. Und wir können hier über das Suchfeld zu jedem beliebigen Ort fliegen und uns dann genauer Details

über die jeweils eingebundene Karte darstellen lassen. Hier ist es jetzt ein Satellitenbild. Natürlich können wir hier auch noch auf Open Street Maps

umschalten. Ja, 3JS steht unter der Apache 2.0 Lizenz und wird über GitHub beziehungsweise NPM veröffentlicht. Und jeder kann dort an der Entwicklung

teilnehmen. Von Analytical Graphics, ein US-Amerikanischer Anbieter von Software für die Raumfahrt und nationale Verteidigung, wird das Kernentwicklerteam gestellt, das sich um Weiterentwicklung und Fehlerbehebung kümmert. Der Community Support erfolgt über ein Forum, in dem aber auch das

Entwicklerteam aktiv ist. Die Bibliothek ist in JavaScript geschrieben und verwendet die WebGL Schnittstelle bzw. HTML5 und CSS zur Darstellung der einzelnen Komponenten. WebGL wird für hardwarebeschleunigtes 3D Rendering mit JavaScript verwendet und basiert auf der bewährten Grafik API OpenGL.

Und WebGL ist vor allem ein Standard, der von allen Webbrowsern auf dem Desktop, aber auch von einer großen Anzahl von mobilen Browsern unterstützt sind die 2017 veröffentlichten WebGL 2.0 Spezifikationen. Das heißt, durch

die Verwendung von Webstandards kann C7.js in allen modernen Browsern ausgeführt werden. Mit einer dedizierten Grafikkarte können zusätzlich die Renderingzeiten beschleunigt werden. Aber selbst auf mobilen Endgeräten sind die Anwendungen mittlerweile nutzbar, da halt auch die

C7.js unterliegt einer ständigen Weiterentwicklung und Fehlerbehebung. Zu Beginn eines jeden Monats wird die neueste Version dann veröffentlicht, aktuell zuletzt vor einer Woche mit Version 1.8.3.

Und zu den Highlights der vergangenen Versionen zählt sicherlich die Veröffentlichung von C7.js für Unreal Engine sowie die grundlegende Unterstützung für das Rendering im Untergrund. Das heißt, wenn sich die C7.js unter der Erdoberfläche befindet, wird der Glowus als feste Oberfläche gerendert und Objekte unterhalb der Erdoberfläche werden nicht

abgeschnitten. Dadurch ist C7.js auch für ganz neue Themengebiete interessant geworden, zum Beispiel für geologische Fragestellungen. Ein weiteres, vor allem bei der Darstellung von 3D Inhalten bekanntes Problem ist das Backface-Culling. Hier wurde halt in C7.js eine Eigenschaft für die 3D Details geschaffen und auch die

Unterseite oder des Inneren eines Objektes oder Modells zu unterstützen. Das größte Architektur-Refactoring fand Ende 2019 statt, wo C7.js von Asynchronous Module Definitions auf

AcmaScript 6 Module wechselte und damit können C7.js-Applikationen nun wesentlich effizienter geladen werden, da die Gesamtgröße des Bibliothek-Pakets verringert wurde. Die Bibliothek liefert auch eine umfassende API mit, die in der Dokumentation beschrieben

ist. Hierüber kann die Darstellung des Glowus, der anzuzeigenden Oberflächenkarten, der Atmosphäre, der Sonne und halt allen sonstigen platzierten 3D-Objekten beeinflusst werden. Außerdem können über die API externe Datensätze eingelesen werden. Dazu zählt neben

GeoJSON zum Beispiel aber auch das eigens für C7.js entwickelte Format CZML. Es ähnelt dem KML-Format, basiert aber auf JSON und wird zur Darstellung von Linienpunkten, Flächen, Modellen und aller anderen grafischen Grundelementen verwendet. Als Besonderheit

bei diesem Format zählt die Möglichkeit der Beschreibung einer zeitdynamischen grafischen Szene in einem Webbrowser auf einem Glowus von C7.js. Das kompakte und einfach zu pasende Format erlaubt ein effizientes Streaming an den Client und ist

halt auch vom Menschenles unschreibbar. Des Weiteren wird über die API der Zuruf auf C7.1 möglich und C7.1 ist ein ab einer gewissen Auslastung kostenpflichtiger cloudbasierter Dienst für C7.js. Hauptsächlich wird hier über das Termin für den Glowus bereitgestellt.

Nutzer können dort aber auch eigene Daten abgelegen. Das sind dann sogenannte Assets, die bei Bedarf an die Anwendung gestreamt werden können. Bei C7.1 können bestimmte 3D-Datenformate in 3D-Teils konvertiert werden, um halt diese dann an den Clienten zu streamen.

Das führt uns dann zum nächsten Teil des Vortrags, zu den Geodatenstandards und 3D-Teils. Lange Zeit gab es halt nur Geodatenstandards im Web für die Darstellung von Raster- und Vektordaten, also WMS, WMTS, Geojson, Shapefile und KML. Dabei war die Darstellung von Rasterdaten niemals ein Problem

für C7.js. Vektordaten aus Shapefiles können als Geojson konvertiert, ebenfalls auf einfache Art und Weise in C7.js angezeigt werden. Allerdings für die wesentlichen Daten, also die 3D-Modelle, gibt es halt schon eine Menge guter Standards und

Dateiformate, um sie zu speichern, zu visualisieren oder auch mit anderen zu teilen. Das Problem ist, dass es sich dabei halt um Austauschformate handelt. Sie sind halt gedacht für den Austausch von Daten zur weiteren Bearbeitung, aber halt keinesfalls für die Echtzeitvisualisierung optimiert und sie waren halt auch definitiv niemals für die

Verwendung im Web gedacht. Erst mit WebGL war es halt möglich, eine Spezifikation für die Darstellung von drei Modellen im Webbereich zu entwickeln. Und die Chronos Group, wo auch OpenGL, WebGL und andere Grafikstandards entwickelt wurden, veröffentlichten halt die Spezifikation

für das offene GLTF oder auch GL-Transmission-Format als JPEG für 3D. So können halt mittlerweile viele andere Projekte mit Daten, die als GLTF vorliegen, umgehen. Dazu zählen halt Season.js, Three.js, Babylon.js, LibreOffice und Blender. Kann halt mittlerweile auch GLTF

lesen und schreiben. Aber das größte Problem lässt sich auch mit GLTF alleine nicht lösen. Ein Modell mit oder anderen Modellen kann nicht einfach 100.000 Webanfragen stellen. Dafür sind die Daten einfach zu groß,

JavaScript zu langsam und die Browser begrenzen den Speicher pro Tab. Ja, und an dieser Stelle kommen halt die Season.js 3D-Tiles ins Spiel. Die 3D-Tiles als OGC-Community-Standard ist eine offene Spezifikation und bildet das fehlende Bindeglied zwischen halt

umfangreichen heterogenen 3D-Geodatensetzen und 3D-Mapping-Engines, wie zum Beispiel Season.js. 3D-Tiles definieren eine räumliche Datenstruktur, die für 3D ausgelegt und für Streaming und Rendering optimiert ist. Dabei wird das Prinzip des hierarchischen

Level of Detail optimal umgesetzt und nur die sichtbaren und priorisierten Teils eines definierten Modells werden an den Client gestreamt. Sieht man hier auf dem ersten Bild ist halt eine Darstellung von 3D-Gebäuden in Cambridge zu sehen, aber in dieser Ansicht ist es halt nicht erforderlich, jedes Detail eines jeden einzelnen

Gebäudes darzustellen, zu laden, da man sie hier von dieser Ansicht aus überhaupt nicht erkennt. Daher kann hier auf eine sehr reduzierte und vereinfachte Darstellung der Gebäude zurückgegriffen werden. Und in der zweiten Abbildung ist die sogenannte Bounding-Volume

als rote Umrandung aller Teils sichtbar, die hier in einem Grid angeordnet sind. Und erst in der dritten Abbildung unten, wo sehr nah an eines der Objekte herangezoomt wurde, sieht man die Details der Objekte. Und alle anderen Teils, die in dieser Ansicht nicht benötigt werden,

sind nicht mit einem höheren Level an Detail nachgeladen worden. Diese Struktur entlastet den Browser und die Anzahl der Web-Anfragen. Orchestriert wird so ein Teilset über eine JSON-Datei. Damit werden die einzelnen Teils zu einem Teilset zusammengefügt. Das Teilset

JSON hat vier Eigenschaften auf oberster Ebene. Das ist halt asset, properties, geometric error und root. Und asset ist halt ein Objekt, das Metadaten über das gesamte Teilset enthält. Properties ist ein Objekt,

das Objekte für jede Eigenschaft pro Merkmal im Teilset enthält. Hier ist es halt die Höhe. Und der geometric error ist halt eine nicht negative Zahl, die den Fehler in Metern definiert, der bestimmt, ob das Teilset gerendert wird. Zur Laufzeit wird

halt der geometrische Fehler verwendet, um den screen space error zu berechnen. Wenn dieser Wert halt ein erforderliches Minimum nicht überschreitet, sollte das Teilset halt nicht gerendert werden. Das heißt, hierüber wird definiert, ob das Teil eines Teilsets zu einer bestimmten

Detailstufe angezeigt werden soll oder nicht. Root ist halt das Objekt, das die Stammkachel definiert. Unter anderem werden darin die Position des Teilsets über die bounding volume definiert, sowie die Position der einzelnen Teils innerhalb dieser bounding volume dann

über das Objekt children. Die Angabe der bounding volume erfolgt halt über ein Array von sechs Zahlen, die die begrenzten geografische Region mit Breitengrad, Längengrad und Höhenkoordinaten

definieren. Breiten- und Längengrade müssen als WGS 84 EPSG 4979 definiert sein und werden hier im Bogenmaß angegeben. Die Höhen sind in Meter über oder auch unter dem WGS 84 Helipsoid angegeben. Über das

refine property können Kind-Elemente hinzugefügt werden oder ihre Elternelemente ersetzen. Insgesamt ist dabei zu beachten, dass über das URI property in der Teilset Jason nur auf die Geometrien verlinkt wird. Die binären Geometrien, die das GLTF enthalten sind, sind nicht

Bestandteil der Teilset Jason. So können ganze Gebäude, hier eine Kirche als Punktwolke aus einem Leiterscan aus einzelnen Teils zu einem Teilset zusammengesetzt werden. Hier handelt es sich um eine additive Verfeinerung, also je näher die Kamera an eine Position des

Teilsets heransucht, desto mehr Punkte werden für diese Position nachgeladen. Im letzten Block soll es noch um die allgemeine Datenverfügbarkeit und die Einsatzmöglichkeiten gehen. Bei 3D-Daten hat man zunächst vor allem im Geo-Bereich das CTGML vor

Augen. Das ist auch das Format, das von vielen Kommunen verwendet wird, um ihre Daten in einem 3D-Format zu veröffentlichen. CSMJS kann diese nicht direkt anzeigen. Sie müssen zunächst in das Format der 3D-Teils konvertiert werden. Diese Funktionalität

stellt die Transformations-Pipeline von CSM1 zur Verfügung. Der Nachteil hier ist, dass die konvertierten Daten nur bis zu einer gewissen Größe abgespeichert werden können. Danach ist ein kostenpflichtiger Plan der Plattform notwendig. Des Weiteren liegen die konvertierten Daten und auch die Originaldaten anschließend

auf den Servern von CSM1. Im Rahmen eines Projekts für ein geologisches Institut haben wir unter Verwendung der externen Bibliothek Pi3D-Teils eine eigene Pipeline entwickelt, die in Zusammenarbeit mit unserem Open-Source-Gist Shogun

XYZ-Daten eines Nutzers zu geologischen Schichten über den CSM Client importiert. In einer Fuskis-Datenbank abspeichert und in das EPSG 4978, einem Earth-Centered-Earth-Fixed

rechtshändigen 3D-Koordinatensystem konvertiert. Damit werden dann über Pi3D-Teils die 3D-Teils exportiert, Metadaten abgelegt und der Nutzer kann nach diesem Prozess sofort

dynamisch in einem CSMJS-basierten Client diese Daten anzeigen lassen. Mittlerweile findet CSMJS in immer mehr Anwendungen seinen Einsatz. Nur als Beispiel zählen dazu unter anderem

die IAEA zur Überwachung von Radioaktivität im Meerwasser, Intel, Geospatial und CSM mit der Identifizierung von Vegetations- überschneidungen und Strommasten mit Hilfe von Leiterpunktwolken,

Flightradar 24 zur Verfolgung des weltweiten kommerziellen Flugverkehrs in der 3D-Ansicht, also auch Swiss Geo zur Darstellung geologischer Daten im Web und auch noch viele weitere Anwendungen, die bei CSM unter den User-Stories geteilt werden.

Wir haben CSMJS aufgrund der hohen Flexibilität, Support-Aktivität und diversen Einsatzmöglichkeiten für unsere Projekte als am besten identifiziert. Das heißt natürlich nicht, dass zukünftig oder generell der Einsatz anderer Bibliotheken für diese Zwecke ausgeschlossen ist.

Um einen detaillierteren Einblick in eine der Anwendungsmöglichkeiten wird es auch hier im Anschlussvortrag über das Portal SwissGeo gehen und ich empfehle halt idealerweise später auch noch die einzelnen Demos der Anwendung im Sandcastle von CSM einfach selbst auszuprobieren.

Ja, damit bin ich am Ende angekommen und bedanke mich für Ihre Aufmerksamkeit. Ja, herzlichen Dank Michael Holthausen nochmal für deinen tollen Vortrag und diesen super Einstieg in CSMJS. Wir gehen jetzt zu den Fragen über und haben auch da

einige Fragen im Chat. Gibt es noch Applaus? Wunderbar. Wer noch Fragen hat, die können gerne noch gestellt werden. So, die erste Frage, da geht es um die Konvertierung und zwar welche Konverter, beispielsweise

GEDA gibt es um beispielsweise von OBJ oder GLTIV-Meshes oder Punktwolken nach CSM 3D-Tiles zu konvertieren. Habe bisher nur den ION-Service gefunden. Gibt es da noch mehr? Ja, das ist korrekt. Also, der ION-Service, der wird halt auch sehr beworben auf der

Seite, ist halt mit den genannten Bedingungen, dass halt die Daten anschließend bei denen auf dem Server liegen zu beachten. Wir haben halt unsere Konverter selber geschrieben, die sich halt nur

auf x y z Punktdaten beziehen. Es gibt noch nicht so viele freie Konverter, die wir für unsere Projekte halt auch gefunden haben. Unter anderem halt dieses Pi 3D-Tiles und das ist schon sehr weit

fortgeschritten. Basiert aber oder hat zur Grundlage auch überwiegend Laser-Scan-Daten. Okay, das wurde hier in den Fragen auch nochmal angesprochen, das Pi 3D-Tiles, ja. Gut, dann die nächste Frage.

Besteht die Möglichkeit, ein eigenes Geländemodell zu nutzen? Ja, es können digitale Geländemodelle auch als Terrain konvertiert werden und dann von Cesium eingebunden werden. Diese Daten müssen dann aber halt auch auf einem Server liegen

beziehungsweise an Cesium gestreamt werden, da sie in der Technik genauso wie die 3D-Tiles halt gehandhabt werden. Da gibt es auch bisher wenig freie Konverter bei Cesium ein, natürlich auch wieder vorhanden dann.

Okay, gut. Und die nächste Frage geht, denke ich, in die Richtung. Gibt es virtuelle Globen auch frei im Internet? Also, Cesium JS ist die Open Source-Version, um diesen Globus darzustellen und das

verstehe ich halt unter frei. Der ist halt rein zur Darstellung des Globus und eventueller Daten gedacht, die halt entweder von Cesium einkommen oder halt von einem eigenen Server bereitgestellt werden.

Okay, gut. Dann noch eine Frage. Wird Cesium JS für den Digital Twin genutzt? Gibt es bekannte Beispiele? Also, ich hatte ja ein paar Beispiele aufgelistet, wo Cesium verwendet wird. Zum Beispiel Flightradar 24. Andererseits wird es halt auch in vielen Entscheidungs-

und Unterstützungssystemen verwendet. Das ist halt immer abhängig von den Daten, die halt integriert werden können oder sollen. Zum Beispiel kann man es auch gut für Hochwasseranalyse benutzen. Mir ist jetzt allerdings kein Beispiel in dieser Richtung bekannt, denn oft werden halt diese Systeme dann nicht mehr öffentlich zugänglich

gemacht, sondern halt nur intern von den jeweiligen Ämtern genutzt dann. Okay, danke. Und dann noch eine letzte Frage zum Abschluss. Da geht es eher um die Installation. Wo kann man eine Installationsdokumentation finden für Windows Server? Wie sieht es mit den

Server-Anforderungen aus? Also, eine Installation erfolgt in der Regel über Node, also npm-Package. Und CSI und JS wird halt nicht auf dem Server ausgeführt, sondern

halt nur die Skripte des Paketes werden halt von dem Server bereitgestellt. Das System selber läuft dann halt ausschließlich im Browser des Endnutzers. Nur die Daten, die man gerne dem Nutzer bereitstellen möchte, die müssen halt gestreamt werden und müssen dann halt auf einem Server bereitgestellt

werden, sei es jetzt halt der eigene Server oder einen. Das heißt, eigentlich muss nur eine gute Upstream-Leitung vorhanden sein. Okay, vielen Dank. Gut, das war's schon mit den Fragen, die hier im Chat auftauchten. Herzlichen Dank nochmal, Michael, an dich.