Ja, herzlich willkommen zum nächsten Vortrag. Das ist der letzte Vortrag in diesem Vortragsblock. Geotiff, denke ich mal, kennt jeder, der in diesem Raum sitzt. Inzwischen gibt es auch Cloud-optimierte Geotiffs.

Was ist das? Wozu brauche ich das? Welche Vorteile hat es? Das erklärt uns jetzt Christian Strobl. Grüß Gott, ich freue mich, dass ich heute einen Vortrag über das Thema halten kann. Ich arbeite im DLR in Oberpfaffenhofen, am Deutschen Fernkundungsdatenzentrum. Und wer das auch immer hier eingeteilt hat, das passt perfekt zum letzten Vortrag.

Beim letzten Vortrag ging es darum, wie kriegt man die Daten über eine Infrastruktur an den User. Und jetzt geht es eigentlich darum, wir müssen die Daten aufbereitet und strukturiert sein, dass der User auch etwas damit anfangen kann. Ich mache jetzt ungern mit diesem ESA-Bashing weiter, was hier so kursiert, obwohl eigentlich, glaube ich, die wenigsten wirklich genau wissen, was die ESA alles macht.

Ich möchte kurz sagen, seit 2014 sind das sieben Satelliten gestartet. Wir kriegen täglich 40 Terabyte Daten rein und die ESA auch schafft es kaum, mit dem natürlich Schritt zu halten und hinten so viele Festplatten rein zu stopfen, wie vorn Daten reinkommen. Und insofern sind natürlich so Technologiewechsel,

wie der Volker das vorstellt, wahrscheinlich im Augenblick gar nicht so einfach für die ESA, weil die kämpfen einfach damit, dass sie Schritt halten. Das würde ich sagen, und wenn man jetzt die Sentinel-Daten anschaut, was da überhaupt alles da ist, ist das in Sachen Fernerkundung der absolute Game-Changer. Wenn man sich überlegt, was bis vor kurzem mit den Paarlandsat und Modestaten von der NASA möglich war

und was heute mit den Sentinel-Daten von der ESA alles erreichbar ist. So, jetzt waren wir eine kurze Verteidigungsrede zur ESA. Wir haben auch, das habe ich gestern vorgestellt, ein deutsches Zugangssystem für Sentinel-Daten, das heißt QoT.de. Das lohnt sich vielleicht auch für den einen oder anderen mal anzuschauen.

Da gibt es ja auch sicher noch das Video von dem Talk von gestern, wo die einzelnen Schnittstellen erklärt werden. Und jetzt komme ich dann zu der Motivation. Als ich das erste Mal von diesem Cloud-Optimized-Geo-TIF gehört habe, ist mir eigentlich sofort irgendwie der Gedanke gekommen, was ist denn das eigentlich?

Ich habe dann gegoogelt und man landet eigentlich wie fast immer irgendwo auf Gedanke-Seite. Und die Motivation, glaube ich, da gibt es sicher den einen oder anderen OS-Geo-Internen, der dann sagt, das hat der Anolf mit dem Chef nach dem dritten Bier mal ausgeklügelt. Oder der Ivan hat das mit dem Frank, weiß ich nicht was, das weiß ich alles nicht.

Ich weiß jedenfalls, dass die Quellen für das Ganze eigentlich auf der Gedanke-Seite liegen und das hängt mit diesen virtuellen Filesystemen zusammen, die Gedanke seit zwei, drei Jahren unterstützt. Und der Vorteil dieser virtuellen Filesysteme ist jetzt, ich kann zum Beispiel ZIP-Dateien,

muss ich nicht mehr auspacken, da habe ich immer ein Beispiel, sondern ich kann direkt auf den Datensatz zugreifen, das dauert natürlich, weil das muss ja intern, wird ja darauf zugreifen, aber wird nicht mehr extra ausgepackt und ich kann praktisch hier dann den Inhalt von meinem ZIP-File sehen und kriege die komplette Information.

Das gleiche geht auch mit FTP, HTTP-Servern oder auch mit S3-Buggets von Amazon. Ich habe mir extra so ein Konto besorgt und bin voll ins Risiko gegangen, habe da Daten hochgeladen

