XYZ-Punktwolke: Was sie ist und wie man sie nutzt

Zusammenfassung

Eine XYZ-Punktwolke ist eine einfache ASCII-Textdatei, die Punktkoordinaten als X-, Y- und Z-Spalten speichert, üblicherweise einen Punkt pro Zeile. Sie wird häufig für schnellen Austausch, Prüfung, Skripting und schlanken Export verwendet, weil die Struktur in einem Texteditor leicht lesbar ist. Der Haken ist, dass XYZ-Punktwolke eine Konvention und keine einzelne formale Austausch-Spezifikation ist. [1] [2]

Diese Mehrdeutigkeit ist das Hauptrisiko. Eine Datei mit dem Namen .xyz, .csv oder .txt kann reine Koordinaten, zusätzliche Attribute, eine ASCII-Tabelle mit Kopfzeile oder ein völlig anderes Format enthalten. Was üblicherweise fehlt, ist ebenso wichtig: Einheiten, Koordinatensystem, CRS- oder EPSG-Code, Datum sowie die Bedeutung von Spalten über X/Y/Z hinaus fehlen oft, sofern sie nicht bereits aus dem Kontext bekannt sind. Dieser Leitfaden konzentriert sich auf einen sicheren Arbeitsablauf: erst prüfen, dann öffnen, konvertieren und mit Blick auf die tatsächliche Dateistruktur Fehler beheben. [1] [2]

Eine unbekannte .xyz sicher prüfen (vor dem Import)

Allein eine .xyz-Erweiterung reicht nicht für einen sicheren Import aus. Die Library of Congress weist darauf hin, dass XYZ-Punktwolkendateien xyz, csv oder txt verwenden können, und auch FME behandelt diese Erweiterungen als konventionell statt obligatorisch. Eine Textdatei mit einem dieser Namen könnte eine reine Punktliste, eine softwarespezifische ASCII-Tabelle oder etwas sein, das nichts mit Punktwolken zu tun hat. Der sicherste erste Schritt besteht darin, den Inhalt als Klartext zu prüfen, bevor die Datei in einen beliebigen Importer geladen wird. [1] [2]

Gesucht wird ein Muster, nicht nur die Erweiterung. Wenn Zeile 1 eine Atomanzahl und Zeile 2 einen Titel oder Kommentar enthält, handelt es sich um chemisches XYZ und nicht um eine Punktwolken-XYZ-Datei. Wenn Zeile 1 eine ganzzahlige Anzahl ist, gefolgt von Punktzeilen, könnte die Datei PTS-ähnlich statt reines XYZ sein. Prüfen Sie außerdem, ob die Datei Leerzeichen, Tabs oder Kommas als Trennzeichen verwendet, ob es eine Kopfzeile mit Spaltennamen gibt und ob die Anzahl der Felder von Zeile zu Zeile gleich bleibt. [15] [4]

Nutzen Sie diese Schnellprüfung vor jedem unbekannten Importversuch:

• Öffnen Sie die ersten 5 Zeilen als Klartext.
• Zählen Sie die Spalten in einigen Datenzeilen.
• Bestimmen Sie das Trennzeichen.
• Unterscheiden Sie Kopfzeile und Daten.
• Erkennen Sie eine Atomanzahlzeile und Kommentar-/Titelzeile eines chemischen XYZ. [15]
• Erkennen Sie eine Punktanzahlzeile, die auf eine PTS-ähnliche Datei statt auf eine reine XYZ-Punktliste hinweist. [4]
• Bestätigen Sie das Dezimaltrennzeichen vor dem Import.

Was ist eine XYZ-Punktwolke?

