Omschrijving topic | Probleemstelling - Opmerkingen en beslissingen | Actiepunten |
|---|
Aanpak BWG 2023 | Doelstelling van de businesswerkgroep: Wat past NIET binnen de businesswerkgroep: Features die geen afstemming meer nodig hebben (informeren) > publieke demo en feature planning Andere infodeling en updates > product mailing Melding problemen, suggesties > vastgoedinformatieplatform@vlaanderen.be en wij evalueren of over dit topic afstemming nodig is op volgende BWG
| |
Aankomende features komende PI |
Nieuwe inlichting: socio-econ. vergunning | Oorspronkelijke vraag kwam van Heusden-Zolder, Zwalm, Gent, Merksplas Wat is de geldigheid hiervan? 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)  Image Removed Image Added
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
|
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. 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
|
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. Voorgestelde (gefaseerde) aanpak Fase 1 (eerste helft 2023):VIP voorziet mechanisme waarbij een gemeente een correctiemelding kan meedelen op inlichtingtypes van gewestelijke read-onlybronnen (GUI/PDF)
Lokaal bestuur gaat ZELF de bronhouder contacteren per mail met deze melding. Binnen de 3 werkdagen antwoord, kan het lokaal bestuur herbevraging doen (via knop in VIP). Indien geen antwoord, dossier valideren mét de correctiemelding die gevisualiseerd wordt voor de aanvrager 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  ADAPT in plaats van FEED Beherende instantie: gedifferentieerde aanpak Lokaal bestuur: code beheerder = niscode dossier Nabijgelegen lokaal bestuur: (nis)code beheerder <> niscode dossier Andere wegbeheerder uit codelijst Ook particulier
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) 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.
- Nicolas Hoflack (Unlicensed)analyse opvolgen hoe verruiming voorwaarden gem. akte in datamodel
- 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, …
| - Akkoord om correctieaanvraag door notaris/makelaar én aflevering gecorrigeerd dossier via VIP pas na 2024 op te nemen in de VIP roadmap.
- 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 | - VIP plant werkgroep in met financieel verantwoordelijken
|
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: 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
| - Evelyne Devos plant aparte analyse call in met vrijwilligers rond aanpassingen waarmee rekening moet gehouden worden wanneer omgevingsloket als centrale bron gebruikt zal worden in VIP (Leuven, Zwalm, SKW, PSA, Brugge)
|
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) 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 Issue met aanvragen die blijven hangen
| |
