We hebben ook de mutatieleveringen bekeken, hierbij onze feedback. Samenvattend heeft het voor ons de hoogste prioriteit dat het ‘eindRegistratie’ issue (https://forum.pdok.nl/t/bgt-issue-doorlevering-veld-eindregistratie/1091) wordt aangepakt. Als dit in de bestaande downloadvoorziening is aangepakt zijn wij al in staat om zelf mutaties te detecteren en hoeven wij niet te wachten op het voltooien van de API voor BGT mutaties.
XML Schema
Voor XML Schema’s wordt verwezen naar GitHub - PDOK/schemas-mutatielevering: XML-schema's van de generieke mutatielevering . Daar staat een bestand mutatielevering-bgt-1.0.xsd maar dat heeft targetNamespace http://www.kadaster.nl/schemas/mutatielevering-bgt/1.0 , terwijl de bestanden http://www.kadaster.nl/schemas/mutatielevering-bgtv3/1.0 hebben. In die bestanden staat een schemaLocation die aangeeft dat het bestand mutatielevering-bgtv3-1.0.xsd zou moeten heten.
In de geleverde bestanden voldoet de inhoud van diverse elementen met uit de namespace http://www.kadaster.nl/schemas/mutatielevering-generiek/1.0 niet aan de definitie in het XML Schema.
Er lijkt een schema wijziging geweest te zijn die niet compatible is met de gepubliceerde versie, maar waarbij de XML namespace niet is gewijzigd.
O.a. inhoud element en mutatieGroep die soms leeg is, zoals in delta bestand 873346d3-b002-4253-95ca-2cd81af99f57.
Inhoud bestanden
Het download-full bestand (zonder filtering) bevat ruim 25 miljoen mutatieGroep elementen, dat lijkt onlogisch voor een stand. Een delta bestand bevat 1 mutatiegroep.
Het id in download-full (27d90524-2a24-46dd-8e94-cf4957a0041d) is niet het laatste deltaId dat wordt teruggegeven door /api/v2/deltas.
Delta bestanden bevatten verwijderingen, toevoegingen en wijzigingen van historische records. Dit is inefficient, en hierdoor is het praktisch onmogelijk om alleen de wijzigingen te verwerken die relevant zijn voor de actuele objecten.
Praktisch
Uit de delta bestanden zelf is niet af te leiden wat de volgorde is waarin de bestanden verwerkt moeten worden. Wenselijk is dat het id van de levering waar het bestand op aansluit in het inhoud element wordt opgenomen.
Aan de id’s van de leveringen is de volgorde niet af te leiden. Het zou handig zijn als de bestanden ook een bestandsnaam krijgen waaruit het soort levering en de verwerkingsvolgorde af te leiden is. Dit maakt het ook makkelijk om dezelfde bestanden meerdere keren te verwerken zonder ze opnieuw te hoeven downloaden (wat na een bepaalde tijd niet meer mogelijk is).
@JBak bedankt voor de goede feedback! Net al even kort intern doorgenomen en hier kunnen we zeker wat mee! We willen het de komende periode even verder analyseren en waar mogelijk concretiseren. Ik kom er daarna op terug. Hartelijk dank 
PS: voor wat betreft het eerste punt/issue. De Landelijke voorziening BGT heeft een oplossing aangedragen en is hier met ons over in gesprek. Terugkoppeling zal via dat topic verlopen. @RobertvH voorzie jij zodra je iets kunt melden in een reactie op het forum (in het topic)? Bedankt!
Extra toevoeging: decoderen van downloadlink kan bijv. hier.
Deze site maakt bijv. van het geografische filterdeel in de gekopieerde link achter 'tiles = : ‘%7B%22layers%22%3A%5B%7B%22aggregateLevel%22%3A3%2C%22codes%22%3A%5B806%5D%7D%5D%7D’ een meer leesbare vorm: {“layers”:[{“aggregateLevel”:3,“codes”:[806]}]}
Ik ben begonnen met het verkennen van de API. Mijn eerste feedback:
Ik heb met de volgende URL een delta opgehaald:
- Het resultaat is een bestand ‘delta.zip’. Het zou mooi zijn als dit bestand de naam krijgt van de gevraagde deltaID, dus: delta_332fc87d-613d-4859-bf7c-a13346a8cc31.zip
Het downloaden en verwerken van de delta’s zal bij veel bedrijven waarschijnlijk een automatisch proces worden. En mogelijk twee processen. Een proces A voor het downloaden en een proces B voor het verwerken. Beide processen kijken mogelijk dan naar dezelfde map. A plaatst de deltabestanden in deze map en proces B leest de deltabestanden uit deze map. proces A en B moeten in principe asynchroon kunnen werken. Proces A haalt bijv. dagelijks een delta op en proces B verwerkt wekelijks alle delta’s van de afgelopen week. Hierbij mag proces A de delta.zip van maandag niet overschrijven met de delta.zip van dinsdag. Graag dus unieke naamgeving.
-
Verder zoals ook door JBak genoemd. Graag bij unieke naamgeving ook een volgordelijkheid hanteren. Zijn de deltaID’s bijv. nu alfabetisch of hexadecimaal geordend en oplopend in de tijd?
Ik zie nu in de inhoud van delta.zip een bestand bgtv3_all.xml. Hier geldt hetzelfde. Of de zip-bestanden graag uniek nummeren met het deltaID of het xml-bestand uniek nummeren met het deltaID of beide. Dit voorkomt per ongeluk overschrijven bij het verwerken. -
In bgtv3_all.xml zie ik o.a. als metadata staan:
<ml:gebied>51584,51585,51586,51587,51588,51589,51590,51591,51592,51593,51594,51595,51596,51597,51598,51599,51600,51601,51602,51603,51604,51605,51606,51607,51608,51609,51610,51611,51612,51613,51614,51615,51616,51617,51618,51619,51620,51621,51622,51623,51624,51625,51626,51627,51628,51629,51630,51631,51632,51633,51634,51635,51636,51637,51638,51639,51640,51641,51642,51643,51644,51645,51646,51647</ml:gebied>
<ml:aanleveringId>332fc87d-613d-4859-bf7c-a13346a8cc31</ml:aanleveringId>
Ik zou voor de herkenbaarheid liever <ml:gebied>806<ml:gebied> zien (en niet de onderliggende kaartgebieden), want dat gebied heb ik opgevraagd.
- Met
<ml:aanleveringID>wordt deltaID bedoeld. Dan graag dit ook<ml:deltaID>noemen.
@Spingerfitz Bedankt voor je bericht en het testen van de test api 
- We zullen dit punt meenemen en verwerken in de applicatie is inderdaad een goed idee. De zip zullen de volgende naamgeving krijgen, gezien dit snel kan worden meegenomen:
- Voor een full levering krijg je “full_{datumvandownload}.zip” (voorbeeld:full_2018-03-02_10-31.zip.zip)
- Voor een delta levering krijg je delta_{deltaId}.zip (voorbeeld: delta_84e8e844-29eb-4b9d-b83b-1b5b55ccf90e.zip)
-
Op dit moment is het delta_id een uuid die uniek is over alle delta’s gemaakt is. Ik kan me voorstellen dat je dit ook aan de hand van de filenaam wil baseren. We gaan even kijken hoeveel werk dit voor ons is om toe te voegen. zouden eventueel net zoals de full een datum nog aan kunnen toevoegen maar moeten oppassen dat de filenaam niet te lang wordt.
-
Bij de nieuwe feedback zal de metadata in een losse file bij de zip worden geleverd. Dit zoals Jeroen al heeft aangekondigd in de post van 9 feb 2018 16:39:
- Metadata
a) Bij iedere aanroep een leveringsdocument
b) De opgegeven parameters van de API meegeven in het leveringsdocument
c) De opgegeven datum/tijdstip van de aanroep meegeven in het leveringsdocument
d) Het aantal mutaties van de aanroep meegeven in het leveringsdocument
Hierbij was het idee om zowel de request als response informatie terug te geven wat de vraag is. Hierdoor zul je in je leveringsdocument het daadwerkelijk van de gevraagde filter zie terugkomen als metadata. Hierbij zie je dus exact wat je gevraagd hebt aan de server.
- Dit zullen we meenemen en zal ook in het leveringsbestand komen te staan.
Binnenkort zullen we een nieuwe versie beschikbaar stellen, waar dit is meegenomen
Hallo PDOK,
De service is niet beschikbaar (503) in ieder geval vanaf gisteren.
Is dit een tijdelijke storing of onderhoud of is de test periode afgelopen?
Groeten,
Harm Olthof
Hoi Harm,
Inderdaad de service gaf vanwege verplaatsing naar een nieuwe machine een 503.
De service staat nu op een nieuwe machine en zal weer benaderbaar moeten zijn.
Met vriendelijke groet,
Hans Lemkes
Hallo Hans,
Het werkt inderdaad weer.
Dank voor de snelle actie.
Groeten,
Harm
Wat is de status en planning voor deze API?
Hallo @rboeters,
Het beschikbaar maken van deze API (BGTKET-201 Mutatieleveringen als A-dienst bieden) staat op de backlog van de BGT keten en zal dus dit jaar nog niet beschikbaar komen.
Er wordt eerst gewerkt aan de verbetering van de “gewone” downloads. (i.v.m. Issue m.b.t. downloads BGT en DKK - PDOK)
De huidige verwerking is niet toekomst vast en niet voldoende schaalbaar.
We gaan daarom de huidige BGT downloads verbeteren om sneller bestanden te kunnen uitserveren en verwerken. Deze verbetering is een eerste stap, die noodzakelijk is om de mutatieleveringen als A-dienst later (volgend jaar) aan te kunnen aanbieden.