(Tijdelijke) Verkeersborden: gebruikerswens dynamische verkeersborden / parametrische input

[ElisabethDeVries]

Ik werd gebeld door een NLCS gebruiker, die aangeeft dat het werken met "platgeslagen" verkeersborden zeer tijdrovend is, in vergelijking met gebruiken van dynamic blocks en meer data-gebaseerde input. Voorbeeld is het kunnen selecteren van een snelheidsbord en dan de snelheid invoeren, eventueel met onderbord tekst of zone/schild, in plaats van selecteren uit een eindeloze lijst met snelheidsborden

Daarnaast maakt dit het ook eenvoudiger om data te leveren over het ontwerp, bijvoorbeeld de informatie op het bord in de vorm van attribuutwaarden leveren, in plaats van alleen als visuele representatie op een tekening

[ElisabethDeVries]

het is me duidelijk, dat NLCS op dit moment beperkt bruikbaar is voor partijen die slimmer willen tekenen, bijvoorbeeld met parameters verkeersborden samenstellen in plaats van uit een enorme lijst te kiezen met “platgeslagen borden”. Deze gebruiker is bang dat ze hun op zeer efficiënte wijze geproduceerde tekeningen moeten gaan “platslaan” en daarbij tijd en voorsprong kwijtraken op bedrijven die veel minder slim aan het werk zijn. Dan zou de standaard ervoor zorgen dat hun innovaties niet meer renderen, de omgekeerde wereld.

Kreeg ik al eerder signalen over, oa van de stedelijk spoorbedrijven. Probleem hierbij is dat wij deze slimme symbolen niet goed kunnen converteren tussen AutoCAD en MicroStation dus dat wij dit niet als “open en uitwisselbaar’ kunnen aanbieden. Er zouden ook andere oplossingsrichtingen kunnen ontstaan, bijvoorbeeld door verkeersborden / objecten geparametriseerd te gaan uitwisselen in plaats van als blocks in een tekening > daarbij zou je een oplossing willen zoeken die aansluit op openBIM/Building SMART (IFC + ?), hoewel ik niet weet of en hoe de uitwisseling op basis van parameters geregeld is of kan worden in open bim

[MvanderHulst]

@ElisabethKloren Bovenstaand vindt ik persoonlijk een slecht voorbeeld van het behalen van winst. Ik lees hieruit dat de gebruiker niet weet wat het RVV-nummer is van een bord en daarom veel moet zoeken. Bij goed wegontwerp weet je de codes en heb je ze zeer snel gevonden.

Ik begrijp uit de uitleg dat de gebruiker een 'leeg' snelheidsbord wilt en middels een attribute de snelheid wilt kunnen invullen. Dit zou volgens de standaard al mogen, maar is wat mij betreft een ongewenste situatie.

Je krijgt dan namelijk een 'algemeen' bord in je model, met een attribute veld. Dit betekend dat het RVV-nummer niet voor komt in het object en het dus een 'onbekend' object is voor de techniek. Bij het bepalen van hoeveelheden zal de gebruiker dit altijd met de hand uit moeten voeren.

De platgeslagen borden bevatten hun unieke RVV nummer en dat is wat je wilt borgen in je project.

Voor dit scenario zou het wel gewenst kunnen zijn om één snelheidblock te maken met een visibilitystate, waarin alle standaard definities zijn opgenomen. Uit een keuzelijst kan dan een RVV-nummer gekozen worden welke vervolgens wordt gepresenteerd. DAT levert wel tijdsbesparing op en houd een object volgbaar in de gehele keten.

Belangrijk uitgangspunt moet zijn dan een dynamisch block ALTIJD een identificeerbaar OBJECT blijft. Verschil tussen een dynamic-block en een block met attribuutwaarden moet hierbij zeer goed in de gaten gehouden worden.

[ElisabethDeVries]

Ik weet zeker dat deze gebruiker dat heel goed weet want die heeft een grootschalig en goed geautomatiseerd werkproces voor het maken van héél veel tekeningen. Ben bang dat ik degene ben die het slechte voorbeeld bedacht 😀

[NielsNederpel]

Je krijgt dan namelijk een 'algemeen' bord in je model, met een attribute veld. Dit betekend dat het RVV-nummer niet voor komt in het object en het dus een 'onbekend' object is voor de techniek. Bij het bepalen van hoeveelheden zal de gebruiker dit altijd met de hand uit moeten voeren.

ik snap wat je zegt en ben het er ook in die zin mee eens...wat er nu wel ook gebeurd is dat FME wordt ingezet om toch objecten met bepaalde attribuutwaarden "te filteren"

Ik weet zeker dat deze gebruiker dat heel goed weet want die heeft een grootschalig en goed geautomatiseerd werkproces voor het maken van héél veel tekeningen. Ben bang dat ik degene ben die het slechte voorbeeld bedacht

mogelijk een slecht voorbeeld maar is wel ook wat er nu gebeurd (met andere onderdelen). Ik heb wel eens dynamische symbolen van straatmeubilair gezien, maar dan ben je dus ook meerdere objecten in 1 symbool aan het plaatsen die je, zoals Michel aangeeft, vervolgens met de hand moet tellen. Niet echt een "winst" voor de tekenaar in 1e instantie misschien wel, maar voor het gehele proces zeker niet. tenzij je dit weer omzijlt met FME/scripten (wat prima mogelijk is), maar dit is niet iets wat we als standaard "even" kunnen oplossen.

op zich wel benieuwd naar "het goede voorbeeld" want misschien kunnen we daar dan toch iets mee.

447

[ElisabethDeVries]

Dit issue wordt verder onderzocht als onderdeel van #447