Use Case Nijmegen

Revisieverwerking van rioleringen

CROW, in consultatie

Meer informatie over dit document
Laatste werkversie:
https://docs.crow.nl/use-cases-door/nijmegen
Geschiedenis:
Wijzigingsgeschiedenis
Redacteurs:
Elisabeth Klören (CROW)
Rosemarie Mijlhoff (OpenPerspectief)
Feedback:
GitHub Stichting-CROW/use-cases-door (wijzigingsverzoeken, nieuw issue, openstaande issues)
Annotaties door Hypothes.is (privacybeleid).

Samenvatting

Dit document beschrijft de use cases van gemeente Nijmegen voor het DOOR-programma. Het onderwerp is revisiegegevens van rioleringen uit projecten verwerken in het beheersysteem.

1. Conformiteit

Naast onderdelen die als niet normatief gemarkeerd zijn, zijn ook alle diagrammen, voorbeelden, en noten in dit document niet normatief. Verder is alles in dit document normatief.

2. Inleiding

2.1 Aanleiding

De CORE gemeenten, Stichting Rioned en CROW hebben de handen ineen geslagen 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. DOOR richt zich op de ontwikkeling van de ontbrekende standaards en uitwisselingsprotocollen, zodat een samenhangend stelsel ontstaat. Daarom is de focus van DOOR gericht op:

2.2 Gebruik van use cases

Use cases zijn het mechanisme om tot de kern door te dringen van de behoefte van de assetmanagers en hun ketenpartners. De keuze van deze use cases is kritisch, omdat de oplossing niet alleen geschikt moet zijn voor de specifieke situatie, maar ook generiek toepasbaar binnen de sector en daarmee een bijdrage leveren aan het programma DOOR.

Use cases zijn essentieel om tot praktijkgerichte resultaten te komen. Door middel van use cases uit de praktijk wordt geëxperimenteerd met nieuwe en aanvullende vastlegging van informatie om de ambitie van DOOR waar te maken.

2.3 Werkwijze

De CORE-gemeenten leveren daartoe use cases, waaruit de informatiebehoefte blijkt, die in de praktijk leeft.​ Dit gebeurt in workshops die uitgaan van een proces van ‘lerend een gezamenlijke informatiebasis ontwikkelen & verankeren’​. Beleids- cq vraagstukinhoudelijk & geo-data-experts van betrokken organisaties samen aan tafel​, over silo’s heen leren samenwerken​, elkaar, elkaars werksituatie en uitdagingen leren kennen en begrijpen​ een gemeenschappelijke taal ontwikkelen​. Een manier van werken ontwikkelen waarop we interdisciplinair en met stakeholders kunnen samenwerken​.

CROW ontwikkelt met de CORE gemeente de logische structuur en data-deel-afspraken die nodig zijn om invulling te geven aan de informatiebehoeften binnen de use case. ​

In een experimenteeromgeving wordt middels prototyping het resultaat beproefd, in samenwerking met marktpartijen, zodat er werkbare standaarden ontstaan, die softwareleveranciers kunnen toepassen.​

Het resultaat wordt vastgelegd in de DOOR-referentiearchitectuur

2.4 Use case Nijmegen

De gemeente Nijmegen is gestart met een groot project voor het op orde brengen van de informatievoorziening van het fysieke domein van de gemeente. Dit heeft geresulteerd in een programma met een doorlooptijd van 2 jaar en 21 deelprojecten. Eén van de deelprojecten is het voorkomen van informatieverlies en het stimuleren van de dataverrijking door het verbeteren en optimaliseren van het revisieproces.

Bij elke verandering binnen de gemeente verandert de data, binnen projecten gaat het om grote hoeveelheden data die door aannemers en bureaus in de vorm van revisiebestanden aangeleverd worden. Deze revisies worden niet of onvoldoende verwerkt ondanks dat hierover afspraken gemaakt zijn.

2.5 Leeswijzer

De use case wordt onderbouwd in een use case canvas, waar de met de gemeente samen vastgestelde onderwerpen aan bod komen in de volgende hoofdstukken:

  1. De toegevoegde waarde wat oplossen en waarom​ (huidige situatie)
  2. Belanghebbenden, wensen en verwachtingen met wie, voor wie en waartoe
  3. Het ontwerp​ op welke manier met het vraagstuk aan de slag (gewenste situatie)
  4. User stories​ wensen en behoeften gebruikers​
  5. Verfijnen user stories & bouwen experimenteer-omgeving incl. ontbrekende informatiemodellen
  6. Evalueren experiment & leerpunten​ de toepassing en borging​
visuele weergave van de 6 onderwerpen van het use case canvas, zoals beschreven in de tekst
Figuur 1 De onderwerpen van het use case canvas

3. Vraagstuk en toegevoegde waarde

Dit hoofdstuk beschrijft het vraagstuk en de toegevoegde waarde.

visuele weergave van de paragraven die men kan verwachten in dit hoofdstuk
Figuur 2 De vragen bij het vraagstuk en de toegevoegde waarde

3.1 Welk vraagstuk willen we oplossen?

3.1.1 Vraagstuk Informatievoorziening