und da gibt es jetzt zum Beispiel die Möglichkeit mit einem neuen Befehl, mit Gedanke-Location-Info kann ich direkt für einen bestimmten Punkt, ich versuche es mir, ob es geht, ich habe vorher die Credentials eingegeben, es geht sogar ziemlich schnell, also dieser Datensatz liegt jetzt bei Amazon und ich suche jetzt für die Koordinatate 00 irgendwo mehr den Value 3, das ist jetzt in dem Fall bei dem Bild oder bei dem Datensatz,

den ich jetzt dann bespreche, ist das jetzt Wasser. Ich kann auch Gedanke-Info-Befehl darauf ausführen, ich kriege ja auch relativ schnell ein Ergebnis, 1,62 Sekunden, und ich kann auch die Daten partiell runterladen, ich habe hier zum Beispiel einen Ausschnitt,

ich habe jetzt hier von minus 10 bis plus 10 und in Breite und Länge als Ausschnitt geholt, dann dauert das jetzt hier ein paar Sekunden, so schnell kann ich gar nicht runterscrollen, das ist schon da und wenn ich das dann darstelle, das Bild, dann ist praktisch das hier sofort runtergeholt

und hier komme ich jetzt auch zu dem Grund, warum es Cloud Optimized GeoTIV braucht oder was das Besondere dran ist oder das Nicht Besondere, das ist nämlich, man sieht das, gut wenn man die Daten kennt, sieht man es sonst, sieht man es wahrscheinlich nicht, dass das jetzt nicht voll aufgelöst ist, sondern das wird genau aufgelöst für diesen Parameter, den ich hier angegeben habe,

ich habe hier gesagt, der Output Size soll nur 1% der Gesamtgröße betragen, das heißt, es werden nicht die gesamten Daten in voller Auflösung runtergetragen,

sondern sie werden komprimiert und diese Komprimierung ist schon vorbereitet, weil das Image nämlich Oberfuse hat und damit sind wir jetzt eigentlich bei dem ersten Punkt, das ist ein bisschen Theorie, was Cloud Optimized GeoTIV eigentlich ist, das enthält nämlich sogenannte Oberfuse. Alle, die aus der Fernerkundung kommen, die kennen das als Pyramiden

oder die früher mal mit Agis arbeiten durften, mussten, was auch immer, die wurden ja immer gefragt, wenn man neues GeoTIV oder neues Rastadatei geladen hat, möchten Sie jetzt Pyramiden bilden und da muss man immer auf hinein klicken und hat irgendwo mal das in den Options gefunden, um das abzustellen und genau das passiert hier.

Also Pyramiden bilden und komme ich dann gleich darauf zurück, was das ist, das ist, oder ich sage es am besten gleich, das ist immer eine Reduzierung der Auflösung, man macht eigentlich ein neues Bild mit einer reduzierten Auflösung und stapelt das so übereinander und hat dann am Schluss, wenn man zum Beispiel jetzt vier oder acht Oberfuse bildet, hat man heute das nächste Oberfue hat dann genau die Hälfte der Auflösung,

das übernächste ist Viertelte, ein Achtel, ein Sechzehntel und so weiter und bei Acht kommt man dann bis zu 256, nur ein 256thel der Daten. Das nächste ist, dass es in Blöcke unterteilt ist, das ist der gegenteilige Fall, das ist nicht, wenn ich rauszoome, sondern wenn ich reinzoome, wird es dann schneller,

das sind die sogenannten Tiles und diese zwei Sachen ist eigentlich bis jetzt nichts anderes als alter Wein in neuen Cloudsporchen, weil das eigentlich genau das ist, was man eigentlich seit Jahren macht, wenn man zum Beispiel so Daten für einen Geo-Server oder für einen OGC-Server und einen Mapserver aufbereitet, dann gibt es irgendwelche Empfehlungen,

Blogposts seit über zehn Jahren, wie man das halt macht, das vom Frank noch, dass man halt zuerst die Oberfüße bildet, dann die Tiles, damit man halt einfach das Performant streamen kann, auch über normale OGC-Services. Also das ist eigentlich jetzt nichts Neues, was jetzt ein bisschen was Neues ist,

ist, dass der Header von dem TIFF und das sogenannte Image-File direkt darüber, was in diesem Header drin ist, schön geordnet ist. Ich habe hier so ein Beispiel von so einem Post auch von Planet, wo das hier ganz schön dargestellt ist, es ist ein schönes Cloud-optimales Geo-TIFF, wo das einfach geordnet ist, wo zuerst der Direktor,

