LAS vs. LAZ: Was ist der Unterschied bei LiDAR-Dateien?

Zusammenfassung

Bei LAS vs. LAZ besteht der Hauptunterschied zwischen einer unkomprimierten LAS-Datei und einer verlustfrei komprimierten LAZ-Datei innerhalb derselben LiDAR-Punktwolkenformatfamilie. Eine LAS-Datei ist ein offenes Austauschformat für Punktwolkendaten, während eine LAZ-Datei dieselbe Bedeutung der Punktfelder beibehält, die Punktdaten jedoch komprimiert speichert. [1] [4]

In der Praxis begegnen Ihnen beide Formate bei luftgestütztem Lidar, Drohnenkartierung, Trassenvermessung und Reality-Capture-Lieferungen. Verlustfreie Komprimierung ist weder Ausdünnung noch Dezimierung oder Resampling, daher verringert LAZ die Punktqualität nicht grundsätzlich. Das größere Risiko liegt im Workflow: Software kann CRS-Metadaten falsch lesen oder verwerfen, Extra-Bytes-Schemata übersehen oder Skalierungs- und Offsetwerte bei der Konvertierung neu schreiben, wenn Sie sie nicht ausdrücklich prüfen. [4] [2] [3]

LAS vs. LAZ: Der Kernunterschied (und die Antwort auf „komprimiertes LAS“)

Eine LAS-Datei ist der unkomprimierte Binärcontainer, der traditionell zum Austausch von LiDAR-Punktwolken zwischen Werkzeugen verwendet wird. In der Formatdefinition enthält die Datei einen Public Header Block, optionale VLRs, Punktdatensätze und optionale EVLRs, sämtlich in Little-Endian-Reihenfolge. VLR-Nutzdaten sind auf 65,535 Byte begrenzt; dies ist ein Grund dafür, dass größere Metadatenblöcke oder später hinzugefügte Metadaten stattdessen in EVLRs landen können. [2]

Eine LAZ-Datei behält diese übergreifende LAS-orientierte Struktur bei, wendet jedoch eine standardisierte verlustfreie Komprimierung auf den Punktdatenblock an. Der aktuelle OGC LAZ 1.4 Community Standard besagt, dass LAZ 1.4 auf LAS 1.4 basiert und die Bedeutung der unkomprimierten LAS-Punktfelder nicht verändert. Anders gesagt: LAZ verändert die Speicherung, nicht die semantische Bedeutung von Koordinaten, Klassifizierungen, Returns oder anderen Punktattributen. [4]

Ist LAZ also einfach ein komprimiertes LAS? Ja, insofern die Bedeutung der Punktfelder erhalten bleibt. Nein, insofern es kein generischer ZIP-Wrapper um eine .las-Datei ist. LAZ verändert die Containersignalisierung, indem 128 zum LAS-Punktdatensatzformat hinzugefügt wird, fügt ein LAZ-spezifisches VLR hinzu, das die Datei identifiziert und die Komprimierung beschreibt, und ersetzt den ursprünglichen Punktdatenblock durch einen komprimierten. Metadaten müssen nach dem Öffnen oder der Konvertierung weiterhin geprüft werden. [4]

Für die meisten Anwender liegt der praktische Unterschied eher im Workflow als in der Analysequalität. LAS ist einfacher für Software oder Skripte, die unkomprimierte Datensätze erwarten, während LAZ Speicher- und Übertragungskosten senkt, wenn die empfangende Software es korrekt dekodieren und die relevanten Metadaten erhalten kann. [4] [2]

Eine klare Zeitleiste: LAS als Austauschformat → LAS-1.4-Basis → LAZ-1.4-Standardisierung

LAS existiert, damit unterschiedliche Hardware- und Softwarewerkzeuge Punktwolkendaten in einem gemeinsamen Format austauschen können. Für heutige Interoperabilitätsdiskussionen ist LAS 1.4 die entscheidende Grundlage, da der OGC LAS 1.4 Community Standard am 1. März 2018 als Dokument 17-030r1 veröffentlicht wurde. OGC weist außerdem darauf hin, dass dieser Community Standard inhaltlich festgeschrieben ist, obwohl ASPRS als ursprüngliches Gremium die Spezifikation möglicherweise weiterhin separat aktualisiert. Diese Unterscheidung ist wichtig, weil viele reale Archive und Beschaffungsprofile weiterhin auf LAS-1.4-Konventionen zielen, obwohl inzwischen neuere ASPRS-Revisionen existieren. [1] [3]