De werkgroep geeft aan dat het van groot belang is om vertrouwen te hebben in het aangeleverde product. Dit houdt in dat de gegevens niet alleen betrouwbaar moeten zijn, maar ook dat de efficiëntie moet worden vergroot om kosten te verlagen. Daarnaast moet het beheer van data goed georganiseerd worden, waarbij volledige overdrachtsdossiers essentieel zijn. Daarbij geldt: om goede revisiegegevens te krijgen uit een project moet men ook goede startinformatie geven aan het project.

Verder wordt besproken welke objecten precies vastgelegd moeten worden in de BGT en/of het KLIC. De werkgroep vraagt zich af of het noodzakelijk is om een compleet overzicht te hebben van alle objecten in de openbare ruimte, of dat het voldoende is om alleen de belangrijkste objecten te registreren.

3.1.2 Vraagstuk organisatiecultuur

De werkgroep geeft aan dat het belangrijk is om een werkomgeving te creëren waarin frustratie wordt voorkomen, en waarin medewerkers met plezier en voldoening aan de slag kunnen gaan. Dit vereist het opstellen van duidelijke, eenduidige en gemakkelijk vindbare afspraken. Door deze afspraken goed vast te leggen, ontstaat er een vangnet voor iedereen in de organisatie. De werkgroep benadrukt ook dat het essentieel is om deze afspraken strikt na te leven, zodat er geen sprake is van "anarchie" binnen het team.

Daarnaast wordt het belang van samenwerking onderstreept: hoe zorgen we ervoor dat we elkaar actief opzoeken in plaats van mijden? De werkgroep ziet dit als een belangrijke factor voor het verbeteren van de onderlinge relaties en de algehele effectiviteit van de organisatie.

3.2 Voor wie is het vraagstuk?

Het vraagstuk betreft de hele organisatie, het management, en alle actoren/stakeholders, omdat onjuiste en incomplete gegevens aanzienlijke impact kunnen hebben op het beheer, de uitvoering, planningen en onderhoud. Voor deze groepen is het essentieel om duidelijke afspraken te maken over welke objecten opgenomen moeten worden en om goed aangeleverde producten in één keer in te winnen. Dit zorgt voor gestroomlijnde processen, verlaagt kosten en maakt het mogelijk om tijdig te sturen op zowel kwaliteit als de beheer- en onderhoudskosten. Het helpt deze belanghebbenden niet alleen om efficiënter te werken, maar ook om risico's en vertragingen te minimaliseren.

3.3 Welke opgave ligt aan het vraagstuk ten grondslag?​

3.3.1 Hoofdlijnen revisieproces

De hoofdstappen worden 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.
visuele weergave van de uitwisseling van informatie tussen landelijke registraties en de beheerder; tussen de beheerder en de projectorganisatie van de opdrachtgever; en tussen interne projectorganisatie en een externe opdrachtnemer.
Figuur 3 De uitwisseling van informatie tussen landelijke registraties en de beheerder; tussen de beheerder en de projectorganisatie van de opdrachtgever; en tussen interne projectorganisatie en een externe opdrachtnemer.

3.3.2 Opgave informatievoorziening

De werkgroep geeft aan dat verschillende plannen en systemen cruciaal zijn voor een goed overzicht van de gemeentelijke infrastructuur. Dit omvat het gemeentelijk rioleringsplan (GRP), het water- en rioleringsplan (WRP) en het gemeentelijk bomenplan. Daarnaast is het van belang om betrouwbaar inzicht te hebben in de kwaliteitssystemen, zodat toekomstige kosten voor beheer en onderhoud goed kunnen worden ingeschat. Het is essentieel dat er een duidelijk en transparant bestek wordt opgesteld, zodat alle betrokkenen weten waar ze aan toe zijn en er geen misverstanden ontstaan over de benodigde werkzaamheden.

3.3.3 Opgave organisatiecultuur**:

De werkgroep benadrukt dat een projectleider zich vrij moet voelen om een aannemer te benaderen voor verbeteringen. Dit is echter vaak moeilijk doordat er te weinig kennis, middelen of mogelijkheden voor sancties zijn. Het besef van het belang om in contact te treden met de aannemer ontbreekt soms. Daarnaast is het belangrijk dat het management durft te investeren in uren en capaciteit, zodat de noodzakelijke veranderingen doorgevoerd kunnen worden. Om een cultuurverandering te realiseren, is het cruciaal dat het management actief betrokken wordt en zijn steun verleent aan dit proces.

3.4 Wat zijn de grootste knelpunten?​

De grootste knelpunten binnen dit proces zijn een gebrek aan bewustzijn, conflicterende belangen en onduidelijkheden in taken, rollen en verantwoordelijkheden. Dit leidt tot een zwak verantwoordelijkheidsgevoel, problemen met tijd, geld en personele bezetting, en onvoldoende toezicht. Daarnaast ontbreekt soms het lef om gebreken te benoemen en tijdig in te grijpen bij kwaliteitsproblemen. Cruciale aspecten zoals het aanleveren van de juiste data, toezicht op de uitvoering, advies en controle tijdens het ontwerp en de revisie lopen hierdoor gevaar.