wo die Daten oder die Oberfüge kommen, mit der geringsten Auflösung, die weiter ich dann reingehe, umso besser wird die Auflösung, und dadurch hat man einfach einen schnelleren Zugriff. Auf der linken, auf der rechten Seite sieht man, wie sowas halt nicht optimal funktioniert. So, das war es jetzt eigentlich schon zu dem Thema,

was kann ich mit einem Cloud-optimales Geo-TIFF machen. Und die Bedeutung, die es hat, ist nochmal das, es gibt, damit komme ich jetzt wieder zu ESA zurück, die unterschiedlichsten Dateiformate gerade im Fernerkundungsbereich. Also Sentinel-1 hat zum Beispiel Geo-TIFF, Sentinel-2 hat JPEG 2000,

Sentinel-3 hat NetCDF, NetCDF ist ja selbst beschreibendes Format, also mit einem bestimmten Sentinel-3-Flaver dann, und Sentinel-5P hat NetCDF mit einem Sentinel-5P-Flaver aus der Atmosphären-Community. Das heißt, ich habe jetzt schon mal bei fünf unterschiedlichen Remote-Sensing-Daten, habe ich vier unterschiedliche Dateiformate.

Und das macht es natürlich jetzt nicht leicht, wenn man diese Formate jetzt über eine Cloud oder auch über einen Remote-Service runterholen will und gleich verarbeiten will, weil ich muss dann immer so Zwischenschritte machen, um die Information aus den Metadaten mir zu holen, die dann zu konvertieren, dass das mein Programm wieder kann und, und, und.

Das ist dann alles sehr speziell. Und damit halt, da komme ich zu dem Punkt, warum das sehr gut zum vorigen Vortrag passt, weil das sind ja zwei unterschiedliche Optimierungsmaßnahmen. Man kann erst einmal schauen, dass die Daten schnell an den User kommen und dass die Daten auch im Format, was jeder verstehen kann, an den User kommt,

weil dann hat der nämlich keine Arbeit damit. Und das ist jetzt eigentlich die Motivation von diesem Vortrag. Als nächstes möchte ich kurz zeigen, wie so ein Cloud-Optimized-Geotiff erzeugt wird.

Das ist auch ganz schön auf den Seiten von Gethal zu finden. Das hat alles der Ivan Rouen gemacht. Und ich gehe das hier mal durch. Und was das Schöne ist, der hat auch so einen Validierungs-Skript zur Verfügung gestellt. Das kann man sich runterladen, das habe ich gemacht.

Das kann man sich dann auch, das ist jetzt hier so ein Jupyter-Notebook. Dann kann ich mir das hier als Python... Oh, doch nicht. Ich bin in einem anderen Verzeichnis. So. Und dann kann ich das jetzt hier mal validieren.

Das ist eine Datei, die tatsächlich schon Cloud-optimiert wurde. Also ein Geotiff-Datei. Und da habe ich hier diesen Output. Und wenn ich das dann noch extern validiere, das geht auch, dass man es in der Kommandozeile aufruft. Ne, Entschuldigung.

Da habe ich hier ein Cloudless-Beispiel. Ja, dann schaut es so aus, das ist nicht die Kleiddatei. Das ist eins, wo ich die Oberfuse und Details entfernt habe. Dann kriege ich hier die Meldung, dass das File größer ist und die Menge ist und für einen internen Oberfuse beinhaltet. Und dass es nicht geteilt ist und dass die Image-File-Directory und so weiter.

Alles nicht stimmt. Also mit diesem Skript, was man sich von der Seite von Gethal runterladen kann, kann man jede Datei dann überprüfen, ob die dementsprechend optimiert wurde. Und jetzt wollen wir so einen Geotiff erzeugen. Das passiert hier mit Sentinel-2-Datensatz,

den ich hier runterladen habe. Machen wir mal Gethal-Info auch wieder drauf. Da sieht man, wie die aufgebaut sind. Das Schöne ist, dass der Sentinel-2-Treiber jetzt funktioniert, von Gethal und auch ziemlich gut. Also ich habe das wie bei HDF-Dateien auch, sehe ich hier unten. Also ich sehe hier oben natürlich die ganzen Metadaten. Auf die gehe ich jetzt aber nicht ein.

