Relatie openbareruimte - woonplaats in atom feed/inspireadressen

janhec · 7 januari 2023 om 12:35

Hopelijk hebben jullie nog geen genoeg van me, maar:
De relatie openbareruimte-woonplaats is nu 1 op 1, zoals bekend, via openbareruimte.woonplaatsref → woonplaats.identificatie.
nummeraanduiding heeft, zoals bekend, een kolom openbareruimteref->openbareruimte.identificatie.
Afgezien van historische gevallen, dus even uitgaand van een selectie waarbij in iedere tabel de kolom identificatie uniek is, lijkt deze verwijzingsystematiek een probleem bij openbareruimtes die gemeenschappelijk zijn aan (doorlopen in) meer dan 1 woonplaats.
Dit punt zag ik pas bij bestudering van het geotoko bagnlextract bagv2 schema (Just van den Broecke, BAG-V2 Extract — NLExtract 1.4.0 documentation); ik had het niet eerder zelf bedacht, tot mijn schande, hoewel ik wel last had van onjuiste woonplaatsen per adres. Dat wijtte ik uitsluitend aan geometrie aanpassingen zonder overeenkomstige aanpassingen van woonplaatsref in de openbareruimte tabel.
In JvdB is in tabel nummeraanduiding een kolom ‘gerelateerdewoonplaats’ opgenomen om dit probleem aan te pakken. (in inspire zou dat woonplaatsref in nummeraanduiding kunnen zijn).
Mijn vragen:

is het juist om (in atom feed/inspire) woonplaats 1 op 1 aan openbareruimte te koppelen?
m.a.w. zou deze ref niet een array moeten zijn, vgl pandref in verblijfsobject?
praktisch: moeten we (voorlopig) de extra kolom woonplaatsref in nummeraanduiding zien als een
verrijking, die desgewenst zelf aangebracht (of aangekocht) moet worden, of kan dit opgenomen
worden in inspire, al dan niet ten koste van de relatie tussen openbareruimte en woonplaats?

Edit:
Ik ben wat op zoek gegaan en heb gevonden dat er een (goede) samenhang wordt bereikt/nagestreefd tussen (gesplitste) wegen/openbareruimtes en woonplaatsen:

De samenstelling van de openbareruimte identificatie heeft zowel gemeente code als woonplaatscode in zich
Er is sprake van geometrische/geografische splitsing in de NWB overeenkomstig openbareruimtes in de BAG. De NWB bevat ook de openbareruimte identificaties (voor wegen) en de splitsing is op de grens, hoewel niet altijd even precies, zoals hier te zien (hier zonder consequenties voor adressen, overigens, bag_orl is de bag identificatie):

image1895×1358 220 KB

Situatie gekozen omdat: getoonde woonplaatsen in 1 gemeente vallen (Apeldoorn) en vanwege bekendheid met de situatie ter plaatse.

Mijn conclusie, voorlopig: er is geen sprake van een ontwerp fout, maar wel van een kwetsbare samenhang die vraagt om monitoring, net als andere (min of meer) redundante attributen, zoals toekenning van (het attribuut) woonplaats vs geografische ligging (in een woonplaats).
Mogelijk is dit op te vangen en al (deels) opgevangen het NWB proces; zo ver reikt mijn kennis niet.

sbjager · 8 januari 2023 om 12:49

Nee hoor. Vraag me af en toe wel af waar je mee bezig bent, en waarvoor je 't doet, maar verder geen probleem mee. Wel interessant om je conclusies af en toe te lezen.

Dat hangt er een beetje van in. In principe zou 1 Openbare Ruimte in 1 Woonplaats moeten liggen inderdaad. Dat een weg en/of straat soms door drie woonplaatsen heen loopt, doet daar niks aan af.

Het enige punt waar ik zo m’n twijfels over heb, is dat je het telkens over de atom feed/inspire hebt. En dat vind ik wat gevaarlijk, want bijvoorbeeld de inspire bevat niet alle gegevens uit de BAG, net zoals bijvoorbeeld de WFS niet alles bevat. Het kan dus zijn dat je daardoor dingen mist of onjuiste conclusies trekt. Als ik je posts zo lees, dan zou ik als ik jou was de volledige BAG downloaden (BAG, kies voor het zip archief). Zit je wel met het probleem van de aanwezige historie die je er uit moet filteren, maar je weet vrij zeker dat je alles hebt in ieder geval.