Deze knelpunten treffen verschillende partijen: aannemers bij herinrichtings- en aanpassingsopdrachten, stadsbeheer door extra kosten en tijdverlies, en gebruikers zoals ondernemers en bewoners, die last hebben van falende processen en hogere kosten. Ook werkvoorbereiding, projectleiding, vakinhoudelijke adviseurs en geo-specialisten ondervinden hinder, bijvoorbeeld doordat objecten achteraf nog ingemeten moeten worden voor de BGT of omdat ondergrondse objecten niet correct worden verwerkt in het KLIC.

3.4.1 Knelpunt: dubbele inwinning van gegevens

Voor de BGT wordt onafhankelijk van de revisiegegevens van het project, altijd door de geo-afdeling een landmeter naar buiten gestuurd en ingemeten. Omdat de aannemer ook nieuw aangebrachte objecten en aansluitingen moet inmeten voor de oplevering van revisiegegevens, wordt buiten dubbel gemeten. Het kan de moeite waard zijn om te onderzoeken, of de revisiemeting van de aannemer de basis kan zijn voor de BGT-levering.

3.4.2 Knelpunt: Te late aanlevering Klic

Voor de KLIC wordt gebruik gemaakt van de revisietekeningen van de aannemer. De levering van gegevens gebeurt door de beheerder. Omdat de aannemer in de huidige situatie pas oplevert aan het einde van het project, worden de Klic gegevens mogelijk te laat aangeleverd, deze zouden na de oplevering van de bouwrijp fase meteen doorgestuurd moeten worden naar de Klic.

3.4.3 Knelpunt: Tegenstrijdige bronnen beheerinformatie

Een projectteam maakt een NLCS-bestekstekening, waarbij vaak twee bronnen worden gebruikt: de BGT en de eigen beheerdatabase. Er blijken regelmatig verschillen op te treden tussen deze bronnen, soms door tijdsverschil bij de verwerking naar de BGT, soms omdat de beheerionformatie wordt vastgelegd op basis van de revisietekening, en deze niet de as-built weergeeft maar het ontwerp. Soms wordt door het project nog eens een meting gedaan buiten, om vast te stellen wat de werkelijke situatie is, omdat de informatie niet als betrouwbaar wordt gezien. Dat is de derde dubbele meting in het huidige proces.

3.4.4 Knelpunt: Beheerdata niet gebaseerd op IMBOR of GWSW

De beheerdatabase is nog niet uitgedrukt in de standaarden IMBOR of GWSW, de rioleringsgegevens worden niet gepubliceerd in PDOK Thema Stedelijk Water. Daarom kan ook voor de uitwisseling met het projectteam nog niet worden uitgewisseld in herkenbare informatie, en zal dit team zelf in de bron moeten kijken voor informatie en deze transformeren naar NLCS-CAD voor het ontwerp en de bestekstekening. Ook de vertalingstabel van rioleringsgegevens vanuit PDOK Thema Stedelijk Water naar NLCS kan niet worden gebruikt. De informatie in de BGT is de enige die kan worden omgezet naar CAD; dit betekent een verlies aan informatie ten opzichte van het beheersysteem, of handwerk per project.

3.4.5 Knelpunt: Verlies ontwerpparameters bij overdracht naar beheer

De bestekstekening bevat voor wat betreft bestaande objecten alleen lijnen, punten, symbolen en vlakken uit de BGT en/of het beheersysteem op basis van GIS. Eventuele CAD-ontwerpparameters zoals wegalignement of bijvoorbeeld offsets tussen lijnen uit eerdere ontwerpen zijn niet bewaard door de beheerder.

3.4.6 Knelpunt: Beheerinformatie ontbreekt in bestekstekening

Bij de beheerinformatie (en de BGT) zit attribuut-informatie over de objecten. Omdat de geometrie wordt omgezet naar CAD op basis van NLCS, kan de beheerinformatie niet in de tekening worden meegeleverd. Dit is een beperking van de CAD-systemen, en bij NLCS is nog geen afspraak beschikbaar over het uitwisselen van attributen bij de objecten in een tekening.
Op dit moment wordt deze informatie ook niet meegeleverd naar de aannemer. De eigen interne projectorganisatie heeft er wel toegang toe, via een intern beschikbare kaart.

3.4.7 Knelpunt: Eisen aan oplevering

Het project krijgt een moederbestek, waarin ook een bijlage is opgenomen over de oplevering van een revisiedossier. Daarin staat voor rioleringen uitgebreid beschreven welke documenten en tekeningen moeten worden opgeleverd.

De ontwerp- en bouweisen staan in het Handboek Inrichting Openbare Ruimte (HIOR) van de gemeeente, deze zit toegevoegd aan het contract. Daarin staan alleen de eisen van de beheerder, niet de kwaliteitseisen voor de BGT meting, omdat deze nu niet hoeft te worden uitgevoerd door de aannemer.

Openstaande vragen zijn hierbij: Is het moederbestek, inclusief bijlagen, logisch en goed leesbaar voor een aannemer of uitvoerende partij? Kunnen zij hier eenvoudig mee aan de slag en wordt het risico op fouten in de uitvoering beperkt?