Sondern ich schaue mir hier unten meine Subdata-Sets an. Und Subdata-Sets sind zum Beispiel immer alle Bänder, die die gleiche Auflösung haben. Also ich habe hier 10 Meter Bänder, 20 Meter, 60 Meter Bänder. Und dann haben es für eine schnelle Ansicht, um so Quicklux zu bilden, gibt es noch so sogenannte TCI-Subdata-Sets, das heißt Pro Color Image.

Mit dem Subdata-Set arbeiten wir jetzt weiter. Also wir definieren praktisch dieses Subdata-Set. Das ist bei Gethal ja immer so, dass man hier eigentlich, wenn dieses Subdata-Set mit dem Ist gleich angegeben ist, dann eigentlich alles, was dahinter kommt, nehmen kann, um ein nächstes Gethal-Info drauf auszuführen.

Dann habe ich praktisch alles, was in diesem Subdata-Set ist, wieder. Ich habe das vorher als Variable definiert. Und dann sehe ich jetzt hier mein Subdata-Set. Und habe hier oben wieder die Metadaten. Dann kann man sehen, dass es schön georeferenziert ist. Und weiter unten sehe ich dann, dass es drei Bänder beinhaltet, nämlich Rot, Grün und Blau. Und das ist eigentlich alles, was wir zu einer Darstellung brauchen.

Und einfach, das reicht auch für viele Anwendungen. Zum Beispiel das, was der Volker jetzt gezeigt hat, um die Daten einfach auch für einen Geo-Server aufzubereiten. Also was wir bei Code.de zum Beispiel machen, mit so einem Full Resolution Browsing, ist das oft eine ausreichende Quelle. Da brauche ich nicht alle Bänder.

So, dann konvertieren wir jetzt dieses Subdata-Set. Das dauert jetzt nicht besonders lang im Notebook. Ich wollte es trotzdem mal zeigen, dass man ungefähr so ein Geschwindigkeitsgefühl kriegt. Also für so einen Sentinel-2-Datensatz, der nicht so klein ist, dann ungefähr, schnell nachschauen, 10.000 Pixel oder so etwas.

Genau, ungefähr 10.000 Pixel kommen wir hier mit einer vertretbaren Geschwindigkeit an so einem Dell Notebook durch. Und ich habe jetzt praktisch hier den JPEG 2000-Datensatz in einem TIFF-Datei komprimiert.

Ich habe den schon mal geteilt und habe ihn komprimiert. Das sieht man hier auch, wenn man wieder das ausführt. Bis jetzt ist nicht viel passiert. Ich kann mir das jetzt plotten. Machen wir mal schnell. Also ich lade das in die G-DAL und plotte dann hier den Datensatz.

Das heißt, so schnell habe ich das jetzt auf alle Fälle schon mal runtergeladen. Das muss man jetzt einmal ausführen manchmal. So schnell habe ich das jetzt runtergeladen und kann eigentlich schon mit dem Datensatz jetzt arbeiten. Also ich habe jetzt hier einen Geo-TIFF mit diesen 2-Color-Image-Kanälen.

Dann machen wir wieder eine Validierung auf diesem. Und ich kriege immer noch die Meldung, dass das größer als 512 x 512 ist. Und dass es interne Oberfus beinhalten sollte. So und jetzt kommt mein Lieblingsbefehl, G-DAL-EDO, der erzeugt diese Oberfus.

Ich führe das auch gleich mal aus. Geht jetzt in dem Fall relativ schnell. Und dann validieren wir es wieder. Und dann sehen wir, also die Oberfus, die sind hier unten. Die sind jetzt im Datensatz drin. Und was noch fehlt, ist die Aufbereitung dieser Image-File-Struktur.

Also im Header. Gehen wir runter. Das mache ich dann mit einem dritten Schritt. Dann fände ich nun mal G-DAL Translate an. Und das Entscheidende bei G-DAL Translate ist, in dem Fall, dass hier dieses Copy Source Oberfus gleich Yes aktiviert ist.

Das ist ein neues Feature von G-DAL, was praktisch diesen Header dementsprechend aufbaut. Machen wir mal schnell definieren.