Auf Ebene der XYZ-Konvention ist eine XYZ-Punktwolke eine einfache ASCII-Textdatei, bei der jede Zeile einen Punkt und jede Spalte eine Punktkomponente darstellt, üblicherweise X, Y und Z. In der Praxis bedeutet das einen Punkt pro Zeile, geschrieben als durch Trennzeichen getrennte numerische Felder. FME beschreibt das Modell direkt: Jede Zeile ist ein Punkt und jede Spalte eine Punktkomponente. Der Eintrag der Library of Congress unterstreicht, wie schlank das Format ist, indem er Dokumentation als keine und Selbstdokumentation als keine aufführt. [1] [2]

Zusätzliche Spalten können vorkommen, erklären sich aber nicht automatisch. Ein viertes Feld könnte Intensität, Klassifizierung, Rot, eine Normalkomponente oder etwas Importerspezifisches sein. Eine Kopfzeile kann helfen, aber viele XYZ-Dateien haben keine. [1] [2]

Was XYZ üblicherweise nicht speichert:

• Einheiten oder Maßstab
• Koordinatensystem oder CRS
• EPSG-Code oder Datum
• Scannerpose oder Registrierungs-Transformationen
• Topologie oder Flächen
• zuverlässige Semantik für Spalten über X, Y und Z hinaus

Das ist wichtig, weil Punktwolken grundlegend unstrukturierte Punktmengen sind, sodass die Bedeutung oft aus dem Dateischema oder externen Notizen stammen muss. Eine einfache XYZ-Datei kann für schnelles Betrachten oder Übertragen ausreichen, trägt aber meist nicht den vollständigen räumlichen Kontext, der für robuste Interoperabilität erforderlich ist. [1] [18]

Das Vorhandensein einer Kopfzeile ist nicht universell. Manche XYZ-Dateien bestehen nur aus einfachen Zeilen, während andere generische ASCII-Tabellen sind, die zufällig X/Y/Z-Spalten enthalten. Kleine Beispiele sehen so aus:

1.0 2.0 3.0

X Y Z

Auf Ebene der XYZ-Konvention kann es beide Varianten geben; ob ein Werkzeug die eine oder andere akzeptiert, ist softwarespezifisch. [1] [2] [3]

Historischer Hintergrund und Formatstatus

XYZ-Punktwolke ist am besten als praktische Textkonvention zu verstehen, die fortbesteht, weil sie transparent und leicht auszutauschen ist, nicht weil eine formale Punktwolken-Spezifikation sie für alle definiert hätte. Die Library of Congress führt XYZ-Punktwolke als Format-ID fdd000617, kennzeichnet den Eintrag als Preliminary und nennt keine formale Dokumentation sowie keine Selbstdokumentation, was zu ihrem Ad-hoc-Status in alltäglichen Arbeitsabläufen passt. Die Dokumentation von Wisconsin erklärt, warum einfaches ASCII attraktiv blieb: Es ist zugänglich und lesbar, auch wenn Text geparst werden muss und Binärdaten direkter gelesen werden können. Spätere Formate wie E57 begegneten den Grenzen des Ad-hoc-Austauschs, indem sie eine dokumentierte Methode zum Speichern von Punktwolken, zugehörigen Bildern und Kernmetadaten bereitstellten, einschließlich Pose-Informationen, damit mehrere Datensätze in einem Koordinatensystem dargestellt werden können. [1] [6] [11]

Wie das XYZ-Dateiformat Punktwolkendaten speichert

Auf Ebene der XYZ-Konvention ist das Speichermodell einfach: durch Trennzeichen getrennter Text. FME beschreibt Point Cloud XYZ als ASCII-Zeilen und -Spalten mit Trennzeichen wie Leerzeichen, Kommas oder Tabs und einer Zeile pro Punkt. [2]

Häufige Spalten, die Sie sehen können:

• X Y Z
• X Y Z R G B
• X Y Z Intensity
• X Y Z Nx Ny Nz
• X Y Z Classification

Die Warnung ist ebenso einfach: Spalte 4 und weitere sind nicht selbsterklärend, sofern nicht eine Kopfzeile, eine begleitende Notiz oder eine werkzeugspezifische Regel ihre Bedeutung angibt. [1] [2] [4] [6]