Biedt het bestek voldoende informatie voor de behoeften van standsrealisatie (doel: controle op correcte uitvoering contract) en stadsbeheer (doel: verwerken mutaties uit project), zodat zij een grondige controle kunnen uitvoeren? Daarnaast is het van belang te beoordelen of de verstrekte informatie voldoet aan alle wettelijke en contractuele verplichtingen.

3.4.8 Knelpunt: Falende controle opleverdossier

De projectleider of contractmanager accepteert de oplevering, terwijl de opzichter de geleverde revisie archiveert bij de projectdocumenten. Echter, de inhoudelijke controle van de gegevens wordt niet goed uitgevoerd, omdat de expert of beheerder hierbij niet betrokken is. Directievoerders houden toezicht op de correcte fysieke uitvoering van het werk, maar controleren de bijbehorende data niet.

3.4.9 Knelpunt: Beheerder niet betrokken

De controle op de uitvoering en oplevering van het werk gebeurt door het projectteam. Dat zijn generalisten die niet van alle assets kennis hebben. De beheerder wordt soms wel geraadpleegd (op basis van persoonlijk initiatief), maar heeft geen rol bij de controle van het werk of het opleverdossier.

3.4.10 Knelpunt: Opleverdossier te laat, incompleet

De beheerder krijgt van het projectteam een opleverdossier, zodra dit geleverd wordt. Vaak wordt dit dossier pas na of ver na afhandeling van de betaling van de aannemer geleverd. Het dossier is vaak niet volledig, en de revisietekeningen geven soms de ontwerpsituatie aan, en niet de ingemeten situatie. De beheerder maakt soms wel een overzicht van gebreken, maar deze worden lang niet altijd alsnog aangeleverd. DE aannemer wordt door de projectleider niet aangesproken op ontbrekende gegevens.

3.5 Welke maatschappelijke waarde willen we realiseren?

We streven naar een deskundige, betrouwbare en transparante organisatie voor burgers, aannemers en andere betrokkenen. Dit omvat het creëren van een goede en veilige openbare ruimte, het bevorderen van een betere integrale samenwerking en het efficiënt gebruiken van belastinggeld. Door zo laag mogelijke (faal)kosten na te streven, willen we verspilling minimaliseren en de maatschappelijke impact maximaliseren.

3.6 Wat zijn onze inhoudelijke doelen?​

Voor de informatievoorziening streven we naar een goed en compleet overdrachtsdossier, beter toezicht buiten, kostenbesparingen en het op orde krijgen van informatie en data in het hele proces van ontwerp tot beheer voor reproduceerbaarheid. Binnen de organisatiecultuur richten we ons op het benadrukken van het belang van dit project bij het MT, meer betrokkenheid van het MT en het vergroten van de inhoudelijke kennis bij MT & PL om het proces te ondersteunen.

3.7 Welke criteria hanteren we om deze doelen meetbaar te maken?​

We maken een 0-analyse voor zowel informatievoorziening als cultuur en leggen nieuwe processen vast. De voortgang en winst worden inzichtelijk gemaakt aan de hand van concrete criteria, zoals deskundig toezicht en controle van data bij ontwerp, realisatie en overdracht. Daarnaast hanteren we de BGT-normen en KLIC-normen van de overheid en de wensen van interne gebruikers met betrekking tot de gewenste (beheer-)informatie over objecten. Voor het monitoren van de cultuur baseren we ons op wetenschappelijke studies.

4. Belanghebbenden, wensen en verwachtingen

Dit hoofdstuk beschrijft de belanghebbenden, wennsen en verwachtingen.

visuele weergave van de paragraven die men kan verwachten in dit hoofdstuk
Figuur 4 De vragen bij de belanghebbenden, wennsen en verwachtingen

4.1 Wie zijn belanghebbend?

4.1.1 Hoofdactoren intern

Vanuit het organisatieperspectief zijn de belangrijkste interne belanghebbenden het MT op bureau- en afdelingsniveau. Vanuit het projectperspectief spelen projectleiders en beleidsmedewerkers een cruciale rol. Daarnaast is integraal samenwerken essentieel. Een goede definitie van het probleem en de consequenties is nodig, met aandacht voor financiële aspecten, kosten, objecten en risico’s.

4.1.2 Hoofdactoren extern

Extern zijn er verschillende partijen betrokken. Burgers zijn belanghebbenden, net als aannemers die zich bezighouden met calamiteiten en projecten. Ook projectontwikkelaars en de standaardisatie-organisaties CROW, Stichting Rioned en DigiGO spelen een rol in het proces. Daarnaast draagt dit bij aan minder overlast in de omgeving en een prettige stad om in te wonen. Kostenverlaging vertaalt zich direct naar lagere belastingen.

4.1.3 Secundaire actoren intern

Binnen de organisatie zijn er ook secundaire actoren die van belang zijn. Vanuit het organisatieperspectief zijn dit beheerders, geo-specialisten, vakinhoudelijke adviseurs, werkvoorbereiders, projectleiders en beleidsmedewerkers. Vanuit het projectperspectief zijn vooral projectleiders van belang. Verder is het essentieel om te beschikken over complete en betrouwbare data, zodat voorspellingen en analyses beter kunnen worden uitgevoerd.

