Ik maak een BGT-extract aan zoals beschreven in Waterdelen opvragen via BGT API.
Als formaat kies ik stufgeo en ik vraag alle IMGeo klassen op behalve plaatsbepalingspunten. Ik hou verder hetzelfde gebied aan als in het beschreven voorbeeld.
Het extract dat ik download bevat duplicaten (ordegrootte: enkele procenten).
En Tijdstipregistratie heeft vaak de waarde van de aanmaaktijd van het bestand (ordegrootte: enkele tientallen procenten).
Tot slot zie ik ook enkele dekkingsfouten: bij enkele panden met relatievehoogteligging=0, ligt op dezelfde plek een erf relatievehoogteligging=0. Bij 1 van die panden (1663100000008089) zag ik dat hij niet meer voorkomt in de PDOK viewer (en ook niet in de BAG viewer, het is in 2018 gesloopt).
Een ander pand met dekkingsfout heeft LokaalID=L0003.3a6c098efe4c47cf9bc5cdd6ba5c7f4a.
Deze dekkingsfouten kunnen niet in de LV-BGT voorkomen.
De eerstgenoemde 2 problemen zie ik ook in een heel ander gebied.
We zijn dit probleem aan het onderzoeken, we komen hier zo spoedig mogelijk op terug.
Dat is snel, ik kwam er achter dat ik geen rekening met een ingevulde Eindtijd hield. Dat lijkt de duplicaten op te lossen en waar Eindtijd is ingevuld, lijkt Tijdstipregistratie gelijk te zijn aan het tijdstip van het extract (ligt misschien aan de manier waarop ik het inlees, ik vermoed dat Tijdstipregistratie leeg is bij een ingevulde Eindtijd).
Het overlap-probleem van het pand 1663100000008089 met het erf blijft staan, het overlap-probleem met het andere pand is opgelost.
Hoofdoorzaak van het probleem is lege Tijdstipregistratie bij ruim 30% van de objectversies (3499 van de 11216).
Probleem is al in oktober 2019 gemeld (BGT downloadviewer PDOK (https://download.pdok.io/lv/bgt/viewer/)). Hopelijk kan hier prioriteit aan gegeven worden, want zolang dit niet is opgelost, is de data onbruikbaar.
Hallo @BSpiering,
We beseffen het belang van dit probleem. Zoals gemeld in (BGT downloadviewer PDOK (https://download.pdok.io/lv/bgt/viewer/) - #5 door copierrj - BGT - Geoforum) moet alle data opnieuw verwerkt worden voordat de oplossing zichtbaar is in de data. De verwachting is nu dat we rond het einde van volgende maand een nieuwe omgeving krijgen waarin dit issue in de data opgelost is.
Bedoel je de definitieve omgeving of nog steeds de beta-omgeving?
Heeft iemand een idee hoe het met dit traject staat? Ik bedoel dan het opnieuw verwerken van de data in de Beta omgeving en dat de Beta omgeving productie omgeving kan worden?
Het een en ander gaat helaas minder vlot dan we gehoopt hadden. Wij zijn momenteel een nieuwe productie-omgeving aan het inrichten en daarin de data vanuit de landelijk voorziening aan het inladen. (herdraaien) Op het moment dat we dat klaar hebben gaan we testen. De verwachting is nu dat we deze productie Url in Mei vrij kunnen geven.
Bedankt voor het melden! Het is erg prettig als we iets weten, we horen liever dat het is uitgesteld tot mei dan dat we vanaf januari elke dag F5-en om te zien of het al omgezet is terwijl er niets lijkt te gebeuren 
Een ander probleem die ik heb zijn onjuiste datums.
ik constateer DateTime velden ‘LV-publicatiedatum’, ‘eindRegistratie’, ‘tijdstipRegistratie’ waarbij de tijd alleen uren:minuten geen seconde
goed: 2016-10-19T11:17:43
fout: 2016-09-02T00:00
Vandaag getest op de nieuwe url https://api.pdok.nl/lv/bgt/download/v1_0. Het eerder genoemde probleem over ontbrekende tijdstipRegistratie / eindRegistratie is in mijn proefgebied opgelost. Bovengenoemde probleem van Thijs Roggekamp (onvolledige Data Time velden) heb ik niet geconstateerd in mijn proefgebied.