So. Validieren wir es nochmal. Und sehen jetzt hier unten das Ergebnis. Ist er Valid Cloud Optimized GeoTIF. Das heißt, mit diesen paar Arbeitsschritten kann man die Daten jetzt aufbereiten.

Das müssten natürlich jetzt wir auch machen und alle, die so Daten nach wieviel vorhalten. Diese Daten damit dementsprechend aufzubereiten. Und jetzt auch nicht bloß die Subdata Sets mit dem True Color Image, sondern alle Subdata Sets, um die dann dem Nutzer zur Verfügung zu stellen. Das macht ja zum Beispiel Amazon und Google mit ihren Daten, wo die ja so eine Aufbereitung vornehmen.

Die machen das nicht unbedingt in einem Cloud Optimized Format, aber die wandeln das alles nach GeoTIF um. Und eigentlich wollte ich jetzt, aber dafür ist die Zeit ein bisschen fortgeschritten. Und deswegen will ich bloß ganz kurz sagen, das Problem bei dem Ganzen ist, das geht alleddo. Das geht alleddo funktioniert nämlich gut jetzt für diese Fernerkundungsdaten, wenn es kleinere Bereiche sind.

Wir haben aber manchmal auch größere Datensätze. Zum Beispiel haben wir von dem Institut für Radartechnik so eine Waldkarte, die auf Terra Satandem-Daten mir ruht mit einer Bodenauflösung von 50 Meter für die ganze Welt. Das ist dann so groß, dass wenn ich da geht alleddo drauf loslasse, dass das tagelang rechnet. Und der fährt immer so einen Punkt. Ich weiß nicht, was fünf Stunden mehr kommt oder so.

Ich weiß nicht, wer sowas schon mal machen musste. Das ist kein Spaß. Vor allem, wenn dann die Verbindung abbricht und man das aus Versehen nicht in einem Screen gemacht hat. Also generell ist das alles schwierig. Und deswegen wollte ich noch so einen Weg vorstellen, wie man mit geht alleddo effizienter, also teils berechnet.

Und das beruht eigentlich nur auf dem Prinzip Teile und Herrsche. Man zerlegt das große Bild in kleinere Teils oder auch in größere. Also 10 x 10 Grad Kacheln, zum Beispiel, die ganze Welt sind da optimal. Dem berechnet man diese externen Oberfüße für die Teils.

Leider sind diese externen Oberfüße nicht georeferenziert. Deswegen muss ich dann noch die Georeferenzierung von meinem ursprünglichen TIFF auf dieses Oberfühl übertragen und dabei berücksichtigen, dass sich ja die Auflösung reduziert hat. Das geht aber relativ einfach. Und dann berechne ich praktisch für jedes meiner Teils die Oberfüße und am Schluss musikiere ich dann diese Oberfüße,

die größer sind, wieder und komme damit viel schneller zum Ergebnis. Also da reduziert sich dann die Zeit von drei, vier Tagen auf fünf Stunden vielleicht oder so. Und das macht natürlich auch was aus, wenn man so Sachen entwickelt. Das wollte ich kurz in einem Detail vorstellen. Dafür reicht jetzt die Zeit leider nicht mehr. Das hätte ich wahrscheinlich auch vorher denken können.

Und deswegen gehe ich, glaube ich, hier nochmal zurück zu dem ursprünglichen Gedanken mit diesen Cloud Optimized Geo TIFF und der Zerfügungstellung mit Amazon. Das ist natürlich eine schöne Sache, wenn so eine Cloud Provider das machen.

Und das haben die natürlich auch so Datenanbieter wie der ESA oder auch sogar Code.de voraus. Und wir sind auch oft mit dem Anwurf konfrontiert worden. Das gibt es doch alles bei Amazon. Das ist nämlich inzwischen auch nicht mehr so, dass es alles bei Amazon gibt,

weil die haben nämlich jetzt, also es sind nicht scheiß, macht das ja. Da gibt es jetzt zum Beispiel dieses Sentinel-2-Level-1-C-Lehr, was bis jetzt frei war seit einem halben Jahr. Bloß mal so ein Request per Pay oder Pay per Request-Buget, wo man dann für jeden Zugriff auch dementsprechend abkassiert wird. Und deswegen ist so, und das passt meiner Ansicht nach ganz gut zu dem Thema,

