Duplicaten BGT dump heel Nederland

Datasets BGT
#1

De historische data in de BGT dump bevat meerdere objecten met een gelijke imgeo:lokaalID, tijdstipRegistratie en eindRegistratie. Volgens ons systeem zijn dit duplicate BGT objecten, immers is het beleid momenteel dat een BGT object een eindregistratie krijgt aan het “eind van de periode waarop deze instantie van het object geldig is bij de bronhouder”.

Zo zijn de eerste twee BGT bakken van de dump exact dezelfde objecten, waarbij alleen de LV-publicatiedatum anders is:

	<cityObjectMember>
	<imgeo:Bak gml:id="b58ca206b-d735-11e8-80e2-b7dac308c237">
		<creationDate xmlns="http://www.opengis.net/citygml/2.0">2016-12-12</creationDate>
		<terminationDate xmlns="http://www.opengis.net/citygml/2.0">2018-10-19</terminationDate>
		**<imgeo:LV-publicatiedatum>2016-12-13T10:06:29.000</imgeo:LV-publicatiedatum>**
		<imgeo:relatieveHoogteligging>0</imgeo:relatieveHoogteligging>
		<imgeo:inOnderzoek>false</imgeo:inOnderzoek>
		<imgeo:eindRegistratie>2018-10-19T11:48:11.000</imgeo:eindRegistratie>
		<imgeo:tijdstipRegistratie>2016-12-12T13:02:24.000</imgeo:tijdstipRegistratie>
		<imgeo:identificatie>
			<imgeo:NEN3610ID>
				<imgeo:namespace>NL.IMGeo</imgeo:namespace>
				<imgeo:lokaalID>G0402.c8d17fb00a2f46a6aa30125fffb2508e</imgeo:lokaalID>
			</imgeo:NEN3610ID>
		</imgeo:identificatie>
		<imgeo:bronhouder>G0402</imgeo:bronhouder>
		<imgeo:bgt-status codeSpace="http://www.geostandaarden.nl/imgeo/def/2.1#Status">bestaand</imgeo:bgt-status>
		<imgeo:plus-status codeSpace="http://www.geostandaarden.nl/imgeo/def/2.1#VoidReasonValue">geenWaarde</imgeo:plus-status>
		<function xmlns="http://www.opengis.net/citygml/cityfurniture/2.0" codeSpace="http://www.geostandaarden.nl/imgeo/def/2.1#TypeBak">niet-bgt</function>
		<imgeo:plus-type codeSpace="http://www.geostandaarden.nl/imgeo/def/2.1#TypeBakPlus">afvalbak</imgeo:plus-type>
		<imgeo:geometrie2dBak>
			<gml:Point xmlns:gml="http://www.opengis.net/gml" srsName="urn:ogc:def:crs:EPSG::28992">
				<gml:pos srsDimension="2">139260.630 471256.365</gml:pos>
			</gml:Point>
		</imgeo:geometrie2dBak>
	</imgeo:Bak>
</cityObjectMember>
<cityObjectMember>
	<imgeo:Bak gml:id="b58ca477d-d735-11e8-80e2-b7dac308c237">
		<creationDate xmlns="http://www.opengis.net/citygml/2.0">2016-12-12</creationDate>
		<terminationDate xmlns="http://www.opengis.net/citygml/2.0">2018-10-19</terminationDate>
		**<imgeo:LV-publicatiedatum>2018-10-23T21:08:42.000</imgeo:LV-publicatiedatum>**
		<imgeo:relatieveHoogteligging>0</imgeo:relatieveHoogteligging>
		<imgeo:inOnderzoek>false</imgeo:inOnderzoek>
		<imgeo:eindRegistratie>2018-10-19T11:48:11.000</imgeo:eindRegistratie>
		<imgeo:tijdstipRegistratie>2016-12-12T13:02:24.000</imgeo:tijdstipRegistratie>
		<imgeo:identificatie>
			<imgeo:NEN3610ID>
				<imgeo:namespace>NL.IMGeo</imgeo:namespace>
				<imgeo:lokaalID>G0402.c8d17fb00a2f46a6aa30125fffb2508e</imgeo:lokaalID>
			</imgeo:NEN3610ID>
		</imgeo:identificatie>
		<imgeo:bronhouder>G0402</imgeo:bronhouder>
		<imgeo:bgt-status codeSpace="http://www.geostandaarden.nl/imgeo/def/2.1#Status">bestaand</imgeo:bgt-status>
		<imgeo:plus-status codeSpace="http://www.geostandaarden.nl/imgeo/def/2.1#VoidReasonValue">geenWaarde</imgeo:plus-status>
		<function xmlns="http://www.opengis.net/citygml/cityfurniture/2.0" codeSpace="http://www.geostandaarden.nl/imgeo/def/2.1#TypeBak">niet-bgt</function>
		<imgeo:plus-type codeSpace="http://www.geostandaarden.nl/imgeo/def/2.1#TypeBakPlus">afvalbak</imgeo:plus-type>
		<imgeo:geometrie2dBak>
			<gml:Point xmlns:gml="http://www.opengis.net/gml" srsName="urn:ogc:def:crs:EPSG::28992">
				<gml:pos srsDimension="2">139260.630 471256.365</gml:pos>
			</gml:Point>
		</imgeo:geometrie2dBak>
	</imgeo:Bak>