Konventionen auf Formatebene gegenüber Erwartungen von Importern

Auf Ebene der XYZ-Konvention kann eine minimalistische XYZ-Datei Leerzeilen und Kommentarzeilen zulassen, die mit # in Spalte 1 beginnen, sowie durch Leerzeichen getrennte Koordinaten in einer Zeile. Burkardt dokumentiert genau diese Art einer schlanken Konvention. Softwarespezifisches Verhalten kann deutlich strenger sein. PDALs readers.text erwartet eine Kopfzeile, die Dimensionen benennt, und jede nachfolgende Zeile muss dieselbe Anzahl an Feldern enthalten, wie die Kopfzeile vorgibt. ROCK Robotic dokumentiert einen weiteren softwarespezifischen Arbeitsablauf, der verlangt, dass die erste Zeile das Format definiert, danach ein Punkt pro Zeile folgt und die Plattform eine .xyz-Erweiterung erhält. Mit anderen Worten: „gültiges XYZ“ und „von diesem Importer akzeptiert“ sind nicht dieselbe Frage. [5] [3] [7]

XYZ-Punktwolkenformatvarianten und verwandte Formate

In der Praxis sind drei Variantengruppen am wichtigsten. Die erste ist die reine XYZ-Punktliste, oft ohne Kopfzeile und nur mit X/Y/Z-Zeilen. Die zweite ist die Form mit erweiterten Zeilen, bei der zusätzliche Attribute wie Farbe, Normalen oder Intensität ergänzt werden, die dennoch undokumentiert sein können. Die dritte ist die generische ASCII-Punkttabelle mit Kopfzeile, die Dimensionen vorab benennt und eher wie eine semantische CSV mit XYZ-Spalten funktioniert. Die dokumentierten Textformen von Open3D veranschaulichen den mittleren Fall deutlich: xyz ist [x, y, z], xyzn ist [x, y, z, nx, ny, nz] und xyzrgb ist [x, y, z, r, g, b]. [4] [2]

Ein kleiner, aber wichtiger softwarespezifischer Konflikt ist die RGB-Skalierung. Die XYZRGB-Konvention von Wisconsin verwendet Gleitkommapositionen plus vorzeichenlose Byte-Farben von 0 bis 255, während Open3D xyzrgb-Farbwerte als Gleitkommazahlen im Bereich 0 bis 1 dokumentiert. PyMeshLab macht dieselbe Mehrdeutigkeit direkt über eine Textimport-Auswahl rgbmode für 0–255 gegenüber 0.0–1.0 zugänglich. Eine Datei kann daher numerisch korrekt aufgebaut sein und dennoch falsche Farben anzeigen, wenn der Importer die falsche Skala annimmt. [6] [4] [17]

Vergleich: XYZ vs. E57 vs. LAS/LAZ vs. PLY vs. PCD

Dieser Vergleich betrifft Metadaten und Interoperabilität, nicht die Einstufung eines Formats als universell besser. XYZ ist minimal und leicht zu prüfen, was nützlich ist, wenn Sie nur Koordinaten oder einen einfachen Textaustausch benötigen. Umfangreichere Formate helfen, wenn die Datei selbst Attribute, Schema, Bilder oder räumliche Referenzinformationen erhalten soll, statt sich auf externe Notizen zu stützen. [1] [10] [12] [14]

E57 wird von der Library of Congress als binäres Austauschformat mit XML beschrieben, das 3D-Punktdaten, Punktattribute und 2D-Bilder speichern kann. LAS ergänzt strukturierte Lidar-Metadaten, einschließlich Header- und VLR/EVLR-Mechanismen sowie WKT-CRS-Unterstützung. PCD ist auf andere Weise selbsterklärend: Es verwendet einen ASCII-Header mit benannten Feldern wie FIELDS, SIZE, TYPE, COUNT, WIDTH, HEIGHT, VIEWPOINT, POINTS und DATA und unterstützt sowohl ASCII- als auch binäre Datenabschnitte. Umfangreichere Container verbessern die Quelldaten nicht selbst, können aber mehr von dem bewahren, was Sie bereits wissen. [10] [12] [14]