so als Schlusswort für alle, die hier anwesend sind oder das irgendwo hören, dass man durchaus auch Rückmeldung und Feedback sowohl bei der ESA als auch bei den deutschen Betreibern, das ist in Deutschland zum Beispiel das Verkehrsministerium, die so Sachen bezuschussen, weil das gehört ja zur digitalen Infrastruktur, dass sowas tatsächlich eine Infrastrukturaufgabe ist

und eigentlich nicht privaten Betreibern belassen werden sollte, weil wenn man das privaten Betreibern belässt, wie das jetzt zum Beispiel bei Amazon und Google ist, dann füttern die halt meiner Ansicht nach an und irgendwann zahlt man dann sehr viel für Daten,

die eigentlich frei zur Verfügung stehen. Und das zeigt auch diese, vor ein paar Jahren hat es gereist, wir brauchen freie Software, die haben wir jetzt zur Genüge. Dann hat es gereist, wir brauchen freie Daten, Bildung und so weiter. Die ESA erschlägt uns mit freien Daten. Was wir jetzt bräuchten ist sowas wie eine freie Infrastruktur, wo man diese Daten auch herbeziehen kann,

freie Cloud, damit man nicht abhängig ist von Organisationen, die irgendwann entweder den Geld haben oder den Informationshandel zudrehen und die Gefahr ist natürlich bei sowas sehr stark gegeben. Das wollte ich nur kurz noch mal ansprechen, weil das eigentlich sehr gut dazu passt zu diesem Thema

mit Cloud-Optimierung, weil diese Cloud-Optimierung betrifft im Augenblick hauptsächlich zwei, drei Anbieter. Und wenn man diese Skripte anschaut und auch geht es an Info, ich habe es mit der Open Telekom Cloud versucht, da funktionieren die zum Beispiel schon nicht, weil die ein bisschen ein anderes Autorisierungsmechanismus haben als Amazon.

Also soviel die Schlussworte. Auf alle Fälle ist das Cloud-Optimized Geotiff eine sehr gute Möglichkeit, um die unterschiedlichsten Daten zusammenzubringen in einem Geotiff-Format und dann halt performant über eine Cloud-Struktur anzuziehen. Was dann natürlich auch sowas wie das Interplanetäre File System oder DAT oder sowas sein kann.

So, dann danke ich Ihnen für die Aufmerksamkeit und wenn Sie Fragen haben. Ja, vielen Dank Christian. Ich kann das mit der ESA bestätigen.

Also die bieten wirklich unglaublich viele Services an und die kriegen aber praktisch nie Rückmeldungen. Und das ist denen ganz wichtig. Also da möchte ich mich nochmal an diesen Appell anschließen. Gibt es Fragen an Christian?

Danke für den Vortrag, fand ich sehr gut. Ich habe eine sehr technische Frage. Wenn jetzt ein Softwareprojekt diese Cloud-Optimized Geotiffs unterstützen möchte, muss es dann noch irgendetwas dafür implementieren? Ich meine Kugel ist auch einfach. Es ist ja das gleiche Dateiformativ. Kann man das einfach einladen und dann gleich die Vorteile nutzen?

Ich zeige es mir schnell, das habe ich vergessen. Also im Augenblick ist das, was ich herausgefunden habe, es hängt eigentlich an Gedall. Und da ja fast jede Software Gedall treiber benutzt, Kugel ist auch, ist man natürlich dann sehr schnell. Also ich gehe jetzt hier mal so schnell rein und raus. Hoppla, zum Tulea.

Also ich mache es jetzt mal konzentrierter. Ich komme jetzt hier bis auf die Bodenauflösung, ohne dass ich irgendeine Verzögerung habe. Weil immer wieder ein anderes Oberfue benutzt wird und Kugel unterstützt das voll. Okay, also wenn eine Software im Hintergrund Gedall verwendet, dann kann man schon davon profitieren? Genau, dann profitiert man automatisch davon. Wenn nicht, muss die Software dafür Sorge tragen, dass sie selber dieses Cloud-Optimized Geotiff dementsprechend umsetzt.

Und wenn ich zum Beispiel was mit Python mache, ich habe hier mal ein Beispiel am Schluss. Da kann ich mir natürlich auch jedes von diesen Overfus, die kann ich auch externe erzeugen.