LAS 1.4 selbst enthält keine Komprimierung, weshalb LAZ separat standardisiert werden musste, statt als Funktion innerhalb des LAS-1.4-Dokuments behandelt zu werden. Der OGC LAZ 1.4 Community Standard wurde am 23. April 2026 genehmigt und am 30. Juni 2026 als Dokument 24-070r1 veröffentlicht. Damit wird LAZ als verlustfreies, LAS-bewusstes Komprimierungsformat formalisiert, das weithin für Speicherung und Lieferung eingesetzt wird, wenn große Punktwolken effizient zwischen Organisationen übertragen werden müssen. [3] [4]

Was eine LAS-Datei speichern kann (und was nicht)

Eine LAS-Datei speichert Punktdatensätze sowie Punktattribute, doch der genaue Attributsatz hängt vom gewählten Punktdatensatzformat beziehungsweise PDRF ab. In LAS 1.4 sind die Formate 0 bis 10 definiert, alle Punktdatensätze in einer einzelnen Datei müssen dasselbe PDRF verwenden, und die Formate 6 bis 10 sind der bevorzugte moderne Satz. Das bedeutet, dass zwei LAS-Dateien beide gültig sein können, jedoch unterschiedliche Kombinationen aus GPS-Zeit, Farbe, NIR oder wellenformbezogenen Feldern enthalten. [3]

Praktisch ist die Datei zuerst als Header, dann als optionale VLRs, danach als Punktdatensätze und schließlich als optionale EVLRs organisiert. Der Header teilt der Software mit, wie viele Punkte existieren, welches PDRF verwendet wird und wie skalierte Koordinaten zu interpretieren sind. In VLRs befindet sich ein Großteil der Metadaten, doch jedes VLR ist auf 65,535 Byte beschränkt. EVLRs erlauben größere Nutzdaten und können an das Ende der Datei angehängt werden; das ist nützlich, wenn Metadaten wie Projektionsinformationen hinzugefügt werden müssen, ohne den gesamten Punktdatenblock neu zu schreiben. [2]

LAS und LAZ speichern Punktwolken, keine fertigen Netze, DEMs oder STL-artige Geometrie. Diese können später aus den Punkten abgeleitet werden, sind jedoch andere Datenprodukte. Zu den häufigen Punktattributen gehören die folgenden. [1] [2] [3]

• X-, Y- und Z-Koordinaten, gespeichert aus ganzzahligen Punktwerten zuzüglich Skalierung und Offset. [2]
• Intensität, die üblicherweise die Stärke des Pulsrücklaufs in einem normalisierten Ganzzahlfeld darstellt. [2]
• Return-Nummer und Anzahl der Returns, die das Multi-Return-Verhalten eines Pulses beschreiben. [2] [3]
• Klassifizierung und zugehörige Flags, deren Umfang von der verwendeten PDRF-Generation abhängt. [3]
• GPS-Zeit, die in PDRF 6 und dem zugehörigen Familiendesign 6–10 obligatorisch ist. [3]
• RGB- und, sofern unterstützt, NIR-Werte in farbfähigen Punktformaten. [3]
• Wellenformbezogene Felder, jedoch nur in einigen Punktformaten und nicht in jeder LAS-Datei. [3]
• Extra Bytes oder andere benutzerdefinierte Dimensionen, wenn ein Produzent zusätzliche Werte pro Punkt über die Standardfelder hinaus anhängt. [3]

Was eine LAZ-Datei verändert (nur auf Containerebene)

Auf Speicherebene ersetzt LAZ unkomprimierte Punktdaten durch verlustfrei komprimierte Punktdaten. Das bedeutet, dass die Werte nach der Dekodierung unverändert zurückkommen, sodass LAZ kein Schritt der Ausdünnung, Dezimierung oder des Resamplings ist. LAZ speichert Punktdaten außerdem in Blöcken, und jeder Block kann unabhängig dekomprimiert werden; deshalb ist wahlfreier Zugriff auf Blockgranularität möglich, statt zuerst die gesamte Datei entpacken zu müssen. [4]

Auf Ebene des Binärcontainers ändern sich mehrere Dinge, obwohl sich die Punktbedeutung nicht verändert. LAZ addiert 128 zum Wert des Point Data Record Format, sodass die Werte 128 bis 138 den LAS-Formaten 0 bis 10 entsprechen. Es fügt ein erforderliches spezielles LAZ-VLR hinzu, das die Datei identifiziert und die Komprimierung beschreibt, und platziert einen komprimierten Datenblock dort, wo LAS einfache Punktdatensätze speichern würde. Optional kann ein Zeiger auf eine Blocktabelle am Dateiende erscheinen. Deshalb sollte LAZ als LAS-bewusste Komprimierung verstanden werden, nicht als „LAS in ZIP“. [4]

Metadaten & CRS: Speicherort und mögliche Probleme

Einer der einfachsten Fehler bei der Verarbeitung von LAS oder LAZ besteht darin, gespeicherte Koordinaten mit Metadaten zum Koordinatenreferenzsystem zu verwechseln. Die gespeicherten X-, Y- und Z-Werte sind ganzzahlige Datensatzwerte, die über Skalierung und Offset interpretiert werden, während das CRS separate Metadaten in VLRs oder EVLRs sind. Eine Datei kann daher numerisch gültige Koordinaten haben und dennoch fehlende, mehrdeutige oder falsche Metadaten zur räumlichen Referenz enthalten. [2]

In LAS 1.4 befinden sich CRS-Metadaten normalerweise unter der Benutzer-ID LASF_Projection. Die WKT-basierten Datensätze sind Record ID 2111 für Math Transform WKT und 2112 für Coordinate System WKT. Die GeoTIFF-artigen Datensätze haben die Record IDs 34735, 34736 und 34737 für die Strukturen GeoKeyDirectory, GeoDoubleParams und GeoAsciiParams. Reale Dateien können WKT, GeoTIFF, beides oder keines von beiden enthalten, und Software kann sie bei der Übersetzung falsch lesen oder weglassen. Ein sicherer Workflow bedeutet deshalb, CRS-Metadaten vor Analyse, Reprojektion, Kachelung oder Export zu prüfen, statt anzunehmen, die Kartenansicht „sehe richtig aus“. [3]

Es gibt zudem einen Versionsvorbehalt. ASPRS LAS 1.5 Revision 00 wurde am 26. August 2025 veröffentlicht; zu den wesentlichen Änderungen gehören erweiterte WKT-CRS-Unterstützung und die Entfernung der GeoTIFF-CRS-Kodierung. LAS 1.5 macht außerdem PDRFs 0 bis 5 für LAS-1.5-Dateien ungültig. Trotzdem sollten sich die meisten Austauschdiskussionen weiterhin auf LAS 1.4 und LAZ 1.4 konzentrieren, da dort viele Archive, Lieferungen und Toolchains arbeiten. Skalierung und Offset steuern die Speicherpräzision, nicht die Vermessungsgenauigkeit. Ihre Änderung kann beeinflussen, wie Koordinaten in der Datei quantisiert werden, ohne für sich allein etwas darüber auszusagen, wie genau die Vermessung im Gelände war. [6] [2]

Punktformate (PDRF) versus Extra Bytes (benutzerdefinierte Dimensionen)

PDRF-definierte Felder sind die Felder, die durch das ausgewählte Punktformat garantiert werden. In LAS 1.4 müssen alle Punkte einer Datei ein einzelnes PDRF teilen, und die bevorzugten modernen Formate sind 6 bis 10. PDRF 6 ist die zentrale 30-Byte-Struktur, die von 6 bis 10 geteilt wird; sie bietet unter anderem Unterstützung für bis zu 15 Returns, 256 Klassen, eine höherpräzise 16-Bit-Speicherung des Scanwinkels statt 8-Bit sowie obligatorische GPS-Zeit. Ist eine Dimension Teil des gewählten PDRF, sollte konforme Software wissen, wo dieses Feld hingehört. [3]

