Verkenning uitwisseling informatie tussen project en beheer

De CORE gemeenten, Stichting Rioned en CROW hebben de handen ineen geslagen in het DOOR-programma om voor de sector assetmanagement ​te komen tot een gemeenschappelijke informatiebasis met het volgende doel: ​

In 2030 beschikken Assetmanagers en hun (keten)partners in de openbare ruimte en infrastructuur over een samenhangend stelsel objectstandaarden in de leefomgeving om de data over hun beheerde assets efficiënt op orde te houden en uit te wisselen.​

Een deel van de objectstandaarden is al uitgewerkt en worden toegepast in diverse (keten) werkprocessen. Het DOOR-programma richt zich op de ontwikkeling van de ontbrekende standaards en uitwisselingsprotocollen, zodat een samenhangend stelsel ontstaat. Daarom is de focus van DOOR gericht op:

• Ontwikkeling van ontbrekende informatiemodellen en onderliggende ontologieën.
• Ontwikkeling van mappings tussen informatiemodellen, die de samenhang verbeteren.
• Ontwikkeling van afspraken voor de uitwisseling van data binnen (keten)werkprocessen.

De uitgangspunten voor technische oplossingen staan in de DOOR-referentiearchitectuur

De CORE-gemeenten zijn niet de enigen met het vraagstuk hoe de informatieketen tussen beheer en projecten te sluiten. Ook de netbeheerders werken aan dit vraagstuk, de waterbedrijven en de stedelijkm spoorbedrijven. Naast de ontwikkelvraagstukken vanuit de beheerders, spelen ook ontwikkelvraagstukken rondom ontwerp- en bouw. Voor NLCS speelt met name ook de wens, om een classificatie te maken (een informatiemodel) bij NLCS, waarmee de standaard gebruikt kan worden om 3D BIM-modellen uit te wisselen met IFC. Bouwbedrijven willen deze classificatie ook gebruiken om betere informatie uit tekeningen te halen voor bijvoorbeeld kostencalculaties en voorbereiding van inkooporders.

1.2.1 Informatielandschap

De hoofdstappencontext van het revisieproces wordt weergegeven in onderstaande vereenvoudigde informatiestroom tussen:

1. De landelijke registraties en de gemeentelijke beheerorganisatie.
2. De beheerder en de projectorganisatie van de gemeentelijke opdrachtgever.
3. De gemeentelijke opdrachtgever en een externe opdrachtnemer.

Het doel is te bepalen hoe NLCS en informatiemodellen het beste verbonden kunnen worden, zodat het DOOR programma kan gaan werken aan het verbinden van NLCS en IMBOR.

De scope is hierbij de situatie, waarbij de beheerder werkt met 2D GIS om informatie vast te leggen over objecten, en het project met 2D CAD werkt. Deze scope is gekozen, omdat dit bij 80% van de projecten in de openbare ruimte en infrastructuur de huidige situatie is.

Daarbij wordt gezocht naar technische oplossingsrichtingen die haalbaar zijn om te implementeren in of naast de huidige softwarepakketten die gebruikt worden, zowel aan de kant van de beheerder (areaalbeheerpakketten) als aan de kant van projecten (NLCS-applicaties).

• In hoofdstuk 2 Staan de use cases die bekend zijn bij CROW en DigiGO.
• In hoofdstuk 3 Staan de resultaten van de vergelijking die gemaakt is tussen NLCS en IMBOR.
• In hoofdstuk 4 Staat het uitwisselproces van objectinformatie tussen beheer en project.
• In hoofdstuk 5 Staan de onderzoeksvragen per processtap, en de in gebruik zijnde oplossingen om informatie uit te wisselen in deze processtap.
• In hoofdstuk 6 zijn de scenario's beschreven voor de technische oplossing om NLCS te verbinden met informatiemodellen.
• In hoofdstuk 7 Staan conclusies en aanbevelingen.

Bij de NLCS standaard zijn de afgelopen jaren relaties gelegd naar andere standaarden, met als doel informatie op basis van die standaard te kunnen transformeren naar een NLCS tekening, of informatie uit de NLCS tekening te transformeren naar data volgens die standaard. Deze relaties zijn meestal niet-semantisch opgesteld in de vorm van mappingstabellen tussen attributen in de dataset en de laagnaam en het symbool op de NLCS tekening:

• NLCS - IMGeo / Basisregistratie Grootschalige Topografie: matching naar dataset
• NLCS - GWSW / PDOK THema Stedelijk Water: alignen informatiemodel naar huidige NLCS
• NLCS - Nationale verkeersbordenregistratie: matching naar dataset
• NLCS - IMBOR: deze vergelijking is een verkenning van de verschillen en niet opgenomen in de standaard.

De meest gangbaar voorkomende use case in projecten om te ontwerpen en bouwen met NLCS start met het transformeren van de BGT en het PDOK Thema Stedelijk Water naar een CAD-tekening op basis van NLCS.

Deze use case vraagt om het reeds bestaande technisch scenario variant 1. Als dit scnenario gebruikt wordt zou de beheerinformatie wel in een gestandaardiseerde geo-dataset beschikbaar moeten zijn.

In de use case van Nijmegen wordt de informatie uit het beheersysteem omgezet naar een CAD-tekening op basis van NLCS. Met deze gegevens als ondergrond wordt een ontwerp gemaakt. Na de bouw wordt de geometrie opnieuw ingemeten voor de revisietekening. Soms gebeurt dit niet, en wordt de ontwerptekening omgezet naar een revisietekening. Daarom zijn er vaak verschillen tussen de revisietekening en de situatie buiten. De beheerder legt vervolgens de revisietekening als onderlegger in het beheersysteem, en verwerkt de verschillen. De gemeente voert ook een eigen meting uit voor de BGT, hierdoor ontstaan verschillen tussen het beheersysteem en de BGT. De uitgebreide beschrijving van de use case Nijmegen staat in dit document.

Deze use case geeft nog geen invulling aan een technische oplossingsrichting voor aansluiting van standaarden.

In de pilot Dordracht is onderzocht, of een NLCS-model drager kan zijn van de beheerinformatie, waarbij objectidentificatie nodig is, en ook objectattributen worden meegenomen in de tekening tijdens het ontwerpproces en ook naar de revisietekening. Technisch is bewezen dat het kan, als tenmisnte bij de NLCS standaard aanvullende afspraken worden gemaakt over uitwisseling van attributen bij tekeningen, en over een extra NLCS-status. De pilot werpt vragen op of dit een gewenst en haalbaar pad is voor aanlevering van mutaties: de ontwerper ontwerpt met andere geometrieën dan een beheerder aanlevert, denk bijvoorbeeld aan hartlijnen en offsets voor een weg in het ontwerp, terwijl de weg als 100 meter vak in de beheergeometrie staat. Het meenemen van de attributen en objectidentificatie zal in elk geval een heel andere werkwijze vragen van de ontwerper. Daarnaast is het de vraag, of een revisie niet onafhankelijk moet gebeuren van het ontwerp, waarbij een object wordt ingemeten en de gebruikte materialen worden geregistreerd tijdens het bouwproces.

Deze use case vraagt om technisch scenario variant 2 of technisch scenario variant 3.

De netbeheerders werken vanuit een heel andere aanname samen: de beheerinformatie is beschikbaar in CAD, op basis van NLCS. Er is geen transformatie nodig. Daarnaast worden bij de objecten attributen vastgelegd. Hierdoor ontstaat de behoefte om een eigen informatiemodel te kunnen gebruiken in combinatie met NLCS. Voor het vastleggen van atgtributen bij een CAD-tekening is door de netbeheerders een individuele oplossing geimplementeerd met een XML formaat bij een tekening van een leverancier-specifiek formaat (.dwg). De netbeheerders hebben daarnaast voor het verwerken van mutaties net als dordrecht een extra NLCS-status nodig, om onderscheid te kunnen maken tussen nieuwe objecten, en bewerkte bestaande objecten, die in de NLCS standaard nu beide de status Nieuw hebben. Dit verzoek is ingediend bij de beheerorganisatie van NLCS.

Deze use case vraagt om technisch scenario variant 2 of technisch scenario variant 3.

