Wegwijzer 3D standaarden

Geonovum Handreiking
Consultatieversie

Deze versie:
https://docs.geostandaarden.nl/3d/cv-hr-hr-3d-standaarden-20241106
Laatst gepubliceerde versie:
https://docs.geostandaarden.nl/3d/hr-3d-standaarden/
Laatste werkversie:
https://geonovum.github.io/hr-3d-standaarden/
Redacteur:
Yneke van Iersel (Geonovum)
Auteurs:
Yneke van Iersel (Geonovum)
Linda van den Brink (Geonovum)
Doe mee:
GitHub Geonovum/hr-3d-standaarden
Dien een melding in
Revisiehistorie
Pull requests

Samenvatting

Voor de verdere ontwikkeling van 3D-technologieën zijn standaarden voor het beheren, modelleren en delen van 3D-data onmisbaar. Ze vormen een betrouwbaar kader voor bedrijven om in te investeren en het stimuleren van hergebruik van 3D-informatie. Dit bevordert de interoperabiliteit tussen systemen en maakt een brede toepassing van 3D-informatie mogelijk in domeinen zoals stadsplanning, infrastructuurbeheer en andere ruimtelijke vraagstukken.

Dit document is een wegwijzer over het uitwisselen van 3D data. Het geeft een overzicht van de verschillende bestandsformaten die je hiervoor kunt gebruiken, geeft handvatten voor het kiezen van het juiste formaat voor de juiste situatie, en geeft in afzonderlijke hoofdstukken gedetailleerde informatie over het uitwisselen van 3D data in CityJSON, CityGML, 3D Tiles, I3S, IFC en LAZ.

Status van dit document

Dit is een consultatieversie. Commentaar over dit document kan gestuurd worden naar

1. 3D Formaten keuzehulp

Keuzehulp 3D standaarden

2. De verschillende 3D bestandsformaten

2.1 CityJSON en CityGML

In de wereld van digitale 3D-modellen van steden zijn er verschillende standaarden ontwikkeld om de opslag en uitwisseling van deze gegevens te ondersteunen. Twee van de meest prominente standaarden zijn CityGML [CityGML3-part2] en CityJSON [CityJSON]. CityGML is al sinds 2008 een gevestigde standaard, ontwikkeld door het Open Geospatial Consortium (OGC), terwijl CityJSON een nieuwer en lichter alternatief biedt dat in 2020 door hetzelfde consortium werd erkend. Beide standaarden zijn gebaseerd op hetzelfde datamodel, dat in het CityGML conceptueel model [CityGML3] is vastgelegd. CityGML maakt gebruik van een op XML gebaseerde structuur, terwijl CityJSON de eenvoud en flexibiliteit van JSON benut. Hoewel ze hetzelfde doel nastreven, namelijk het modelleren van 3D-steden en landschappen, verschillen de formaten sterk in hun technische aanpak en gebruiksscenario’s. Een kernconcept binnen zowel CityGML als CityJSON, is het gebruik van niveaus van detail (Levels of Detail, LOD). Dit concept maakt het mogelijk om objecten op verschillende schaalniveaus te modelleren, variërend van eenvoudige 2.5D-terreinmodellen (LOD0) tot zeer gedetailleerde 3D-modellen inclusief interieurmodellen van gebouwen (LOD4).

Het belangrijkste verschil tussen CityGML en CityJSON ligt in de manier waarop de gegevens worden geëncodeerd. CityGML gebruikt XML, een tekstgebaseerd formaat dat bekend staat om zijn robuustheid en flexibiliteit, maar dat vaak als zwaar en moeilijk te bewerken wordt beschouwd. CityJSON daarentegen is veel compacter en maakt gebruik van het JSON-formaat, dat veel eenvoudiger te verwerken is door programmeurs. Een ander belangrijk verschil is de bestandsgrootte. CityJSON-bestanden zijn aanzienlijk kleiner dan CityGML-bestanden; vaak wordt een CityGML-bestand door CityJSON met een factor 7 verkleind [CityJSON]. Dit maakt CityJSON aantrekkelijker voor situaties waarin bandbreedte en opslagcapaciteit beperkte middelen zijn. Het nadeel van CityJSON is echter dat het sommige complexe topologische relaties, zoals die met water of terrein, niet volledig ondersteunt [CityJSONImplementation].

