Downloadformaten en metadata
LAZ, LAS, E57, COPC, 3D Tiles en equirectangulaire JPG, met coördinaatstelsel, hoogtereferentie en tijdstempel er standaard bij.
LAS is de open standaard van de ASPRS voor puntenwolken. LAZ is precies hetzelfde bestand, maar verliesvrij gecomprimeerd: doorgaans een factor vijf tot tien kleiner, zonder dat er één punt of één eigenschap verdwijnt. Dat is de reden dat je bij ons standaard LAZ krijgt en niet LAS.
Per punt blijft bewaard: de coördinaten, de intensiteit van de retour, het GPS-tijdstip, het retournummer en het totaal aantal retouren, de scanhoek, de classificatie, de puntbron en, als de wolk is ingekleurd, de RGB-waarde uit de panoramabeelden. Juist die extra velden bepalen wat je er later mee kunt: op tijdstempel kun je passages scheiden, op retournummer vegetatie van harde oppervlakken onderscheiden, op classificatie maaiveld isoleren.
E57 is een andere standaard, vastgelegd in ASTM E2807, en past beter bij statisch scanwerk. Waar LAZ één ongestructureerde wolk is, houdt E57 de scans per standplaats gescheiden en kan het de bijbehorende beelden en de opstelling meenemen in hetzelfde bestand. Voor uitwisseling naar CAD- en modelleersoftware is dat vaak het handigere formaat.
Een landsdekkende of stadsdekkende puntenwolk is te groot om in zijn geheel te downloaden voordat je iets kunt zien. COPC lost dat op zonder een nieuw formaat te verzinnen: een COPC-bestand is een geldig LAZ 1.4-bestand, maar de punten zijn intern geordend in een octree en er zit een index in het bestand zelf. Een viewer of QGIS vraagt met een HTTP range request alleen het deel op dat in beeld is en op het detailniveau dat nodig is. Eén bestand functioneert daarmee tegelijk als download en als streaming bron, en je hoeft geen tienduizenden losse tegels te beheren.
Voor 3D-modellen, meshes en fotogrammetrie geldt hetzelfde principe onder de naam 3D Tiles, een community standard van de OGC. Een tileset beschrijft in een hiërarchie welk detailniveau waar geldt, zodat de client per beeldrichting bepaalt wat hij ophaalt. Voor tweedimensionale beeldlagen doet WMTS ditzelfde werk, en dat is het formaat waarmee je een dataset zonder verdere conversie als achtergrondlaag in QGIS of ArcGIS zet.
Panorama’s lever je als equirectangulaire JPG. Dat deel is eenvoudig. Wat een panorama bruikbaar maakt is niet het beeld maar de bijgeleverde opnamegegevens: de positie van het opnamepunt in een benoemd coördinaatstelsel, de hoogte, de oriëntatie in heading, pitch en roll, het tijdstip van opname en de identificatie van de rit waaruit het beeld komt.
Zonder die gegevens is een panorama een plaatje. Mét die gegevens kun je er in je eigen software in meten, objecten uit het beeld op de puntenwolk projecteren, of andersom een locatie uit je GIS terugvinden in het juiste beeld. Wij leveren die opnamegegevens als tabel naast de beelden, en dezelfde waarden komen terug via de open API, zodat je niet vastzit aan onze viewer om ze te gebruiken.
Een bestand zonder context kost meer tijd dan het oplevert. Daarom draagt elke dataset dezelfde vaste set gegevens met zich mee, ongeacht met welk systeem er is ingewonnen.
Dat begint bij het coördinaatstelsel, expliciet als EPSG-code in plaats van als aanname: in Nederland doorgaans RD New (EPSG:28992) met hoogtes in NAP, en voor internationale projecten ETRS89 of een UTM-zone. Daarnaast leggen we per dataset de hoogtereferentie vast, het opnametijdstip of de opnameperiode, het gebruikte inwinsysteem, de bijbehorende meetronde of project-identificatie en het bestandstype van de laag.
Die uniformiteit is wat het mogelijk maakt om datasets van verschillende leveranciers en verschillende jaren naast elkaar te leggen zonder eerst uit te zoeken wat waar vandaan komt. Het is ook de voorwaarde om datasets machineleesbaar te ontsluiten: dezelfde velden vullen de laagbeschrijving in een WMTS-service en de antwoorden van de open API.
