Issue wordt met hoge prioriteit behandeld, de relevantie is duidelijk, maar de formulering van de prognose blijft nog even zoals die nu is. Zodra er meer helderheid is, wordt dat gecommuniceerd.
Goed nieuws
BGT-issue niet doorleveren veld ‘eindRegistratie” afgerond
@JBak , @Ronald_Mulder, @HvdMeij, @fsteggink
Afgelopen weekend zijn de objectmutaties hersteld in PDOK voor dit issue
zie:
https://www.pdok.nl/nl/actueel/nieuws/artikel/14mei18-bgt-issue-niet-doorleveren-veld-‘eindregistratie”-afgerond
1 like
Beste John, wat hebben jullie getest waaruit blijkt dat het is opgelost? In het bestand dat wij hebben geanalyseerd blijkt nog het onderstaande.
@Ronald_Mulder, heb jij andere bevindingen?
Features die onterecht geen eindRegistratie hadden, komen nog steeds voor zonder eindRegistratie.Daarnaast zijn er objecten waarvan voor iedere versie (LV-publicatiedatum) 2 objecten geleverd worden. Het gevonden object L0001.11aa0fea1722452ca41119823df491db is gemuteerd in de periode dat het probleem optrad.
Hier wat fragmenten uit het bestand dat gisteravond is gedownload (en in ieder geval tot vandaag 15:00 is er geen nieuwe versie geplaatst):
<PlantCover xmlns="http://www.opengis.net/citygml/vegetation/2.0" p1:id="bddd75476-20eb-11e8-951f-610a7ca84980" xmlns:p1="http://www.opengis.net/gml">
<creationDate xmlns="http://www.opengis.net/citygml/2.0">2014-11-04</creationDate>
<LV-publicatiedatum xmlns="http://www.geostandaarden.nl/imgeo/2.1">2017-05-01T23:59:01.000</LV-publicatiedatum>
<relatieveHoogteligging xmlns="http://www.geostandaarden.nl/imgeo/2.1">0</relatieveHoogteligging>
<inOnderzoek xmlns="http://www.geostandaarden.nl/imgeo/2.1">false</inOnderzoek>
<tijdstipRegistratie xmlns="http://www.geostandaarden.nl/imgeo/2.1">2017-05-01T15:18:43.000</tijdstipRegistratie>
<identificatie xmlns="http://www.geostandaarden.nl/imgeo/2.1">
<NEN3610ID>
<namespace>NL.IMGeo</namespace>
<lokaalID>L0001.11aa0fea1722452ca41119823df491db</lokaalID>
</NEN3610ID>
</identificatie>
<bronhouder xmlns="http://www.geostandaarden.nl/imgeo/2.1">L0001</bronhouder>
…
<PlantCover xmlns="http://www.opengis.net/citygml/vegetation/2.0" p1:id="bd80d237b-53f6-11e8-a5a2-73a1868acdce" xmlns:p1="http://www.opengis.net/gml">
<creationDate xmlns="http://www.opengis.net/citygml/2.0">2014-11-04</creationDate>
<LV-publicatiedatum xmlns="http://www.geostandaarden.nl/imgeo/2.1">2017-05-01T23:59:01.000</LV-publicatiedatum>
<relatieveHoogteligging xmlns="http://www.geostandaarden.nl/imgeo/2.1">0</relatieveHoogteligging>
<inOnderzoek xmlns="http://www.geostandaarden.nl/imgeo/2.1">false</inOnderzoek>
<eindRegistratie xmlns="http://www.geostandaarden.nl/imgeo/2.1">2018-02-22T11:47:02.000</eindRegistratie>
<tijdstipRegistratie xmlns="http://www.geostandaarden.nl/imgeo/2.1">2017-05-01T15:18:43.000</tijdstipRegistratie>
<identificatie xmlns="http://www.geostandaarden.nl/imgeo/2.1">
<NEN3610ID>
<namespace>NL.IMGeo</namespace>
<lokaalID>L0001.11aa0fea1722452ca41119823df491db</lokaalID>
</NEN3610ID>
</identificatie>
<bronhouder xmlns="http://www.geostandaarden.nl/imgeo/2.1">L0001</bronhouder>
En de nieuwe versie van het object:
<PlantCover xmlns="http://www.opengis.net/citygml/vegetation/2.0" p1:id="bddd77b87-20eb-11e8-951f-610a7ca84980" xmlns:p1="http://www.opengis.net/gml">
<creationDate xmlns="http://www.opengis.net/citygml/2.0">2014-11-04</creationDate>
<LV-publicatiedatum xmlns="http://www.geostandaarden.nl/imgeo/2.1">2018-03-05T18:45:51.000</LV-publicatiedatum>
<relatieveHoogteligging xmlns="http://www.geostandaarden.nl/imgeo/2.1">0</relatieveHoogteligging>
<inOnderzoek xmlns="http://www.geostandaarden.nl/imgeo/2.1">false</inOnderzoek>
<tijdstipRegistratie xmlns="http://www.geostandaarden.nl/imgeo/2.1">2018-02-22T11:47:02.000</tijdstipRegistratie>
<identificatie xmlns="http://www.geostandaarden.nl/imgeo/2.1">
<NEN3610ID>
<namespace>NL.IMGeo</namespace>
<lokaalID>L0001.11aa0fea1722452ca41119823df491db</lokaalID>
</NEN3610ID>
</identificatie>
<bronhouder xmlns="http://www.geostandaarden.nl/imgeo/2.1">L0001</bronhouder>
<PlantCover xmlns="http://www.opengis.net/citygml/vegetation/2.0" p1:id="bd80d4a8c-53f6-11e8-a5a2-73a1868acdce" xmlns:p1="http://www.opengis.net/gml">
<creationDate xmlns="http://www.opengis.net/citygml/2.0">2014-11-04</creationDate>
<LV-publicatiedatum xmlns="http://www.geostandaarden.nl/imgeo/2.1">2018-03-05T18:45:51.000</LV-publicatiedatum>
<relatieveHoogteligging xmlns="http://www.geostandaarden.nl/imgeo/2.1">0</relatieveHoogteligging>
<inOnderzoek xmlns="http://www.geostandaarden.nl/imgeo/2.1">false</inOnderzoek>
<tijdstipRegistratie xmlns="http://www.geostandaarden.nl/imgeo/2.1">2018-02-22T11:47:02.000</tijdstipRegistratie>
<identificatie xmlns="http://www.geostandaarden.nl/imgeo/2.1">
<NEN3610ID>
<namespace>NL.IMGeo</namespace>
<lokaalID>L0001.11aa0fea1722452ca41119823df491db</lokaalID>
</NEN3610ID>
</identificatie>
<bronhouder xmlns="http://www.geostandaarden.nl/imgeo/2.1">L0001</bronhouder>Beste John,
Ik ben ook geneigd om te denken dat dit nog niet is opgelost. Als ik een testgebied bij mij in de omgeving bekijk dan zie ik historie die nog steeds geen eindDatum heeft…
In mijn voorbeeld is sprake van een kruising die is overgegaan in een rotonde, beide sets met wegdelen zijn nu actueel terwijl dit bijvoorbeeld in de BGT viewer niet zo is. Ook het herstelscript van @fsteggink levert wel een correcte situatie op.
Ik heb getest met een bestand wat ik gisteren, 14 mei 2018, gedownload heb.
https://downloads.pdok.nl/service/cache/bgt-citygml-nl-nopbp.zip
Groet,
Ronald
@Ronald_Mulder @JBak
Bij PDOK hebben we de inhoud van de data inderdaad niet getest. Afgelopen weekend hebben we een correctie-levering gekregen vanuit de landelijke voorziening. Deze correctielevering is verwerkt. Wij zijn er van uitgegaan dat deze correctie-levering alle objecten zonder einddatum registratie zou corrigeren gerelateerd aan dit issue. We gaan nu de genoemde foutsituaties uitzoeken.
Graag zouden wij (en onze klanten) een update willen ontvangen over de status van dit probleem.
@JBak je hebt helemaal gelijk, een eerdere tussentijdse update was op zijn plaats geweest. Excuses! Er zijn inmiddels iets meer dan een miljoen objecten hersteld maar we zijn ons ervan bewust dat dat er nog steeds veel objecten scheef zitten, deze zijn we samen met de landelijke voorziening BGT aan het opsporen en aan het herstellen! We communiceren op korte termijn over het vervolg (dan weten we iets meer).
1 like
Ik kan wel iets meer duidelijkheid geven, aangezien ik zowel vanuit PDOK als vanuit NLExtract hier naar gekeken heb. Over eventuele oplossingsrichtingen en -termijnen verwijs ik naar Jeroen, John en Robert.
De issues van Joris en Ronald zijn verschillend van aard. Het issue van Ronald heeft er mee te maken dat de eindregistratie nog niet is gefixed bij objecten die vervallen zijn. Ook hebben nog niet alle vervallen objecten een objecteindtijd. In totaal gaat het om bijna een half miljoen objecten van bijna alle featuretypen. Ik heb o.b.v. het extract van vandaag een CSV met de ID’s van de betreffende objecten aan PDOK gegeven.
Het issue van Joris heeft te maken met dubbele objecten. Dit kwam bij bak, begroeid terreindeel en pand voor. Bij de eerste twee is dit nu opgelost, bij de laatste nog niet. Het gaat om 2358 panden. Ook hiervan heb ik een lijst aan PDOK gegeven.
Voor zover ik heb gezien is de eindregistratie van objecten die nog niet vervallen zijn nu wel goed. Voor de zekerheid laat ik dit nog in het NLExtract script zitten.
Voor de gebruikers van de NLExtract Postgis dumps hoop ik vanavond of morgen een correcte dump te maken o.b.v. het extract van vandaag.
Ik bemerk o.a. in deze thread wel de nodige onvrede t.a.v. PDOK. Aangezien ik afnemer ben en ook ik dus behoorlijk last van dit issue heb (kostte me vandaag de hele dag), kan ik me dit wel voorstellen. Maar vanwege mijn inzet bij PDOK heb ik ook de andere kant van het verhaal gezien. Het meeste is terug te voeren op externe oorzaken en historie. Ik wil hier niet teveel over uitweiden, maar ik kan je wel verzekeren dat er met veel betrokkenheid keihard aan het in de lucht houden en het verbeteren van PDOK wordt gewerkt. Om een goed voorbeeld te noemen: ik denk dat de meeste gebruikers van PDOK wel gemerkt hebben dat PDOK nu een stuk stabieler is en minder verstoringen heeft dan pakweg een jaar geleden. Daar mag ook wel eens bij stil gestaan worden!
2 likes
Bedankt @fsteggink voor de heldere toelichting. We zijn nu eerst bezig met de herstel van de door jou genoemde issues, waarna we later de ontbrekende fouten m.b.t. eindtijd registratie gaan aanpakken.
@John_Schaap Is er inmiddels een planning of update beschikbaar in deze kwestie?
Mijn opdracht waar ik de BGT met kloppende historie voor nodig heb staat nu al heel lang on-hold.
Wachten an-sich is niet zo erg maar wachten zonder informatieverstrekking is niet fijn.
Dat werkt door naar mijn opdrachtgever, ik kan zo ook niets concreets melden.
Als we straks met zijn allen terugkijken op ruim langer dan een half jaar een foutieve BGT levering worden we toch allemaal niet blij, geen goede reclame voor de BGT en PDOK.
Dus wanneer is e.e.a. bij jullie gepland wat betreft een oplossing voor dit probleem?
Liefst SMART deze keer, dus met een datum…
Ik hoor graag van jou of collega, alvast dank.
(Sorry voor de kritische toon maar van steeds geen concreet nieuws wordt ik een beetje prikkelbaar.)
Hallo @Ronald_Mulder,
Ik begrijp dat je exact wilt horen wanneer het een en ander is opgelost. Helaas kan ik je die zekerheden niet geven. Momenteel zijn de ontwikkelaars bezig een analyse te maken van de de objecten die niet correct uit PDOK komen. Deze objecten zullen in een komend weekend aan PDOK geleverd gaan worden. Op het moment dat dit gaat gebeuren zal mogelijkerwijs de dagelijkse doorlevering vertraging oplopen en zullen we dit ook communiceren.
Hoi @Ronald_Mulder
Om toch iets meer te vertellen over de ‘status’, de situatie is nu als volgt.
Waar we op dit moment staan is dat:
• We al onze objecten gecontroleerd hebben op de: “ten onrechte niet ingevulde eindregistratie”
• Dat we nu een lijst hebben van foute objecten
• Deze lijst gaan we controleren op volledigheid vanuit ons (PDOK) perspectief en we vanuit het LV-BGT perspectief.
Wat de vervolg stappen zijn:
• De lijst van objecten wordt terug gegeven aan de LV-BGT
• De LV-BGT gaan deze objecten (inclusief historie) opnieuw aan ons aanbieden. (m.a.w. deze objecten gaan wij compleet opnieuw opbouwen)
• Wanneer dit is gedaan gaan we de nieuwe situatie controleren/test
M.b.t. tijd: deze week willen we de lijst van foute objecten dus controleren/bespreken. Op basis van mogelijk conclusies die hier uitkomen zal een moment gepland worden van de herstel actie.
Deze herstel actie zal zo ie zo in een weekend gaan plaats vinden.
@wouter.visscher Dank! 
Dit is wat mij betreft het type informatie wat best af en toe gedeeld mag worden in dit soort langlopende kwesties, dan blijft het draagvlak onder de betrokkenen toch net wat beter!
Ik ben / blijf uiteraard benieuwd naar welk weekend jullie gaan plannen voor de herstelactie.
Succes met het verdere onderzoek en de uitvoering!
@Ronald_Mulder Even een update. De eerste batch van objecten met “ten onrechte niet ingevulde eindregistratie” worden dit weekend vanuit de LV-BGT opnieuw aangeleverd.
Maandag gaan we controles uitvoeren. Aan de hand van het resultaat hiervan zullen we vervolg acties koppelen, mogelijkerwijs een volgende batch.
2 likes
@Ronald_Mulder Hier even een update, we zijn weer een stapje verder. De batch heeft van het weekend gedraaid. De eerste controle (tellingen) op totalen bevestigd dat dit goed verlopen is.
@John_Schaap dank voor deze updates, helemaal top!
Het maakt het wel spannend zo, binnenkort zou het zomaar opgelost kunnen zijn… 
1 like
Even een update. De huidige status is dat in de gehele dataset 2 waterdelen, 2 onbegroeide terreindelen en waarschijnlijk 60 panden fouten bevatten. Deze 64 objecten gaan we onderzoeken, en ik stel voor dit forum topic te gaan sluiten, omdat het een en ander op deze 64 objecten na (die we wel gaan onderzoeken) opgelost is. Mee eens?
Prettig weekend John
1 like
@John_Schaap hier ben ik al erg blij mee. De foutieve aantallen zijn wat mij betreft minder urgent.
Het zou wel handig zijn om in dit topic later nog even te melden wanneer deze laatste objecten zijn hersteld. Maar dat zou natuurlijk ook via een nieuw bericht of topic kunnen.
Ik ga z.s.m. even een test doen met het herstelde BGT extract! 