Zoals gemeld in het nieuwsbericht van donderdag 8 februari 2018, is gebleken dat het veld ‘eindRegistratie’ bij gemuteerde objecten niet werd meegeleverd met de doorlevering vanuit de BGT naar PDOK.
Sinds 22 maart 2018 is dit issue in de BGT opgelost.
Objectmutaties in de periode vanaf 24 november 2017 t/m 22 maart 2018 zijn nog niet hersteld in de PDOK-data.
De verwachting is dat dit issue eind april volledig is hersteld.
Voor eerdere communicatie hierover, klik hier.
Beste Rob,
Kun je al inmiddels aangeven of eind April gehaald gaat worden? Dit in verband met een product voor een klant van mij waarbij historie (en dus eindRegistratie) een essentiele rol speelt.
Ik vraag niet zozeer om een garantie maar misschien kun je een tussentijdse stand van zaken geven?
Groet,
Ronald Mulder
@Ronald_Mulder - Wellicht is NLExtract een passend alternatief …? Deze heeft al sinds februari een adequate correctie op bijna alle BGT-objecten. Alleen bij de OR-labels gaat dit nog niet goed …
@HvdMeij Dank voor de tip!
Echter het eindRegistratie gegeven mist al in de CityGML Extract bestanden zelf. Wat is je redenatie dat NLExtract dit dan wel zou bevatten? Bedoel je dan een Extract / dump wat vanuit NLExtract wordt aangeboden?
Er wordt na verwerking uit PDOK een correctie-script overheen gedraaid die checkt welke varianten historisch zijn en (volgens mij uit de keten) bepaald welke varianten dan welke eindregistratie waarde moeten krijgen. Ben er niet heel diep in gedoken, maar het belangrijkste is dat je niet voortdurend met dubbele of zelfs meervoudige objecten wordt geconfronteerd waar recente mutaties hebben gespeeld …
Het gaat wel om de totale dump, dus heel NL … En het is een PostgreSQL 9.6.3 dump (bij lagere releases kan de restore een fail geven). Gebruik daarom zelf sinds dit weekend PostgreSQL versie 10.3 …
Dank, klinkt interessant en zeker als alternatief!
Ik wacht echter eerst nog even de reactie van @Rob af voordat ik dit pad bewandel.
Als e.e.a. snel gefixed is dan vergt mijn huidige inrichting vermoedelijk minder inspanning.
Hier even een update over dit issue:
Dit issue (zie https://www.pdok.nl/nl/actueel/nieuws/artikel/28mrt18-update-rond-bgt-issue-niet-doorleveren-veld-‘eindregistratie”) is inmiddels hersteld in de landelijke voorziening.
Dit weekend gaat PDOK dit issue herstellen. De verwachting is dat de data uit de periode vanaf 24 november 2017 t/m 22 maart 2018 begin volgende week hersteld is.
Dat is goed nieuws, we zullen het volgende week in onze routines controleren. Bedankt voor de update.
@John_Schaap, laat je @JBak en @Ronald_Mulder weten (en iedereen natuurlijk 
) mocht er onverwacht nog iets zijn wat de verwachting beïnvloedt? Bedankt!
@JBak en @Ronald_Mulder. Helaas is het herstellen van de data uit de periode 24 november 2017 t/m 22 maart 2018 niet gelukt. We streven nu om de herstellevering van de landelijke voorziening naar PDOK komend weekend te doen.
@HvdMeij, @Ronald_Mulder: het issue met de openbareruimtelabels in de NLExtract Postgis dump is gefixed.
Het NLExtract script kijkt naar de volgorde van de voorkomens van BGT-objecten in de historie en werkt de eindregistratie bij van alle objecten m.u.v. het laatste, indien dit veld leeg is.
Vervolgens wordt in een tweede run de objecteindtijd gezet en ook eindregistratie van objecten die helemaal afgesloten zijn. Merk op dat in de GML dump, dus ook in NLExtract, het laatste voorkomen twee keer voorkomt. Alleen het veld lv-publicatiedatum is gewijzigd.
Openbareruimtelabels waren lastiger, omdat die bij het inlezen opgeknipt wordt, zodat ieder label slechts één punt en één bijbehorende hoek bevatten.
Code: NLExtract/fix-eindregistratie.sql at master · nlextract/NLExtract · GitHub
Hoi @fsteggink, geniaal stukje SQL, complimenten! 
Het concept wat je toepast had ik wel bedacht, althans dat zoiets zou moeten kunnen maar het daadwerkelijk maken ervan was vast even een puzzeltje!
Niet flauw bedoeld hoor maar verwacht je dat dit script nog in deze vorm nodig is als de levering hersteld is?
Ronald, dat is dan niet meer nodig. Ik neem met alle plezier afscheid van dit script 
Ook omdat dit ervoor zorgt dat het laden van de BGT geen 2 uur meer duurt, maar 5 uur…
In ieder geval is het handig om in voorkomende gevallen zelf een alternatief achter de hand te hebben, zodat gebruikers van NLExtract (de software of de data) geen last hiervan hebben.
Nieuwe week, nieuwe kansen. Kan er een update worden gegeven rond dit issue? Is het gelukt om de herstellevering afgelopen weekend door te voeren?
Vanwege problemen met de (verwerking) van de dagelijkse BGT doorlevering van Kadaster aan PDOK(https://www.pdok.nl/nl/actueel/meldingen/26apr18-verstoring-bij-updates-bgt) hebben we de herstelwerkzaamheden dit weekend helaas moeten uitstellen. Op dit moment ligt de nadruk op het oplossen van het issue met de dagelijkse doorlevering en hopen we de herstellevering in een volgend weekend uit te kunnen voeren.
@alexander_maljaars @JBak jammer dat het niet gelukt is! 
De zinsnede “in een volgend weekend” verontrust mij wat, ik doe de aanname dat er een planning is waar dit op komt te staan / staat?
Ik heb een opdrachtgever die wacht op analyse resultaten op deze dataset, dit staat nu op hold en ik kan enkel de status doorgeven die jullie hier publiceren.
Kun je aangeven met welke prioriteit dit door jullie behandeld wordt? Dit loopt al meer dan een kwartaal immers!!