Plus dat je zit met het feit van verschillende statussen die elkaar lijken tegen te spreken, zoals dat van een geldige uitgegeven VBO in een Pand dat de status “Bouwvergunning verleend” heeft. Wat dus betekent dat er een VBO, en een adres, maar nog niet noodzakelijkerwijs een postcode, op een braakliggend terrein aanwezig kan zijn. Veelal word dat overigens gedaan omdat de nutsbedrijven daar dan alvast de aansluitingen en dergelijke kunnen gaan realiseren, die vaak ook al nodig zijn voordat de bouw start. En het kan handig zijn voor bijvoorbeeld een ambulance die naar een ongeval in een bouwput moet.

Maar: dat is natuurlijk ook afhankelijk van wat je uiteindelijke doel is, waarvoor je doet wat je aan het doen bent (af en toe lijkt het er op alsof je de BAG lokaal wil dupliceren ).

ALs je meer wil weten over het NWB, zou ik eens op de website rond gaan neuzen:
https://www.nationaalwegenbestand.nl/

janhec · 8 januari 2023 om 13:40

Goed om te horen dat mijn gedoe geen irritatie wekt .
Waar ik het voor doe en dupliceer;
Ja, klopt, ik dupliceer de BAG lokaal (maandelijks uit de inspire/atom feed) en gebruik die om schattingen te maken van personenaantallen per pand.
Daar ben ik in 2014 mee begonnen, toen nog bij provincie Zuid-Holland (nu gepensioneerd). In de loop van afgelopen jaar is de populatie service, zoals die in externe veiligheids kring bekend staat, overgegaan naar IPO (BIJ12); in het migratie proces heb ik nog regelmatig datasets aangemaakt om de uitkomsten te checken. Er is nog een toepassing die sterk verband houdt, en voor wat meer precisie werken we ook o.a. met de NHR en LRK en dan is het niet (altijd) eenvoudig om het juiste verblijfsobject te bepalen bij een (NHR) adres; daarom was/ben ik bezig om de ‘baglocatie’ van de NHR, zoals ik het maar noem, te toetsen en verbeteren.
De NWB heb ik er ondertussen bijgehaald (ook lokaal) en er komt uit dat de kwaliteit van de werkwijze/resultaten procentueel heel goed is, maar wel degelijk problemen geeft in uitzonderingsgevallen, en m.i. zijn die niet altijd structureel oplosbaar.
De uitzondering die ik opgezocht heb op Schouwen-Duivenland is illustratief:

Je ziet hier 2 adressen met een onjuist geregistreerde woonplaats.
Beide adressen komen uit op de N tak van de Weeldijk. Deze tak, itt tot de rest, is gemarkeerd in de NWB als behorend bij Zonnemaire, hoewel gelegen in Noordgouwe. Er is wel mogelijk een reden, nl dat de bijbehorende adressen in Zonnemaire liggen. Dat kan echter slecht doorkomen in de BAG registratie omdat beide delen van de Weeldijk dezelfde bag-identificatie hebben gekregen; maw de NWB zou hier kunnen helpen als de N tak een andere (extra) identificatie krijgt in de BAG, maar daar lijkt geen (andere) goede reden voor.
Nou, lijkt dit genoeg om even op te kauwen, maar er is meer.

De zuidelijke tak van de Weeldijk heeft de potentie om zowel adressen in Noordgouwe als in Zonnemaire te bedienen. Die zijn er nog niet, maar dat kan komen, toch? Zie plaatje:

Let ook op de adresstip in de ZO hoek die aangeeft dat de afstand tussen weg en woonplaatsgrens groot genoeg is voor een pand/adres aan de Weeldijk binnen Noordgouwe; op diverse plaatsen is die afstand klein genoeg om ook een adres in Zonnemaire te bedienen. In dat (hypothetische) geval heb je een onoplosbare situatie als je de woonplaats wilt afleiden uit de openbareruimte.
(Ik ben niet op zoek gegaan naar bestaande gevallen met deze situatie en weet dus niet of die voorkomen)

Dat is in mijn opvatting een reden om te zeggen dat het schema wijziging nodig heeft (woonplaatsref naar nummeraanduiding).
Ik zie ook een andere oplossing: als de geometrie van de verblijfsobjecten (plus ligplaatsen en standplaatsen) primair en juist is, evenals de geometrie van de woonplaatsen, is het attribuut woonplaats op te vatten als een afleidbare verrijking.
M.a.w. je zou dit kunnen realiseren in de inspire dataset en als (extra) info in de WMS/WFS, zonder de BAG zelf geweld aan te doen.
Zo is het iets duidelijker, hoop ik, wat me van de straat houdt en op de virtuele toer brengt.

