OTL

AWV standaardiseert de informatie over de assets/infrastructuurobjecten in haar beheer in een ObjectTypenBibliotheek (OTL). 


BIM schema

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 AWV OTL  is een objecttypenbibliotheek van alle weginfrastructuurobjecten, 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. 
  • AWV geeft hiermee de nodige richting aan de sector zodat de verwachtingen van AWV 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 het latere beheer en onderhoud.  

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) 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 AWV beheert en exploiteert. 

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, een brug, de verschillende delen van de verticale wegopbouw, een verkeersbord, software ... 

Elk van deze objecttypes krijgt een eenduidige definitie in de OTL zodat iedereen binnen en buiten AWV 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.

superklassen

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. De 2 belangrijkste artefacten zijn:

  • Een XMI-formaat dat toelaat om de OTL te openen in software zoals Enterprise Architect en verdere analyse en/of uitbreiding toelaat.
  • 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.

Stap 4: OTL integratie in bestaande tooling zoals Civil3D

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.

Hieronder een voorbeeld van een koppeling tussen de OTL en Civil 3D Property Sets.

Stap 5: 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 met AWV.

Domein afstemmen met OSLO

De AWV OTL is opgenomen in het Vlaamse informatiemodel Open Standaarden voor Linkende Organisaties (OSLO²) en is op die manier een Vlaamse standaard,beschikbaar als “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 AWV 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 bij het BIM-team van AWV in de vorm van opmerkingen en vragen. Deze zullen bekeken, geëvalueerd en indien nodig doorvertaald worden in de OTL, documentatie, FAQ’s, e.d..