4.1.4 Secundaire actoren extern

Extern zijn er naast aannemers en projectontwikkelaars ook landmeetkundigen en softwareontwikkelaars die een rol spelen in het proces. Een goede samenwerking en efficiënte datauitwisseling zorgen ervoor dat werkzaamheden sneller en effectiever kunnen worden uitgevoerd.

4.1.5 Ihkv organisatiecultuur

Belanghebbenden, zoals aannemers en projectleiders, moeten samen aan tafel zitten om een slag te kunnen maken. Dit stelt hen in staat om elkaars situatie en belangen toe te lichten en

4.1.6 Voor welke vragen zoeken zij een oplossing?

Interne hoofdactoren richten zich op het terugbrengen van faalkosten, het vergroten van betrouwbaarheid en reproduceerbaarheid, en het efficiënt ontvangen van revisiedata. Externe hoofdactoren streven naar minder belasting. Zowel interne als externe secundaire actoren delen deze doelen en werken aan hetzelfde streven naar efficiëntie en betrouwbaarheid binnen het proces.

4.1.7 Welke beslissingen willen zij kunnen nemen

Interne hoofdactoren willen beslissingen kunnen nemen over een goede scope en een duidelijke visie voor het revisieproces, de producten en de succes- & faalfactoren. Daarnaast is het essentieel dat zij voldoende (financiële) middelen en mensen kunnen regelen, de overdracht kunnen accepteren en projecten succesvol kunnen afronden. Ook speelt de opname in de BGT en KLIC een belangrijke rol binnen hun besluitvorming.

4.1.8 Wie is eigenaar van het vraagstuk?​

​Gemeentelijke organisatie:​ Concernmanager stadsbeheer ​

4.1.9 Wie is opdrachtgever voor het oplossen?​

​ Gemeentelijke organisatie:​ Stuurgroep programma Datagedreven Samenwerken​

4.1.10 Wie is budgethouder?​

Programmamanger Datagedreven samenwerken​

5. Het ontwerp

Dit hoofdstuk beschrijft het ontwerp.

visuele weergave van de paragraven die men kan verwachten in dit hoofdstuk
Figuur 5 De vragen bij het ontwerp

5.1 Algemeen advies

Algemeen adviea aan Nijmegen:

5.2 Toetsen ontwerp en contract

5.3 Toetsen werk & uitvoeren meting tijdens en na realisatie bouwrijpfase

5.4 Riool inspectie uitvoeren (voor het gat dichtgaat tijdens bouwrijp maken)

5.5 Besluit: voldoet riool aan de vereisten? Go / no go

5.6 Oplevering informatie controleren (na bouwrijp maken)

5.7 Gegevens opleveren aan KLIC

5.8 Meting van het op te leveren werk (woon-/inrichting rijp) en uitvoeren rioolinspectie

5.9 Controlemeting op de meting van de aannemer

5.10 Toetsing revisiedossier

5.11 Formele oplevering woon-/inrichting rijp

5.12 Besluit: voldoet de oplevering?

Ja: betalen laatste termijn aannemer

Nee: laatste termijn niet betalen en actie ondernemen naar aannemer

6. User stories

Dit hoofdstuk beschrijft de user stories per stap in het ontwerp.

visuele weergave van de paragraven die men kan verwachten in dit hoofdstuk
Figuur 6 De vragen bij de user stories

6.1 User stories Toetsen ontwerp en contract

6.1.1 Als rioolbeheerder

Wil ik

  1. toetsen of het ontwerp voldoet aan mijn eisen als beheerder
  2. toetsen of de correcte informatie over bestaande assets is gebruikt bij het opstellen van het ontwerp (levering bestaand areaal aan aannemer)
  3. toetsen of de correcte informatie over bestaande assets is gebruikt bij het opstellen van het ontwerp (levering bestaand areaal aan aannemer)

Zodat ik kan zorgen dat de aannemer met de juiste uitgangspunten aan het werk gaat en de juiste informatie oplevert.

Omdat het rioolsysteem goed moet functioneren tijdens de gebruiks- en beheerfase

6.1.2 Als rioolbeheerder

Wil ik toetsen of mijn informatieleveringsspecificaties voor oplevering van informatie voor BGT, Klic en beheersysteem goed in het contract staan

Zodat ik kan zorgen dat de aannemer de juiste informatie oplevert.

Omdat ik tijdens de beheer- en gebruiksfase alle informatie nodig heb om het systeem te kunnen beheren.

6.1.3 Als werkvoorbereider​

Wil ik De gegevens weten die de beheerder nodig heeft om zijn beheersysteem volledig en goed in te vullen (ligging, type, kenmerken)​ en de technische eisen die de beheerder stelt aan de riolering

Zodat ik kan zorgen dat de juiste onderdelen in het moederbestek​ en in contracten komen

Omdat ik zo kan zorgen dat werk goed kan worden overgedragen aan de beheerder

6.2 User story Toetsen werk & uitvoeren meting tijdens en na realisatie bouwrijpfase

6.2.1 Als aannemer

Wil ik toetsen en inmeten of ik het juiste gebouwd heb

Zodat ik zorg dat mijn werk en de opgeleverde informatie voldoen aan de contractuele vereisten