Das muss ich dann machen, wenn ich es muss. Dann kann ich natürlich auch diese externe Overfus benutzen, mir so eine eigene Logik zu machen. Also hier habe ich die optimale Auflösung, hier habe ich die schlechteste Auflösung. Und ich habe dann wirklich sehr viele Möglichkeiten. Und es wird zwar empfohlen, diese Overfus intern zu erhalten, weil das natürlich dann nur eine Datei ist.

Aber man hat durchaus einen Vorteil, wenn man die extern hält, weil Gedall erkennt, das macht keinen Unterschied. Ob intern und extern und Performance-Messungen, die ich so ein bisschen gemacht habe, haben mir jetzt auch keinen großen Unterschied hier gegeben. Aber ich habe die Möglichkeit dann wirklich jedes Overfue ohne Mühe anzusprechen und kann mir immer das Praktische holen. Ich kann hier auch innerhalb von ein paar Sekunden mit einem ...

Wo ist das? Nein, das ist falsch. Ach, das habe ich jetzt gar nicht offen. Ich kann auch innerhalb von ein paar Sekunden hier mit einem Overfue das Ganze visualisieren,

indem ich hier das sechste oder siebte Overfue hernehme. Während wenn ich deshalb mit dem ganzen Datensatz machen würde, würde der der Stunde brauchen, bis er die Daten überhaupt ändert. Auf die Weise habe ich sowieso viele Vorteile und das macht eigentlich jeder, der mit diesen Rasterdaten arbeitet, eigentlich schon immer. Insofern ist es auch nicht der große Wechsel, aber wenn es alle benutzen würden, wäre es sehr bequem.

Ich merke auf jeden Fall, dass das Beispiel mit dem GeoTip jetzt schon ein bisschen Schule macht. Es gibt ja mittlerweile auch schon Cloud-optimized GeoJSON, ich glaube auch Cloud-optimized VectorTiles. Also das scheint jetzt gerade so ein bisschen um sich zu greifen.

Arbeitet ihr mit den Formaten oder beschränkt ihr euch hauptsächlich auf Rasterdaten? Mit GeoJSON. Ja, eine Cloud-optimized GeoJSON. Also ich persönlich weniger, aber die Leute, die das sind hauptsächlich die kleinen Entwickler, die mit GeoJSON viel hin und her machen, die machen das natürlich auch.

Eine Frage noch. Ja, ich wollte fragen, wie sieht es denn aus mit der Dateigröße, wenn man das so gearbeitet hat gegenüber den Ursprungsdaten? Ja, da bin ich jetzt nicht drauf eingegangen. Man kann ja auch verschiedene Kompressionsmethoden hernehmen. Allgemein würde ich dieser Deflate-Algorithmus empfohlen,

den ich auch noch unterschiedlich scharf schalten oder unterschiedlich hart einstellen kann. Und deswegen ist die Frage praktisch schwer zu beantworten. Also das kommt sehr drauf an, wie sehr ich das halt komprimiere.

Aber das ist ja jetzt eigentlich eine Maske. Also da sind jetzt bloß vier Werte drin. Und da bringt immer sehr viel, wenn ich diesen Greshen-Option von Gedal benutzt, wo ich die Bit-Tiefe tatsächlich angeben kann. Also wenn ich eine schwarz-weiß-Maske nur habe, dann mache ich n bits gleich 1, also 2 hoch 1.

Hier habe ich jetzt 2 hoch 2, also n bits gleich 2 gemacht. Und allein das reduziert dann die Dateikröße um ein Faktor 4,5 oder so. Also ohne Kompression. Also man kann sowohl mit der Farbtiefe als auch mit dem Kompressionsalgorithmus da wahnsinnig viel erreichen.

Aber man kann es nicht als Faustregel sagen. Also bei Fernerkundungsdaten, wo ich natürlich eine viel größere Bandbreite habe an Werten, kann ich natürlich nicht die Farbtiefe einschränken und habe Integer-Datentyp.

Da wird das nicht viel bringen. Ja, Christian, vielen Dank. Mir fallen da gleich Anwendungsmöglichkeiten von meiner eigenen Arbeit ein. Also echt super. Vielen Dank für die Einführung in, glaube ich, optimierte Geotips. Danke.