Het Beleidsdomein Mobiliteit en Openbare Werken standaardiseert de informatie over de assets/infrastructuurobjecten in een ObjectTypenBibliotheek (OTL).
@
Het doel van de OTL is het in kaart brengen, definiëren en standaardiseren van de informatiebehoefte met betrekking tot assets/infrastructuurobjecten aan de hand van een semantisch model dat als open standaard beschikbaar wordt gesteld.
De OTL is een ObjectTypenBibliotheek van alle infrastructuurobjecten, zoals beschreven in de verschillende standaardbestekken. Elk objecttype heeft daarin een eenduidige definitie, een aantal vastgelegde eigenschappen en mogelijke relaties met andere objecttypes.
Door de objecten te standaardiseren worden volgende doelstellingen gerealiseerd:
- Data kan vlot hergebruikt worden door alle belanghebbenden. We willen immers allemaal werken met betrouwbare, uniforme, continu actuele en volledige data.
- Als aanbesteder geven we de nodige richting aan de sector zodat de verwachtingen van ons als infrastructuurbeheerder en aanbestedende overheid rond informatieoverdracht duidelijk zijn voor studiebureaus, aannemers of andere projectpartners. Door die verwachtingen te uniformiseren en gedetailleerd op te nemen in de omschrijving van de opdrachten worden de gevraagde inspanning van projectpartners en de noden van de Vlaamse Overheid op elkaar afgestemd. Niet alleen binnen een specifiek project, maar ook voor de volledige levenscyclus van de assets.
De OTL vormt de basis voor de BIM modellen, zodat die modellen perfect te integreren zijn in ons ‘Master Data Model’ na oplevering van de infrastructuur. Na de ingebruikname van (delen van) de OTL en de bijgewerkte standaardbestekken en opdrachtdocumenten is het aanleveren van OTL conforme (as-built) gegevens een basisvereiste voor alle BIM-projecten en opdrachten.
Aan de slag met OTL
@
Stap 1
OTL implementatiemodel als vertrekpunt
De OTL wordt beschikbaar gesteld als implementatiemodel(len) op de publicatieomgeving.
De productieomgeving (vanaf de lente 2020 e.v.) bevat de definitieve implementatiemodellen en is te raadplegen op wegenenverkeer.data.vlaanderen.be.
De testomgeving bevat alle implementatiemodellen inclusief diegene die in opbouw/review zijn en is te raadplegen op wegenenverkeer-test.data.vlaanderen.be.
Er zijn 2 soorten implementatiemodellen beschikbaar op de publicatieomgeving.
- Deel-implementatiemodellen lichten een bepaald thema toe of bevatten ondersteunende concepten maar streven geen volledigheid na voor data-aanleveringen.
- Het master-implementatiemodel bevat alle objecttypes die in de volledige OTL voorkomen. Dit dient ook als basis voor data-aanleveringen. Raadpleeg het master-implementatiemodel.
De OTL is opgebouwd uit 3 basiscomponenten: objecttypes, attributen en relaties. Elke basiscomponent komt overeen met een bepaald deel van de assets die de infrastructuurbeheerders beheren en exploiteren.
1. Objecttypes
Objecttypes vormen de bouwstenen van de OTL. Ze zijn de virtuele tegenhanger van de fysieke realiteit. Elk object waaruit de realiteit is opgebouwd kan een objecttype zijn in de OTL. Voorbeelden van objecttypes in de OTL zijn een camera-installatie, een verlichtingspaal, een kast de verschillende delen van de verticale wegopbouw, een verkeersbord, software-componenten, ...
Elk van deze objecttypes krijgt een eenduidige definitie in de OTL zodat iedereen steeds ondubbelzinnig over hetzelfde spreekt.
2. Attributen
Aan elk object zijn een aantal attributen gekoppeld die het objecttype verder specificeren. Dit kan bv. gaan om de kleur van een paal, het merk en type van een camera, het asfaltmengsel dat gebruikt is bij een verharding, de hoogte van een seinbrug, het schakelplan van een laagspanningsbord,...
Aan elk attribuut wordt ook een definitie gegeven zodat het duidelijk is waar dit attribuut over gaat. Bv. is de ‘hoogte van een seinbrug’ de vrije hoogte onder de seinbrug, het hoogste punt van de seinbrug of de maaiveldhoogte van de locatie waar de seinbrug geplaatst is?
Elk attribuut krijgt in de OTL ook een datatype toegekend voor de mogelijke waarden, bv. is het een getal (meter, volt, aantal ...), een keuzelijst, een bijlage (PDF, Excel ...), een tekstveld, …
3. Relaties
Een object staat zelden volledig alleen in de fysieke realiteit. Het bestaat net in relatie met andere objecten. Bv een camera is bevestigd aan een paal, een aftakking voedt een verkeersregelaar. Binnen de OTL worden deze relaties ook vastgelegd zodat enkel relaties gebruikt kunnen worden die effectief overeenkomen met de realiteit.
@
Stap 2
Gecoördineerde versie van objecttypes o.b.v. hun superklassen
In de implementatiemodellen van de OTL wordt gebruik gemaakt van overerving tussen verschillende klassen.
Voor een volledig en correct beeld op een implementatiemodel moet gekeken worden naar de gecoördineerde, samengevoegde klassen. Het zijn enkel deze die instantieerbaar zijn en waarvoor data aangeleverd kan worden.
Overerving wordt toegepast wanneer een aantal klassen gemeenschappelijk gedrag hebben. Dit gemeenschappelijk gedrag kan zowel over attributen als over relaties gaan. Deze overerving blijft zichtbaar in de implementatiemodellen maar moet opgelost worden om tot de juiste, volledige objecttypes te komen.
Een overerving wordt in de OTL aangeduid door een relatie van het type “generalisatie”. Op basis van de generalisaties kan bepaald worden wat de superklassen zijn van een objecttype en kan dus ook de afdaling gedaan worden. Alle attributen en relaties van een superklasse zijn integraal van toepassing op een subklasse.
Instantieerbare klassen -klassen waarover data uitgewisseld wordt- die bij objecttypes horen zijn alle klassen in de OTL die niet van het type “abstracte” zijn. Een abstracte klasse kan herkend worden doordat ze zich steeds bevindt in het voc abstracten.
Stap 3
OTL in het SQLite artefact
Naast de mens-leesbare versie van de OTL zijn er ook een aantal machine-leesbare artefacten die gepubliceerd worden. Op basis hiervan kan de OTL verder bevraagd worden voor analyses of gebruikt worden in software toepassingen. Het belangrijkste artefact is:
- Een SQLite-formaat waarin de volledige OTL is opgenomen als een relationele databank. Hierin zijn ook de gecoördineerde versies van alle instantieerbare objecttypes terug te vinden waarin alle overervingen opgelost zijn.
Artefacten als bijproducten van de OTL
- Geometrie Artefact
Het geometrie artefact (GA) slaat de brug tussen de meetrichtlijnen zoals beschreven in het AWV Topografisch Legendeboek en de klassen in de OTL. Het vormt geen nieuwe set regels, maar koppelt de steekkaarten uit het legendeboek aan de juiste OTL-klassen, en maakt deze koppeling machineleesbaar. Zo dient het GA als leidraad bij het bepalen welke geometrie je moet koppelen aan objecten in een OTL aanlevering. Voor elk onderdeel is vastgelegd welke geometrische weergave hiervoor van toepassing is.
- Posten Mapping Artefact
Het PostenMapping artefact (PMA) slaat de brug tussen het postenboek en de klassen in de OTL. Het vormt geen nieuwe set regels, maar koppelt de posten uit het postenboek aan de juiste OTL-klassen, en maakt deze koppeling machineleesbaar. Zo kan het PMA dienen als leidraad voor het automatisch afleiden van meetstaten uit een BIM-model
De artefacten volgen in principe dezelfde releasecyclus als het de OTL. Ze kunnen geraadpleegd worden op https://wegenenverkeer.data.vlaanderen.be/ Het PostenMapping Artefact staat voorlopig enkel op de test-omgeving: https://wegenenverkeer-test.data.vlaanderen.be/
@
Stap 4
OTL Subset Tool - Subset maken voor mijn project
Omdat niet alle OTL objecten relevant zijn voor jouw project, kan je ook een subset maken van de OTL. Je extraheert als het ware enkel de OTL objecten die jij nodig hebt in je project in een aparte SQLite. Je kan deze OTL Subset tool hier terugvinden. Naast het aanmaken van een nieuwe subset kan je hier ook bestaande subsets aanpassen. Het aanpassen kan gebaseerd zijn op een nieuwe versie van de OTL, of op basis van een andere bestaande subset.
De OTL subset tool kan ook gezien worden als een handige manier om de OTL onder de loep te nemen. De OTL subset tool heeft een zoek en filter functionaliteit waardoor je OTL klassen kan filteren op basis van een klasse naam, klasse omschrijving, een attribuut naam van die klasse of een attribuut omschrijving van die klasse.
Wanneer je in de OTL subset tool een OTL klasse bekijkt, houdt deze automatisch rekening met de overerving principes waarmee de OTL is opgebouwd. Alle attributen die aangeleverd dienen te worden voor een specifieke OTL klasse, worden dus automatisch afgeleid. Verder kan je ook slechts enkele attributen selecteren in de attributenlijst, indien niet alle attributen noodzakelijk zijn om aan te leveren in een bepaalde projectfase. Alle relaties die gelegd worden met een specifieke OTL klasse, kunnen ook worden aangevinkt of worden geselecteerd in de grafische weergave van alle mogelijke relaties.
Afhankelijk van de gemaakte afspraken, wordt een projectspecifieke subset meegegeven aan de opdrachtnemer bij de project opstart, dient de opdrachtnemer zelf een subset aan te maken en hiermee aan te leveren, staat het de opdrachtnemer vrij om de subset tool te gebruiken.
Stap 5
OTL integratie in bestaande BIM/CAD toepassingen
Op basis van de SQLite versie van de OTL kunnen integraties gebouwd worden met bestaande toepassingen. De integraties worden bij voorkeur dynamisch opgebouwd omdat de OTL onderhevig kan zijn aan wijzigingen door nieuwe evoluties binnen een domein.
@
Stap 6
Voor wie nog een stap verder wil gaan: integratie van OTL en andere OSLO² standaarden
Om de OTL op te nemen in het datalandschap van uw eigen organisatie kan de methodologie van OSLO² gevolgd worden. Hierbij worden bestaande standaarden, zoals de OTL geïntegreerd in uw datalandschap om tot een harmonieus geheel te komen dat toelaat eenvoudig data uit te wisselen.
De OTL is opgenomen in het Vlaamse informatiemodel Open Standaarden voor Linkende Organisaties (OSLO²) en is op die manier een erkende Vlaamse standaard, beschikbaar onder het “Thema Wegen en Verkeer”.
Om als OSLO²-standaard erkend te worden, wordt de OTL ontwikkeld op basis van een gemeenschappelijk proces en volgens de modelleerrichtlijnen van OSLO². De OTL is zo herbruikbaar en inzetbaar op dezelfde manier als andere standaarden die binnen OSLO² bestaan.
Daarnaast is er ook een afstemming en koppeling met andere standaarden binnen OSLO² zoals het “Thema Openbaar Domein”.
Mogelijke wijzigingen in de OTL
De definities die binnen de OTL zijn opgenomen zijn bedoeld om zo lang mogelijk stabiel te blijven. Om dit te realiseren werden ze opgemaakt in samenspraak met de domeinexperten van de verschillende fysieke objecten.
De realiteit is echter onderhevig aan veranderingen, uitbreiding,.. dus ook de OTL die deze realiteit beschrijft. Om deze mogelijke wijzigingen of uitbreidingen op te vangen, dient ook de OTL af en toe te wijzigen. Hiervoor kan steeds een aanvraag gedaan worden. Dat kan via volgend formulier of via TeamBim@verzendlijst.wegenenverkeer.be