Vragen en antwoorden uit de chat van het Webinar IMBOR - NLCS 23 mei 2024

[ElisabethKloren]

Over BIM en delen van bestanden

• Waar bewaren jullie (gemeente Dordrecht) alle bestanden? (Lokaal of bijvoorbeeld in SharePoint?)

  Nu nog lokaal maar omdat alle systemen en data naar de cloud gemigreerd worden zal dit in de toekomst tot een andere werkwijze zorgen waarbij het samenwerken in Sharepoints veel logischer wordt.

• Is de gemeente Dordrecht bekend met werken in de BIM methodiek in een Common Data Enviroment, dan tackel je alle zaken in het proces en krijg je geen overdracht meer

  Ik weet niet of er bekendheid is met deze methodiek. In de pilot wordt deze nog niet gebruikt. Onze pilot is een tussenstap om in de toekomst tot volwaardig BIM te komen.

Product manager NLCS: of je nu deelt in een Common Data Environment of anders, het blijft zo dat de software ook wel elkaars geometriën (CAD versus GIS) en attribuutgegevens moeten kunnen gebruiken. Daarvoor zijn afspraken nodig, liefst nationaal anders moet elke gemeente dit voor zichzelf gaan uitwerken.

Over gebruik van NLCS of niet

• waarom wordt er in ontwerp met microstation nog geen NLCS gebruikt? NLCS is software onafhankelijk en zou dus wel moeten kunnen...
• In Nijmegen precies zo. Werkvoorbereiders tekenen in NCLS en stedenbouwers niet 😔

  Goede vraag. Of het eigenwijsheid van de stedenbouwers is die zich niet willen vastpinnen aan opgelegde systemen of dat er nooit over nagedacht is weet ik niet.

Over de BGT

• Ik mis de BGT in dit verhaal?

  in de eerste pilot hebben we die bewust buiten beschouwing gelaten om ons op de IMBOR/NLCS combinatie te kunnen richten. In de tweede pilot (die net is gestart) nemen we dat vraagstuk wel mee. BGT is overigens al een tijd geleden op NLCS gemapped en moet prima mee kunnen lopen in dit traject. In de vervolgpilot wordt de BGT nadrukkelijk betrokken. De revisie van de aannemer is dan zowel voor de BGT als het beheersysteem bedoeld. Uiteraard moet deze data naadloos op elkaar aansluiten waarbij de BGT leidend is voor de geometrie.

• Alle informatie die in ons BOR systeem staat wordt eerst opgenomen in onze BGT. Waar staat deze stap in dit verhaal? BGT en BOR-informatie moeten naadloos in elkaar passen.

  In Dordrecht is deze koppeling er helaas nog niet maar dat is wel het toekomstige streven. Als de koppeling tot stand gebracht is zal de BGT leidend zijn voor de geometrie van de BOR-objecten.

Over controles van revisietekeningen

• Wie controleert dan de revisie op NLCS? Dat kun je wel eisen, maar controleren is noodzakelijk.

  Antwoord Dimitry: er zijn meerdere controles nodig

  1. Opdrachtgever (de ontwerper) controleert of gerealiseerd is wat er was afgesproken (die controle zou reeds moeten bestaan)
  2. De Geo-specialist controleert of het geleverde voldoet aan de BGT-eisen
  3. Beheerder controleert of de As-built gegevens conform de gemaakte afspraken zijn opgeleverd, zodat deze goed kunnen worden verwerkt in het beheersysteem.
  4. daarnaast een technische controle door een applicatie: voldoet de geleverde data aan de technische eisen?

Ontwerper heeft meer nodig dan de beheerder

• Mijn ervaring is dat de 3d informatie vaak nodig is t.b.v. het ontwerpen en dat deze niet aanwezig zijn in de BOR. Hoe zijn jullie hiermee omgegaan in de POC.

  Daar hebben we in de eerste pilot nog geen rekening mee gehouden. In de tweede pilot nemen we in ieder geval ook hoogtes mee zodat de ontwerper die kan gebruiken in zijn ontwerp. Die informatie is niet beschikbaar in het beheersysteem, dus die moet apart worden ingewonnen.
  De vervolgpilot is nog gewoon in 2D en de ontwerphoogtes worden als getal (NAP-hoogtes) in de ontwerptekening gezet. Ik verwacht niet dat deze na afloop meegaat in het beheersysteem want daarin worden geen hoogtes bijgehouden/. @ Dimitry: heb jij hier een aanvulling op?

• Voor ontwerp en realisatie is de ondergrond ook van groot belang, waar zit fundering, waar zit bomengrond, etc. Hoe zit dat in de IMBOR en is er gekeken naar de uitwisseling naar NLCS?

  dat is in de eerste pilot nog niet meegenomen. IMBOR biedt wel mogelijkheden om hiervan zaken te registreren, maar veel gemeenten zijn nog niet zover dat die mate van detail ook beschikbaar is in beheersystemen. Het is zeker denkbaar dat dit gaat groeien als we deze informatie in de ontwerpfase vastleggen en meenemen naar het beheersysteem. In Dordrecht zijn alleen gemeentelijke eigendom geregistreerd in het BOR-systeem. Voor de ondergrond zijn dit met name riolen. Dus deze gegevens kunnen geautomatiseerd overgezet worden naar de ontwerpomgeving. Ontbrekende informatie zoals funderingen, kabels- en leidingen moet net zoals nu apart toegevoegd worden uit andere bronnen. kijk ook eens in de viewer van IMBOR wat er kan worden geregistreerd: https://docs.crow.nl/onto-verkenner/imbor/#/view