</cityObjectMember>

Dit is één voorbeeld, maar wordt bij veel meer BGT objecten geconstateerd.
In een eerdere post werd verbeterde downloadfunctionaliteit beloofd. Hebben jullie die inmiddels kunnen realiseren en is dit dus te verklaren gedrag of zitten er nog inconsistenties in deze historische data?

#2

Beste Jan,

Het specifieke scenario welke hier wordt genoemd is in de nieuwe PDOK API ook aanwezig. Dat komt omdat dit in de data zit en niet in de verwerking van data aan de kant van PDOK. We hebben dit aan de LV doorgegeven.

Groeten Gerwin

#3

Hallo @hulstg,

Goed om te weten dat dit bekend is en dat hier actie op wordt ondernomen door dit te communiceren naar LV-zijde. Is er een planning bekend wanneer LV deze bug gaat verwerken en opnieuw aan gaat bieden of is de oplossingsrichting bekend?

Groet, Jan

#4

Beste Jan,

Het probleem dat je schetst m.b.t. de LV-publicatiedatum is geen bug, dit is de wijze waarop wij de historie leveren vanuit de LV-BGT.
In het geschetste voorbeeld van de bak, geven we deze data mee omdat je anders de voorgaande publicatiedatum verliest. Op deze wijze is deze wel zichtbaar, dit resulteert wel in 2 identieke voorkomens.

LV-BGT

#5

Beste @Eric ,

Dank voor de reactie. Ik heb de categorie bug verwijderd van dit topic. Hebben jullie een link naar documentatie over hoe de historie van BGT-objecten momenteel is vastgelegd via de BGT dump? Is het bijvoorbeeld voor ieder BGT-object zo dat de dump gesorteerd is op imgeo:LV-publicatiedatum?

Het is prettig voor gebruikers te weten of de huidige methodiek consistent blijft de komende jaren vanuit de LV-BGT wat betreft de dump. Kunnen jullie aangeven of dat het geval gaat zijn?

En meer uit interesse: Waarom is er niet voor gekozen om de bgt-status (e.g. niet-bestaand) te gebruiken in combinatie met een ontbrekende eindregistratie (zoals ook bij de BAG) om te benadrukken dat het object geen geldige status meer heeft?

#6

Hallo Jan,

Voor wat betreft de documentatie van de dump, ik begreep van PDOK dat deze niet beschikbaar is. De afnemer is zelf verantwoordelijk voor de verwerking van de goede volgorde als dit niet door een XML-schema word afgedwongen. Wellicht kan PDOK je deze vraag zelf beter beantwoorden.

Voor wat betreft de methodiek van uitleveren, dit zal vermoedelijk niet op korte (en lange) termijn niet gaan veranderen. Een verandering in de extracten is niet alleen een verandering in het model, maar ook in de keten.

Er is bij het ontstaan van de BGT gekozen om het object aan te leveren aan de LV met de status bestaand, wij mogen deze waarden niet veranderen. Dit is dus een gevolg van het BGT model. Ook hier zal een modelwijziging nodig voor zijn.

Met vr. groet,

LV-BGT

#7

Hallo @GeoJanMov

Ik weet niet of je dit gaat helpen maar de BGT (dump) XML structuur staat beschreven op Voorlaatste versie - Gegevenscatalogus IMGeo versie 2.1.1 | Geonovum

Groet
John

#8

Dank @John_Schaap voor de link naar het schema. Daarin staat beschreven wanneer een object geldig is of niet. Dat de publicatiedatum wordt meegegeven om de historie van een object te leveren en de status bestaand wordt meegegeven zou aan de Gegevenscatalogus kunnen worden toegevoegd voor de duidelijkheid.

Fijn om te horen van @Eric dat de methodiek van uitleveren op korte termijn vermoedelijk niet verandert. Dat betekent dat we op basis van deze informatie ons systeem hierop kunnen aansluiten.