Goals & Features

Product success equals successfully replacing IRG.

Minimum-Viable-Product

  • Import data from external source (URIs + map from VKB.VL)

  • Compose a new AR (=aanvullend reglement) based on import

  • Edit / Delete an existing AR (?)

  • Manage existing ARs (> Registry admin? )

    • Manage articles

    • Manage location-determination ("plaatsbepaling")

    • Manage ARs

Future-Features

1 Automatic Notifications:

A feature that would alarm the user when certain content changes are made, a similar feature exists in IRG to mitigate the impact of these changes. In IRG three notification levels are used:

The content of a measure or a template is changed (Green notification- informative)

The user can open the warning for more detail, and the user can dismiss the warning themself.

A case-example would be the administrator fixing typo's or similar issues.

The administrator changes the zonal or variable use of a traffic sign. (Yellow notification - warning)

The user can open the warning for more detail, but CAN'T dismiss the warning. Only when the article(s) using the faulty sign are removed from the measure will the warning dissapear.

When the transition period for an older traffic measure ends, the measure will be blocked. (Red notification - warning)

The user can open the warning for more detail, but CAN'T dismiss the warning. Only when the article(s) using the faulty sign are removed from the measure will the warning dissapear.

2 A Municipality requests a new traffic sign (to be added to the DB)

Needs Refinement:

  • Data input / user flow

  • Admin side: flow / panel / screens. (=RVM story)

A feature that will ease the request and processing of 'non-legal' traffic signs (see link for an overview), for both the users as the administrators. These types of signs are often used by municipalities (eg: camera bewaking; spelende kinderen; paddenoversteekplaats,..) but have no legal structure. To add these types of signs to the database a seperate flow is necessary.

Current flow in VKB VL:

  1. Reques by municipality through mail > Helpdesk (Lien)

  2. Processing by Geert in VKB VL:

    1. Creation of SVG file

    2. add measurements

    3. add new sign-code to CSV file (used for DB)

Current apps used:

InkScape : https://inkscape.org/ VsDesign : https://www.dlw.be/vsdesign/

---

Proposed functionalities:

A form with input fields for:

  • Name (subject)

  • Organization

  • Photo1 (of the actual traffic sign)

  • Photo2 (the design of the sign with measurements etc., admins prefer to receive SVG-files)

  • a dropdown for 'onderschriften' (Talk to Geert for actual content in VKBVL)

  • a text box for custom 'onderschrift' / 'vrije ingave'

Mockups:

3 Partial alterations of data from Uri's in a Measure/Article?

needs refinement.

Nice-To-Have's

  • Re-use of "Maatregel"

  • In an AR (aanvullend reglement) every article has an index number (creating an order to the articles). The ability to change the sequence order of the articles (the index) in the AR is also a nice-to-have.

  • Signalisation of Zonal validity

  • Signalisation variable validity

  • "Opheffingsbepaling" -> Sometimes certain ARs become obsolete and need to be cancelled. When this field? is not filled out a message should appear along the lines: "Niet van toepassing".

*VV: Opheffingsbepaling is een specifiek type artikel, dat misschien generiek kan opgelost worden (cf. catalogus van bepalingen) In elk geval moet je zowel in juridische gronden als in de opheffingsbepaling verwijzen naar het betrokken besluit van het lokaal bestuur dat je wilt opheffen. Dit is dan gekoppeld aan de "citatenplugin" (maar dan uitgebreid naar de eigen besluiten van het bestuur en niet enkel de Vlaamse Codex) (deze feature zou best ook toegevoegd worden in de featurepassport van de citatenplugin ;) )

Last updated