De use case van Amsterdam, die ook is overgenomen door Gelderland en Zuid-Holland werkt met een heel ander uitgangspunt. De opdrachtnemer krijgt de bestaande objecten en een minimale dataset mee in een op NEN 2660-2 gestandaardiseerde Geopackage (waar per object al attributen en waardelijsten in staan die uit een "objecttypenbibliotheek" komen, een gemeetne-eigen informatiemodel op basis van de NEN 2660-2 waarin standaarden als IMBOR gebruikt zijn). Na afloop van het project moet de opdrachtnemer een Geopackage terugleveren met de gemeten nieuwe objecten, de vervallen objecten en gewijzigde objecten erin. De NLCS wordt gebruikt door het projectteam, maar niet voor de overdracht naar de beheerder.

Deze use case vraagt om het standaardiseren van de techniek waarmee een minimale dataset wordt uitgewisseld, en het standaardiseren van de techniek waarmee zowel geometrische als alfanumerieke informatie wordt opgeleverd. Er is geen matching nodig tussen NLCS en informatiemodellen, omdat het gebruik van tekeningen tijdens ontwerp en bouw los staat van het opleveren van revisiegegevens.

Heel andere use cases komen vanuit de BIM Basis Infra. Daarin zitten bouwbedrijven waaronder VolkerWessels, en ingenieursbureaus waaronder Movares die gevraagd hebben om van NLCS een informatiemodel te maken, met als doel om objecten goed te kunnen classificeren in 2D CAD en 3D BIM modellen en te automatiseren met het maken van hoeveelheidsberekeningen, inkoopstaten en dergelijke. Bij de BIM Basis Infra zitten ook opdrachtgevers waaronder Gelderland, die de classificatie willen gebruiken om informatie vanuit het project over te dragen naar beheer. Deze groep wil inzetten op een duurzame oplossing voor de langere termijn.

Deze use case vraagt om technisch scenario variant 3.

Uit de use cases en huidige praktijk blijkt dat niet wordt gewerkt met één duidelijke dataflow met datatransformaties tussen beheer en project. Er zijn grote verschillen tussen organisaties.

In de praktijk wordt vooral ingezet op manieren om om te gaan met de verschillen tussen GIS en CAD, omdat veel organisaties hun beheer- en projectinformatie nog steeds in die silo's beheren. Oplossingen waarbij alleen met semantische informatie wordt uitgewisseld, worden nog niet ondersteund door de bestaande softwareleveranciers.

De CORE-gemeenten hebben DigiGO in 2024 gevraagd om NLCS en IMBOR op elkaar aan te sluiten met deze opdracht:

NLCS versie 5.x (opname IMBOR 2022), ontwerp tooling, ILS en IFC: Door NLCS 5.0 uit te bereiden met IMBOR 2022 met als resultaat NLCS 5.x, kan een eerste versie van een “ILS” conform ISO19650, worden gecreëerd, voor het werken met één gemeenschappelijke omgeving welke data levert die actueel en betrouwbaar zijn. Hiermee worden waardevolle informatie in de levenscyclus van ‘ontwerp-bouw/aanleg-Geoinformatie-beheer’ beschikbaar gesteld om zowel de dagelijkse (onderhoud)werkzaamheden uit te kunnen voeren als ook te kunnen beheren (analyseren en programmeren).

Technische bestanden en inhoudelijke adviezen zijn te vinden vanuit GitHub issue 187.

Een werkgroep met NLCS experts heeft IMBOR en NLCS vergeleken. De werkgroep heeft geconstateerd, dat een vergelijking tussen IMBOR en NLCS niet eenvoudig of eenduidig te maken is maar dat het gaat om een complexe vergelijking. De NLCS laagnamen bevatten verschillende soorten concepten zoals ruimtelijke gebieden, fysieke objecten, materialen en eenheden die al dan niet te matchen zijn met dergelijke concepten in IMBOR.

Uit het project is verder naar voren gekomen, dat zowel de gebruikersvraag als de oplossingsrichting voor de aansluiting van IMBOR en NLCS niet direct duidelijk is. Uit de reviewsessie van het project met het DOOR programmateam, CROW en DigiGO is gebleken dat er verschillen in inzichten bestaan over korte en lange termijn oplossingen. De volgende vragen zijn tijdens het project nog niet voldoende beantwoord om al een definitieve uitwerking te kunnen maken:

1. Er zijn concrete uitgewerkte use cases nodig waarbij de combinatie van NLCS en IMBOR nodig is. Uit een use case moet blijken welke uitwisselmomenten gefaciliteerd moeten worden, welke informatie moet worden uitgewisseld en met welke uitwisseltechnieken gewerkt moet gaan worden.