Typische Stärken und Grenzen sehen so aus, weil XYZ üblicherweise reiner Text ist, während E57, LAS und PCD mehr Struktur in der Datei selbst enthalten. [1] [10] [12] [14]

So öffnen Sie eine XYZ-Punktwolkendatei

Der sicherste Arbeitsablauf zum Öffnen beginnt mit allgemeiner Logik, nicht mit einem bestimmten Produkt. Prüfen Sie zuerst die Textdatei. Bestimmen Sie dann, ob die erste Zeile Daten, eine Kopfzeile oder eine Zählzeile ist. Stimmen Sie anschließend Trennzeichen, Spaltenreihenfolge und Feldanzahl auf den geplanten Importer ab. Auf Ebene der XYZ-Konvention kann eine Datei lediglich aus Zahlenzeilen bestehen. Softwarespezifische Importer können stattdessen benannte Dimensionen, feste Feldanzahlen oder bestimmte Textvarianten verlangen. [1] [2] [3] [5]

Das Verhalten unterscheidet sich zwischen Werkzeugen ausreichend stark, sodass ein erfolgreicher Import nicht beweist, dass die Datei portabel ist. Eine Datei, die sich in einer Anwendung sauber öffnet, kann in einer anderen fehlschlagen, weil das zweite Werkzeug eine andere Kopfzeilenregel, Farbskala oder Feldzuordnung erwartet. [3] [4] [7] [17]

Softwarespezifische Beispiele helfen, Erwartungen einzuordnen. FME dokumentiert das Lesen und Schreiben von Point Cloud XYZ als zeilen- und spaltenbasierte Punktdaten. PDALs readers.text erwartet eine Kopfzeile, die Dimensionen benennt, und erlaubt zudem extern bereitgestellte SRS über override_srs oder default_srs mit WKT-, PROJ- oder EPSG-Zeichenfolgen. Open3D dokumentiert Unterstützung für xyz, xyzn, xyzrgb und pts. Autodesk ReCap führt XYZ beim Import sowie E57, PTS und RCP/RCS beim Export auf. Das Handbuch von CloudCompare führt asc, txt, neu und xyz als ASCII-Punktwolkendateien auf. PyMeshLab dokumentiert sowohl das Laden als auch Speichern von xyz. [2] [3] [4] [8] [16] [17]

So konvertieren Sie das XYZ-Punktwolkenformat

XYZ wird üblicherweise konvertiert, wenn eine stärkere Metadatenbehandlung benötigt wird, als reiner Text bieten kann. Bestimmen Sie vor der Konvertierung, was die Quelldatei tatsächlich enthält, und dokumentieren Sie den Kontext, den die Textzeilen nicht selbst enthalten. Das ist wichtig, weil ein Punktwolkenkonverter Spalten neu zuordnen und Metadaten verpacken kann, aber keine räumliche Bedeutung ableiten kann, die nie erfasst wurde. Formate wie E57 und LAS können umfangreichere Strukturen bewahren, wenn Sie sie zum Zeitpunkt der Konvertierung bereitstellen. [10] [11] [12]

Dokumentieren Sie vor der Konvertierung diese Details:

• Einheiten
• CRS/EPSG oder lokaler Koordinatenrahmen
• Trennzeichen
• Spaltenreihenfolge
• RGB-Skala
• Intensitätsskala
• Quellscanner/-software
• Erfassungsdatum, falls bekannt

Warnhinweis: Ehrlichkeit bei der Konvertierung

Die Konvertierung kann vorhandene Spalten neu zuordnen und vom Nutzer bereitgestellte Metadaten anhängen. Die Konvertierung kann fehlende Einheiten, CRS oder Datum, Scannerpose, strukturierte Scan-Topologie oder Registrierungs-Transformationen nicht rekonstruieren, wenn diese nie mit der XYZ-Datei bereitgestellt wurden.

