Punktwolkenformate: Überblick und praktischer Nutzen
Die Arbeit mit Laserscandaten beginnt beim Rohscan und endet oft in einem vollständig modellierten BIM-Modell. Dazwischen liegt ein komplexer Austausch zwischen verschiedenen Softwarelösungen und jede davon bringt eigene Anforderungen mit. Punktwolkenformate sind dabei mehr als nur ein Mittel zur Datenspeicherung. Sie beeinflussen maßgeblich, wie effizient Daten verarbeitet werden können, ob alle Informationen erhalten bleiben – und wie flexibel man auf neue Anforderungen im Projekt reagieren kann.
In diesem Artikel werfen wir einen Blick auf folgende Fragen: Welche Formate sind aktuell verbreitet? Wo liegen ihre Stärken und wo stoßen sie an Grenzen? Welche Formate eignen sich besonders gut, um große Punktwolken effizient zu visualisieren oder gemeinsam daran zu arbeiten?
Standardformate: Gute Basis für den Austausch
Textbasierte Formate: Offen, aber wenig effizient
Beispiel: ASCII-Dateien wie .XYZ, .CSV oder .PTS
Diese Formate stammen aus den Anfangszeiten des Laserscannings. Sie speichern Punktdaten im Klartext. Das ist einfach zu lesen und flexibel, aber nicht besonders speicherschonend.
Ein Beispiel: Eine Punktwolke mit rund einer Milliarde Punkten belegt im ASCII-Format etwa 88 GB. Zum Vergleich: in Binärformaten, wie dem e57-Format liegt dieselbe Punktmenge bei nur 27 GB und mit moderner, verlustfreier Kompression sogar bei nur 11 GB.
Ein weiterer Nachteil: Beim Einlesen müssen die Daten erst in ein nutzbares Format umgewandelt werden, was den Prozess verlangsamt. Zwar werden diese Formate von vielen Programmen unterstützt, aber in der Praxis spielen sie heute kaum noch eine Rolle, allenfalls zur Fehleranalyse oder als Notlösung bei inkompatiblen Daten.
LAS / LAZ: bewährt in der Fernerkundung
Beispiel einer digitalisierten Überfliegung.
LAS wurde ursprünglich fürs Airborne Laserscanning entwickelt. Es speichert Koordinaten als skalierte Ganzzahlen und ist robust aufgebaut. Die komprimierte Variante LAZ reduziert die Dateigröße deutlich, was bei großen Datenmengen ein echter Pluspunkt ist.
Bei terrestrischen Scans kommt das Format aber an seine Grenzen. Strukturierte Scans mit Zeilen-Spalten-Logik, Panoramabildern oder zusätzlichen Metainfos lassen sich damit nicht abbilden. Für einfache, unstrukturierte Punktwolken ist es gut geeignet, für komplexe Indoor-Projekte mit Fotodokumentation eher weniger.
E57: vielseitig, aber technisch anspruchsvoll
Schema des E57-Formats.
Quelle: https://www.ri.cmu.edu/pub_files/2011/1/2011-huber-e57-v3.pdf.
E57 wurde entwickelt, um genau diese Lücken zu schließen. Es kann sowohl strukturierte als auch unstrukturierte Scans speichern, unterstützt Panoramabilder und verwaltet zusätzliche Infos wie Scannerpositionen oder Sensordaten in einer einzigen Datei.
Diese Vielseitigkeit hat aber ihren Preis: Das Format ist technisch komplex, sowohl für Entwickler als auch für Anwender. Manche Softwarelösungen interpretieren E57 leicht unterschiedlich, was zu Kompatibilitätsproblemen führen kann, besonders bei Metadaten oder Bildern. Auch das Nachladen bestimmter Inhalte ist nicht immer performant. Das kann gerade bei großen Projekten zu Verzögerungen führen.
Trotzdem: Wer auf Standardisierung, Vollständigkeit und Zukunftssicherheit setzt, kommt an E57 kaum vorbei.
Herstellerformate: Leistungsstark, aber geschlossen
Viele Scannerhersteller setzen auf eigene Dateiformate mit voller Kontrolle über Struktur, Inhalt und Komprimierung. Diese Formate enthalten nicht nur Punktdaten, sondern auch Zusatzinfos wie Kalibrierwerte, Rohdaten oder Scannerpositionen. Für die erste Verarbeitung sind sie deshalb meist unerlässlich, beim Datenaustausch mit anderer Software wird es aber oft kompliziert.
| Hersteller | Dateiendung | Scanformat | SDK Verfügbar? |
| Zoller+Fröhlich | ZFPRJ | ZFS | Ja (kostenpflichtig, nur Windows) |
| FARO | LSPROJ | FLS | Ja (nur Windows) |
| Riegl | RSP, RPP | RDBX | Ja |
| Leica | LGS, LGSX | PTG u. a. | Ja (meist kostenpflichtig) |
| Trimble | RWP | - | Nein |
Die größte Herausforderung: Viele dieser Formate sind stark an die Hersteller-Software gebunden, oft nicht dokumentiert, und die nötigen SDKs (Software Development Kits) gibt es nur eingeschränkt oder gegen Gebühr. Dadurch entsteht eine gewisse Abhängigkeit vom jeweiligen Anbieter, was langfristig die Flexibilität einschränken kann.
Autodesk RCP / RCS: Gut integriert, aber proprietär
In Autodesk ReCap werden Punktwolkendateien vorbereitet.
Autodesk geht mit seinen Formaten RCP und RCS einen eigenen Weg: RCS speichert einzelne Scans, RCP fasst sie projektbezogen zusammen. Das Ganze ist eng in Produkte wie Revit, AutoCAD & Co. integriert, ideal also für Nutzer, die ohnehin im Autodesk-Ökosystem unterwegs sind.
Die Kehrseite: Der Austausch mit anderen Systemen ist schwierig, weil die Formate proprietär sind. Selbst mit dem SDK ist der Zugriff auf Inhalte nicht ganz einfach. Und außerhalb der Autodesk-Welt stößt man schnell an Grenzen. Zudem bringen große Punktwolken zusätzliche Hürden mit sich: Man muss sie oft manuell vorverarbeiten, und die Formate stellen hohe Anforderungen an Bandbreite und Speicher. Um flüssig arbeiten zu können, sollten die Daten lokal vorliegen.
Datenflut im Projekt: Klassische Formate stoßen an ihre Grenzen
Moderne Laserscanner erfassen pro Standort mehrere hundert Millionen Messpunkte. In großen Projekten mit vielen Standorten kommen schnell Terabyte an Daten zusammen. Selbst mit Kompression sind diese Datenmengen oft zu groß, um sie vollständig in den Arbeitsspeicher oder auf die Grafikkarte zu laden.
Ein weiteres Problem: Klassische Formate müssen meist komplett geladen werden, bevor überhaupt etwas angezeigt werden kann. Das führt gerade bei der Arbeit über Cloud oder Netzwerkspeichern zu längeren Wartezeiten.
Streamingformate setzen genau hier an. Sie organisieren Punktwolken in sogenannten Octrees, das sind hierarchische Datenstrukturen, die es ermöglichen, zuerst nur das Sichtbare zu laden und Details bei Bedarf nachzuliefern. Gleichzeitig sind die Punkte in mehrere Auflösungsstufen eingeteilt. Das erlaubt flüssiges Zoomen und Navigieren, selbst bei schwächerer Internetverbindung.
Dank dieser Struktur sinken die Anforderungen an Hardware und Netzwerk deutlich. In Kombination mit Caching-Techniken lassen sich auch riesige Punktwolken in Echtzeit visualisieren und analysieren.
Typischerweise sind diese Formate für webbasierte Anwendungen ausgelegt. Anbieter wie NavVis, Faro, PointSharePlus und andere bieten kommerzielle Lösungen an, um umfangreiche Punktwolkenprojekte in der Cloud zu speichern, zu verwalten und zu teilen.
Streamingformate im Vergleich
Sukzessive Unterteilung einer Punktwolke in eine Octree-Datenstruktur.
Quelle: https://www.cg.tuwien.ac.at/research/publications/2020/SCHUETZ-2020-MPC/
Potree wurde ursprünglich für die Darstellung im Web entwickelt. In der ersten Version wurde jeder Octree-Knoten als eigene Datei gespeichert. Das führte bei großen Projekten schnell zu Millionen Einzeldateien, was das Kopieren, Sichern und Übertragen aufwendig machte.
Potree 2 löst viele dieser Probleme durch optimierte Speicherung, moderne Kompression und eine bessere Konvertierung.
EPT (Entwine Point Tile) kommt aus dem GIS-Bereich. Es speichert viele kleine LAZ-Kacheln, kämpft aber ebenfalls mit der großen Anzahl an Dateien.
CopC (Cloud Optimized Point Cloud) ist eine moderne Weiterentwicklung: Hier steckt der komplette Octree in einer einzigen LAZ-Datei. Bestehende Tools können diese Dateien nutzen, auch wenn sie die spezielle Struktur nicht voll verstehen. Das spart Zeit beim Übertragen, ohne auf Kompatibilität zu verzichten.
Gegenüberstellung: Formate, Stärken, Herausforderungen
| Format | Vorteile | Herausforderungen |
| ASCII (.XYZ etc.) | Einfach, lesbar, flexibel | Sehr groß, ineffizient, veraltet, keine bildbasierten Metadaten |
| LAS / LAZ | Standardisiert, komprimierbar, weit verbreitet | Keine Bilder, keine strukturierten Scans, eingeschränkte Erweiterbarkeit |
| E57 | Vollständige Speicherung, inkl. Bilder und Scanstruktur | Komplex, teils inkonsistente Implementierungen, eingeschränkte Performance bei Zugriff |
| RCP / RCS | Nahtlose Autodesk-Integration | Proprietär, kaum außerhalb Autodesk nutzbar, hohe Bandbreitenanforderungen |
| Herstellerformate | Komplette Gerätedaten, leistungsfähig | Proprietär, geringe Interoperabilität |
| Potree 1 | Streamingfähig, flexibel | Viele Einzeldateien, langsamer Transfer |
| Potree 2 | Streamingfähig, kompakt, moderne Darstellung, verbesserte Konvertierung | Kein Standard, hohe technische Einstiegshürde |
| EPT | Streamingfähig, modular | Sehr viele Dateien, keine interne Struktur |
| CopC | Streamingfähig, LAZ-kompatibel, einfach zu übertragen | Noch relativ neu, technisch anspruchsvoll, ähnliche Beschränkungen wie LAZ |
Fazit
Das gewählte Punktwolkenformat hat großen Einfluss auf Speicherbedarf, Ladezeiten, Austauschbarkeit und die spätere Weiterverarbeitung. Klassische Textformate sind heute kaum noch praktikabel. Offene Standards wie E57 oder LAZ bieten eine gute Grundlage für flexible Workflows. Proprietäre Formate eignen sich oft gut für interne Prozesse, stoßen aber beim Austausch schnell an Grenzen.
Wer mit sehr großen Punktwolken arbeitet (oder in der Cloud) sollte von Anfang an auf moderne Streamingformate wie CopC oder Potree 2 setzen. Damit bleibt die Performance hoch und die Projekte skalierbar.
Praxistipp:
- Für den Austausch: auf standardisierte und komprimierte Formate wie E57 setzen.
- Für die Verarbeitung: Herstellerformate nutzen, aber im eigenen System bleiben.
- Für große Projekte, an denen kollaborativ gearbeitet wird: frühzeitig an Streaming-Strategie denken.
Qbitec geht hier mit Qbitec for Revit einen praktischen Ansatz: Die Vorteile von Streamingformaten werden direkt in Revit gebracht. Durch clevere Datenstruktur und effizientes Caching kann man auch in sehr großen Projekten schnell zwischen Detailstufen wechseln, ohne Ladezeiten oder Datenverlust. So bleibt der Zugriff auf die Punktwolke flexibel, performant und unabhängig von Projektgröße oder Netzwerkumgebung, inklusive Panorama-Integration und smarter Visualisierung.