Omdat ik betaald wil krijgen voor mijn werk en geen herstelwerkzaamheden wil uitvoeren

6.3 User story Riool inspectie uitvoeren (voor het gat dichtgaat tijdens bouwrijp maken)

6.3.1 Als rioolbeheerder

Wil ik zorgen dat eventuele aanlegfouten zoals onvoldoende hoogteverschillen of verzakkingen worden ontdekt

Zodat ik kan zorgen dat dit hersteld wordt door de aannemer, voordat voor herstel in een later stadium veel grotere uitgaven gedaan moeten worden op kosten van de beheerder.

Omdat de technische kwaliteit van het stelsel gewaarborgd moet blijven tijdens de jaren van gebruik en beheer.

6.4 User story Besluit: voldoet riool aan de vereisten? Go / no go

6.4.1 Als toezichthouder

wil ik zorgen dat eventuele aanlegfouten zoals onvoldoende hoogteverschillen of verzakkingen tijdig worden ontdekt

zodat ik ik kan zorgen dat de aannemer het werk volgens het contract uitvoert

omdat:

  • Ik moet zorgen dat fouten hersteld worden door de aanemer, voordat ik over ga tot betaling.

6.5 User story Oplevering informatie controleren (na bouwrijp maken)

6.5.1 Als rioolbeheerder

wil ik de geografische ligging, gegevenskenmerken van het rioolstelsel met een bepaalde nauwkeurigheid, volledigheid en kwaliteit op een snelle manier importeren in mijn beheersysteem

zodat ik deze data snel en volledig (wat nodig is) kan verstrekken aan de organisatie en externe partijen

omdat:

  • Ik het rioolsysteem kan onderhouden, reinigen en inspecteren
  • De organisatie integraal kan ontwerpen, opbouwen van hydraulische modellen, opstellen van MJP
  • Technische kwaliteit van het stelsel / kwaliteit van gegevens gewaarborgd blijft.

6.6 User story Gegevens opleveren voor de KLIC

Wil ik tijdig de revisiegegevens ontvangen van de aannemer voor de levering aan Klic

Zodat ik de geografische ligging, gegevenskenmerken van het rioolstelsel met een bepaalde nauwkeurigheid, volledigheid en kwaliteit kunnen opleveren aan de Klic

Omdat ik een wettelijke plicht heb te zorgen dat informatie over ondergrondse infra volledig is, zodat graafschade voorkomen kan worden bij verdere uitvoering van werkzaamheden.

6.7 User story Meting van het op te leveren werk (woon-/inrichting rijp)

6.7.1 Als rioolbeheerder

Zie User story Oplevering informatie controleren (na bouwrijp maken)

6.8 User story Controlemeting op de meting van de aannemer

wil ik een locatie-nauwkeurige revisie, inclusief tijdsplanning​

zodat ik eenvoudig de projectinformatie kan verwerken in de BGT en kan doorsturen naar assetbeheerders​

omdat ik verantwoordelijk ben voor nauwkeurige datalevering aan de landelijke voorziening en deze data ook aanlever aan assetbeheerders (horizontaal berichtenverkeer)​

6.9 User story Toetsing revisiedossier

6.9.1 Als rioolbeheerder

Zie User story Oplevering informatie controleren (na bouwrijp maken)

6.10 User story formele oplevering woon-/inrichting rijp

6.10.1 Als toezichthouder

Zie User story Besluit: voldoet riool aan de vereisten? Go / no go

6.10.2 Als aannemer

Zie User story Toetsen werk & uitvoeren meting tijdens en na realisatie bouwrijpfase

6.11 User story Besluit: voldoet de oplevering?

6.11.1 Als projectleider

wil ik zorgen dat de aannemer alle informatie heeft opgeleverd.

zodat ik eenvoudig de projectinformatie kan doorsturen naar assetbeheerders​ en het werk goed kan opleveren.

omdat ik verantwoordelijk ben voor controle dat het contract goed is uitgevoerd voor ik overga tot betaling.

7. Bouwen

Dit hoofdstuk beschrijft het bouwen: De ontwikkeling van modellen en inrchten van de experimenteeromgeving. Daarnaast is de beschrijving toegevoegd van een al eerder uitgevoerd onderzoek, de Inventarisatie BGT-meting versus revisie.

visuele weergave van de paragraven die men kan verwachten in dit hoofdstuk
Figuur 7 De vragen bij het bouwen

7.1 Inventarisatie BGT-meting versus revisie

Het direct kunnen importeren van revisiegegevens in de verschillende beheersystemen (BGT/gemeentelijk beheersysteem) kan een enorme tijdwinst opleveren. Indien de door de aannemer geleverde gegevens voldoen aan de overeengekomen kwaliteit (volledigheid/nauwkeurigheid) die door de betreffende beheersystemen worden vereist, is een (hernieuwde) inwinning van de objecten in de openbare ruimte overbodig en kunnen beide systemen met behulp van de revisiegegevens relatief eenvoudig up-to-date worden gehouden.