E57 ist nützlich, wenn Sie ein dokumentiertes Austauschformat benötigen, das 3D-Punkte, Attribute und 2D-Bilder speichern kann. Hubers Paper erklärt auch, warum die Pose wichtig ist: Mehrere Datensätze können in einem einzigen Koordinatensystem dargestellt werden, indem zugehörige Pose-Informationen gespeichert werden. Als softwarespezifisches Beispiel beschreibt die E57-Exportdokumentation von Autodesk ReCap eine E57-Wurzel mit data3D und images2D, kartesische Koordinaten in Metern und eine Pose pro Scan mit Translation plus Quaternionenrotation. LAS ist ein anderes umfangreiches Zielformat: Die Library of Congress beschreibt LAS als Format mit strukturierten Headern plus VLR/EVLR-Einträgen und WKT-CRS-Unterstützung. Diese umfangreicheren Container sind nur dann wertvoll, wenn Sie die Metadaten, die sie tragen sollen, tatsächlich kennen. [10] [11] [9] [12]

Leistungs- und Grenzen der Dateiverarbeitung

Auf Ebene der XYZ-Konvention ist einfaches ASCII leicht zu prüfen, aber im Vergleich zu binärer Speicherung aufwendig zu parsen. Wisconsin formuliert den Zielkonflikt direkt: Textdateien müssen geparst werden, während Binärdateien direkter gelesen werden können. [6]

Dieser Aufwand betrifft nicht nur die reine Lesegeschwindigkeit. Reines XYZ verfügt außerdem nicht über die selbsterklärenden Header, organisierte Indizierung oder umfangreicheren Metadatenstrukturen, von denen viele größere Arbeitsabläufe profitieren. Der LAS-Eintrag der Library of Congress erläutert die Begründung deutlich: ASCII-Austausch kann sehr langsam sein, die Dateigröße kann sehr groß werden und lidar-spezifische Informationen können verloren gehen. Das ist ein Grund, warum binäre oder selbsterklärende Formate mit zunehmender Projektgröße über einfache Prüfung und Austausch hinaus oft leichter zu verwalten sind. [6] [12]

Keine verlässliche allgemeine Angabe für universelle Größenverhältnisse, Punktanzahlgrenzen oder eine einzige maximal praktikable XYZ-Dateigröße gefunden. Jede tatsächliche Grenze hängt vom Parserdesign, verfügbarem Speicher, Betriebssystemverhalten, Trennzeichenstil und davon ab, ob der Arbeitsablauf die Daten als Text behält oder in eine umfangreichere binäre Struktur konvertiert. [6] [12]

Anwendungen von XYZ-Punktwolkendateien

XYZ-Punktwolkendateien sind am nützlichsten, wenn eine einfache zeilen- und spaltenbasierte ASCII-Darstellung ausreicht. Häufige Beispiele sind Scannerexport, Photogrammetrieexport, schneller Austausch von GIS-Höhenpunkten, Skripting, das Debuggen einer Pipeline und minimale Archivprüfung, bei der Lesbarkeit wichtiger ist als umfangreiche eingebettete Metadaten. Die Dokumentation von FME spiegelt diese grundlegende Austauschrolle wider, und die Begründung von Wisconsin erklärt, warum das Format fortbesteht: ASCII bleibt mit gewöhnlichen Werkzeugen zugänglich und leicht zu prüfen. Der Vorbehalt bleibt derselbe: Wenn nachgelagerte Arbeit von Einheiten, CRS, Registrierungskontext oder eindeutigen Attributbezeichnungen abhängt, benötigt die XYZ-Datei üblicherweise begleitende Notizen oder eine Konvertierung in ein umfangreicheres Format. [2] [6] [1]

Einschränkungen und häufige Importfehler

