Beste Mensen,
Sorry voor cross-posting, maar deze discussie is voor de meesten niet
zichtbaar omdat ie zich in een GitHub issue afspeelt.
Waar het om gaat, is hoe we op correcte wijze BAG Mutatie bestanden met
NLExtract verwerken. We zijn al dichtbij een oplossing, maar onder
jullie zitten vele BAG-experts en mogelijke gebruikers van mutaties.
Evt antwoorden via de GitHub issue zodat we kennis op 1 plek houden:
https://github.com/opengeogroep/NLExtract/issues/55
groet,
Just
-------- Original Message --------
Subject: Re: [NLExtract] BAG : mutaties worden niet correct verwerkt
(#55)
Date: Tue, 19 Nov 2013 01:22:08 -0800
From: bartkraan <notificati...@github.com>
Reply-To: opengeogroep/NLExtract
<reply+i-5348673-ed5e6a9396f50e7ddffc882e8609aa105ae771eb-582...@reply.github.com>
To: opengeogroep/NLExtract <nlextr...@noreply.github.com>
CC: Just van den Broecke <j...@justobjects.nl>
Beste Just,
Het mutatiemechanisme van de BAG is inderdaad erg complex. Hieronder een
poging om het te verduidelijken:
De BAG bevat de levenscyclus de zeven objecttypen van adressen en
gebouwen. Ik gebruik hier verder pand als voorbeeld, maar hetzelfde
geldt voor alle andere BAG objecttypen.
Een pand wordt gebouwd, de situatie van het pand verandert een aantal
keer en uiteindelijk wordt het pand gesloopt. Vanaf het moment van
ontstaan van het nieuwe pand (bouwvergunning verstrekt) krijgt het pand
een uniek bag-id. Als de tijd verstrijkt zullen er meerdere voorkomens
van het pand zijn, bijvoorbeeld omdat de status van het pand wijzigt van
'bouwvergunning verstrekt' naar 'bouw gestart'. Om te weten welk
voorkomen actueel is op een peildatum moet er daarom gekeken worden naar
begindatumtijdvakgeldigheid en einddatumtijdvakgeldigheid.
Er is echter door de ontwerpers van het datamodel nog een tweede
mechanisme toegevoegd met als doel om eerder gemaakte foute mutaties te
kunnen corrigeren. De fout blijft gewoon onderdeel van de levenscyclus
van het pand, maar wordt gecorrigeerd met nieuwe voorkomens. In zo'n
geval wordt niet tijdvakgeldigheid maar aanduidingrecordincatief en
aanduidingrecordcorrectie gebruikt. Aanduidingrecordcorrectie geeft
daarbij aan wat het volgnummer is van de correctie, bij meerdere
correcties achter elkaar op hetzelfde voorkomen.
In een mutatiebestand kunnen op basis van dit mechanisme de volgende
wijzigingen doorkomen:
1: Een nieuw pand.
Nieuw pand-id dat nog niet bestond; wordt met insert toegevoegd.
2: Een situatiewijziging.
Bestaand pand-id; de nieuwe situatie wordt met een insert toegevoegd,
aan het record met de oude situatie wordt met een update een
einddatumtijdvakgeldigheid toegevoegd. Begindatumtijdvakgeldigheid van
het nieuwe record is gelijk aan einddatumtijdvakgeldigheid van het oude
record.
3: Verbetering van een fout.
Bestaand pand-id; de verbeterde situatie wordt met een insert
toegevoegd. Aan het record met de foute situatie wordt met een update de
aanduidingrecordinactief op true gezet en het foutvolgnummer in
aanduiddingrecordcorrectie gezet.
Een mutatiebestand bevat daarmee dus inserts van nieuwe voorkomens en
updates van voorkomens die al in de database zitten. Door een update
worden uitsluitend de velden einddatumtijdvakgeldigheid,
aanduidingrecordinactief en aanduidingrecordcorrectie geupdate.
Heel vervelend is het, dat bij mutaties van de derde soort (fouten), de
unieke key van een record wordt geupdate. Bovendien heeft dit het gevolg
dat door deze soort mutaties niet meer uit de levenscyclus van een pand
is op te maken in welke volgorde de mutaties zijn binnengekomen.
De volgorde van verwerking van de mutatiestroom is heel belangrijk.
Indien dit niet op extact de goede volgorde gebeurt, zou het kunnen
gebeuren dat er een update binnenkomt voor een record dat nog niet is
toegevoegd. In het mutatiebestand heeft daarom iedere bewerking een
tijdstipverwerking met 6 cijfers achter de secondekomma en daarbinnen
nog een volgnummer. Gelukkig komen de mutatiebestanden precies op die
volgorde gesorteerd binnen.
Voor mijn propertydata toepassingen ben ik vooral geïnteresseerd in de
dagelijkse/maandelijkse mutatiestroom. Die is echter alleen te
reproduceren op basis van de mutatiebestanden. Een levenscyclus-bestand
bevat geen informatie over het tijdstipverwerking van een mutatie. Ik
voeg inmiddels het tijdstipverwerking wel toe aan mijn bag database
tijdens het verwerken van mutaties.
Ik ben nog wel op zoek naar de maandelijkse mutatiebestanden vanaf het
moment dat de BAG compleet gevuld was. (1 juli 2011). Indien iemand met
hier aan kan helpen houd ik me aanbevolen!
Ik hoop dat het hiermee weer iets duidelijker is geworden. Indien iemand
nog vragen heeft dan help ik graag.
Met vriendelijke groet,
Bart Kraan
www.propertydata.nl <http://www.propertydata.nl>
—
Reply to this email directly or view it on GitHub
<https://github.com/opengeogroep/NLExtract/issues/55#issuecomment-28775752>.
_______________________________________________
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl
