We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

COPC, das neue cloudoptimierte Format für Point Clouds

00:00

Formal Metadata

Title
COPC, das neue cloudoptimierte Format für Point Clouds
Title of Series
Number of Parts
107
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Neben dem bereits etablierten Format COG für Cloud-optimized GeoTIFFs finden cloudoptimierte Formate auch für andere Anwendungen immer mehr Interesse. Für Point Cloud Daten existiert das COPC Format (https://copc.io/), welches auf dem bewährten offenen LASzip Format für verlustfrei komprimierte LIDAR-Daten aufbaut. Wie COGs sind die Daten rückwärtskompatibel, was die Implementation stark vereinfacht und die Adaption fördert.
Keywords
File formatVector graphicsPoint cloudSoftware developerService (economics)NumberOpen setLinieMetadataGoogle EarthBinary fileLaserGeometryWeb browserSoftwareServer (computing)DesktopIndexPoint cloudSmart cardOpen sourceAsset <Informatik>WEBPhysical quantityComponent-based software engineeringHTTP cookieGIPSY <Programm>Vector graphicsScripting languageZugriffLimitierungsverfahrenSATAN <Programm>Quest <Programm>Version <Informatik>TiefeLevel (video gaming)Lecture/Conference
Beat (acoustics)WEBIndexData storage deviceSQLiteFile formatSystems <München>ORACLSJSON
HTMLLevel (video gaming)InformationMetadataScheibeProviderHTTP cookieIndexGraphics tabletFunktionalitätTor <Netzwerk>Computer fileGrand Unified TheorySoftwareC++Route of administrationBlock (periodic table)Structural loadMetrePhysical quantityBitJSONComputer animation
Demo (music)File viewerComputer animation
Computer animation
5 (number)
Autoregressive conditional heteroskedasticityDemosceneComputer animationLecture/Conference
WEBWeb browserDownloadComputer fileBitMP3SoftwarePoint cloudOnline chatService (economics)File viewerRoute of administrationDisk read-and-write headDirection (geometry)Version <Informatik>JavaScriptRow (database)SpeciesInformationMilitary rankSequenceSimulationFile formatPlug-in (computing)LengthDepictionHausdorff spaceMobile appMetadataÖko <Programm>Computer animation
Transcript: German(auto-generated)
Dann herzlich willkommen zu dieser Nachmittags-Session am 2. Vosges-Tag mit spannenden Vorträgen. Einmal geht es um cloud-optimierte Formate. Hat da schon mal jemand mit zu tun gehabt?
Hand hoch, ärgern wir mal die Online-Leute ein bisschen, dass sie das nicht sehen. Aber ich würde jetzt mal sagen, für die Online-Leute ein Viertel hat damit schon mal zu tun gehabt. Also ihr habt schon mal euch mit riesen Datenmengen beschäftigen müssen im Browser oder in anderen Tools. Okay, und dann zum Schluss haben wir noch einen Vortrag über Datenportalzugriff über Kugis.
So, als Erster ist jetzt hier Permian. Eigentlich solange ich auf der Vosges bin, war Permian immer damit im Vortrag. Eigentlich auch immer ziemlich cutting-edge, muss ich sagen. Immer an den neuesten Technologien. Und ich freue mich jetzt, dass er etwas über cloud-optimierte Punktwolken erzählen wird.
Dankeschön Felix. Ich erzähle etwas über dieses neue Format COPC, das sich eben für Pointclouds eignet. COPC ist schon, man kann es auf verschiedene Arten aussprechen. Und das ist eine der offiziell unterstützten Arten, wie man das aussprechen darf.
Es gibt eine ganze Liste, wie man das sagen kann. Ich arbeite für SourcePool. Wir sind eine Softwareentwicklungsfirma in Zürich. Wir machen WebGIS, Kugis WebClient 2 und Kugis auf dem Desktop, Kugis Server und weitere Softwareentwicklungen im Open Source-Geo-Bereich.
Pointcloud-Formate gibt es schon viele. Sehr viele sogar. Es gibt ASCII-basierte Formate XYZ, wirklich ganz simpel. Drei Spalten, drei Zahlen. Und das OBJ-Format, auch sehr verbreitet. Da gibt es diverse binäre Formate, PLY, E57 und LAS.
Das kennt man vielleicht am besten. Das ist eigentlich auch so ein normiertes Format. Und davon gibt es eine komprimierte Version, das LAS-ZIP, LAS, das eigentlich ein sehr gutes komprimiertes Format ist und halt offene Spezifikation ist und Open Source-Implementation davon gibt.
Die Frage ist jetzt, wieso brauchen wir noch ein weiteres Format? Und da hole ich jetzt etwas aus. Wieso überhaupt cloud-optimierte Formate? Also jetzt gerade bei großen Datenmengen, sei es das Luftbilder, Satellitenbilder oder eben Punktwolkendaten, funktioniert der klassische Desktop-GIS-Ansatz eigentlich nicht mehr.
Das heißt, ich hole alle Daten auf den Desktop, verarbeite sie und das Resultat publiziere ich irgendwo wieder. Sondern ich muss direkt mit dem Daten arbeiten. Jetzt kann ich entweder quasi meine Prozessierung zu den Daten verlegen in die Cloud, wo die häufig liegen
oder eben ich mache ein Format, das ich übers Netz effizient lesen kann. Und im cloud-optimierten Format haben wir genau dieses Ziel, dass ich auf große Datenmengen über HTTP-Protokoll, also als Webzugriff effizient zugreifen kann.
Das heißt, ich muss nicht das ganze File lesen, sondern ich kann Ausschnitte lesen und das geht über diesen HTTP-Range-Request, den gibt es schon lange und der wird auch gut unterstützt und wenn ich eine gute Anordnung von den Daten habe, dann kann ich auch effizient Teile davon lesen.
Und weiter ist der große Vorteil, ich brauche keinen spezifischen Service mehr, also ich brauche nicht einen WMS-Service, um Geotiffs zu publizieren, sage ich jetzt mal, oder eben Rasterbilder zu publizieren, sondern ich kann direkt aus einem cloud-optimized Geotiff mein Bild extrahieren,
ohne dass ich einen Server brauche. Ich brauche wirklich nur einen Web-Server, das ich HTTP machen kann. Bei point cloud ist das zum Beispiel Entwine, das ich als Server-Komponente habe und das ich jetzt eben vermeiden will. Der Vorteil ist auch, die Tendenz ging dann zum Beispiel zu Google Earth Engine,
die haben ein gutes Angebot, wir haben hier alle Daten und Prozessierungsfunktionalität, ihr könnt jetzt eure Prozessierungs-Skripte schreiben, aber ich bin dann in dieser Earth Engine drin und muss dann vielleicht exportieren oder eben ich kann nur das machen, was der Wender mir zulässt
und wenn ich eben ein cloud-optimiertes, offenes Format habe, kann ich die bei irgendeinem cloud-Provider lagern und kann die Prozessierung irgendwo anders machen oder wo ich will. Eine Limitierung, die man schon beachten muss, wenn ich jetzt so ein cloud-optimiertes Format habe, das ist in erster Linie optimiert fürs Lesen.
Das heisst, wenn ich jetzt Teile bearbeiten will, geht das jetzt häufig nicht, dann kommen dann wieder Service, spezielle Services ins Spiel, das geht nicht einfach über HTTP, das ist eigentlich in erster Linie fürs Lesen. Und es gibt bereits diverse cloud-optimierte Formate, das erste bekannte ist das cloud-optimale Geotiff,
das hat Geotiff erweitert, also Geotiff hat schon einiges, es hat zum Beispiel Kacheln, das unterstützt Overviews und da hat man gemerkt, man muss gar nicht mehr viel machen, dass es gut funktioniert über HTTP, man hat die Metadaten sortiert und hat eine Vorgabe gemacht,
wie dann eben diese Kacheln und Overviews im File angeordnet werden müssen und da das Geotiff oder das T-Format so flexibel ist, gab das gar keine Änderung am Geotiff-Format selbst, sondern es war nur eine Vorgabe, wie man die Sachen organisieren soll, die Daten intern. Und das hat den enormen Vorteil, jede Software, die Geotiff lesen kann, kann auch cloud-optimized Geotiff lesen
und spezialisierte Software kann dann halt wirklich diese cloud-optimized Versionen oder Zusatzinfos auswerten und dann optimiert nur Teile eines großen Tiffs anzuzeigen.
Das ist für Astro-Daten, für Vektordaten ist FlightGeoBuff, denke ich das bekannteste, weil da gab es eigentlich gar nichts und da hat man ein neues Format erfunden, dieses FlightGeoBuff, das enthält Metadaten mit einem R3-Index
und die Vektordaten sind dann auch sortiert, das bringt da noch viel, weil es ist wichtig, dass das örtlich nahe Features auch datenmäßig nahe beieinander sind, dass sie nicht irgendwo immer im Pfeil hin und her springen muss,
sondern dass ich wirklich große Chancen habe, dass es gerade in der Nähe ist und ich vielleicht mit einem großen Hardhead-Perquest gerade mehrere Geometrien lesen kann. Passiert auf Google Flight Buffers, das hat einige gute Eigenschaften, ist jetzt in Diskussion um ein OGC-Community-Standard zu werden,
aber ist bereits anwendbar und gut unterstützt. Dann gibt es auch optimierte Kachel-Archive, das denke ich der bekannteste oder am besten unterstützte ist das PMTiles, das definiert ein Format, wie kann ich Raster- oder Vektorkacheln
in einem Pfeil speichern. Man kennt die Speicherung, dass alle Teile separat sind, dann habe ich einfach sehr viele Pfeils, die sind zum Teil sehr mühsam zu handhaben, oder dann gibt es MB-Teils, wo das Ganze an einem SQLite gespeichert wird,
oder ich könnte auch Geopackage nehmen, aber da ist eine SQLite-Datenbank und die ist nicht gut zu lesen über das Web. Das heisst, die ist eigentlich sehr gut für das File-System, aber nicht für Netzwerk-File-Systeme und nicht für Web.
Und deshalb gibt es hier auch neue Formate dieses PMTiles, das diese Kacheln sinnvoll anordnet und einen guten Index macht. Und da gibt es auch bereits Unterstützung, in Open-Layers ist es drin und in Map Libre wird es unterstützt. Das heisst, es gibt schon Viewer, die das direkt darstellen können.
Hier noch weitere, die ersten zwei habe ich schon aufgelistet. Geopackage ist sehr im Gespräch, als für spaltenorientierte Daten, für NRE-Daten, Zar gibt es nachher einen Vortrag darüber.
PMTiles kommt auch im Vortrag nachher noch. Und was ganz neu ist, ist noch dieses SOZIP von Ivan Ruo, der hat ein ZIP-File so ein bisschen noch weiter definiert, dass man, wenn man die Files richtig sortiert
und noch ein Index oder noch zusätzliche Informationen reinpackt, dass man dann ein ZIP-File sehr effizient über das Netz lesen kann. Ich weiss noch nicht, was das für praktische Anwendungen bringen wird, also er hat schon Geopackages verpackt und gute Resultate erhalten,
aber ich kann mir vorstellen, dass es da wirklich noch ganz interessante Anwendungen davon gibt. Aber eben jetzt kommen wir zu den Point Clouds und die Spannung ist wahrscheinlich nicht so gross, weil meine Antwort ist COPC, das ist dieses Cloud Optimized Point Cloud und COPC.io ist die Spezifikation.
Das ist eine Last-ZIP-Erweiterung, das heisst, es nimmt das bestehende LAZ-File und macht Vorgaben, wie die Daten da drin sortiert werden müssen. Das ist analog zu EBT, das ist auch ein verbreitetes Format,
um grosse Point Clouds abzulegen. Da ist es so, dass es die aber aus vielen Files besteht und dann so JSON-Metadaten auf diese Point Cloud Blöcke verweist. Und hier ist eigentlich die gleiche Struktur ins Last-ZIP integriert worden.
Es gibt aber die Unterscheidung, man kann es wie bei EBT in mehrere Files aufteilen oder man kann ein grosses File schreiben und dann halt verschiedene Stufen aus diesem Oct-Tree abgelegt sind.
Und dann sind zusätzliche Metadaten in diesem Last-ZIP-Header drin und das hat wieder eigentlich dieses wichtige Kriterium erfüllt, nämlich, dass alle Reader, die LAZ lesen können, und das sind recht viele, die können dieses COPC schon mal lesen
und damit arbeiten und wenn noch diese zusätzliche Information verarbeitet wird, erlaubt es aber das effiziente Arbeiten über HTTP für grosse Dateien. Und das ist es eigentlich schon, ich habe jetzt weit ausgeholt, könnte es noch in die Bits und Bytes gehen,
aber das ist eigentlich nicht so wichtig, denke ich. Womit kann ich jetzt solche Files schreiben oder womit kann ich sie lesen? Die Softwareunterstützung gibt es eine Seite dazu. Pedal, denke ich recht verbreitete Bibliothek,
wo man so ganze Point-Cloud-Prozessierungen machen kann, also man kann so einen JSON deklarieren und dann ein Workflow und Pedal arbeitet das ab und das hat ein COPC-Driver gekriegt, um COPC lesen und schreiben zu können.
Dann gibt es für verschiedene Sprachenimplementierungen, also für Python gibt es jetzt LastPy, es gibt C++-Implementierung und eine Rast-Implementierung, die aber noch nicht vollständig ist. Und dann, das ist jetzt neu, gibt es halt eine JavaScript-Implementierung, also ich kann COPC.js, das mir erlaubt,
ein COPC-File übers Netz, also jetzt hier mal die Metadaten mindestens auszulesen und dann lese ich dann die verschiedenen Blöcke dazu. In Kugis ist das auch recht schnell eingeflossen.
Also ich kann bereits jetzt, also mit der aktuellen Kugis-Version, COPC lesen, also da gibt es eine, da ist die C++-Bibliothek, die ich jetzt hier nicht aufgelistet habe, die wird in Kugis integriert, um Point-Cloud-Daten zu lesen.
Also man kann diese Daten hier bereits anschauen. Das war jetzt quasi das Anschauen, Erstellen ist eben Pedal, wahrscheinlich das verbreiteste Tool und das, wenn ich jetzt ein Last-File habe, zum Beispiel, und ein COPC-File schreiben will, dann ist das diese Pipeline mit diesen zwei Schritten.
Also ich lese das Last und schreibe das COPC.laz, also so die Namenskonvention. Dann gibt es eine zweite Implementation in C++, die eigentlich spezialisiert ist auf COPC, das heisst Antwine, also mit U.
Die hat jetzt nicht alle die Verarbeitungsfunktionalität von Pedal, aber einfach schreiben und diese Konvertierungsfunktionalität ist da dann eher ein bisschen einfacher. Genau das war es jetzt eigentlich schon. Jetzt versuche ich das zu zeigen.
Und zwar das ist so ein Demo-Viewer, ein Globe, wo man verschiedene Point-Cloud-Daten anschauen kann. Das ist gerade so das erste Beispiel.
Also in der Viewer ist es generisch einfach UR-COPC und ich kann hier das LAZ oder das COPC als die URL anhängen. Das ist hier etwas, das auf Amazon ist, das flimmert ein bisschen. Das ist auch nichts.
Jetzt weiß ich natürlich nicht, ist das F11 oder so.
Ich würde jetzt gerne noch den Netzwerkinspektor zeigen. Oh nein, F11 Fullscreen. Ich weiß.
Ich glaube, ich muss meine Demo abbrechen. Es kann sein, dass das WebGL im Browser nutzt. Dass das WebGL mit dem Projektor irgendwie Schwierigkeiten macht,
ist jetzt meine Erklärung. Also was ich da zeigen wollte, ich kann wirklich, es ist eine große Sammlung, es ist ein Katalog dahinter mit Punkt-Cloud-Wolken. Also USGS hat gerade eine riesige Datensammlung angelegt und da kann ich Hunderte von Datensätzen auswählen und die anschauen.
Und eben das Spezielle daran ist, die liegen einfach als große Dateien irgendwo bei Amazon und ohne zusätzliche Software kann ich die in Viewer effizient anschauen. Das ist eigentlich der große Schritt, dass ich das irgendwo einbetten kann ohne zusätzliche Server-Software und einfach auf der JavaScript-Seite muss ich dieses Point-Cloud-Format verstehen.
Ja, ich hätte jetzt ein bisschen länger demonstriert, aber jetzt werde ich halt früher fertig sein, das ist das, was ich noch sagen kann. Morgen gibt es noch ein Community-Treffen zu einem verwandten Thema, zu 3D-Tiles um 11 Uhr. Und das Bild da, also in 3D-Tiles gibt es auch Point-Cloud-Unterstützung,
aber eben es geht im Allgemeinen überhaupt so um 3D-Darstellung im Web, wo ja dieses Copsy-Format jetzt ein neuer Ansatz ist oder ein neues Format ist. Und 3D-Tiles, die ja jetzt gerade in der neuen Version wieder zum Community-Standard wurden,
da geht es ja noch um alle anderen Arten von 3D-Objekten, die man damit darstellen kann. Gut, ja, dann schließe ich mit dem und danke fürs Interesse.
Jetzt? Ja, okay. Gibt es Fragen von eurer Seite an Pärmin? Ich habe jetzt hier im Chat, glaube ich, keine gesehen.
Ja, vielen Dank für den Vortrag. Ich hätte eine Frage zu dem Range-Request. Der würde mich interessieren, was da möglich ist, was ich da übergeben muss und was zurückkommt. Also, im HTTP-Request kann ich einen Range-Header setzen
und da kann ich sagen, ich will von 0 bis 2000 lesen. Also ich habe einen von bis Range. Gibt es ein paar Feinheiten noch, ob ich quasi, ich glaube ich kann auch sagen von 1000 und gib mir 2000 Bites oder so, aber es geht einfach darum, ich kann sagen von bis, gib mir einen Ausschnitt aus einer Datei.
Das ist auch interessant, wenn ich eine große MP3 habe, dann kann ich quasi das auch streamend lesen. Also ich kann immer wieder Stücke von diesem MP3 lesen und das abspielen. Und den gibt es schon seit Jahrzehnten, diesen HTTP-Range-Request.
Und gibt es auch so etwas wie ein Get-Capabilities, wo ich mir auch mal Meta-Informationen vorher dann holen kann von so einem File? Nein, das gibt es hier jetzt in dem Sie nicht, weil eben es gibt keinen Service, oder? Es gibt einfach dieses File, das heißt, ich habe jetzt hier dieses CopsyJS, also diese Bibliothek, die sagt man jetzt, ich lese den Header und gebe dir in JavaScript die Informationen zu dieser Datei zurück.
Aber es gibt keinen offiziellen Service dafür, sondern man muss sich halt die Meta-Daten aus dem File rauslesen.
Vielen Dank, Per-Man, immer wieder sehr spannend, was sich so bewegt im Cloud-Bereich. Ich habe mich gefragt, weil du ja auch gesagt hast, diese HTTP-Range ist ja schon lange da. Also vielleicht eine bisschen schwierige Frage, weil es keine technische Frage ist,
sondern eher so eine organisatorische Ökosystemfrage, wie wir in deiner Einschätzung, warum haben wir jetzt erst so in den letzten Jahren so die Bewegung Richtung dieser Cloud-Formate, weil technisch hätte das doch schon früher kommen können, oder? Das stimmt, ich weiß auch nicht, wieso man das nicht früher entdeckt hat. Es kam jetzt wirklich dadurch, dass die Dateien eben größer wurden
und quasi der Leidensdruck wurde immer größer. Und dann hat ihr jemand mal gemerkt, ja, da gibt es ja schon lange was und hat ihm einen schönen Namen gegeben, wie das im Cloud optimisiert. Also ich glaube eben diese, soll ich sagen, die ersten Applikationen, die es gab, waren eigentlich diese, wie heißen sie genau, diese Loader,
oder quasi, dass man eine Datei dann den Rest laden kann, also wenn etwas abbricht und ich kann dann weiter lesen, also wenn ich große Dateien, die Downloader sind es eigentlich so, diese Downloader-Plugins oder Downloader-Apps, die nutzen diesen Rancher-Quest schon immer, aber in der Gießwelt hat die niemand recht früher entdeckt.
Ok, weitere Fragen? Ich habe sonst auch noch eine. Weil mir bewusst ist, im Automotive wird ja auch super viel mit Punktwolken gemacht. Ob die auch schon dieses Format nutzen oder haben die ihre eigenen proprietären Formate? Wie sieht so die Akzeptanz in der Industrie aus für dieses Copsy-PC?
In der Hinsicht wahrscheinlich nicht so gut, weil alle diese spezialisierten Applikationen haben eigentlich ihr eigenes Format definiert und unterstützen maximal noch ein weiteres und Copsy gibt es jetzt eigentlich seit maximal ein halbes Jahr, habe ich so das Gefühl,
also das wird noch nicht so breit unterstützt, aber das wirklich ein einfaches und gutes Format ist, glaube ich, wird die Unterstützung kommen. Ok, danke.
Noch weitere Fragen? Ich kann auch mal ganz kurz im Chat gucken hier. Hier sehe ich keine Fragen. Im Chat sehe ich nur Links zur Anwendung. Ah ja, Range, HTTP, Links hier, ok.
Also wenn keine weiteren Fragen sind, dann danke, Benjamin. Und wir schauen uns dann gleich das Saar-Format an im nächsten Vortrag.