Die meisten XYZ-Importfehler sind keine rätselhafte Beschädigung. Es handelt sich um Abweichungen zwischen einer lockeren Textkonvention und einem strengeren Importer. Auf Ebene der XYZ-Konvention kann eine Datei eine völlig angemessene Koordinatenliste sein. Softwarespezifische Werkzeuge können sie dennoch ablehnen, weil sie eine Kopfzeile, eine feste Feldanzahl, ein bestimmtes Trennzeichen oder eine spezifische Attributreihenfolge erwarten. PDAL und ROCK Robotic sind gute Beispiele für dokumentierte Importererwartungen, die über die reine Konvention hinausgehen. [3] [7] [1]

Einige Fehler sind überhaupt keine Formatfehler. Eine Datei kann korrekt geparst werden und dennoch ein falsches Ergebnis liefern, weil die Einheiten falsch sind, das CRS fehlt, der lokale oder Projektkoordinatenrahmen undokumentiert ist oder Achsen vertauscht wurden. Reines XYZ enthält üblicherweise nicht genug Selbstbeschreibung, um solche Fehler selbst zu verhindern. [1] [12]

Farbe fügt eine weitere Ebene der Mehrdeutigkeit hinzu. Wisconsin dokumentiert XYZRGB mit Byte-Farben von 0–255, Open3D dokumentiert xyzrgb mit Gleitkommafarben von 0–1 und PyMeshLab bietet aus genau diesem Grund einen Schalter rgbmode. Eine numerisch gültige Datei kann daher mit ausgewaschenen oder abgeschnittenen Farben importiert werden, wenn die Skalierungsannahme falsch ist. Dieselbe allgemeine Vorsicht gilt für andere Textimportdetails wie gemischte Leerzeichen, wiederholte Trennzeichen, unerwartete Kopfzeilen, Dezimalkommas, wissenschaftliche Notation oder zusätzliche Nicht-Datenzeilen am Dateianfang. Chemisches XYZ kann mit Punktwolken-XYZ verwechselt werden, weil es mit einer Atomanzahlzeile und einer Titel- oder Kommentarzeile beginnt, während PTS-ähnliche Dateien mit einer Punktanzahlzeile beginnen können. Und eine Punktliste ist kein Mesh: XYZ speichert Punkte, keine Flächen oder Topologie. [6] [4] [17] [15]

Eine kompakte Checkliste zur Fehlerbehebung lautet:

1. Prüfen Sie auf falsche Trennzeichen, wiederholte Trennzeichen oder gemischte Leerzeichen.
2. Prüfen Sie auf eine fehlende oder unerwartete Kopfzeile.
3. Prüfen Sie Dezimalkomma gegenüber Dezimalpunkt.
4. Prüfen Sie, ob der Importer die in der Datei verwendete numerische Notation einschließlich wissenschaftlicher Notation akzeptiert.
5. Prüfen Sie auf ein unerwünschtes BOM oder Kommentarzeilen vor dem erwarteten Datenblock.
6. Prüfen Sie, ob RGB 0–255 oder 0–1 ist. [6] [4] [17]
7. Prüfen Sie, ob Einheiten dokumentiert und plausibel sind.
8. Prüfen Sie, ob CRS fehlt oder Achsen vertauscht sind.
9. Prüfen Sie, ob die Datei tatsächlich chemisches XYZ ist. [15]
10. Prüfen Sie, ob die erste Zeile wirklich eine Punktanzahl aus einer PTS-ähnlichen Datei ist. [4]
11. Prüfen Sie, ob Sie versuchen, eine Punktliste zu verwenden, wo ein Mesh-Format mit Flächen erforderlich ist.

Wann eine XYZ-Punktwolke verwendet werden sollte – und wann nicht

