Adres conform BAG toepassen

[PalmJanssen]

Adres in IMEV is opgenomen als CharacterString. Een adres conform de BAG bestaat uit een aantal benoemde velden. Zie dit voorbeeld uit IMKL: (rode lijnen hebben voor dit voorbeeld geen betekenis)

Voor IMEV ligt een dergelijke toepassing van adres ook voor de hand.

relatie met #19

[PalmJanssen]

Zou een aanpassing zijn bij alle attributen waar een adres is opgenomen. Het datatype is dan geen CharacterString maar het Gegevensgroeptype Adres.

[PalmJanssen]

Werkgroep: onderzoek

• niet alle objecten hebben een volledig adres
• zorg voor zo'n optie. Bijvoorbeeld een locatieaanduiding (of omschrijving)
• is BAGid niet genoeg?
• wat is functie van adresseerbaarobject identificatie?

[PalmJanssen]

1. er is een optie om het adres of een locatieOmschrijving te gebruiken
2. BAGid is als optioneel attribuut opgenomen
3. Voor de directe herkenbaarheid van adres zijn de bag adres-attributen opgenomen

Oplossing ziet er zo uit:

[PalmJanssen]

Aanleiding wijziging

Adres in IMEV is opgenomen als CharacterString. Een adres conform de BAG bestaat uit een aantal benoemde velden en/of een BAGid.

Voorstel is om dat in IMEV ook te doen en daarmee de basisregistratie BAG toe te passen.

Adres wordt op de volgende plaatsen toegepast:

relatie met #19

Voorgestelde wijziging

Zou een aanpassing zijn bij alle attributen waar een adres is opgenomen. Het datatype is dan geen CharacterString maar het Gegevensgroeptype Adres.

Een volledige toepassing van het BAG adres is de volgende. Zou een aanpassing zijn bij alle attributen waar een adres is opgenomen. Het datatype is dan geen CharacterString maar het Gegevensgroeptype Adres. Er is hierbij rekening gehouden dat een locatie ook een niet BAG adres kan hebben. In dat geval wordt een attribuut 'locatieomschrijving' ingevuld.

Oplossing ziet er zo uit:

Voor de BAGid moet nog bepaald worden van welk BAG object de id wordt uitgewisseld. Het ligt voor de hand om het id van BAG:AdresseerbaarObject daarvoor te gebruiken.

In IMKL wordt BAGid op deze manier gedefinieerd:
Naam: BAGid
Definitie: BAG identifier van een AdreseerbaarObject of een Nummeraanduiding zoals geregistreerd bij de BAG.
Omschrijving: Afhankelijk van de context waarin het adres wordt gebruikt wordt de BAGid van het AdresseerbaarObject of van de Nummeraanduiding gebruikt. Voor een koppeling naar een bezoek of postadres de BAGid van de Nummeraanduiding.

Impactanalyse

Geef hier een indicatie van de impact van de wijziging:

• Wie gaat er wat van merken? dataprovider, REV en Softwareleveranciers
• Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Nee, de informatie betekenis blijft gelijk.
• Heeft het impact op het json-schema? Ja.

Prioriteit

laag, midden, hoog

Toelichting

Kan met twee attributen en een constraint worden uitgewerkt (zoals nu gedaan) of met een keuze attribuut. De laatste heeft het voordeel dat validatie via het JSON schema wordt afgedwongen.

[PB-GNM]

Reacties software leveranciers:

• Wij kennen de behoefte aan een adres of locatieomschrijving, omdat niet alle locaties een adres hebben. Wij hebben dan ook geen bezwaar om dat in het IMEV op te nemen.
  Het gaan hanteren van BAG-adressen heeft wel de nodige impact. Een aanpassing van de API en software is overkomelijk, maar we zitten dan ook met alle productiedata die ofwel opnieuw aangeleverd moet worden, ofwel op een andere manier bijgewerkt. Beiden opties waar niemand heel gelukkig van zal worden. Dit zal dus goed afgewogen moeten worden.
• Geen voorkeur, maar als BAG-gegevens worden toegevoegd dan alleen de BAG-ID. En ook deze id - net als adres - niet verplicht maken. Dan is er geen of weinig impact.
• Wij gebruiken in ons VTH-systeem nu alleen het BAG-ID (van het Terrein-Gebonden-Object) en dat object heeft een relatie met een BAG-Nummeraanduiding. Die nummeraanduiding heeft eigenschappen zoals openbareRuimteNaam, huisnummer, huisletter, huisnummertoevoeging, woonplaatsNaam en postcode. Als een object geen relatie heeft met een BAG-ID gebruiken we de ‘globale locatie’ die overeenkomt met de ‘locatieomschrijving’ van de LocatieActiviteit. Wij voorzien slecht een beperkte impact als jullie dit wijzigingsvoorstel gaan doorvoeren. Wat belangrijk is om vast te leggen is welk BAGid moeten we vastleggen als “attribuutsoort” van het Adres!

[PB-GNM]

Ter verduidelijking hier het BAG objecten model:

[PB-GNM]

Expertgroep:
Vraag: BronVanGeometrie wat is het nut hiervan?
Constraint moet worden xor. minimaal 1 van de 2, dus mag ook beide

[PalmJanssen]

Voorstel is op de volgende manier verwerkt.

Twee attributen:
adres met de definitie: Het adres van de locatie waar de activiteit wordt uitgeoefend door middel van een verwijzing naar de BAGid van het BAG-Object Nummeraanduiding.

locatieomschrijving met de definitie: Omschrijving van de locatie als alternatief of toevoeging aan het adres.

Er is een constraint AdresEnOfLocatieomschrijving met de regel dat minimaal 1 van beide ingevuld moet zijn. Ze kunnen ook beide zijn ingevuld.

Ook bij het attribuut adresExploitant is de BAGid van de nummeraanduiding opgenomen.

[PB-GNM]

Opgelost in versie 1.3.