Page Comparison

Stand van zaken: terugkoppeling themawerkgroepen

Inname: Grondwerken

• “Spoorwerken” voldoet als term. Indien er werken aan eigen busbedding moeten gebeuren, valt dit onder “Wegeniswerken”. Werken aan bovenleidingen zijn niet ondergronds, en zullen als Werk van het type “Spoorwerken” geregistreerd worden. Daarenboven is “Openbaar vervoer” is geen type werk, en via beheerder van het Grondwerk/Werk zal duidelijk zijn dat het om werken aan de infrastructuur van het openbaar vervoer gaat (De Lijn, Infrabel, …).

• “Boring” wordt toegevoegd als specificatie bij Grondwerken.

• Bij de specificaties “(her)aanleg” en “herstel/onderhoud” moet altijd minstens 1 andere specificatie aangeduid worden, ter verduidelijking van het Grondwerk. Omgekeerd is dit niet verplicht: wanneer bijv. “toplaag” aangeduid wordt, hoeft er niet gespecificeerd te worden of het om heraanleg dan wel herstel/onderhoud gaat.

• “Dringend” is geen specificatie van een Grondwerk, maar wel een categorie op zichzelf en moet naast cat1-2-3 komen te staan. Een grondwerk van categorie dringend heeft eigen regels. Er zullen dus 4 categorieën van grondwerken zijn.

• De codelijst van types grondwerken wordt niet uitgebreid met bijv. fietslaadpalen, elektriciteitskasten, … Dit zijn details van het openbaar domein die na installatie ervan in het GRB moeten terechtkomen, maar in GIPOD niet nodig zijn. Indien blijkt dat er heel veel grondwerken als type “Andere” geregistreerd worden die allemaal onder 1 noemer te vatten zijn, kan de codelijst later alsnog uitgebreid worden.

• “Spoorwerken” blijft een type Grondwerk.

•  AIV: Definitie “Spoorwerken” verduidelijken in documentatie.

• “Boring” is een specificatie bij Grondwerken.
• Bij “(her)aanleg” en “herstel/onderhoud” is het verplicht minstens 1 andere specificatie te selecteren.
• “Dringend” is geen specificatie, maar een categorie Grondwerk.

Inname: Werken

• “Hoogtewerker” wordt toegevoegd als subtype bij Werken > Bouwwerken.

• “Spoorwerken” blijft als type bij Werken. Zo is er consistentie met de term bij Grondwerken (zie hierboven).

• “Verkaveling” mag geschrapt worden als specificatie bij Werken. Zal altijd om Grondwerken gaan.

• “Hoogtewerker” is een subtype bij Werken > Bouwwerken.
• “Spoorwerken” blijft een type Werk.
• “Verkaveling” is geen specificatie van een Werk.

Inname: Evenementen

• Akkoord met de voorgestelde uitbreidingen van de lijst: Reclame en Uitstalling.

• “Reclame” is een type Evenement.
• “Uitstalling” is een type Evenement.

GRB-melding bij GW

• GRB-melding vanuit GIPOD door 2 extra velden bij GW in te vullen:

  • is er impact op het GRB: ja/nee ?

  • zal er een as-built ikv bijhouding worden opgeleverd: ja/nee ?

• Deze velden kunnen vanaf de creatie van het GW meegegeven worden, ze zijn pas verplicht mee te geven bij afsluiten van het GW (status “uitgevoerd”).

• GRB-melding gebeurt via GIPOD door 2 extra velden te voorzien bij een GW, verplichte velden bij het afsluiten van het GW.

Sleufsynergie-aanvraag (SSA)

• Verwittiging indien “voorlopige unie SSA” vergroot door gekoppelde GW. Keuze tussen melding wanneer er x aantal m² wordt toegevoegd aan de “voorlopige unie” SSA (door een GW te koppelen), of melding wanneer de “voorlopige unie” vergroot met x% oppervlakte? Men wil niet teveel meldingen krijgen, maar ook niet te weinig. En moet men inschrijven op deze melding, of net uitschrijven als men ze niet wil ontvangen. Per GW, of geldt inschrijving voor organisatie?

  • melding indien “voorlopige unie” SSA met 50m² vergroot (en dus geen 3 meldingen bij % zoals voorgesteld)

  • melding voor organisaties die de oorspronkelijke SSA ontvangen hebben (ongeacht hun antwoord)

  • opt-out systeem: uitschrijven indien je geen meldingen wil ontvangen; per organisatie (met synergie-interessezone), niet per GW

