Oorspronkelijke vraag kwam van Heusden-Zolder, Zwalm, Gent, Merksplas
Wat is de geldigheid hiervan?
onbepaalde duur, dus nog relevant voor een VIP-dossier
Gemeenten hebben dit al gedeeltelijk gedigitaliseerd maar wordt nog niet meegegeven
Merksplas is klaar om dit mee te geven, Gent ook
Meeste gemeenten niet, dus voorkeur om optioneel te houden
Fednot vraagt aandachtig te zjin dat het niet is omdat een inlichting vandaag niet kant-en-klaar beschikbaar is, deze niet belangrijk is om mee te geven - moet verder geanalyseerd worden wat de impact is
‘Oude’ vergunningen zitten niet bij RO, maar bij dienst ‘Economie’
Recente vergunning zitten in Omgevingsloket, oudere niet
Momenteel socio-economische vergunning nog niet verplichten
@Evelyne Devos aparte analysecall inplannen met de gemeenten die dit wensen mee te geven (Merksplas, Hove, Heusden-Zolder, Gent)
Visualisatie adressen​
Probleemstelling
Wanneer de gebouweenheid niet aanwezig of gekend (bv. notarissen kennen enkel partitienummers) worden vaak ALLE gebouweenheden geselecteerd en wordt in het toelichtingsveld gespecifieerd waarover de aanvraag gaat. Met als gevolg een lange, onoverzichtelijke lijst van adressen bij veel gebouweenheden in PDF en GUI en geen onderscheid tussen hoofdadressen en subadressen.
Doelstelling
Duidelijk manier van adressen visualiseren in de VIP GUI en PDF
Voorgestelde aanpak
Hoofdadressen vermelden met vermelding subadressen tussen haakjes (zoals busnummers)
Ook toelichtingsveld met bv. partitienummers vermelden
De gebouweenheden worden niet weergegeven in VIP GUI en PDF. De gebouweenheden blijven wel beschikbaar in API.
Bij aanduiding van een gebouweenheid zonder subadres staat enkel het hoofdadres vermeld, gelijkaardig aan een aangeduid adres zonder gebouweenheden (bv. voor gemene delen van een appartementsgebouw)
Toelichting aanvraag iBOT (FEDNOT) naar VIP - waarom gebeurt aanduiding van alle adressen en gebouweenheden ookal is het slechts voor een aantal partitienummers?
FEDNOT koppelt met federale authentieke bron (kadaster)
Wanneer zij de gebouweenheid in VIP kunnen matchen, geven ze in de interactie het specifieke adres mee
Indien niet, zal de integratie iBOT - VIP alle gebouweenheden selecteren.
Opmerkingen
Dit blijft een tussentijdse oplossing, de grond van het probleem, zijnde een goede matching tussen partitienummers, adressen en gebouweenheden moet de doelstelling blijven > VIP blijft hier inderdaad parallel mee aan sturen
Waarvoor is specificatie van adres nodig? een dossier wordt afgeleverd op capakey/perceel:
Voor inlichtingen leegstand en verwaarlozing, VLOK-data (op heden nog geen filtering, maar wel de bedoeling), vergunningstoestand (optioneel), mogelijks ook bepaalde vergunningen en bouwovertredingen
Akkoord om de visualisatie van adressen (via hoofd/subadressen tussen haakjes) op PDF en in GUI door te voeren
Akkoord dat de aangevraagde gebouweenheden niet worden weergegeven in VIP GUI en PDF
Akkoord om bij aanduiding van een gebouweenheid zonder subadres niets te tonen in PDF/GUI
@Nicolas Hoflack (Unlicensed) volgt werkgroepen rond matching partitienummers/adressen/gebouweenheden mee op
Contactinformatie op PDF/GUI​
Voorstel om de contactinformatie van alle informatieleveranciers in de pdf toe te voegen bij ‘over dossier’ en in de GUI per inlichting. Op vandaag enkel via gebruikersomgeving beschikbaar. De bron wordt ook bij elke inlichting vermeld. Dit om duidelijk te maken dat de verantwoordelijke bronhouder moet gecontacteerd worden bij inhoudelijke vragen over de doorgegeven inlichting.
Opmerking
In een latere fase kunnen de logo’s van gemeenten en andere infoverstrekkers ook opgenomen worden.
Het is momenteel niet mogelijk om contactgegevens per rubriek/inlichting mee te geven. In de MVP versie is het enkel mogelijk om 1 email adres te voorzien, in de toekomst eventueel op te delen per rubriek.
Vraag van Leuven en Antwerpen
Is het mogelijk om bij doorklikken op mailadres een mail met vooringevuld onderwerp en/of inhoud toe te voegen? bv. Link naar dossier, dossiernummer… > wordt bekeken in welke mate dit kan opgenomen worden in de MVP versie.
Akkoord om op voorgestelde manier de contactinformatie op te nemen in de PDF/GUI
@Nicolas Hoflack (Unlicensed) zet vraag op backlog om contactinfo per rubriek/inlichting te kunnen specifiëren
@Nicolas Hoflack (Unlicensed) bekijkt om default mail onderwerp/body toe te voegen bij doorklikken op mailadres bronhouder
Correctiemelding door lokaal bestuur visualiseren​
Probleemstelling
Lokale besturen merken (mogelijke) fouten op bij read-only inlichtingen waarvan zij geen bronhouder zijn dus geen aanpassingen kunnen doen. Om te vermijden dat aanvrager deze mogelijks foutieve info doorkrijgt, staat het dossier on hold tot de bronhouder de fout heeft aangepast en de bron herbevraagd kan worden: dit is omslachtig en verlengd de doorlooptijd.
Fase 2 (eind 2023): Mail notificatie: VIP gaat de foutmelding van het lokaal bestuur per mail verzenden naar de bronhouder – met de vraag om deze binnen de 3 werkdagen uit te voeren
Resultaat van gewijzigde read-only bronnen weergeven: Bij herbevraging van de bronnen gaat VIP een resultaat weergeven welke gewijzigd zijn. Zodat het lokaal bestuur deze controleert en waar nodig de foutmelding verwijdert. Lokaal bestuur gaat ook hier de 4e werkdag het dossier valideren, met of zonder foutmelding.
Niet in scope voor 2023: Gecorrigeerd dossier automatisch bezorgen aan aanvrager indien correctie doorgevoerd werd na validatie.
Opmerkingen
Niet alle gemeenten controleren de read-only inlichtingen.
Belangrijke nuance:
soms is dit wel relevant, zoals bij Onroerend Erfgoed of VLOK data
VIP als katalysator voor bronoptimalisatie, waar de gemeenten mee een rol (kunnen) spelen
De aanvrager kan terecht bij de bronhouder voor verdere vragen. Contactinformatie wordt voorzien (zie hoger)
Gemeente is niet verantwoordelijk voor de read-only gewestelijke data, op deze manier kan de gemeente wel adviserend optreden naar de bronhouder - gelijktijdig kan de aanvrager hiervan op de hoogte worden gesteld.
Van dit soort inlichtingen een 'adapt' inlichting maken zodat gemeente meteen juist kan wijzigen, is juridisch niet toegestaan. Gemeente is geen bronhouder en zou hierdoor verantworodelijkheid nemen over data waarvan zij geen infoverstrekker is.
Kunnen bronhouders niet proactief hun lagen goed zetten? Hier zijn we parallel ook mee voor aan het sensibiliseren.
Akkoord met de voorgestelde gefaseerde aanpak voor visualisatie correctiemelding door lokaal bestuur. Het is optioneel, maar wel aangeraden dat lokale besturen de check doen om zo de brondata te helpen verbeteren.
Aankomende change requests​
Soort weg waarlangs perceel gelegen is​
Voorgestelde aanpak
Bedoeling om te koppelen met het Wegenregister voor het verrijken van deze inlichting, met nieuwe attributen
Er wordt met buffers gewerkt, 13m voor alle wegtypes, m.u.v. autosnelwegen waarbij buffer = 30m
Geen filtering: alle wegen, ook de trage wegen
Opmerkingen
Hoe kan het wegenregister goed gezet worden? (decentraal beheer)
via GIS-bulk of later via een loket: we vragen hierover verdere info aan wegenregister
Mogelijk wel teveel informatie doorkomen, door het gebruik van de buffers. Het is de bedoeling dat het lokaal bestuur dit gaat aanpassen/verwijderen, vermits ADAPT
Wordt er aan de andere wegbeheerder ook gevraagd om hun wegen na tek kijken? bv. Infrabel > te bekijken samen met wegenregister
@eveline.neirings plant overleg in met wegenregister over decentraal beheer en bespreking andere wegbeheerders (bv. Infrabel) en hun data
Akkoord met de voorgestelde aanpak herwerking inlichting soort weg en koppeling wegenregister
Voorwaarden gem. akte
Huidige context
Percelen die in het verleden eigendom waren van de gemeente en die verkocht zijn mits bepaalde voorwaarden
Als hetzelfde perceel daarna doorverkocht wordt en er zijn bepaalde van die voorwaarden uit de gemeentelijke akte nog van toepassing voor de nieuwe eigenaar
Voorstel verruiming context
Deze optionele inlichting kan ook gebruikt worden voor een perceel dat nog in eigendom van de gemeente
De voorwaarden meegeven die al bepaald werden door de gemeenteraad/CBS en ter info al worden meegeven aan de koper, vóór de akte wordt verleden
Opmerkingen
Optionele inlichting
Bij voorkeur ook in een vastgoeddossier en niet enkel bekend gemaakt in de onderhandse akte zodat de gemeente al tijdig kan informeren aan de potentiële kopers
Verduidelijking nodig hoe lang de voorwaarden geldig zijn + wanneer de akte is verleden of nog moet verleden worden
Akkoord dat de optionele inlichting voorwaarden gem. akte gebruikt kan worden voor een perceel dat nog in eigendom is van de gemeente en waarvoor de voorwaarden al gekend zijn, mits nuance tussen beide soorten duidelijk is.
@eveline.neirings neemt met Blankenberge op hoeveel keer dit voorkomt
Oostende bekijkt of ze deze verruiming ook zouden gebruiken/of dit vandaag nog veel voorkomt
Â
Features high level
Correctieaanvraag
Voorstel
Tot nog toe beperkt aantal fouten opgemerkt door de notarissen en makelaars op aan een (gemeentelijke) inlichting. De afhandeling van deze correctie aanvraag gebeurt buiten VIP. Gezien het beperkt aantal correctie aanvragen stelt VIP voor om dit pas na 2024 via VIP te laten verlopen.
Opmerking
Metrics opnieuw bekijken want gemeenten geven aan dat er al meer zijn
Aanvraag tot correctie en aflevering gecorrigeerd dossier blijft via mail aan de gemeente verlopen
Gemeente moet, tot deze feature is geïmplementeerd, bij wijziging na validatie van het dossier de pdf zelf sturen naar de aanvrager van het dossier vermits geen van de aanvrager applicaties de nieuwe PDF bezorgen.
Zal het mogelijk zijn om extra bijlage toevoegen bij de melding vanuit de aanvrager naar de gemeente? Voorbeelden: plannen, vergunningen, aktes, …
@eveline.neirings bekijkt met DEV de metrics van hoeveel keer afgelopen tijd hervalidaties gebeurd zijn
Betalingsflow - gemeente
Het is de bedoeling dat VIP eind 2023 de inning van retributies gaat doen en het deel gemeentelijke retributie doorstort aan de gemeenten.
De gemeentelijke retributies dienen gefactureerd te worden aan DNB vanuit de gemeenten
Hoe gaat dit in zijn werk: maandelijkse factuur of self-billing principe?
Wat hebben jullie als gemeenten nodig qua detail?Â
Jullie collega’s van de financiële dienst worden uitgenodigd op een volgende werkgroep
Discrepanties omgevingsloket
Probleemstelling
Zij er discrepanties tussen gemeentelijke data omgevingsvergunning en wat in omgevingsloket zit? In functie van latere koppeling VIP met het omgevingsloket.
Input gemeenten
Welke aanpassingen:
Geometrie
Omschrijving passen ze wel aan in functie van consequentie
De aanpassingen gebeuren lokaal in eigen software en stromen niet terug naar het omgevingsloket
Bij Leuven: pas volledig en ontvankelijk als geometrie overeenkomt met de realiteit
Kavels worden door aanvragers dikwijls niet of slordig ingetekend
Bij Antwerpen is de afspraak dat dossier onontvankelijk wordt verklaard als contour verkeerd is omdat aanpassingen niet terugvloeien en anders is er een discrepantie tussen GIS bij gemeente en de 'officiële' (en verschillen die later niet kunnen opgezocht)
Leuven: Algemene contour van verkavelingsaanvraag is correct maar specifiek deelkavels (wat is groep, voorschriften… is niet gegeorefeerde info)
Brugge: Als het om een ingedeelde activiteit gaat (milieu-luik), dan kunnen de rubrieken anders vergund worden dan aangevraagd. Deze anders-vergunde  rubrieken worden niet geregistreerd in het omgevingsloket, staan enkel in de beslissing die een bijlage is in het omgevingsloket.Â
Brugge: Wat met beschikbaarheid data? dossiers blijven maar 2 of 3 jaar zichtbaar in het omgevingsloket, dacht ik - na te gaan
Antwerpen: Probleem is ook de historische verkavelingscontouren en -loten die niet centraal beschikbaar zijn maar enkel op gemeentelijk niveau
Â
Andere/vragen
Â
Meldingsysteem: er komen veel vragen bij gemeenten over update dossier
notificaties zijn geïmplementeerd in iBot en sinds 27/02 gereleased.
notificaties waren reds geïmplementeerd in RealSmart, aangevuld met de mogelijkheid welke notificaties
voor VIP GUI te bekijken of en wanneer dit zal opgenomen worden en welke notificaties
Urgente aanvragen zijn niet mogelijk. Aanvragen worden chronologisch afgehandeld. Sensibilisering vanuit FedNot is al gebeurd.
Fouten bij kadastrale perceel nummers (basisregister wordt met maand vertraging geüpdatet, terwijl in de aanvraag toepassing de federale authentieke bron wordt gebruikt)
Voorstel om met het oude kadastrale perceel nummer de aanvraag te doen en dan in de toelichting de nieuwe capakey.
Inlichting risicogronden OVAM: analyse is ongoing, we komen er later op terug.
Algemeen de gewoonte maken als gemeente om bij problemen door te verwijzen naar de servicedesk van de toepassing van de aanvrager
Aanvrager moet zelf servicedesk contacteren
indien nodig neemt RealSmart of iBOT wel contact op met VIP