Bij wijze van proef is onderzocht in hoeverre de revisie-dataset, aangeleverd door de aannemer, overeenkomt met of afwijkt van de inwinningsgegevens van onze eigen landmeter. De vergelijking beperkte zich hierbij tot de locatiegegevens (x- en y-coördinaten) van de rioolputten.

7.1.1 Datavergelijking

Testgebied: Woenderskamp en Hof van Holland, Nijmegen Noord

Datasets:

  1. Revisietekening (AutoCAD-bestand), aangeleverd door aannemer
  2. Inmeting BGT (inwinning landmeter gemeente Nijmegen)

Met analysetool FME zijn de datasets vergeleken.

7.1.2 Analyse

Om iets te kunnen zeggen over de kwaliteit van de geleverde CAD-tekening, zijn de locatiegegevens (x- en y-coördinaten) van de objecten (rioolputten) in deze dataset vergeleken met de locatiegegevens van de betreffende rioolobjecten die middels inmeting door de landmeter van de gemeente Nijmegen zijn verkregen.

De locatiegegevens van de rioolobjecten uit deze twee beschikbare datasets zijn vervolgens met elkaar vergeleken (onderlinge afstand is berekend) en de resultaten van deze analyse zijn op kaart weergegeven.

7.1.2.1 Toetsingscriteria

De toetsingscriteria zijn als volgt gedefinieerd:

Toetsingscriteria gevisualiseerd, dit zijn de cirteria die verderop in de tekst met bullets zijn beschreven
Figuur 8 Toetsingscriteria
  • Is de berekende onderlinge afstand van een rioolput in beide beschikbare datasets kleiner of gelijk aan 10 cm, dan wordt de revisietekening beoordeeld als ‘nauwkeurig’ en wordt het object als een groene punt op de kaart weergegeven.
  • Is de berekende afstand tussen 10 en 25 cm (dus grotere onderlinge afwijking), dan wordt de rioolput geel weergegeven.
  • Is de berekende onderlinge afstand groter dan 1 meter of is het object door de landmeter niet aangetroffen, dan verschijnt er een rode punt op de kaart.
  • Indien de landmeter in het veld een rioolput constateert die niet op de revisietekening staat, dan wordt dit weergegeven als een paarse ruit.

Deze toetsingscriteria zijn in samenwerking met de projectleider Waalsprong tot stand gekomen.

7.1.2.2 Stappenplan
  1. Converteren CAD-data (revisietekening aannemer) naar GIS-data t.b.v. publicatie in GIS-software (QGIS/gemeentelijke Kaartviewer).
  2. Inlezen meetgegevens landmeter gemeente Nijmegen.
  3. Bepalen onderlinge afstand object (rioolput) met behulp van FME.
  4. Visualiseren analyseresultaten op basis van de kleurindeling van de toetsingscriteria.

7.1.3

Geleverde revisietekening aannemer (AutoCAD)
Fragment geleverde revisietekening aannemer (AutoCAD)

Zelfde fragment, BGT-data landmeter gemeente Nijmegen
Merk op: zwarte cirkels zijn de gemeten rioolputten.

BGT-data landmeter gemeente Nijmegen
Figuur 9 Zelfde fragment, BGT-data landmeter gemeente Nijmegen (zwarte cirkels zijn de gemeten rioolputten)

7.1.4 Analyseresultaten

Analyseresultaten
Figuur 10 Analyseresultaten van de vergelijking tussen revisiedata en BGT-data
Revisietekening aannemer
Figuur 11 Revisietekening aangeleverd door aannemer
Inmeting BGT
Figuur 12 Inmeting BGT door landmeter gemeente Nijmegen
Analyseresultaten
Figuur 13 Detail van de analyseresultaten van de vergelijking tussen revisiedata en BGT-data

7.1.5 Beoordeling resultaten

De resultaten dienen (zoals altijd) kritisch beoordeeld te worden. De mogelijke redenen voor afwijkingen zijn divers en vaak niet toe te schrijven aan één enkele oorzaak.

7.1.6 ‘Bijvangst’ data-analyse

Naast eventuele nauwkeurigheidsissues kwamen er voor het gekozen gebied ook andere onvolkomenheden aan de oppervlakte, die in feite buiten de scope van de analyse vielen.

Een opvallende constatering was dat er in een aantal gevallen een rioolput op de revisietekening stond aangegeven die door de landmeter niet was ingemeten.

Deze putten ontbraken ook daadwerkelijk in het straatbeeld (controle via Streetview). Nader onderzoek wees uit dat in deze gevallen de putobjecten tijdens de bouwrijpmaakfase weliswaar weliswaar waren aangelegd, maar dat de putranden tijdens de fase-overgang ‘bouwrijp maken / woonrijp maken’ niet waren opgemetseld waarna het nieuwe straatwerk over deze pas aangelegde putten was aangebracht.

De kosten om dit te herstellen liggen tussen de 3.000 en 4.000 euro per putobject. Deze kosten komen vaak voor rekening van de gemeente omdat deze ‘fouten’ bij oplevering vaak niet gesignaleerd worden en pas bij problemen van het rioolstelsel (dus vaak jaren later) naar boven komen. De data-analyse heeft echter plaatsgevonden kort na oplevering, waarna de aannemer is aangesproken op bovenstaande fouten. Kostenbesparing voor de gemeente Nijmegen: een kleine 60.000 euro.