sbjager · 8 januari 2023 om 20:35

Let op dat de NWB de BAG volgt (moet volgen).De NWB is niet eens een Basisregistratie, dus die kan nooit leidend zijn. Dus de redenering die je hier volgt is gevaarlijk. Sterker, de NWB word gevoed door de BAG (en de BGT en BRT).

De woonplaatsgrens is daar slecht gekozen, zodat twee huizen aan verschillende kanten van de weg in verschillende woonplaatsen liggen. Misschien is dit 1 van de redenen waarom ze toentertijd geen geometrie aan openbare ruimtes wilden geven (ondanks mijn vragen daarover). En het is inderdaad raar dat een adres aan een openbare ruimte is gelinkt die in een andere woonplaats ligt dan het adres zelf, maar onmogelijk is het niet.

Volledig mee eens. Met name het feit dat Openbare ruimte een geometrie nodig heeft. En de controle op woonplaats en Openbare Ruimte moet ruimtelijk zijn, niet administratief. In dit geval zou je dus gedwongen moeten worden om de woonplaatsgrens aan te passen, zodat zowel adres als openbare ruimte in dezelfde woonplaats liggen. Het probleem daarmee is weer dat alle mensen die aan die openbare ruimte liggen, dan ineens verhuizen. En da’s geen pretje… (ik heb voor een gemeente gewerkt en daar toentertijd hernummeringen meegemaakt. Niet leuk…)

Just_OSGeo · 9 januari 2023 om 10:22

Interessante thread! Ik denk dat @sbjager de nodige goede antwoorden heeft gegeven. Mijn bijdrage puntsgewijs:

ik zou altijd van de BAG LV brondata uitgaan
NLExtract leest deze data 1:1 in in PostGIS, bijv ‘woonplaats(ref)’ in NUM
de dataset ‘inspireadressen’ Atom feed is een extractie van BAG LV waarin mogelijk interpretaties zijn gedaan.
NHR: had ik zelfs nooit van gehoord, NWB zou ik ook niet zo gauw van uit gaan
bij twijfel/onderzoek, raadpleeg bagviewer.kadaster.nl, daar gemakkelijk ook terugmeldingen te doen.

Ik heb de BAG weleens, gekscherend, een veelkoppig monster genoemd. Dat verwees, bij naïef gebruik/inlezen, naar onverwachte multipliciteit (VBO-PND en impliciet OPR-WPL), “dubbele records” (vaak gehoord, ja historie dus), Nevenadressen die zelfde locatie als hoofdadres hebben, en dat qua gebruik voor de een adressen voorop staan, de ander Panden, en alles daartussenin.

Het aanvankelijke onderwerp hier, de OPR-WPL relatie was ook ooit een “instinker” bij NLExtract ontwikkeling. Er hadden andere oplossingen gekozen kunnen worden, bijv:

maak WPL expliciet “1-naar-N” in OPR zelf, dus “Array Type” in PostGIS en geef de actuele WPL BAG Id, of index in NUM
splits OPR in segmenten zodat OPR-WPL altijd 1:1 is en dus OPR binnen 1 WPL valt. De OPR-naam doet er in feite niet toe.

Maar beiden geven weer nieuwe problemen, dus de huidige oplossing valt mee te leven.

Er zitten op dit Forum ook mensen van de BAG LV, die veel meer inzicht en kennis hebben dan ik, bijv weten waarom historisch bepaalde ontwerpkeuzes zijn gemaakt.

sbjager · 9 januari 2023 om 10:26

Heel interessant inderdaad. 't is jammer dat mijn interview in het kader van het evaluatieonderzoek BAG al geweest is, anders had ik nog wat zaken uit deze draadjes ook vermeld

PieterDijkstraBAG · 10 januari 2023 om 07:08

Deze thread vraagt inderdaad om een reactie vanuit de LV BAG.

De registratie van objecten die in een andere woonplaats liggen dan de openbare ruimte waaraan deze objecten liggen roept al sinds het begin van de BAG vragen op. Laat ik beginnen met de opmerking dat deze situaties in de basis gewoon ingewikkeld zijn en dat het onmogelijk is deze situaties op een eenvoudige manier vast te leggen in een Basisregistratie.

Hoewel ik al sinds 2010 betrokken ben bij het beheer van de LV BAG geldt voor mij dat de ontwerpkeuze van voor mijn tijd is. Wat de argumenten zijn geweest om de huidige manier van het vastleggen ‘grensgevallen’ zijn geweest, is mij niet bekend. Ik kan natuurlijk wel toelichten hoe de BAG op dit gebied bedoeld is.