Extra Bytes sind etwas anderes. Sie sind benutzerdefinierte Dimensionen pro Punkt, die nach den Standard-PDRF-Feldern angehängt werden; ihre Bedeutung wird durch das Extra-Bytes-VLR unter Benutzer-ID LASF_Spec, Record ID 4, beschrieben. Dies ist leistungsfähig, doch die Portabilität hängt davon ab, dass dieses Schema den Workflow übersteht und das nächste Werkzeug es berücksichtigt. Die Writer-Dokumentation von PDAL verdeutlicht das Erhaltungsproblem: Das Weiterleiten von Headerwerten, Skalierung, Offset und VLR-Inhalten ist explizites Verhalten und nicht etwas, von dem Sie ausgehen sollten, dass es bei jeder Konvertierung automatisch geschieht. [3] [9]

Ein praktisches Beispiel: RGB kann in einem farbfähigen Punktformat durch das PDRF definiert sein, während eine benutzerdefinierte Dimension wie Amplitude oder Echobreite stattdessen als Extra Bytes gespeichert wird. Wird das Schema für diese Extra Bytes verworfen oder falsch neu erstellt, lassen sich die Punkte möglicherweise weiterhin öffnen, doch die benutzerdefinierte Dimension kann für nachgelagerte Software bedeutungslos werden. [3] [9]

Wellenformdaten: Warum sich manche LAS/LAZ-Dateien nicht überall öffnen lassen

Dateien mit Wellenformfähigkeit sind ein Sonderfall. In LAS 1.4 fügen PDRFs 4, 5, 9 und 10 Wellenformpaketfelder hinzu. Das bedeutet nicht, dass jede Datei in diesen Formaten in der Praxis eine identische Wellenformverarbeitung enthält, wohl aber, dass Reader mehr als die übliche XYZ- und Attributlogik benötigen. Eine ansonsten gültige Datei kann in einem Werkzeug scheitern, nur weil dieses Werkzeug jene wellenformbezogenen Punktformate nicht implementiert. [3]

Die aktuelle Dokumentation von PDAL zu readers.las stellt ausdrücklich fest, dass die Wellenform-Punktformate 4, 5, 9 und 10 nicht unterstützt werden. LAZ 1.4 fügt eine weitere Einschränkung hinzu: Intern gespeicherte Wellenformdaten in einem EVLR werden nicht unterstützt, daher müssen Wellenformpakete eine Hilfsdatei wie .WDP verwenden; der Standard weist außerdem darauf hin, dass die interne Wellenformspeicherung auch in LAS 1.4 veraltet ist. Wenn sich eine Wellenformdatei nicht sauber öffnen lässt, sollte der erste Verdacht auf Unterstützungsgrenzen fallen, nicht automatisch auf Beschädigung. [7] [4]

LAS/LAZ-Dateien öffnen (Anzeige + Konvertierung ohne Metadatenverlust)

Das korrekte Öffnen von LAS oder LAZ hängt von zwei Dingen ab: ob die Software die Datei dekodieren kann und ob sie die Metadaten wie erwartet interpretiert. LAZ erfordert einen LAZ-fähigen Reader, kein allgemeines Dekomprimierungsprogramm. Die Unterstützung ändert sich außerdem im Laufe der Zeit; es lohnt sich daher, die Dokumentation für die genaue verwendete Version oder den verwendeten Build zu prüfen, insbesondere wenn die Datei moderne PDRFs, Wellenformfelder oder benutzerdefinierte Dimensionen nutzt. [4] [7] [18]

QGIS 3.44 ist ein gutes Beispiel für ein in der Praxis relevantes Verhalten. Die Punktwolkendokumentation besagt, dass QGIS bei LAS oder LAZ als Quelle beim ersten Laden in EPT konvertiert und neben den Quelldaten einen Unterordner ept_... erstellt. Das bedeutet, dass das erste Öffnen Zeit beanspruchen und zusätzlichen Speicherplatz belegen kann, während spätere Öffnungen schneller sind, weil QGIS die zwischengespeicherte EPT-Struktur wiederverwendet. [10]