• Verwittiging bij lancering SSA in zone waar reeds SSA/SSYN is, om 2 gelijktijdige SSA/SSYN te vermijden. GIPOD kan nieuwe lancering niet afblokken (beslissingsregels te moeilijk), maar kan wel ondersteunen:

  • in GUI zullen SSA/SSYN in omgeving GW getoond worden, gebruiker beslist dan zelf of hij nieuwe SSA lanceert

• • via services (API) vraagt gebruiker eerst SSA/SSYN in omgeving GW op, alvorens nieuwe SSA te lanceren (zal gedocumenteerd worden in best practices integratie) - geen melding via services nadat SSA gelanceerd werd

• Lijst met organisaties die SSA ontvangen: in 1e release beschikbaar NA lancering SSA

• Antwoord op SSA kan gewijzigd worden zonder reden op te geven; antwoord kan niet verwijderd worden.

• Melding wanneer “voorlopige unie SSA” vergroot met 50m².
• Naburige SSA en SSYN worden getoond in GUI bij lanceren nieuwe SSA; geen melding via services.

•  AIV: Documenteren ‘best practices lanceren SSA - eerst naburige SSA/SSYN opvragen’.

• Lijst met organisaties die SSA ontvangen hebben beschikbaar NA lancering SSA.
• Niet nodig om reden op te geven bij wijzigen antwoord op SSA.

Sleufsynergie (SSYN)

• Akkoord met voorstellen ivm attributen SSYN

• Bij elke set contactgegevens zal kunnen meegegeven worden of deze ook gepubliceerd mag worden. Wanneer contactgegevens als publiek gemarkeerd staan, zullen deze mee ontsloten worden via de public API en zichtbaar zijn in Geopunt; indien niet gemarkeerd als publiek, zullen ze enkel zichtbaar zijn in GIPOD.

• Beheer SSYN kan overgedragen worden naar een nieuwe piloot (die minstens 1 GW in de SSYN moet hebben). Deze nieuwe piloot moet de overdracht niet goedkeuren, dit zou het proces enkel vertragen. Bij overdracht zal GIPOD de contactgegevens van de piloot van de SSYN ineens vervangen door deze van de nieuwe piloot.

• Het moet mogelijk zijn om een signalisatievergunning aan te vragen voor de SSYN, ipv voor de verschillende GW die in de SSYN zitten. Maar aanvraag op GW-niveau moet ook nog steeds kunnen.

• Initiële zone SSYN = unie van alle grondwerkzones in SSA

• Mogelijke rollen contactgegevens SSYN: dossierbeheerder, gemeenschappelijke aannemer, veiligheidscoördinator ontwerp, veiligheidscoördinator uitvoering, toezichter
• Niet nodig om coördinatievergaderingen te registreren in GIPOD
• Beheer SSYN kan zonder goedkeuring overgedragen worden naar nieuwe piloot; contactgegevens veranderen mee.
• Signalisatievergunning moet ook aangevraagd kunnen worden voor de SSYN in zijn geheel (en niet enkel voor GW).

Webtoepassing (GUI)

• Akkoord met voorstel om in eerste release van de GUI bij het zoeken op ‘beheerder’, enkel resultaten te tonen voor de organisatie waarop gezocht wordt, niet van de suborganisaties ervan.

  • dit kan later nog toegevoegd worden, indien gewenst

  • via de services (API) kan er wel gezocht worden op meerdere organisaties en/of suborganisaties in 1 request

• Vragen ivm detail SSA in GUI komen later verderop aan bod.

• In eerste release GUI worden bij zoeken op ‘beheerder’ enkel resultaten voor de geselecteerde organisatie getoond, niet voor de suborganisaties ervan.

Flow Sleufsynergie(-aanvraag)

SSA vanuit grondwerk

• Flow werd overlopen aan de hand van wireframes GUI

Verschil SS(A) en P(A)

• Verschil tussen sleufsynergie-aanvraag (SSA) en projectaanvraag (PA) werd visueel verduidelijkt.

Samenwerkingsaanvraag: detail-schermen

• Detailschermen samenwerkingsaanvraag (SSA of PA) werden besproken.

  • aanvraag lanceren vanuit GW

  • voor deadline 1

    • TBD: welke gegevens lancerend GW moeten getoond worden in detail SSA (sidebar)? - zie slide 37

      • bijv: type - subtypes - specificaties - …

    • TBD: welke gegevens mbt. gegeven antwoord moeten getoond worden in detail SSA (sidebar)? - zie slide 44

      • bijv: JA/NEE - voorwaarden - ID - type - subtypes - …

  • na deadline 1 en voor deadline 2

  • na deadline 2 (of bij het voortijdig afsluiten SSA)

    • Eens SSA afgesloten en SSYN gemaakt werd, zal link SSYN op detail GW te zien zijn ipv link SSA. Link SSA is wel beschikbaar in historiek.

      • Ook al moet je op dat moment niks meer doen met de SSA, de info blijft nuttig. Raadplegen via opvragen historiek lijkt omslachtig, te bekijken of het eenvoudiger kan (link behouden).

• In kaartview aan rechterkant zullen verschillende lagen aan- en afgezet kunnen worden, met relevante zaken in de omgeving van het grondwerk: andere innames, SSA, SSYN, …

  • niet enkel bij lanceren SSA, maar ook bij intekenen innames, …

  • bedoeling is om op die manier zo veel mogelijk conflicten te vermijden (ipv te berekenen)

  • BWG vraagt om deze zaken ook via de “services” te kunnen zien (dus in eigen systeem, buiten GIPOD)

    • is eigenlijk een weergave van verschillende zoekopdrachten, dus kan zeker

    • indien dit op eenvoudige wijze zou kunnen (WMS, WFS, … ), is dat makkelijker dan via zoekqueries

    • moet wel beveiligd zijn, gaat immers om alle GIPOD data

•  VRN: Doorgeven welke gegevens lancerend GW getoond moeten worden in detail van SSA
•  VRN: Doorgeven welke gegevens mbt. antwoord op SSA moeten getoond worden in detail van SSA
•  AIV: Analyse ‘welke links tonen op detail GW: SSA en/of SSYN’
•  AIV: Analyse ‘tonen van verschillende lagen op eenvoudige wijze via services’

Sleufsynergie: detailschermen

• Detailschermen sleufsynergie werden besproken. Er wordt geen onderscheid gemaakt tussen het GW van waaruit de SSA initieel gelanceerd werd en de andere gekoppelde GW in de sleufsynergie. Wel is aangegeven wie de piloot is (“door …”), en welk GW bij welke deelnemer van de sleufsynergie hoort.

Flow Hinder bij inname

Hinder bij grondwerk

• Flow hinder bij GW werd overlopen aan de hand van wireframes GUI

  • nutsbedrijf registreert GW met o.a. grondwerkzone

  • aannemer vraagt signalisatievergunning aan met o.a. werfzone

    • via formulier GIPOD: beperkte set velden kan doorgegeven worden (geen hindergegevens zoals doelgroep/gevolg, …) + signalisatieplan als bijlage

    • via tool S&G: info naar keuze kan gevraagd worden aan aannemer; gegevens aanvraag signalisatievergunning en evt. hindergegevens (bv. doelgroep/gevolg) worden doorgestuurd naar GIPOD

  • lokaal bestuur behandelt aanvraag => creatie en beheer hinder(s)

    • default hinderzone (in GUI) = werfzone; kan aangepast worden

    • niet nodig om default doelgroep/gevolg te voorzien in GIPOD bij creatie hinder; gemeente vult deze in

    • periode kan aangepast worden

  • link naar vergunning kan toegevoegd worden: URL/URI of als bijlage

• Focus zal eerst liggen op de API’s, erna pas op UI, omdat de API’s sneller klaar moeten zijn voor de integratoren.

• GIPOD voorziet geen default doelgroepen/gevolg bij de creatie van hinder bij GW

Hinder bij evenement

• Flow hinder bij E werd overlopen aan de hand van wireframes GUI

  • vereenvoudigde versie van flow hinder bij GW

  • hier ook geen default doelgroep/gevolg voorzien in GIPOD bij creatie hinder

• Nog te bekijken hoe een parkeerverbod bij evenement dient ingegeven te worden

• GIPOD voorziet geen default doelgroepen/gevolg bij de creatie van hinder bij E

•  AIV: Analyse ‘registreren parkeerverbod bij evenement’

Flow Hinder bij synergie

• Flow hinder bij SSYN werd overlopen aan de hand van wireframes GUI

  • hinder kan beheerd worden voor de volledige sleufsynergie

  • ook hier moeten geen default doelgroep/gevolg voorzien worden in GIPOD bij creatie hinder

• GIPOD voorziet geen default doelgroepen/gevolg bij de creatie van hinder bij SSYN

What’s next?

Overzicht kalender: volgende themawerkgroepen, business werkgroep, deadlines, …