2. Zonder use cases kan niet goed worden bepaald, in hoeverre de standaarden geharmoniseerd moeten worden en welk semantisch alignment daarbij nodig is op korte termijn.

3. Er bestaan al diverse alignments naar NLCS, waaronder vanuit de BGT en het PDOK Thema Stedelijk Water. Ook de netbeheerders en waterbedrijven werken aan informatiemodellen die moeten aansluiten op NLCS. De beheerorganisatie van NLCS heeft gevraagd, om te zorgen dat er niet voor iedere uitwisseling of datatransformatie andere alignments en andere uitwisselformaten ontstaan en dit project in een bredere context te bekijken.

4. De opdrachtgever is gevraagd om een voorstel te doen voor de wijze van structurele financiering van een eventueel alignement tussen IMBOR en NLCS. Dit kan niet worden begroot vanuit bestaande beheerbudgetten. Hoe complexer de alignment, hoe meer werk om deze actueel te houden met nieuwe versies van de beide standaarden.

Deze vraag is onderschat in de opdracht omdat geen duidelijke architectuur vanuit een use case beschreven is. Daarom is niet duidelijk wat gevraagd wordt van welk type softwareleverancier. Daarom is dit onderdeel niet uitgevoerd.

Deze vraag is onderschat in de opdracht omdat gebleken is dat er geen duidelijke use case is die leidt tot aanvullingen in de BIM Basis Infra, en de sector eerst aan het werk zal moeten gaan met stelselafspraken om dit goed in te kunnen vullen.

Deze vraag is onderschat in de opdracht omdat gebleken is dat dit een langere termijn ontwikkeling vraagt waar een veel grotere investering voor nodig is. Er wordt in samenwerking met de BIM Basis Infra een projectplan opgesteld dat zal worden ingebracht in het Bestuursakkoord Digitale Gebouwde Omgeving '27. Het project zal zich richten op het ontwikkelen van een ontwerpclassificatie op basis van NLCS en het maken van implementatievoorbeelden, waarbij de uitwisseling tussen beheer (IMBOR) en project (NLCS) één van de voorbeelden is.

Onderzoeksvragen:

• Hoe (met welke technologie / taal / uitwisselformaat) wordt het objectenpaspoort aangeleverd?
• Hoe kan men hierin de objecttypen, kenmerken en domeinwaarden herkennen uit IMBOR, GWSW of de andere standaarden?

Onderzoeksvragen:

• Hoe (met welke technologie / taal / uitwisselformaat) wordt de minimale dataset voor de oplevering van informatie uit projecten aangeleverd?
• Moet onderscheid gemaakt worden tussen gemuteerde of nieuwe objecten?

1. De Geopackage-oplossing is hierboven al beschreven.

2. De netbeheerders hebben een oplossingsrichting voor xml/xsd uitgewerkt, waarbij in xsd de minimale dataset wordt aangeleverd. Deze oplossing ligt dicht bij de technologie die bij alle CAD pakketten beschikbaar is en is daarom gekozen. Er is geen standaard manier om in xsd te refereren aan de informatiemodellen, deze oplossing is daarom minder makkelijk schaalbaar.

3. In het Digitaal Stelsel Gebouwde Omgeving wordt voorgesorteerd op uitwisseling van ontwerpen in IFC; daarbij kan de open BIM standaard IDS worden gebruikt. Dit wordt nog niet gebruikt in de openbare ruimte en infra, omdat de 2D CAD pakketten (nog) niet worden geleverd met mogelijkheid om uit te wisselen in IFC.

4. Daarnaast kan men uiteraard in linked data de minimale dataset definiëren (SHACL). Dit wordt nog zelden gebruikt omdat dit specifieke nieuwe digitale vaardigheden vraagt.

Onderzoeksvragen:

• Hoe (met welke technologie / taal / uitwisselformaat) wordt geometrie in CAD uitgewisseld? Er is geen open uitwisselformaat bij NLCS, er wordt gewerkt met bestandsformaten van leveranciers dgn, dxf en dwg.
• Hoe wordt gewerkt met objectidentificatie in CAD, en kan men de identificatie van bestaande objecten meenemen tijdens het ontwerp? Dit gebeurt nu nog niet, de ontwerper werkt soms ook met andere detailniveau's van uitwerkinng, of kleinere samenstellingen dan de beheerobjecten.
• Hoe (met welke technologie / taal / uitwisselformaat) komt het objectpaspoort van de beheerder in CAD? Hier is op dit moment geen oplossing voor, alleen bij symbolen kunnen de CAD-pakketten onderling sttributen uitwisselen.
• Hoe (met welke technologie / taal / uitwisselformaat) komt de minimale dataset in CAD (als de ontwerper handmatig in moet vullen) of uit CAD (als informatie uit laagnaam / symbool in de tekening kan worden afgeleid.)

Deze vragen vallen buiten scope van deze verkenning.

Onderzoeksvragen:

• Kunnen de mutaties automatisch worden herkend in de ontwerptekening?
• Is het huidige gebruik van statussen voldoende indien men aan de objectidentificatie kan zien of een "N" (nieuw) object op de ontwerptekening een bestaand beheerobject is?

Deze vragen vallen buiten scope van deze verkenning.

Onderzoeksvraag:

• Kan men mutaties in geometrie ten opzichte van de bestaande situatie goed identificeren?
• Mutaties in geometrie: hoe moet worden omgegaan met het verschil tussen CAD en GIS qua geometrie?
• Hoe (met welke technologie / taal / uitwisselformaat ) worden mutaties uitgewisseld?

De mutaties komen evident voort uit CAD. Toch kan men ervoor kiezen om een afspraak te maken over het leveren van revisie in geo-formaat. hierbij spelen de volgende vraagstukken:

1. De NLCS-applicaties of aanverwante applicaties zouden de gebruiker moeten ondersteunen om te zorgen dat de geometriën voldoen aan de vereisten voor transformatie naar GIS. Hiervoor zijn reeds marktoplossingen beschikbaar.
2. In NLCS is minimaal een afspraak nodig, om de identificatie van bestaande objecten uit het beheersysteem te kunnen tonen bij het object in CAD.
3. Ideaal gesproken ziet de ontwerper ook de beheerinformatie bij het obnject in CAD, daarvoor moet een afspraak worden gemaakt hoe deze kan worden verwerkt in of bij een ontwerp.
4. Indien men de informatie uit de minimale dataset niet kan afleiden uit de laagnaam, symboolnaam en de CAD-paramaters van het object, zal de ontwerper in CAD de minimale dataset moeten zien, en ontbrekende attributen moeten invullen voor oplevering van de revisietekening.
5. Om neutrale validatieservices te bouwen die bijvoorbeeld verschillen tussen tekeningen kunnen odnerzoeken, is een open uitwisselformaat van de CAD-geometrién met objectidentificatie gewenst.

Deze vragen vallen buiten scope van deze verkenning.

Onderzoeksvragen:

• Kan men door de tekening met bestaande situatie en de revisietekening te vergelijken, alle mutaties identificeren?
• Kan men door de revisietekening en de ontwerptekening te vergelijken alle wijzigingen in de uitvoering ten opzichte van het ontwerp identificeren?
• Hoe (met welke technologie / taal / uitwisselformaat ) kan worden gecontroleerd of de minimale dataset is opgeleverd?

Deze vragen vallen buiten scope van deze verkenning.

Onderzoeksvraag:

• Welke afspraken moeten gemaakt worden om individuele mutaties op te leveren?

Deze vraag valt buiten scope van deze verkenning.

Er zijn grote verschillen tussen organisaties in de inrichting van het data-uitwisselingsproces. Wel zijn enkele stappen te destilleren waarvoor collectieve oplossingen gemaakt kunnen worden op korte termijn, op basis van de bestaande werking van standaarden en bestaande open uitwisselformaten. Deze worden hieronder beschreven.

5.9.1 Korte termijn oplossingen

Om de uitwisseling van beheer- en revisiedata data te kunnen automatiseren moet dit op dit moment voor elk type uitwisselformaat, API of endpoint worden geschreven. Het zou dan ook kosten kunnen besparen in de sector, om standaard uitwisselafspraken te maken bij de huidige praktijk met GIS en CAD:

1. Uitwisselafspraken beheerdata
Doel: bestaande geometrie en objectpaspoorten leveren aan project. Er is geen gestandaardiseerde beheerdataset waarop gematcht kan worden. De huidige beheerdata conform IMBOR is voor de meeste gebruikers beschikbaar in GIS. Hiervoor zou een standaard op geo gebaseerde uitwisselafspraak gemaakt kunnen worden voor de korte termijn, eventueel zowel één met een connector om rechtsreeks data te bevragen bij de bron, als het gebruiken van de Geopackage oplossing als data wordt uitgewisseld. Met een alignment naar NLCS kan de beheerdata dan worden getransformeerd naar CAD om de bestaande situatie weer te geven. Hiervoor is elk van de drie varianten bruikbaar.

2. Uitwisselafspraken minimale datasets.
Doel: Minimale datasets specificeren voor oplevering revisie uit project. Ook voor het uitwisselen van de minimale dataset is behoefte aan een eenvoudiger uitwisselmethode dan semantisch conform de NEN 2660-2. In de praktijk blijkt dat ketenpartners en softwareleveranciers hier nog niet mee kunnen werken. De geopackage-oplossing zou hierbij gebruikt kunnen worden als tussentijdse solution architectuur. Merk op dat de informatievraag dan uitgedrukt kan worden in informatiemodellen zoals IMBOR, maar dat hier nog geen aansluiting mee ontstaat naar CAD-modellen op basis van NLCS. Wel zou de gewenste laagnaam en het te gebruiken symbool opgenomen kunnen worden in de minimale dataset. Dit vraagt wel een alignment naar NLCS.

3. Uitwisselafspraken revisiedata
Doel: Oplevering revisie met geometrie en objectpaspoorten uit het project naar de beheerder. Voor het opleveren van revisiedata is een uitwisselafspraak nodig hoe meetgegevens worden aangeleverd, en hoe de objectatributen worden aangeleverd om mutaties te kunnen verwerken. De beheerder zou daarbij het meest geholpen zijn met een geo-oplossing. De route van aanlevering van revisiemetingen met objectpaspoorten via een Geopackage met NEN2660-2 inrichting is ook hier haalbaar. Met een alignment naar NLCS kan de data vervolgens ook worden getransformeerd naar een revisietekening voor het projectteam. Projectteams en opdrachtnemers hebben nu alles ingericht om revisie op te leveren in CAD volgens de NLCS standaard. Hierbij bestaat in de huidige standaard geen mogelijkheid om bestaande objecten te identificeren, of attributen mee te leveren. Als men de mkb-opdrachtnemers niet wil overvragen met extra dataleveringen, kan een transformatiemechanisme worden bedacht om de CAD tekening op basis van NLCS om te zetten naar geodata met objectpaspoorten. Deze route werkt alleen, als de geometriën in CAD voldoen aan de voorwaarden van de geo-formaten (onder meer het sluiten van vlakken). Niet alle informatie die de beheerder nodig heeft kan automatisch uit een CAD-tekening gehaald worden, dus dit vraagt daarna nog werk van de opdrachtgevende organisatie.

4. Collectieve transformatie- en validatie
De implementatie van de standaarden en alignments gaat elke organisatie veel ontwikkelbudget kosten in het standaardiseren van het eigen werkproces, maar ook in het automatiseren van datatransformaties en validaties. Daarom wordt aanbevolen om gezamenlijk te onderzoeken of collectieve scripts, services of andere middelen voor transformatie- en validaties de implementatie kunnen helpen versnellen, en meervoudige implementatiekosten kunnen voorkomen. Als beheerdata en revisiedata worden uitgewisseld in open geo-formaten, zou een datatransformatie van en naar een "kale" NLCS-tekening zonder extra uitwisselafspraken op korte termijn het meest haalbaar zijn.

Dit hoofdstuk beschrijft de technische oplossingsrichtingen voor het verbinden van NLCS met informatiemodellen.

De meest basale oplossing werkt met matching ten opzichte van een geodataset. De huidige mappingstabellen bij NLCS, NLCS-BGT en GWSW-NLCS werken op basis van dit principe, er is een experimentele vergelijking tussen verkeersborden in NLCS en de verkeersborden in de George-database van het Nationale Dataportaal Wegen.