Verwenden Sie eine XYZ-Punktwolke, wenn Transparenz, schneller Austausch und einfaches Skripting wichtiger sind als eingebettete Metadaten. Sie eignet sich gut für Prüfung, Tests und schlanken Austausch, gerade weil die Datei nur Text ist. Verlassen Sie sich nicht darauf als einziges Produktions- oder Archivformat, wenn Einheiten, CRS, Datum, Attributsemantik, Registrierungskontext oder eine umfangreichere Schemaintegrität eine Übergabe ohne Rätselraten überstehen müssen. Der Eintrag der Library of Congress stellt ausdrücklich fest, dass XYZ keine formale Dokumentation und keine Selbstdokumentation besitzt, während E57, LAS und PCD stärker strukturierte Möglichkeiten bieten, Bedeutung in der Datei selbst zu bewahren. Kurz gesagt: XYZ-Punktwolke ist nützlich, wenn die Koordinaten die Botschaft sind; sie ist eine schwache Wahl, wenn auch die Metadaten Teil der Botschaft sind. [1] [10] [12] [14]

FAQ

Diese kurzen Antworten konzentrieren sich auf Interoperabilität und Fehlerbehebung. Das wiederkehrende Problem ist einfach: Die Textzeilen sind oft leicht zu lesen, aber der fehlende Kontext um diese Zeilen verursacht üblicherweise Verwirrung. [1] [2]

Was ist eine XYZ-Punktwolke?

Eine XYZ-Punktwolke ist eine textbasierte Punktliste, bei der jede Zeile üblicherweise einen Punkt darstellt und die Spalten typischerweise X-, Y- und Z-Koordinaten speichern. Sie ist einfach und für den Austausch nützlich, aber nicht stark selbsterklärend. [1] [2]

Warum lässt sich meine .xyz-Datei nicht als Punktwolke öffnen?

Weil .xyz mehrdeutig ist. Die Datei könnte das falsche Trennzeichen, unerwartete Kopfzeilen oder eine zusätzliche Zählzeile verwenden oder tatsächlich chemisches XYZ sein, bei dem Zeile 1 die Atomanzahl und Zeile 2 ein Titel oder Kommentar ist. [15] [4]

Speichert eine XYZ-Punktwolkendatei Einheiten (mm gegenüber m) oder einen CRS/EPSG-Code?

Üblicherweise nicht selbst. Auf Ebene der XYZ-Konvention sind diese Details oft extern. Softwarespezifische Werkzeuge wie PDAL können SRS-Informationen über override_srs oder default_srs mit WKT-, PROJ- oder EPSG-Zeichenfolgen anwenden, aber das ist Importerlogik und keine Garantie der XYZ-Datei selbst. [1] [3]

Kann eine XYZ-Punktwolke Farbe, Normalen oder Intensität speichern, und wie erkenne ich den RGB-Bereich?

Ja, zusätzliche Spalten können solche Attribute speichern, doch ihre Bedeutung ist oft mehrdeutig, sofern sie nicht dokumentiert ist. Open3D dokumentiert xyzn und xyzrgb, Wisconsin dokumentiert XYZRGB mit Byte-Farben von 0–255 und PyMeshLab bietet eine Auswahl rgbmode zwischen 0–255 und 0.0–1.0. [4] [6] [17]

Wie öffne ich eine XYZ-Punktwolkendatei in PDAL, Open3D oder CloudCompare, ohne Spalten zu verlieren?

Stimmen Sie die Datei auf die dokumentierten Erwartungen des Werkzeugs ab. PDALs readers.text erwartet eine Kopfzeile, die Dimensionen benennt. Open3D dokumentiert feste Textvarianten wie xyz, xyzn, xyzrgb und pts. CloudCompare dokumentiert Unterstützung für ASCII-Punktwolkendateien einschließlich xyz, aber Sie benötigen weiterhin das korrekte Trennzeichen und die richtige Spalteninterpretation. [3] [4] [16]

Wie konvertiere ich das XYZ-Punktwolkenformat in E57 oder LAS/LAZ, ohne fehlende Metadaten zu erfinden?