Andere Werkzeuge haben andere Grenzen. Die aktuelle Dokumentation zu Create LAS Dataset von ArcGIS Pro besagt, dass LAS-Datasets auf .las-, .zlas– und .laz-Dateien verweisen können, und warnt davor, dass fehlende oder falsche räumliche Referenzinformationen Dateien mit unbekannter räumlicher Referenz hinterlassen können. CloudCompare sollte als buildabhängig behandelt werden, da die offizielle Build-Dokumentation besagt, dass LAS/LAZ-Unterstützung LASzip über den qLASIO-Pfad erfordert. Die Seite zu unterstützten Formaten von Autodesk ReCap listet LAS-Import sowie RCP/RCS-Export, jedoch kein LAZ; daher kann in manchen CAD/BIM-Workflows ein vorgeschalteter Konvertierungsschritt erforderlich sein. [11] [18] [12]

Ein sicherer Konvertierungsworkflow ist einfach, aber streng. [2] [3] [9]

1. Prüfen Sie zuerst Header und CRS-Metadaten, einschließlich der Frage, ob WKT- oder GeoTIFF-Projektions-VLRs vorhanden sind. [3]
2. Bestätigen Sie das Punktformat und ob Extra Bytes existieren, denn benutzerdefinierte Dimensionen sind nur portabel, wenn das Schema erhalten bleibt. [3] [9]
3. Verwenden Sie LAZ-fähige Werkzeuge und dokumentationsgestützte Workflows, etwa QGIS 3.44, die LAS/LAZ-Stufen von PDAL, LAS-Dataset-Werkzeuge von ArcGIS Pro oder einen mit LASzip-Unterstützung kompilierten CloudCompare-Build. [10] [7] [11] [18]
4. Erhalten Sie bei der Konvertierung ausdrücklich Skalierung, Offset, kompatible Punktformatentscheidungen sowie das VLR/EVLR- und Extra-Bytes-Schema. Die Writer-Dokumentation von PDAL zeigt, dass das Weiterleitungsverhalten konfigurierbar statt automatisch ist; „konvertieren“ garantiert also nicht den Erhalt von Metadaten. [2] [9]
5. Behandeln Sie DEM-, Netz- und CAD-Exporte als abgeleitete Produkte, nicht als bloßes „Öffnen“ einer LAS- oder LAZ-Datei. Eine Punktwolke bleibt eine Punktwolke, bis Sie bewusst etwas anderes daraus ableiten. [1]

Dateigröße & Leistung: Was die Quellen tatsächlich sagen

Veröffentlichte Angaben zu Größe und Geschwindigkeit sollten als Beispiele gelesen werden, nicht als Zusagen. In Martin Isenburgs LASzip-Paper von 2013 beträgt die angegebene komprimierte Größe 7 bis 25 Prozent der ursprünglichen Dateigröße, bei Kodierung und Dekodierung von etwa 1 bis 3 Millionen Punkten pro Sekunde und Unterstützung für wahlfreien Zugriff bei einer Standardgranularität von 50,000 Punkten. Die Workshop-Dokumentation von PDAL nennt eine andere Faustregel und sagt, typische LASzip-Komprimierung liege je nach LiDAR bei 5:1 bis 8:1. Die ArcGIS-Pro-Dokumentation von Esri nennt eine weitere datensatzorientierte Zahl: Komprimierte Dateien benötigen typischerweise ungefähr 30 Prozent des Speicherplatzes unkomprimierter Dateien. Diese Zahlen sollten getrennt bleiben, statt sie zu einem Slogan zu mitteln. [16] [8] [11]

Warum unterscheiden sich die Verhältnisse so stark? Weil die Komprimierung von den Daten selbst abhängt: Attributmix, Punktreihenfolge, das Vorhandensein von Farb- oder wellenformbezogenen Inhalten, Entscheidungen zur Koordinatenpräzision, Rauschen und Implementierungsdetails spielen alle eine Rolle. LAZ ist zuverlässig verlustfrei, aber keine glaubwürdige Quelle stützt die Behauptung, es werde bei allen Punktwolken universell „immer um X Prozent kleiner“. [4] [8] [16]

LAS/LAZ vs. COPC (und kurze Hinweise zu EPT und ZLAS)

COPC hat keine andere Rohpunktbedeutung als LAZ. Die COPC-Spezifikation definiert eine COPC-Datei als LAZ-1.4-Datei, deren Punktdaten in einem geclusterten Octree organisiert sind. Die Punktattribute folgen weiterhin LAS/LAZ-Konventionen, doch die räumliche Organisation ist für Streaming und Teilzugriff optimiert, weshalb sich COPC in Web-, Cloud- oder Workflows mit sehr großen Datensätzen oft anders anfühlt. [17]