Dit is de goedkoopste manier om een oplossing te ontwikkelen. Het vraagt om een afspraak, dat beheerinformatie in een geoformaat wordt opgeleverd, daarnaast moet duidelijk zijn welke kenmerken meegegeven worden aan de objecten met welke domeinwaarden. Op basis van deze kenmerken kan gematch worden met de laagnaam en de symbolen uit NLCS.

Met scripts kunnen datatransformaties worden geschreven in twee richtingen: van de geodataset van de beheerder naar NLCS-CAD en weer terug.

Omdat het een vergelijking op termen is, levert deze oplossing een relatief hoge beheerlast op bij wijzigingen aan NLCS of de gematchte standaard.

Een stap verder is de oplossing, waarbij semantisch gematcht wordt aan het informatiemodel. Dit is voorbereid in de experimentele mapping van GWSW en NLCS, een ander voorbeeld is de relatie tussen verkeersborden in NLCS en de standaard verkeersborden in het in ontwikkeling zijnde Informatiemodel Verkeersborden.

De kosten van ontwikkeling zijn iets hoger. Wel kan gebruik gemaakt worden van bestaande alignments, voor IMBOR hoeft geen alignment meer gemaakt te worden naar het rioleringsgedeelte zolang dit al is gedaan bij het GWSW.

De beheerlast is gemiddeld, omdat veranderingen in de standaarden geutomatiseerd opgespoord kunnen worden en gericht verbeterd.

Een nog meer toekomstbestendige stap is het eerst opstellen van een NLCS classificatie, waarna deze geharmoniseerd kan worden met de andere domeinmodellen. Daarna kunnen eventueel alignments worden opgezet tussen de standaarden voor specifieke use cases.

Een NLCS classificatie geeft een voorbereiding op aansluiting op het digitaal stelsel gebouwde omgeving en de internationale open BIM standaarden waaronder IFC en IDS. et de NLCS classificatie kunnen zowel in 2D als 3D ontwerpen en revisietekeningen de objecten herkend worden.

De kosten voor ontwikkeling liggen hoger, en het groeipad is langer, omdat de classificatie moet worden ontwikkeld en beproefd in samenwerking met ingenieursbureaus en aannemers. De beheerders uit hte DOOR programma kunnen dit niet stand-alone realiseren, maar kunnen meedoen in het landelijke programma rondom uitwisseling van areaalinformatie bij digiGO.

De beheerlast is gemiddeld, omdat veranderingen in de standaarden geutomatiseerd opgespoord kunnen worden en gericht verbeterd.

De eerste twee varianten zijn korte termijn oplossingen die het probleem van datatransformatie tussen datasets proberen op te lossen. Hiervan heeft de beheerorganisatie van NLCS aangegeven, dat er niet te veel van dit soort relaties moet ontstaan, omdat de totale beheerlast hoog is en ook niet duidelijk is wie hier gebruik van maakt, zodat het vrijmaken van beheerbudget voor deze alignments geen prioriteit krijgt ten opzichte van het odnerhoud van de basisstandaard NLCS. Toch kan men, mits voldoende onderbouwd dat hier vraag naar is, werken aan een korte termijn oplossing voor een datatransformatie.

De derde variant is een meer lange termijn oplossing, gericht op informatiemanagement en federatief datadelen, waarbij de specifieke dataste die wordt gebruikt niet van te voren gedefinieerd hoeft te worden.

Uit de use cases en huidige praktijk blijkt dat niet wordt gewerkt met één duidelijke dataflow met datatransformaties voor het opleveren van revisies vanuit NLCS tekeningen, of voor het gebruik van de NLCS-modellen als drager van aanvullende informatie. Er zijn grote verschillen tussen organisaties. Wel zijn enkele stappen te destilleren waarvoor collectieve oplossingen gemaakt kunnen worden op korte termijn, op basis van de bestaande werking van standaarden en bestaande open uitwisselformaten. Deze worden hieronder beschreven.

In de praktijk wordt vooral ingezet op manieren om om te gaan met de verschillen tussen GIS en CAD, omdat veel organisaties hun beheer- en projectinformatie nog steeds in die silo's beheren. Oplossingen waarbij alleen met semantische informatie wordt uitgewisseld, worden nog niet ondersteund door de bestaande softwareleveranciers.

Bij het DOOR prgoramma wordt gewerkt met een datastrategie. Onderstaande vragen vormen het toetsingsmechanisme.