“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.
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
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 ‘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, …