Die Einschränkung lautet: COPC ist nicht „jede LAZ-Datei“. Die Spezifikation erlaubt nur LAS-PDRFs 6, 7 oder 8, daher sollten eine generische .laz-Datei und eine .copc.laz-Datei nicht als austauschbare Bezeichnungen behandelt werden. EPT lässt sich hier am besten als indexierte Speicher- und Streamingstruktur verstehen, die auch im Erstlade-Workflow von QGIS für LAS oder LAZ erscheint. ZLAS ist eine Klarstellung für das Esri-Ökosystem: Die ArcGIS-Pro-Dokumentation behandelt .zlas zusammen mit .las und .laz, was ausreicht, um es nicht mit LAZ zu verwechseln, obwohl beide komprimierte Punktwolkencontainer sind. [17] [10] [11]

Aktuelle Standards & reale Profile

Der Stand der Standards am 21. September 2026 ist eindeutig. OGC LAS 1.4 wurde am 1. März 2018 veröffentlicht. OGC LAZ 1.4 wurde am 23. April 2026 genehmigt und am 30. Juni 2026 veröffentlicht. Separat wurde ASPRS LAS 1.5 Revision 00 am 26. August 2025 veröffentlicht, mit bemerkenswerten Änderungen wie dem Wegfall der PDRFs 0 bis 5 für LAS 1.5 und erweiterter WKT-basierter CRS-Unterstützung. Dieser neuere ASPRS-Status ist real, sollte jedoch als begrenzter Vorbehalt und nicht als Grund behandelt werden, ältere LAS-1.4- und LAZ-1.4-Bestände neu zu interpretieren. [3] [4] [6] [2]

Als konkretes Marktbeispiel verlangt die Lidar Base Specification 2025 rev. A des U.S. Geological Survey, veröffentlicht am 10. Juni 2025, Punktlieferungen in LAS 1.4-R15 unter Verwendung der PDRFs 6 bis 10 sowie die Lieferung in LAZ 1.4. Sie besagt außerdem, dass im Kompatibilitätsmodus komprimierte LAZ-1.4-Dateien nicht verwendet werden dürfen. Dies ist ein US-Beschaffungsbeispiel, keine universelle globale Regel, aber ein starker Indikator für die aktuelle Realität bei großen Lieferungen im öffentlichen Sektor. Die Beschränkung des Kompatibilitätsmodus ist wichtig, weil dieser ältere Modus PDRFs 6 bis 10 als 0 bis 5 plus Extra Bytes unter älteren LAZ-1.2- oder 1.3-Headern speichert, statt als normales LAZ 1.4. [15] [14] [13] [4]

LAS vs. LAZ: Welches sollten Sie wählen?

Für die meisten modernen Austausch- und Lieferworkflows ist LAS vs. LAZ keine Frage von Qualitätsverlust. Es ist eine Frage der Kompatibilität, Speicherung und Metadatendisziplin. Wählen Sie LAZ, wenn Ihre Toolchain es unterstützt und Speicher- oder Übertragungseffizienz wichtig ist. Wählen Sie LAS, wenn ein nachgelagertes Werkzeug, Skript oder eine Übergabe an einen Anbieter ausdrücklich unkomprimierte Datensätze erfordert. Ziehen Sie COPC in Betracht, wenn Sie LAZ-kompatible Inhalte plus besseres Teilzugriffsverhalten für große oder entfernte Datensätze benötigen. Bewahren Sie in jedem Fall CRS-Metadaten, PDRF-Treue, Skalierung und Offset sowie jedes Extra-Bytes-Schema. Denken Sie auch daran, dass eine Punktwolke nicht dasselbe wie ein Netz oder DEM ist, selbst wenn Sie diese später ableiten möchten. [4] [17] [13]

