Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

Focus

Functionele werkgroep - Aanvraagproces (deel 2)

Presentator(s)

Inleiding en moderatie: Sammy Parmentier (product owner) en Eveline Neirings (Relatiebeheerder)
Presentatie: Benjamin Peeters (business analist)

Agenda

09:00 - 09:05

Welkom en agenda

09:05 - 09:15

Status werkgroepen, bevraging, Confluence

09:15 – 9:30

Aanvraag concept

09:30 – 9:45

Scenario’s en functionele vragen voor de werkgroep over aanvraagproces

9:45 – 10:20

Voorstelling van de data per rubriek

10:20 – 10:30

Vragen en opmerkingen

10:30-11:00

Marge

Deelnemers

Presentatie

Verslag

Omschrijving topic

Probleemstelling - Opmerkingen en beslissingen

Actiepunten

1

Het concept ‘Aanvraag’

Voorstel:

  • Buk aanvragen blijven mogelijk;

  • De aanvrager beslist zelf over het al dan niet koppelen van meerdere aanvragen via “Uw referentie”;

  • Per Capakey wordt een apart vastgoeddossier opgemaakt met:

    • “Uw referentie” indien ingevuld,

    • Een unieke VIP referentie,

    • Een Uuid.

Opmerkingen:

  • Afgesproken datamodel respecteren;

  • Het concept van een aanvraag ID behouden.

Het datamodel en de praktische én technische invulling ervan wordt bij het volgende overleg met het ontwikkelingsteam besproken, waarbij de requirement van een aanvraag en de identificatie ervan behouden blijft.

2

Interpretatie van bepaalde ‘gebieden’ op een perceel

Vraag: werken met binnenbuffers en dient het VIP interpretatie te geven?

  • (Sub-) Rubriek per (sub-) rubriek en per bron te analyseren indien al dan niet rekening te houden met buffers. Ook voor waterlopen en hoogspanning wordt een buffer gehanteerd.

  • “Semi-automatische” interpretatie:

    • Indien het perceel volledig ‘bedekt’ is door een gebied, dan zal het VIP “Ja” antwoorden.

    • Indien het perceel nergens raakt aan een bepaald gebied, dan zal het VIP “Neen” antwoorden.

    • Indien gedeeltelijk, te bekijken per bron en de wettelijke bepalingen of het VIP “Gedeeltelijk” dient te antwoorden.

  • Visualisatie van het perceel (en omgeving) en het bepaalde gebied op een kaart.

  • Steden en gemeenten gaan rubrieken waarvoor zij geen bronbeheerder zijn, de ontvangen informatie niet of nauwelijks contesteren. Enkel de informatie onder hun eigen beheer zal door hen geïnterpreteerd worden.

Per (sub-) rubriek en per bron meenemen in de analyse rond de informatie verzameling.

3

Zoeken en filteren op dossier

Extra attributen waarop gezocht en gefilterd zou kunnen worden:

  • Adres

  • Status

Zoeken op polygoon werd ook voorgesteld; voor de aanvrager (zowel notaris als makelaar) zien hierin weinig toegevoegde waarde. Echter, voor steden en gemeenten zou dit wel een functionaliteit kunnen zijn.

De 2 additionele attributen meenemen in analyse en voorstel GUI.

Polygoon als zoek-attribuut meenemen in analyse naar complexiteit.

4

Identificatie van het vastgoed

De verschillende scenario’s werden overlopen.

Capakey en gebouweenheid ID of partitienummer blijken voor de verschillende types onroerend goed en de verschillende scenario’s grotendeels de unieke sleutel.

Identificatie via het tekenen van een polygoon op de kaart is wel een vereiste (in het kader van openbaar domein).

Als enige “edge case” werd de woonboot aangehaald. Maar op het eerste zicht is dit voor België niet in scope: een woonboot wordt als roerend goed beschouwd.

  • No labels