Dokumentieren Sie zuerst die Einheiten, das CRS, die Spaltenzuordnung und die Attributbedeutung. Die Konvertierung kann Spalten neu zuordnen und von Ihnen bereitgestellte Metadaten anhängen, aber sie kann fehlenden Kontext nicht rekonstruieren, der nie in der XYZ-Datei gespeichert war. E57 und LAS sind nützliche Zielformate, weil sie umfangreichere Strukturen bewahren können, sobald diese Informationen bekannt sind. [10] [11] [12] [9]

Ist eine XYZ-Punktwolke dasselbe wie ein Mesh?

Nein. Eine XYZ-Punktwolke ist eine Punktliste. Ein Mesh erfordert Topologie wie Flächen oder Konnektivität, die reines XYZ nicht kodiert. [1] [14]

Quellen

1. Library of Congress — XYZ Point Cloud (fdd000617). https://wwws.loc.gov/preservation/digital/formats/fdd/fdd000617.shtml
2. Safe Software (FME) — Point Cloud XYZ Reader/Writer. https://docs.safe.com/fme/html/FME-Form-Documentation/FME-ReadersWriters/pointcloudxyz/pointcloudxyz.htm
3. PDAL — readers.text. https://pdal.org/en/latest/stages/readers.text.html
4. Open3D — Dateiein-/ausgabe (xyz/xyzn/xyzrgb/pts). https://www.open3d.org/docs/latest/tutorial/geometry/file_io.html
5. John Burkardt — XYZ-Dateien. https://people.math.sc.edu/Burkardt/data/xyz/xyz.html
6. Wisconsin Institute for Discovery (vizHOME) — XYZ-Dateiformat / XYZRGB. https://pages.discovery.wisc.edu/vizhome/documentation_file_format.html
7. ROCK Robotic Help Center — XYZ-ASCII-Uploadformat. https://learn.rockrobotic.com/xyz-format
8. Autodesk ReCap Help — Unterstützte Dateiformate. https://help.autodesk.com/view/RECAP/ENU/?contextId=supported_file_formats
9. Autodesk ReCap — E57-Exportunterstützung (technische Spezifikation). https://help.autodesk.com/cloudhelp/ENU/Reality-Capture/files/Saving_Exporting_Your_Project/export_e57_technical_specifications.html
10. Library of Congress — ASTM-E57-3D-Dateiformat (E57). https://www.loc.gov/preservation/digital/formats/fdd/fdd000563.shtml
11. Daniel Huber (CMU) — Das ASTM-E57-Dateiformat für den Austausch von 3D-Bildgebungsdaten (PDF). https://www.ri.cmu.edu/pub_files/2011/1/2011-huber-e57-v3.pdf
12. Library of Congress — LAS-(LASer)-Dateiformat, Version 1.4 (fdd000418). https://wwws.loc.gov/preservation/digital/formats/fdd/fdd000418.shtml
13. ASPRS — LAS-Spezifikation 1.5 R00 (PDF). https://lasformat.org/_/downloads/en/latest/pdf/
14. PCL-Dokumentation — PCD-Dateiformat. https://pcl-docs.readthedocs.io/en/latest/pcl/doc/tutorials/content/pcd_file_format.html
15. Open-Babel-Dokumentation — Format für chemische XYZ-kartesische Koordinaten. https://openbabel.org/docs/FileFormats/XYZ_cartesian_coordinates_format.html
16. CloudCompare-Benutzerhandbuch v2.1 (PDF-Spiegel). https://cloud.sdsc.edu/v1/AUTH_opentopography/www/shortcourses/13SCEC_course/Documentation_CloudCompare_version_2_1_eng.pdf
17. PyMeshLab-Dokumentation — E/A-Formatliste. https://pymeshlab.readthedocs.io/en/2021.7/io_format_list.html
18. Tychola et al. 2024 — systematische Übersichtsarbeit zu 3D-Punktwolken. https://link.springer.com/article/10.1007/s00371-023-03237-7