Er zijn twee belangrijke uitgangspunten bij de registratie van objecten bij een woonplaatsgrens:

Een openbare ruimte is een buitenruimte die in één woonplaats is gelegen. Praktijkhandleiding BAG: Openbare ruimte. Een openbare ruimte die in meerdere woonplaatsen ligt, wordt meerdere keren (met een apart ID) geregistreerd in de BAG. Een openbare ruimte wordt niet geregistreerd in een woonplaats waarin de openbare ruimte niet is gelegen. Er is dus altijd maar 1 woonplaats bij een openbare ruimte
Bij het adres wordt de woonplaats gebruikt van de woonplaats waarin het object zich fysiek bevindt: Praktijkhandleiding BAG: Welke woonplaats wordt in de BAG gebruikt in 'het adres'?

Er zijn situaties waarin het object in een andere woonplaats ligt dan de openbare ruimte waaraan dit object gelegen is. Dit geldt ook voor het voorbeeld in Schouwen-Duivenland. De objecten liggen in Zonnemaire en de openbare ruimte ligt in Noordgouwe.

Je krijgt hierbij de situatie dat het verblijfsobject in Zonnemaire (via de nummeraanduiding) gerelateerd wordt aan de openbare ruimte in Noordgouwe. De openbare ruimte Weeldijk bevindt zich immers niet in Zonnemaire en mag daarom niet worden geregistreerd in de woonplaats Zonnemaire.
Let op: nu komt het!
Als je de relatie vanuit de openbare ruimte zou volgen, krijg je Noordgouwe als woonplaats. Het object ligt echter in Zonnemaire en moet dus Zonnemaire krijgen als woonplaats voor het adres. Hiervoor is de verwijzing naar de woonplaats vanuit de nummeraanduiding. Deze direct relatie gaat boven de relatie tussen de openbare ruimte en de woonplaats. Hierdoor ontstaat dus alsnog een adres met de woonplaats Zonnemaire. De directe woonplaatsrelatie overschrijft de relatie tussen openbare ruimte en woonplaats.

We hebben uitgebreid beschreven hoe dit in de BAG wordt geregistreerd.

Het lastige is dat directe relatie naar een woonplaats vanuit de nummeraanduiding relatief gezien erg weinig voorkomt (2249 keer bij huidige adressen), maar dat wanneer deze relatie er is de woonplaats bij een adres verandert.

PieterDijkstraBAG · 10 januari 2023 om 07:17

Hieronder nog even een printscreen uit de BAG-viewer waaruit blijkt dat aan de openbare ruimte Weeldijk in Noordgouwe twee adressen zijn gelegen in Zonnemaire (en geen adressen in Noordgouwe).

janhec · 10 januari 2023 om 09:42

Er is dan een verschil tussen de inspire dataset en de BAG, wat ik nooit in de gaten heb gehad, en, ik wist niet van de optionele invulling van woonplaatsref in de BAG. Die bestaat niet in de inspire data en dat is dus een extra reden om NLExtract te gebruiken. Met dank dus, voor de reacties.
Ik heb er veel van geleerd, want ging er klakkeloos van uit dat de inspire data overeenkomen met de (‘echte’) BAG.
Ik heb in de laatste inspire data (download 8 januari jl) gecheckt op een eventuele recente verandering en vind:
(Weeldijk heeft identificatie 1676300000422467)

select distinct woonplaatsref, w.naam woonplaats, o.status opr_status , o.tijdstipregistratie::date "datum registratie", o.eindgeldigheid from openbareruimte o join woonplaats w on w.identificatie=woonplaatsref where o.identificatie='1676300000422467' order by o.eindgeldigheid;
 woonplaatsref | woonplaats |      opr_status       | datum registratie | eindgeldigheid
---------------+------------+-----------------------+-------------------+----------------
 2690          | Zonnemaire | Naamgeving uitgegeven | 2010-12-30        | 2021-09-28
 2681          | Noordgouwe | Naamgeving uitgegeven | 2021-09-29        | (null)

m.a.w. er is geen heel recente mutatie, maar kennelijk is de Weeldijk in september '21 van Zonnemaire naar Noordgouwe gezet. Dat is juist qua ligging, maar niet voor de adressen; hier is de optionele relatie dus nodig en kennelijk gebruikt. Er is geen relevante grens correctie in het spel.
(de laatste correctie is eind 2011 gedaan in het NW deel).