Gesprek MOW

GESPREK GEERT VAN GAEVER (MOW)

Overleg van 04/07/2022

WAT VOORAF GING: Al heel lang geleden heeft men gezegd dat we een verkeersbordendatabank moeten hebben. Het departement MOW is hiermee aan de slag gegaan (via externe firma): alle verkeersborden in Vlaanderen zijn gedigitaliseerd. Databank was hiermee af.

Er kwam echter een besef dat er geen software was om de verkeersborden te gaan editeren. Hiervoor heeft het departement MOW een toepassing ontwikkeld (eerste versie verkeersbordendatabank). Dit werd niet-agile en zonder afstemming gebruikersgroep top-down ontwikkeld door HB+. De toepassing had echter niet voldoende raakvlak en werd -op uitzondering van enkele lokale besturen- niet gebruikt.

AWV initieerde daarop de ontwikkeling van de huidige verkeersbordendatabank. Eerste release van huidige databank dateert van 2009-2010.

AWV voegde zich niet onmiddellijk bij de ontwikkeling van het departement omdat er onvoldoende aandacht besteed werd aan het standaardbestek 250 (lees: de wettelijke bijbel hoe een verkeersbord eruit moet zien (standaard AWV)). CHECK: https://www.vlaanderen.be/het-standaardbestek-250-voor-wegenbouw

Een jaar of vier geleden (in kader project snelheid Vlaanderen) is er budget via Vlaanderen Digitaal (VRD-1-project - Vlaanderen Radicaal Digitaal) gekomen en daarmee is er een gebruikersgroep opgezet. Er werd gestart met demo en er werd lokale besturen gevraagd wat er aangepast moest worden. Vraag aan lokale besturen om mee in te stappen. De bestaande DB was al vrij goed ontwikkeld en er werd gevraagd om nog enkele aanpassingen te maken. Ondertussen ook mobiele applicatie toegevoegd. CHECK: https://www.vlaanderen.be/uw-overheid/werking-en-structuur/hoe-werkt-de-vlaamse-overheid/informatie-en-communicatie/vlaanderen-radicaal-digitaal-ii/prioriteiten-voor-vrd-2

AS IS:

Momenteel is de software 'op' (12 jaar oud). Het javascript is moeilijk te upgraden (potentieel ernstig risico!) Er dringt zich een redesign op van de huidige applicatie.

Links maken om om te kunnen gaan met LBLOD-verhaal en het register om hier de verkeersborden te kunnen halen (+ alle toeters en bellen).

Peter Bogaert (stad Gent) heeft via het GZG-project indienen waarmee gepland wordt het redesign van de verkeersbordendatabank mee te kunnen financieren. Met betrokken lokale besturen (huidige gebruikers en nieuwe), met ABB (linkedverhaal correct implementeren). CHECK: https://gzg.vlaanderen.be/

DE STANDAARDEN:

WMS en WFS zijn de standaard (niet linked) bestanden.

Opdracht: bekijken of dit futureproof is (weet wel dat stad Gent de WFS heel vaak gebruikt). De open data die doorstroomt naar de kaartenmakers via TN-ITS-standaard (Rosatta-formaat) zou futureproof zijn. CHECK: https://tn-its.eu/standardisation

MANUELE TUSSENKOMSTEN / AUTOMATISCHE ONDERDELEN IN HET PROCES: Er zit een deel automatisme in. Bordenbib (zipbestand met alles svg’s) "op de sharepoint ergens bij ABB".

In de svg zit ook hoe die borden worden gemaakt. In het simpelste geval bevat dit volgende data-elementen: bv. grootte (700/900/1100mm bv.), folie van het bord type 3 en standaardhoogte van 1500mm. Een verkeerswijzerbord van 3000 breed zal standaard de suggestie van 3 steunen krijgen = automatisatie. Complexere borden zoals een bord voor steile helling/daling heeft iets meer data nodig: de hellingsgraad wordt on the fly gegenereerd op het bord – decimal met achterliggende property file die zegt waar de hellingsgraad wordt gedefinieerd bv. waar: boundinbox 180*117 op inplantingspunt x/y, gecentreerd en in 30%, lettertype en zwart erop gedrukt) Standaard is deze gewoon leeg qua bord. = Validatieregels.

Import/Export naar xml-formaat >> bewerken en terug importeren. Er wordt vaak samengewerkt met firma DLW (extern) die software ontwikkeld hebben voor onder ArcMap hetzelfde te doen (signalisatieplannen ontwerpen). Export vanuit Simat en import in verkeersbordendatabank en signalisatieplan zit zo in de databank. Zo werken ook de grote steden (Apen en Gent) = Simat, maar met maandelijkse push via rest API naar de verkeersbordendatabank waarmee ze rechtstreeks kunnen gaan importeren (enkel schrijven, niet lezen (one direction)). >> Wat is SIMAT?

VRAAG: POTENTIELE VERBETERINGEN NAAR HET HUIDIGE PROCES TOE (INITIËLE REQUIREMENTS):

Gebruik maken van de bordenbib (nieuwe register) >> bedoeling dat Els en Geert dit gaan bijhouden op termijn.

"Iedereen die met verkeersborden werkt zou op zijn minst dezelfde bordcodes moeten gebruiken!" Register geeft bordcodes mee, maar bv. bord kikker (verschillende borden die hetzelfde doel dienen) >> werd een wildgroei aan namen: bv. ‘A_pad’, ‘A43’ (ging maar tot 42), ‘pad’. Mag een AXX zijn, maar iedereen moet over hetzelfde praten. Geen 27 verschillende borden voor eenzelfde betekenis.

De bordcode is belangrijker dan het bord. Bordcode is primair en moet altijd hetzelfde zijn, maar de pad mag op verschillende manieren weergegeven worden. Voor Geert maakt het niet uit hoe die pad eruit ziet (of die nu ligt of kruipt of platgereden is).

Opschriften moeten zoveel mogelijk gelijkgetrokken worden. Bv. ‘uitzonderlijk plaatselijk verkeer’, ‘uitgez. Plaats. Verk.’, ‘uitgezonder plaatselijke bediening’

GUI zit vrij goed, maar kan gemoderniseerd worden. CHECK: https://www.computerhope.com/jargon/g/gui.htm

Voor het nieuwe tabletproof maken, zodat er niet met de andere app op de baan moet gegaan worden.

Verder import/exportmogelijkheden uitbreiden. XML is moeilijk te genereren >> ge moet svg’s altijd aanmaken (verplicht mee te inporteren in de verkeersbordendatabank).

OUT OF SCOPE (duidelijk communiceren): Wij hebben minder interesse in het beeld zelf: wij gaan geen tekenprogramme maken dat svg samenstelt (toch niet in de eerste fase).

TO DO: WEGENDATABANK = er bestaat geen mock login. Bij Peter De Ronde access vragen in de dev-omgeving. Wat staat er in de schermen? En wat zijn de noden? Geert kan me nadien rechten geven en een regio toewijzen. Access opnieuw aangevraagd o.b.v. rijksregisternummer

TYPES VERKEERSBORDEN (bv. A-bord, XX-bord, …)