Deze analyse heeft niet geleid tot de controle van het volledige projectgebied dat is opgeleverd. Deelnemers aan de werksessie wijten dat aan de cultuur binnen de gemeente.

7.2 Experiment reviesieverwerking

In het experiment revisieverwerking worden de volgende stappen worden onderzocht met hulp van de proefdataset die door de gemeente Nijmegen wordt verstrekt aan CROW:

  1. Beheerinformatie riolering publiceren met GWSW-standaard. Hiervoor wordt de geleverde beheerinformatie over putten en rioolleidingen omgezet naar linked data op basis van het GWSW-model.
  2. De revisietekening riolering wordt omgezet naar linked data op basis van het GWSW-model, op basis van een test-ontology alignment tussen NLCS en GWSW. Deze wordt gemaakt op basis van de tabel waarmee PDOK Thema Stedelijk Water wordt vergeleken met NLCS.
  3. Onderzocht wordt, of de bestaande objecten uit de beheerdata herkenbaar zijn in de revisietekening. Omdat nog niet met objectidentificatie gewerkt kan worden in NLCS, wordt gebruik gemaakt van de aanname, dat een object op dezelfde locatie in de tekening als in de beheerdata, hetzelfde object zijn.
  4. Mutaties aan bestaande objecten worden geïdentificeerd, vervallen of bewerkte objecten.
  5. Mutaties met nieuwe objecten worden geïdentificeerd.
  6. Onderzocht wordt welke attributen reeds bekend zijn op basis van het symbool en/of de laagnaam, deze attributen worden toegevoegd bij de gemuteerde objecten.
  7. De verwerking van de mutaties in de beheerdata wordt gesimuleerd.

8. Experimenteren en evalueren

Dit hoofdstuk beschrijft het uitvoeren en evalueren van het experiment​, de toepassing en borging​.

visuele weergave van de paragraven die men kan verwachten in dit hoofdstuk
Figuur 14 De vragen bij het experimenteren en evalueren

9. Definities

BGT
BGT is een digitale kaart van Nederland waarop gebouwen, wegen, waterlopen, terreinen en spoorlijnen eenduidig zijn vastgelegd met een nauwkeurigheid van 20 centimeter. De informatie wordt aangeleverd door de beheerders van de objecten. Wegen zijn hierin opgenomen als 2D-vlakobjecten, terwijl verkeersborden als 2D-punten van het type bord worden geregistreerd, conform het IMGeo
GWSW
Het GWSW is een gestandaardiseerd informatiemodel voor het vastleggen, beheren en uitwisselen van gegevens over stedelijk waterbeheer. Het bevat eenduidige definities en semantische afspraken voor objecten zoals rioleringen, watergangen en bergingsvoorzieningen. Het model zorgt voor een betere interoperabiliteit tussen verschillende partijen, zoals gemeenten, waterschappen en ingenieursbureaus. Zie ook deze website en deze viewer.
IMBOR
Het IMBOR bevat de afspraken over de benamingen en definities van alle type objecten in de openbare ruimte en de beheergegevens die per type object vastgelegd kunnen worden. Veel gemeenten gebruiken de objecttypen uit de BGT voor de geometrische representatie van de objecten. Zie ook deze website en deze viewer.
KLIC
Een digitaal systeem waarin netbeheerders informatie over ondergrondse kabels en leidingen registreren. Het portaal wordt beheerd door het Kadaster en maakt het mogelijk om via een KLIC-melding gegevens op te vragen over de ligging van kabels en leidingen. Dit is verplicht bij graafwerkzaamheden om schade te voorkomen en de veiligheid te waarborgen.
Use Case
Een **use case** binnen het **DOOR-programma** beschrijft een proces vanuit het perspectief van de betrokken partijen (actoren) en hoe zij informatie met elkaar uitwisselen. Het gaat hierbij niet om het ontwikkelen van software, maar om het waarborgen van een **interoperabele** en **eenduidige uitwisseling van informatie** tussen ketenpartners.

De use case beschrijft wie betrokken is bij de informatie-uitwisseling (actoren), wat het doel is en hoe de interactie verloopt in een reeks logische stappen. Actoren kunnen personen, organisaties of systemen zijn die gegevens aanleveren, verwerken of gebruiken. De focus ligt op het creëren van een gestroomlijnd proces waarin data betrouwbaar en reproduceerbaar wordt gedeeld, zodat alle partijen effectief kunnen samenwerken bij werkzaamheden in de openbare ruimte en infrastructuur.

User story
Een user story is een bekend concept in agile softwareontwikkeling en helpt bij het beschrijven van softwarefunctionaliteiten vanuit het oogpunt van de eindgebruiker.​ De user story wordt geformuleerd vanuit het oogpunt van een gebruiker, beschrijft wat deze wil bereiken en met welk doel. Deze structuur helpt het ontwikkelteam en andere belanghebbenden te begrijpen wat ​ er moet worden gebouwd en waarom, en biedt meetbare criteria voor succes.​

A. Index

A.1 Termen gedefinieerd door deze specificatie

A.2 Termen gedefinieerd door referentie