• Wählen Sie LAZ, wenn Sie kleinere Lieferungen und schnellere Übertragung wünschen und die empfangende Software nachweislich LAZ-fähig ist. [4] [13]
• Wählen Sie LAS, wenn ein erforderliches Werkzeug oder Austauschpartner unkomprimiertes LAS erwartet oder Sie den einfachstmöglichen Weg zur Fehlersuche bei der Metadatenprüfung benötigen. [1] [2]
• Ziehen Sie COPC in Betracht, wenn Sie LAZ-1.4-Semantik plus Octree-artige Organisation für Cloud- oder Teilzugriffsworkflows benötigen. [17]
• Tun Sie dies niemals: Exportieren Sie in einfaches XYZ oder ein anderes reduziertes Format und nehmen Sie an, dass Klassifizierungen, CRS, GPS-Zeit, Farbe oder Extra Bytes vollständig erhalten bleiben. Nutzen Sie diese nur, wenn Sie den Attributverlust bewusst akzeptieren. [3] [9]

FAQ

LAS vs. LAZ: Was ist der Unterschied?

LAS ist der unkomprimierte Austauschcontainer für Punktwolkendaten, während LAZ die verlustfrei komprimierte, LAS-bewusste Variante ist. Die Punktattribute bedeuten nach der Dekodierung dasselbe, doch LAZ verändert die Speicherschicht durch LAZ-Signalisierung und ein Komprimierungs-VLR sowie durch den Ersatz einfacher Punktdatensätze durch einen komprimierten Datenblock. [2] [4]

Ist LAZ einfach ein komprimiertes LAS?

Ja, wenn Sie damit meinen, dass LAZ dieselbe Bedeutung der Punktfelder wie LAS erhält. Nein, wenn Sie „eine in ZIP verpackte LAS-Datei“ meinen. LAZ hat seine eigene Signalisierung auf Containerebene, einschließlich PDRF-Werten 128 bis 138, eines speziellen LAZ-VLR, blockweiser komprimierter Punktspeicherung und optionaler Blocktabellenmechanismen für wahlfreien Zugriff. [4]

Verringert LAZ die Punktwolkenqualität?

Nicht für sich allein. LAZ ist verlustfrei, daher entsprechen die dekodierten Punktwerte den kodierten Werten. Problematisch ist nicht die Komprimierung selbst, sondern der umgebende Workflow: Eine fehlerhafte Konvertierung kann die Behandlung von Skalierung und Offset verändern, CRS-Metadaten verwerfen oder Extra-Bytes-Definitionen verlieren. [4] [2] [3]

Wo wird das Koordinatensystem in einer LAS/LAZ-Datei gespeichert?

In der Praxis der LAS-1.4-Ära wird das CRS in VLRs oder EVLRs gespeichert, nicht in den XYZ-Ganzzahlen selbst. Die wichtigsten LASF_Projection-Datensätze sind 2111 und 2112 für WKT-Inhalte sowie 34735, 34736 und 34737 für CRS-Metadaten im GeoTIFF-Stil. Deshalb genügt die alleinige Prüfung des Headers nicht, wenn Sie die Metadatensätze auslassen. [3]

Was ist der Unterschied zwischen PDRF-Feldern und Extra Bytes?

PDRF-Felder sind die Standardfelder, die das gewählte Punktformat für jeden Punkt in der Datei garantiert. Extra Bytes sind benutzerdefinierte angehängte Dimensionen, die durch das Schema LASF_Spec Record ID 4 beschrieben werden. Wenn das Extra-Bytes-VLR fehlt, ignoriert oder falsch neu erstellt wird, können die Punkte weiterhin geladen werden, doch die benutzerdefinierten Dimensionen sind möglicherweise nicht mehr interpretierbar. [3] [9]

Warum öffnen manche Werkzeuge meine LAS/LAZ-Wellenformdaten nicht?

Weil die Wellenformunterstützung spezialisierter ist als die gewöhnliche Punktunterstützung. Wellenformbezogene Felder erscheinen in PDRFs 4, 5, 9 und 10, und manche Software implementiert sie nicht. readers.las von PDAL unterstützt diese Wellenformformate ausdrücklich nicht, und LAZ 1.4 erlaubt keine intern gespeicherten Wellenform-EVLR-Daten, sondern erfordert stattdessen eine Hilfsdatei .WDP. [3] [7] [4]

Wie konvertiere ich LAZ in LAS, ohne Metadaten zu verlieren?