CityJSON is een open standaard, beheerd door de gemeenschap, en heeft de status van "Community Standard" binnen het Open Geospatial Consortium (OGC). Dit betekent dat het breed ondersteund wordt door verschillende partijen en softwarepakketen (https://www.cityjson.org/software/). De standaard staat open voor continue verbetering door een brede gebruikersbasis. CityJSON is ontwikkeld met de gedachte om 3D-stadsmodellen toegankelijker te maken voor programmeurs. Het is een gebruiksvriendelijk formaat dat zich richt op eenvoud in het lezen, verwerken en creëren van datasets. CityJSON legt, net als CityGML, veel nadruk op semantiek, wat essentieel is voor toepassingen waar gedetailleerde beschrijvingen van stedelijke objecten nodig zijn. Het formaat is voornamelijk gericht op analyse in plaats van visualisatie en wordt gebruikt in statische toepassingen, zoals stedelijke planning en 3D-dataverwerking. Daarnaast ondersteunt het ook dynamische toepassingen door middel van CityJSON-Sequence, een uitbreiding die data streaming mogelijk maakt, waardoor grote datasets stapsgewijs kunnen worden verwerkt zonder de volledige dataset in één keer te hoeven laden, wat efficiëntie verhoogt bij real-time verwerking van stedelijke data

Versie 2.0 van CityJSON, geadopteerd door het OGC, biedt ten opzichte van CityGML enkele extra functionaliteiten die specifiek zijn voor JSON. Hierdoor kunnen ontwikkelaars eenvoudig API’s en tools bouwen die compatibel zijn met CityJSON. De JSON-specifieke extensiemechanismen maken het mogelijk om de basisstructuur uit te breiden zonder de kern van de standaard te doorbreken. Meer details en specificaties over CityJSON zijn te vinden op de officiële website, zoals de specificaties van versie 2.0.1 [CityJSONSpecifications].

CityGML daarentegen is een uitgebreidere standaard evenveel gedetailleerde semantische informatie biedt over stedelijke objecten. CityGML is een officiële OGC-standaard die ontwikkeld is door het Open Geospatial Consortium zelf. Het formaat is gebaseerd op een UML-model dat een gemeenschappelijke basis biedt voor de uitwisseling en opslag van virtuele 3D-stadsmodellen. CityGML wordt breed ondersteund door zowel commerciële als open-source software en biedt uitgebreide mogelijkheden voor zowel geometrische als semantische modellering van steden. Een groot voordeel van CityGML is dat het compatibel is met een breed scala aan softwarepakketten, van commerciële oplossingen zoals Autodesk en ESRI tot open-source projecten zoals 3DCityDB. Dit maakt CityGML zeer geschikt voor grote, complexe projecten waarin zowel geometrie, semantiek als topologie een belangrijke rol spelen. Meer technische details over de werking van CityGML zijn te vinden in de officiële documentatie van het OGC, zoals beschreven op [CityGML3].

2.1.1 Wanneer CityGML en CityJSON gebruiken?

  • Als je werkt aan grote, complexe projecten waarin gedetailleerde semantische informatie en verschillende niveaus van detail essentieel zijn, zoals in stedelijke infrastructuur of grootschalige stadsmodellering, dan is CityGML de aangewezen standaard.
  • Als je meer gericht bent op het ontwikkelen van API’s, tools of analyses waarbij eenvoud, compactheid en snelle verwerking belangrijk zijn, dan is CityJSON een betere keuze.

2.2 3D tiles

De 3D Tiles standaard biedt een open manier om grote hoeveelheden 3D-geogegevens zoals gebouwen, point clouds en infrastructuur te streamen en weer te geven. De standaard is ontwikkeld door Cesium, nu onderdeel van Bentley Systems, en is een door OGC goedgekeurde specificatie [OGC3DTiles]. Het maakt gebruik van een hiërarchische structuur, waardoor data snel kan worden ingeladen en aangepast aan de schaal van de applicatie. Dit maakt 3D Tiles bijzonder geschikt voor dynamische visualisaties in omgevingen zoals webapplicaties, waar schaalbaarheid en prestatie cruciaal zijn. In tegenstelling tot andere standaarden is de focus vooral op visualisatie, en minder op geavanceerde semantische analyses.

Wat 3D Tiles onderscheidt, is de mogelijkheid om dynamische niveaus van detail (Level of Detail, LoD) te ondersteunen. Dit betekent dat objecten afhankelijk van de kijkafstand en prestaties met meer of minder detail worden weergegeven, wat cruciaal is voor efficiënte visualisatie van grote datasets. Deze standaard is met name gericht op visualisatie en minder op diepgaande semantische analyses, waardoor het ideaal is voor toepassingen zoals het weergeven van stedelijke 3D-modellen, puntenwolken en topografische data. Dankzij de hiërarchische structuur van 3D Tiles kunnen datasets efficiënt worden georganiseerd en gestreamd, wat de prestaties verbetert in zowel statische als dynamische weergaveomgevingen. Deze standaard vereist echter specialistische kennis op het gebied van rendering en ruimtelijke gegevensbeheer om optimaal benut te worden. Voor meer informatie, zie de bronnen: [Handreiking3DTiling] en [3DTiles].

3D Tiles is eén van de open standaarden van het OGC, waar het de status van een "community standard" heeft. Dit bevordert interoperabiliteit tussen verschillende softwareplatformen (zoals CesiumJS, gaming engines en ESRI software), wat zorgt voor bredere adoptie en uitwisseling van 3D-geogegevens. De standaard maakt gebruik van tiling-technieken waarbij grote datasets in kleinere, beheersbare tiles worden opgedeeld om efficiëntere streaming en weergave mogelijk te maken. Een belangrijk voordeel van 3D Tiles is de flexibiliteit om te worden toegepast in diverse contexten, zoals stedelijke planning, infrastructuurbeheer en crisisbeheersing. Dit wordt verder ondersteund door de [OGCAPITiles] en de [3DGeoVolumes], die de integratie in verschillende software-ecosystemen mogelijk maakt. Verdere details over de standaard en toepassingen zijn te vinden op de OGC-website.

3D Tiles ondersteunt geen geprojecteerde coördinaatsystemen. 3Dtiles wordt altijd gedefinieerd in WGS 1984 en een ellipsoïdaal verticaal coördinatensysteem (EPSG 4978). Dit is belangrijk om te beseffen als je 3D tiles wil combineren met bestaande geografische informatie in EPSG 28992 (RD New).

2.2.1 Wanneer 3D tiles gebruiken?

  • Als je werkt aan toepassingen waarbij efficiënte visualisatie en streaming van grote 3D datasets cruciaal zijn is 3D Tiles een uitstekende keuze.
  • Je wil de data op verschillende (web)softwareplatforms kunnen gebruiken.
  • Als je werkt in een globale context en geografische projectie (zoals WGS1984).

2.3 Indexed 3D Scene Layer (I3S)

De Indexed 3D Scene Layer (I3S) standaard is specifiek gericht op het efficiënt beheren, analyseren en visualiseren van grote hoeveelheden 3D-geo-informatie. Deze standaard is ontwikkeld door Esri en is een landing page over I3S bij OGC [I3SlandingpageOGC]. Deze standaard is ontworpen voor het streamen van 3D-data zoals gebouwen, terreinmodellen, mesh en puntwolken, en wordt veelal toegepast in GIS-toepassingen zoals Esri's ArcGIS-platform en in Cesium [I3SCesiumJS]. In tegenstelling tot 3D Tiles van Cesium, dat primair is gericht op visualisatie, biedt I3S ondersteuning voor zowel visualisatie als GIS-analyse, wat het bijzonder geschikt maakt voor gedetailleerde ruimtelijke analyses.

I3S maakt gebruik van een hiërarchische, op knooppunten gebaseerde ruimtelijke indexstructuur, waarin elke knoop (node) gegevens bevat zoals geometrie, texturen en attributen. Deze structuur zorgt voor een efficiënte organisatie van 3D-data. Het doel van deze index is om snelle toegang te bieden tot relevante gegevensblokken, zie hoofdstuk 8 van [I3S]. Het systeem ondersteunt dynamische niveaus van detail (LoD), zodat objecten afhankelijk van de kijkafstand en de rekenkracht van het apparaat met meer of minder detail worden weergegeven. Dit maakt het mogelijk om 3D-modellen efficiënt te streamen en te visualiseren zonder prestatiedalingen, vooral binnen GIS-omgevingen. Daarnaast is I3S niet alleen geschikt voor statische visualisaties, maar ook voor analytische toepassingen, waardoor het een veelzijdige keuze is voor gebruikers die zowel ruimtelijke analyses als visualisatie van 3D-modellen willen uitvoeren.

Hoewel I3S als open standaard door de OGC is aangenomen, is het grotendeels beheerd door Esri. De I3S-standaard is ideaal voor gebruikers binnen het Esri-ecosysteem, voor verdere specificaties kun je kijken in de I3S Specificatie [I3Sspecification].

2.3.1 Wanneer I3S gebruiken?

  • Snelle data-invoer van zowel feature layers, mesh layers en point cloud layers.
  • Je wil 3D-geo-informatie zowel visualiseren als analyseren binnen (ESRI) GIS platformen.
  • Je wilt 3D-data aanbieden of gebruiken in een globale en lokale context met een geografisch of geprojecteerd coördinatensysteem (zoals EPSG 28992 (RD New)).

2.4 Industry Foundation Class (IFC)

De Industry Foundation Classes (IFC) standaard, ontwikkeld door [buildingSMART], is een open dataformaat dat voornamelijk wordt gebruikt binnen Building Information Modelling (BIM) voor het uitwisselen van bouwinformatie en -modellen. Deze standaard is ook internationaal erkend als [ISO16739], wat de brede acceptatie en het belang binnen de bouwindustrie onderstreept. De IFC-standaard wordt vanuit de BIM-wereld steeds vaker uitgewisseld naar de GIS-wereld. De IFC-standaard kan worden geconverteerd naar verschillende GIS standaarden met behoud van gedetailleerde 3D-modellen, wat essentieel is voor geïntegreerde stadsplanning, infrastructuurbeheer en ruimtelijke analyses. Deze brug tussen BIM en GIS maakt het eenvoudiger om bouw- en infrastructuurgegevens in een bredere geo context te plaatsen, waardoor betere beslissingen en analyses mogelijk zijn.

De IFC standaard is ontworpen om uitwisseling en samenwerking te bevorderen tussen verschillende softwareplatforms die worden gebruikt in de bouwsector. De IFC-standaard maakt het mogelijk om verschillende soorten bouwinformatie vast te leggen en uit te wisselen, waaronder 3D-modellen van bouwwerken, technische details en zelfs bouwplanningen. Technisch gezien omvat IFC een breed scala aan gegevensstructuren en representatiemodellen. De huidige versie (IFC4.3) bevat meer dan 700 entiteiten en ondersteunt verschillende geometrische representaties zoals sweep volumes, booleaanse CSG-modellen, en B-rep-modellen (Boundary representation). Deze worden vaak gebruikt om complexe 3D-objecten in bouwprojecten te beschrijven. In GIS-applicaties wordt veelal B-rep ondersteund. Voor de uitwisseling is het van belang dat de IFC standaard gestuurd wordt dat de informatie in een bruikbare geometrische representatie geexporteerd wordt. Veelgebruikte geometrieën in IFC worden gegenereerd via 'primitive instancing', waarbij objecten worden gedefinieerd op basis van parameters zoals vormen en profielen. Dit maakt IFC flexibel en geschikt voor complexe bouwprojecten, van kleine gebouwen tot grootschalige infrastructuren. Meer informatie kun je lezen in de documentatie van [IFC4.3].

Qua gebruiksvoorwaarden en specificaties is IFC een open standaard, wat betekent dat de specificaties vrij beschikbaar zijn voor gebruik en implementatie. Dit bevordert interoperabiliteit tussen verschillende softwarepakketten binnen de bouwsector. Maar IFC wordt voornamelijk gebruikt voor statische datasets, wat betekent dat het minder geschikt is voor dynamische of tijdsgevoelige gegevens. De bestanden kunnen worden opgeslagen in verschillende formaten, zoals XML, JSON EN STEP. Ondanks de openheid, is de IFC standaard vrij complex en vereist specialistische kennis voor volledige implementatie. De [GeoBIMbenchmark] heeft informatie gepubliceerd over de intergratie van de GIS en BIM, waaronder het gebruik van de IFC standaard in GIS software.

2.4.1 Wanneer IFC gebruiken?

  • Bij complexe bouwprojecten waarbij gedetailleerde bouwinformatie en 3D-modellen van belang is, zoals in architectuur, engineering en bouw (AEC);
  • Wanneer de BIM-informatie open aangeboden wordt en uit wil wisselen, zodat het gecombineerd kan worden met andere BIM-modellen of met Geo-modellen.

2.5 LAZ

Het LAZ-formaat is een gecomprimeerde versie van het LAS-formaat (LIDAR Aerial Survey), ontworpen in 2007 om efficiënt grote hoeveelheden 3D puntenwolkdata op te slaan en uit te wisselen. LAS is een OGC community standaard [LAS] in de geospatiale wereld voor het beheren van LiDAR-gegevens, waarin naast de geometrie, ook attributen zoals intensiteit, classificatie en kleurinformatie worden opgeslagen. Hoewel LAS-bestanden bijzonder nuttig zijn, hebben ze vaak een grote bestandsgrootte. Het LAZ-formaat biedt hiervoor een oplossing door middel van verliesloze compressie, die de bestandsgrootte tot wel 10 à 15% van de originele LAS-bestanden kan terugbrengen. Hierdoor kunnen grote datasets sneller en efficiënter worden opgeslagen en gedeeld, zonder dat dit ten koste gaat van de gegevenskwaliteit.

Technisch gezien heeft het LAZ-formaat dezelfde binaire structuur als het LAS-formaat [LASSpecification1.4], waarbij data compact wordt opgeslagen voor efficiënte verwerking. Het binaire formaat van LAS biedt hoge prestaties voor het lezen en schrijven van XYZ-hoogtedata en specifieke metadata van een LiDAR-missie, zoals GNNS-tijd, intensiteit, het aantal echo's en returnnummers. Dit maakt gestandaardiseerde uitwisseling van data mogelijk zonder dat er extra metadatabestanden nodig zijn. De compressie in LAZ wordt gerealiseerd door efficiënte algoritmen, zoals entropiecodering en codering met variabele lengte, die de gegevens compact opslaan zonder kwaliteitsverlies.

Gebruikerservaringen op [Geoforum] wijzen erop dat het LAZ-formaat breed geaccepteerd is binnen de geospatiale gemeenschap, mede door de interoperabiliteit met diverse softwaretools en het open-source karakter van de standaard. Veel GIS- en LiDAR-verwerkingssoftware ondersteunen zowel LAS- als LAZ-bestanden, wat betekent dat gebruikers niet beperkt zijn tot één specifieke tool voor het verwerken van deze data. Omdat de bestanden kleiner zijn, worden ze sneller geladen, wat vooral voordelen biedt bij het werken met grote datasets of wanneer snelle toegang tot de gegevens vereist is. In de inventarisatie puntenwolken in Nederland [WP1] wordt veelal de gecomprimeerde LAS standaard gebruikt.

2.5.1 Wanneer LAZ gebruiken?

  • Als de gegevensnauwkeurigheid van grote puntenwolkenbestanden belangrijk is;
  • Als de puntenwolken bestanden zodanig groot zijn, dat compressie belangrijk is;
  • Wanneer je de data van puntenwolken wil analyseren;
  • Wanneer open source de maatstaaf is.

3. 3D GeoVolumes API

Zoals in het vorige hoofdstuk beschreven, bestaan er verschillende standaarden voor 3D geodata. Sommigen beschrijven alleen een bestandsformaat, anderen zowel het bestandsformaat als de manier waarop de data toegankelijk wordt gemaakt. De OGC 3D GeoVolumes API [3DGeoVolumes] specificeert zelf geen specifiek formaat voor 3D geodata, maar beschrijft alleen hoe je 3D geodata aan kan bieden in verschillende formaten, waarbij de gebruiker het formaat kan kiezen en data kan selecteren.

OGC API - 3D GeoVolumes facilitates efficient discovery of and access to 3D content in multiple formats based on a space-centric perspective.

Een API is een Application Programmimg Interface - een manier waarop twee computers, een server en een client, met elkaar communiceren. De server is in dit geval de computer die 3D geodata aanbiedt, de client is de computer die data vraagt.

Het Open Geospatial Consortium (OGC) heeft een hele reeks APIs gestandaardiseerd. Het vormen bouwstenen waarmee je geodata op een standaardmanier kan serveren. Denk bijvoorbeeld aan het bekijken van geodata in een web viewer, het bladeren door collecties van geodata, het opvragen van een geo-object op basis van het id, of het opvragen van geo-objecten binnen een bounding box of tijdsperiode.

De 3D GeoVolumes API [3DGeoVolumes] standaard bevat specifieke bouwstenen voor 3D geodata. Centraal in deze standaard staat het idee van Bounding Volumes (ook een centraal begip in 3D Tiles en soms aangeduid als 3D Containers). Dit zijn 3-dimensionale bounding boxes waarbinnen zich ofwel andere bounding boxes, ofwel 3D geo-objecten kunnen bevinden. De Bounding Volumes kunnen verschillende vormen hebben. Elke Bounding Volume vormt een collectie die de gebruiker kan opvragen.

Een client kan bij een GeoVolumes API een specifiek GeoVolume opvragen op basis van id. Ook kan een client geo-objecten binnen een zelf gespecificeerde 3D bounding box opvragen, al dan niet binnen een specifiek Geo-Volume.

In de standaard worden 3D Tiles [3DTiles] en i3s [I3S] specifiek genoemd als ondersteunde formaten, maar het is ook toegestaan om andere formaten te serveren, bijvoorbeeld CityGML [CityGML3-part2], CityJSON [CityJSON] of glTF [glTF].

3.1 Wanneer 3D GeoVolumes gebruiken?

A. Referenties

A.1 Informatieve referenties

[3DGeoVolumes]
OGC API - 3D GeoVolumes. Open Geospatial Consortium. 2022. Draft. URL: https://docs.ogc.org/DRAFTS/22-029.html
[3DTiles]
3D Tiles Specification 1.1. Open Geospatial Consortium (OGC). 2023-01-12. Approved. URL: https://docs.ogc.org/cs/22-025r4/22-025r4.html
[buildingSMART]
buildingSMART. buildingSMART. 2024. Approved. URL: https://technical.buildingsmart.org/standards/ifc
[CityGML3]
OGC City Geography Markup Language (CityGML) Part 1: Conceptual Model Standard v3.0. Open Geospatial Consortium. 2021-09-13. Approved. URL: https://docs.ogc.org/is/20-010/20-010.html
[CityGML3-part2]
OGC City Geography Markup Language (CityGML) Part 2: GML Encoding Standard. Open Geospatial Consortium. 2023-06-20. Approved. URL: https://docs.ogc.org/is/21-006r2/21-006r2.html
[CityJSON]
CityJSON Community Standard 2.0. Open Geospatial Consortium. 2023-10-20. Approved. URL: https://docs.ogc.org/cs/20-072r5/20-072r5.html
[CityJSONImplementation]
CityJSON: CityGML v3.0 implementation details. Open Geospatial Consortium. 2024. Approved. URL: https://www.cityjson.org/citygml/v30/#specific-citygml-v30-features-not-supported
[CityJSONSpecifications]
CityJSON Specifications 2.0.1. Open Geospatial Consortium. 2024-04-11. Approved. URL: https://www.cityjson.org/specs/2.0.1/
[GeoBIMbenchmark]
GeoBIM benchmark. ISPRS, EuroSDR, Tu Delft 3Dgeoinfo, Lund University, National University of Singapore, National Technical University of Athens. 2019. Approved. URL: https://3d.bk.tudelft.nl/projects/geobim-benchmark/task1.html
[Geoforum]
Geoforum. URL: https://geoforum.nl/
[glTF]
glTF 2.0 Specification. Khronos Group. 2021-10-11. Published. URL: https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html
[Handreiking3DTiling]
Handreiking 3D Tiling. Geonovum. 2024-07-05. Workversion. URL: https://geonovum.github.io/3d-tiling/
[I3S]
OGC Indexed 3d Scene Layer (I3S) and Scene Layer Package (*.slpk) Format Community Standard Version 1.3. Open Geospatial Consortium (OGC). 2023-01-11. Approved. URL: https://docs.ogc.org/cs/17-014r9/17-014r9.html
[I3SCesiumJS]
I3S in CesiumJS. ESRI. 2022-11-08. Approved. URL: https://www.esri.com/arcgis-blog/products/developers/3d-gis/ogc-i3s-cesiumjs/?srsltid=AfmBOoodzV1B6R25DaY9BTw5PdcnTQxqHZOJ8m58JvT2MTL7L4TbuBwI/
[I3SlandingpageOGC]
I3S landing page OGC. Open Geospatial Consortium (OGC). 2024. Approved. URL: https://www.ogc.org/publications/standard/i3s/
[I3Sspecification]
Scene Layers: Service and Package Standard. ESRI. 2023. Approved. URL: https://github.com/Esri/i3s-spec
[IFC4.3]
IFC4.3. buildingSMART. 2024. Approved. URL: https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/index.html
[ISO16739]
ISO 16739. ISO. 2024-03. Approved. URL: https://www.iso.org/standard/84123.html
[LAS]
LAS Specification. Open Geospatial Consortium. 2017. Published. URL: https://www.ogc.org/publications/standard/las/
[LASSpecification1.4]
LAS Specification 1.4. Open Geospatial Consortium. 2013-07-15. Approved. URL: https://portal.ogc.org/files/?artifact_id=74523
[OGC3DTiles]
3D Tiles OGC landing page. Open Geospatial Consortium (OGC). 2024. Approved. URL: https://www.ogc.org/publications/standard/3dtiles/
[OGCAPITiles]
OGC API - Tiles. Open Geospatial Consortium (OGC). 2022-11-10. Approved. URL: https://docs.ogc.org/is/20-057/20-057.html
[WP1]
WP1: Inventarisatie van puntenwolken in Nederland. Rijkswaterstaat, Het Waterschapshuis, Kadaster & TU Delft. 2024. In review. URL: nog niet beschikbaar
Geonovum Handreiking - Consultatieversie