Over de mapping IMBOR - NLCS

• De vertaling tussen IMBOR en NLCS gaat dus via een vertaallijst. Maken jullie die mapping beschikbaar? Net zoals de mapping tussen NLCS en IMGEO beschikbaar is via de NLCS?
• Er is dus een mapping toegepast tussen IMBOR en NLCS?

  Hier wordt aan gewerkt in een werkgroep van NLCS. Volg de voortgang live via #110

Uitwisseling van attributen

• Hoe zit het met filtering van kenmerken, je wilt toch niet dan niet-specialisten zaken kunnen aanpassen, waar ze geen kennis van hebben. Of de werklast bij een ontwerper leggen zoals je schetst terwijl deze bij de BOR beheerder ligt. Dus denk aan filtering, autorisatie aanpassen van kenmerken etc. En bv een BOOM heeft 120 kenmerken. Hoe gaan jullie hiermee om?

  Dat gaan we proefondervindelijk ontdekken. In principe wordt informatie toegevoegd daar waar die ontstaat in de keten. Als het in de ontwerpfase is zal de ontwerper dit invoeren waarbij hij gevoed moet worden door de beheerder. De ontwerper en beheerder moeten als duo gezamenlijk optrekken. Ook zal de beheerder pas een deel van de data invoeren als hij deze in beheer heeft gekregen. We gaan ontdekken wat handig werkt in de praktijk. op dit moment is daarvoor technisch nog geen oplossing gerealiseerd. Uiteraard zijn we ons wel bewust van de noodzaak daarvan. Tot een passende oplossing is uitgewerkt, kan het maken van duidelijke afspraken (ILS) zorgen dat de taakverdeling kraakhelder is.

• Zijn de attribbutgegevens uitwisselbaar tussen ACAD en MicroStation?

  Daar bestaan nu nog geen afspraken voor binnen NLCS, daar werken we aan. In de pilot hebben we hier wel aan gedacht. De attribuutdata wordt in XML opgeslagen en is daarmee CAD-systeem onafhankelijk. In de praktijk is op dit moment nog geen ondersteuning voor deze XML oplossing op Microstation. Als de techniekkeuze wordt gemaakt bij NLCS, is dit wel te maken in combinatie met MicroStation, verwachten we.

• Welke tool wordt er gebruikt om de attributen aan de objecten te linken in de Cad tekening? Of is deze ingebakken in de gis omgeving?

  In de pilot hebben we gebruik gemaakt van InfraCAD van Arkance. Deze software ondersteunt reeds de attribuutdata inclusief gebruik van keuzelijsten in de meest recente versie.

Verschil CAD en GIS

• In dit voorbeeld zien we een voorbeeld van een lijnelement. Beheer werkt met vlakken, ontwerp werkt met lijnen. Hoe wordt met dat verschil omgegaan? Stel de weg moet 1 meter verbreed worden?

  in de pilot hebben we dat opgelost door vlakobjecten ook werkelijk als vlakobjecten uit te wisselen. Dat vroeg wat gewenning maar bleek wel goed te kunnen werken. Op dit moment moet je in een informatieleveringsspecificatie aangeven, hoe de informatie geleverd moet worden. De ontwerper zal mogelijk met lijnen werken tijdens ontwerp en uitvoering, maar dit toch terug moeten vertalen naar bestaande en nieuwe vlakken voor de oplevering aan de beheerder.

  • Wijzigingen in vlakobjecten (vooral bij uitwisseling BGT-BOR) zal dan idd eerst in BGT beheersoftware moeten worden verwerkt. Rechtstreeks de revisie terug leveren naar BOR beheersoftware lijkt mij dan niet wenselijk. gemeenten hanteren hierin verschillende werkwijzen, die vragen om verschillende aanpak voor de verwerking van revisie. Wat je in ieder geval wilt bereiken is dat beheersysteem en BGT consistent zijn met elkaar. Zie ook Aanpak BGT-BOR | VNG

  Eigen toevoegingen aan NLCS

• NLCS biedt enige vrijheid tot het maken van eigen levels. Hoe tackelt men dit?

  Voor eigen toegevoegde laagnamen zal je zelf in de informatieleveringsspecificatie moeten aangeven hoe deze te verwerken; als er straks een standaard mapping is tussen NLCS en IMBOR, zal je deze moeten aanvullen als organisatie,. Bij het verwerken van objecten vanuit de As-built tekening in het beheersysteem is het noodzakelijk dat de data op vooraf overeengekomen layers staat. Indien daarvan wordt afgeweken zullen de objecten op die layers uitvallen. Uiteraard kan de beheerder besluiten om de configuratie van de Preview/Import tool aan te passen en de toegevoegde layers te ondersteunen, waardoor ze alsnog succesvol kunnen worden verwerkt.

[ElisabethKloren]

Ik sluit deze issue, omdat hier geen wensen voor aanpassingen uit NLCS uit voortkomen die we niet al hebben geregistreerd in andere issues.