Beginnen Sie mit der Prüfung von CRS-Metadaten, PDRF, Skalierung und Offset sowie der Frage, ob Extra Bytes vorhanden sind. Verwenden Sie anschließend ein Werkzeug, mit dem Sie Headerwerte und relevante VLR-Inhalte ausdrücklich erhalten oder weiterleiten können. Prüfen Sie die Ausgabe nach der Konvertierung erneut, statt anzunehmen, dass die Metadaten automatisch übernommen wurden, denn das Writer-Verhalten ist werkzeugspezifisch. [2] [3] [9]

Quellen

1. ASPRS LAS 1.5 Intro (Zweck + Status) — https://lasformat.org/latest/01_intro.html
2. ASPRS LAS 1.5 Format Definition (Struktur, VLR/EVLR, X/Y/Z-Speicherung, Skalierung/Offset) — https://lasformat.org/latest/02.00_definition.html
3. OGC LAS 1.4 Community Standard (17-030r1, veröffentlicht 2018-03-01) — https://docs.ogc.org/cs/17-030r1/17-030r1.pdf
4. OGC LAZ 1.4 Community Standard (24-070r1, veröffentlicht 2026-06-30) — https://docs.ogc.org/cs/24-070r1/24-070r1.pdf
5. OGC-Seite zur Auflistung der LAS-Standards (Auffindbarkeit von LAS- + LAZ-Dokumentnummern) — https://www.ogc.org/standards/las/
6. ASPRSorg/LAS GitHub Releases (wesentliche Änderungen LAS 1.5 R00; Status LAS 1.4 R16) — https://github.com/ASPRSorg/LAS/releases
7. PDAL readers.las (LAZ-Lesen + Einschränkung bei Wellenformen) — https://pdal.org/en/latest/stages/readers.las.html
8. PDAL-Komprimierungsworkshop-Hinweis (typisch 5:1–8:1) — https://pdal.org/en/latest/workshop/introduction/compression.html
9. PDAL writers.las (Hinweise zum Weiterleiten von Header/VLR; Verhalten bei zusätzlichen Dimensionen/Extra Bytes) — https://pdal.org/en/2.6.3/stages/writers.las.html
10. QGIS-3.44-Handbuch zu Punktwolken (LAS/LAZ → EPT-Konvertierung beim ersten Laden; COPC-Erwähnung im VPC-Kontext) — https://docs.qgis.org/3.44/en/docs/user_manual/working_with_point_clouds/point_clouds.html
11. Esri ArcGIS Pro Create LAS Dataset tool (Hinweis zu 30% Speicher) — https://doc.esri.com/en/arcgis-pro/latest/tool-reference/data-management/create-las-dataset.html
12. Von Autodesk ReCap unterstützte Dateiformate (LAS-Import; RCP/RCS-Export) — https://help.autodesk.com/view/RECAP/ENU/?contextId=supported_file_formats
13. USGS Lidar Base Specification 2025 rev. A — Lieferungen (LAZ 1.4; kein Kompatibilitätsmodus) — https://www.usgs.gov/ngp-standards-and-specifications/lidar-base-specification-deliverables
14. USGS Lidar Base Specification 2025 rev. A — Datenverarbeitung/-handhabung (LAS 1.4-R15; PDRF 6–10) — https://www.usgs.gov/ngp-standards-and-specifications/lidar-base-specification-data-processing-and-handling-requirements
15. USGS-LBS-Online-Übersicht (Veröffentlichungsdatum 10. Juni 2025) — https://www.usgs.gov/ngp-standards-and-specifications/lidar-base-specification-online
16. Isenburg LASzip-Paper als PDF (Komprimierungsbeispiele + Leistung) — https://www.cs.unc.edu/~isenburg/lastools/download/laszip.pdf
17. COPC-1.0-Spezifikationsseite (COPC = LAZ 1.4 + Octree; PDRF-Einschränkungen) — https://copc.io/
18. CloudCompare-Build-Dokumentation (LAS/LAZ-Unterstützung hängt von LASzip / Plugin ab) — https://github.com/CloudCompare/CloudCompare/blob/master/BUILD.md
19. Library of Congress FDD: LAS-1.4-Beschreibung (allgemeinverständliche Sprache + Erhaltungskontext) — https://www.loc.gov/preservation/digital/formats/fdd/fdd000418.shtml
20. OGC-Ankündigung (nur Kontext, nicht für harte Daten) — https://www.ogc.org/announcement/ogc-announces-publication-of-the-laz-1-4-community-standard/