Download formats and metadata
LAZ, LAS, E57, COPC, 3D Tiles and equirectangular JPG, with coordinate reference system, height datum and timestamp included as standard.
LAS is the ASPRS open standard for point clouds. LAZ is exactly the same file, losslessly compressed: typically five to ten times smaller without a single point or property being dropped. That is why LAZ is what you receive by default rather than LAS.
Preserved per point are the coordinates, the intensity of the return, the GPS time, the return number and the total number of returns, the scan angle, the classification, the point source and, where the cloud has been colourised, the RGB value taken from the panoramic imagery. Those extra fields are what determines what you can do later: timestamps let you separate passes, return numbers help distinguish vegetation from hard surfaces, classification lets you isolate ground level.
E57 is a different standard, defined in ASTM E2807, and suits static scanning better. Where LAZ is one unstructured cloud, E57 keeps the scans separated per setup position and can carry the associated imagery and station poses inside the same file. For exchange into CAD and modelling software that is often the more practical format.
A city-wide or nationwide point cloud is too large to download in full before you can see anything. COPC solves that without inventing a new format: a COPC file is a valid LAZ 1.4 file, but its points are internally ordered in an octree and the index sits inside the file itself. A viewer or QGIS uses an HTTP range request to fetch only the part currently in view, at the level of detail required. One file therefore serves as both a download and a streaming source, and there are no tens of thousands of separate tiles to manage.
For 3D models, meshes and photogrammetry the same principle carries the name 3D Tiles, an OGC community standard. A tileset describes in a hierarchy which level of detail applies where, so the client decides per view direction what to retrieve. For two-dimensional image layers WMTS does the same job, and that is the format that puts a dataset into QGIS or ArcGIS as a background layer without any conversion.
Panoramas are delivered as equirectangular JPG. That part is simple. What makes a panorama usable is not the image but the acquisition data supplied with it: the position of the camera station in a named coordinate reference system, the height, the orientation in heading, pitch and roll, the moment of capture and the identifier of the run the image came from.
Without that, a panorama is a picture. With it, you can measure inside it in your own software, project features from the image onto the point cloud, or work the other way round and find a location from your GIS back in the correct image. We supply that acquisition data as a table alongside the imagery, and the same values are returned through the open API, so you are not tied to our viewer in order to use them.
A file without context costs more time than it saves. Every dataset therefore carries the same fixed set of information, regardless of the system it was captured with.
That starts with the coordinate reference system, stated explicitly as an EPSG code rather than left as an assumption: in the Netherlands usually RD New (EPSG:28992) with heights in NAP, and for international projects ETRS89 or a UTM zone. Alongside it we record the height datum, the moment or period of capture, the acquisition system used, the survey round or project identifier and the file type of the layer.
That uniformity is what makes it possible to place datasets from different suppliers and different years side by side without first working out what came from where. It is also the precondition for exposing datasets in a machine-readable way: the same fields populate the layer description in a WMTS service and the responses of the open API.
