Trage download BGT zip-bestanden

@Anton we zitten nog in ontwikkel-en testfase en er lopen wat onderzoeken v.w.b. een aantal componenten dus vandaar. We willen de nieuwe straat volledig (door) testen, ook met gebruikers om hun ervaringen/feedback te horen dus we willen wel over naar actuele data.

Met actuele data en een reëel testtraject wil ik wel meewerken door de functionaliteit in te bouwen in onze software.

Nog meer vragen die opkomen:

  1. Kun je ook ergens uitlezen van wanneer de dataset is (zodat je kunt controleren of er wel geupdate is)
  2. Hoelang blijven de downloads staan of worden deze verwijderd na een geslaagde download?

@Anton,

  1. Ja, de API krijgt een endpoint “dataset” waarmee de actualiteit van een dataset is op te vragen. We zijn dit zelfde systeem nu eerst aan het ontwikkelen voor de DKK (testversie met testdata te zien op https://download.pdok.io/kadaster/dkk/viewer/).
    De API (https://download.pdok.io/kadaster/dkk/api/v1/dataset) geeft dan deze informatie.

  2. We gaan er nu vanuit dat een afnemer de download voor een eigen interessegebied nog dezelfde dag binnen haalt. De download blijft dus nog even staan na download. Voor de mutatie API zijn tot 31 dagen downloads met mutaties te maken en op te halen. (behalve in het uitzonderlijk geval na een calamiteit-levering van uit de landelijke voorziening).

De mutaties API werkt als volgt: De initiële download is alleen voor de actuele datum beschikbaar. Een afnemer kan dus op elke dag beginnen en een dataset bijwerken als hij niet verder dan 31 dagen achter loopt. Bij een calamiteit kan de landelijke voorziening opnieuw alle data leveren en verwijderen we de downloads met (mogelijk foutieve) mutaties.

Update: Bovenstaande DKK urls ziijn inmiddels veranderd naar PDOK download viewer voor de downloadviewer en PDOK API - Swagger UI voor informatie over de API.

Ik zie in de API geen voorbeelden waar de actualiteit op te vragen is, mis ik iets? In de viewer wordt wel keurig gemeld wat de datum is:

image

Verder nog een vraag over de API: is de DownloadRequestId hetzelfde als de DeltaId? En hoe wordt deze meegegeven aan de request? De API voorbeelden van Delta Custom zijn hetzelfde als Full Custom

Hallo @Anton. De dataset API geeft een json terug met deze info.
Zie PDOK API - Swagger UI

De DeltaId’s worden geleverd door de Delta api PDOK API - Swagger UI en zijn een indicatie voor de levering (sdatum). De DownloadRequestID’s zijn een uniek nummer voor de url behorende bij een specifiek request


Een specifieke delta wordt als volgt opgevraagd (in de post body)

 {
  "format": "gml",
  "geofilter": "POLYGON((81044.88 455429.52,81634.56000000001 455444.64,81735.36000000002 455199.36,81612.72 454955.76,81070.08 454952.4,80880.24 455192.64,81044.88 455429.52))",
  "deltaId": "d3879f7a-e79d-4ca0-be2b-259cfab33958",
  "featuretypes": [
    "perceel",
    "kadastralegrens"
  ]
}

en geeft dan een response met een DownloadRequestId:

{"_links":{"status":{"href":"/kadastralekaart/api/v4_0/delta/custom/20756195-0e94-4d8a-5c0f-86fb13d33d70/status"}},
"downloadRequestId":"20756195-0e94-4d8a-5c0f-86fb13d33d70"
}

Ah, de Dataset had ik over het hoofd gezien :slight_smile:

Delta’s zijn me nu ook duidelijk. Ik dacht dat elke download een eigen delta Id kreeg maar het blijkt een tijdframe te zijn als ik het goed heb. Maw, een Delta Id is een verwijzing naar een tijdsperiode van (in dit geval) 1 dag.

Er is een optie om alleen de Delta Id’s na een specifieke Id op te vragen maar er is geen optie om de Id op te vragen van een specifieke dag of de laatste Id? Dus de eerste keer zou een applicatie alle pagina’s moeten doorlopen tot er geen Next Page meer is?

Verder heb ik begrepen dat er 31 dagen aan mutaties zijn op te vragen. Moet na 31 dagen het oorspronkelijke gebied weer worden gedownload of is het doorlopend, als er maar telkens binnen 31 dagen opnieuw wordt bevraagd?

Als ik de API goed begrijp, zou een te ontwikkelen applicatie het volgende doen:

  1. Opvragen Delta Id’s en laatste Id intern onthouden voor de huidige download
  2. Gebied downloaden en geen Delta Id opgeven om alles te verkrijgen
  3. Als een gebruiker het gebied wil ‘verversen’, de Delta Id’s opvragen na de onthouden Delta Id en voor elk gevonden Id een nieuwe download van het gebied uitvoeren waarbij het Delta Id wordt meegegeven
  4. Na 31 dagen moet het oorspronkelijke gebied opnieuw worden opgevraagd of kan worden doorgegaan met punt 3 als er maar binnen 31 dagen een verversing is uitgevoerd?

Bij punt 3 zou het dus kunnen gebeuren dat een verversingsactie kan leiden tot max 31 downloads. Of kan worden volstaan met het opgeven van de oudste Delta Id na de oorspronkelijke aanvraag zodat alle mutaties vanaf die dag worden geleverd?

Hallo @Anton

De interface gaat uit dat een afnemer weet welke delta’s hij verwerkt heeft en dan dit delta nummer meegeeft aan de delta interface. Verder kan het aantal resultaten op een pagina ingesteld worden. (b.v. > 31).

Een afnemer kan hoeft na 31 dagen niet opnieuw te beginnen, maar kan blijven doormuteren.

Behalve in uitzonderlijke situaties kan de landelijke voorziening beslissen om opnieuw alle data te leveren. In deze situatie worden alle delta
mutaties verwijderd met mogelijk foutieve mutaties. In dit geval moeten alle afnemers ook opnieuw beginnen
met het opbouwen van een nieuwe actuele dataset. (Schema's van het Kadaster - Developer portaal “mutatieformaat Kadastrale Kaart v.1.0.pdf”)

Beantwoord dit je vraag? Groet John

Ja, ik denk het wel John, bedankt!

Het zal een kwestie zijn van testen en controleren of het gewenste resultaat is bereikt :slight_smile: Er is zeker geen testgebied beschikbaar waar door het systeem automatisch elke dag een paar lijntjes worden verwijderd en toegevoegd zodat softwarebouwers e.e.a. kunnen testen? Het is nu een blinde gok waar in NL de komende tijd wat mutaties gaan ontstaan.

Nee zo’n gebied is er niet, ik denk ook niet dat we zoiets kunnen toevoegen aan productie data (de rijdende rechter krijgt het dan druk in dat gebied :slight_smile:) . Het is wel een mooi idee om specifiek test-endpoint te maken met een klein gebied waar ad random grenzen elke dag veranderen. Met dit test-endpoint kunnen afnemers dan hun software testen.

Het valt me op dat de laatste tijd erg veel incomplete leveringen optreden. Voorbeelden:

Hier mist bebouwing en groenvlakken:

Hier mist bebouwing en verhardingsvlakken:

Dit is een voorbeeld van een volledige levering:

Hoewel ik van de laatste niet zeker ben of er toch geen objecten missen. Het is namelijk niet te zien aan een levering of deze incompleet is.

:thinking: