Een UP-Adpf aanmaken op basis van UP-Adp

Gepubliceerd door Wouter Verhelst op

Jaarlijks wordt de productie van Adpf gestart rond april. Indien de eerste release van het uniek percelenplan (UP) voor jouw gemeente na deze periode valt, zal deze release dus nog géén uniek percelenplan zijn. De periodiek bijgewerkte percelenlaag uit het GRB (Adp-actueel), zal echter wel een uniek percelenplan zijn. Op die manier zit je dus tot het daaropvolgende jaar met 2 percelenkaarten die op sommige plekke geometrisch kunnen verschillen. Er is echter een manier om op basis van een UP-Adp-actueel toch al een Adpf aan te maken dat de geometrieën van het uniek percelenplan heeft. Deze methodiek is uitgewerkt door Informatie Vlaanderen.

  • Download Adp (meest recent) en Adpf (01-01-2019)
  • Selecteer in beide gevallen de percelen die behoren tot de gemeente (selectie op NIS-code)
  • JOIN beide bestanden obv CAPAKEY en selecteer de verschillen in 2 richtingen:
    • Percelen die nog voorkomen in Adpf 01-01-2019 en niet meer in Adp > deze moeten worden teruggezet
    • Percelen die voorkomen in Adp maar nog niet in Adpf 01-01-2019 > deze moeten worden verwijderd
  • Verwerk bovenstaande wijzigingen in de meest recente Adp, hierbij is soms wat interpretatie nodig maar meestal wijst dit zichzelf uit.
    • Delete uit Adp-actueel de percelen die voorkomen in Adp maar nog niet in Adpf 01-01-2019
    • Creëer in de laag Adp-actueel de percelen die nog voorkomen in Adpf 01-01-2019 en niet meer in Adp. Je doet dit door nieuwe polygonen te creëren op basis van de begrenzing van de omliggende percelen. In feite vul je dus de gaten opnieuw op.
  • Het resultaat is een fiscale toestand van de percelen voor 01-01-2019 maar met de geometrieën van na de release van het uniek percelenplan
  • Opgelet: de datastructuur van Adp en Adpf is anders. In het resultaat worden 2 attributen OIDN_ADPF en UIDN_ADPF toegevoegd. Op basis hiervan kan deze versie samen gebruikt worden met alle toekomstige versies van Adpf (01-01-2020, 01-01-2021, …). De datastructuur is nu als volgt:
    • OIDN: de objectidentificator van Adp (dus niet van Adpf !) > krijgt waarde -8 voor de teruggeplaatste percelen
    • UIDN: de versieidentificator van Adp (dus niet van Adpf!) > krijgt waarde -8 voor de teruggeplaatste percelen
    • VERSIE: het versienummer van Adp > krijgt waarde -8 voor de teruggeplaatste percelen
    • BEGINDATUM > krijgt waarde 01-01-1900 voor de teruggeplaatste percelen
    • VERSDATUM > krijgt waarde 01-01-1900 voor de teruggeplaatste percelen
    • CAPAKEY > komt 1 op 1 overeen met Adpf
    • FISCDATUM > krijgt waarde 01-01-2020 voor elk perceel, vanaf nu zal elk gewijzigd perceel als fiscale toestandsdatum de waarde krijgen van het fiscale jaar waarin hij wordt gecreëerd/gewijzigd
    • BHRDR > krijgt waarde 2
    • LBLBHRDR > krijgt waarde “AAPD”
    • NISCODE
    • BGNINV > krijgt waarde -8 voor de teruggeplaatste percelen
    • LBLBGNINV > krijgt waarde -8 voor de teruggeplaatste percelen
    • LENGTE
    • OPPERVL
    • OIDN_ADPF: de objectidentificator van Adpf, deze kan je gebruiken om verschillen met volgende versie van Adpf te detecteren
    • UIDN_ADPF: de versieidentificator van Adpf, deze kan je gebruiken om verschillen met volgende versie van Adpf te detecteren
Categorieën: GRB

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Deze website gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.