Wijziging achterliggende URL’s download wizard AHN3

De data van AHN3 wordt beschikbaar gesteld via de PDOK download wizard, te vinden op: https://downloads.pdok.nl/ahn3-downloadpage/. Gebruikers kunnen via deze wizard kaartbladen van de AHN3 downloaden. Door een kaartblad te selecteren en vervolgens in de wizard op downloaden te klikken, start een download in de browser.

Deze downloads hebben vervolgens achterliggende URL’s die niet officieel door PDOK gecommuniceerd worden. Voor de zekerheid willen wij eventuele gebruikers echter informeren dat deze URL’s zijn gewijzigd naar:

https://download.pdok.nl/rws/ahn3/v1_0/ en dan vervolgens het type download (zoals DSM of DTM). Een voorbeeld is: https://download.pdok.nl/rws/ahn3/v1_0/05m_dsm/R_45CZ1.ZIP

De oude URLs (die begonnen met https://geodata.nationaalgeoregister.nl) zijn nog beschikbaar tot woensdag 15 april 2020.

2 likes

Waarom zo korte periode? 2 weken maar. Ik gebruik de ‘oude’ url in onze software, het is niet te doen om in 2 weken alles aan te passen en alle gebruikers te laten updaten.

Andere ‘oude’ databronnen blijven normaal gesproken een half jaar lang nog beschikbaar, kan dat in dit geval ook niet?

Kan jullie software omgaan met een http redirect (301 of 302)?

Edit: sorry, verkeerd gelezen.

De software doet een http request en downloadt de aangeboden zip-file. Denk dat het geen probleem is als je die via een 301 doorgeeft.

@Anton de reden van de korte periode is dat we de achterliggende data gemigreerd hebben (nodig i.v.m. toename data) waarbij de URL’s wijzigen. Als we dit niet verplaatsen zullen de downloads op korte termijn niet meer werken dus helaas is dat geen oplossing in deze.

Andere databronnen/services blijven normaal inderdaad een half jaar beschikbaar maar de URL’s van de AHN3 zijn achterliggende URL’s van een downloadinterface en zijn niet ingericht en gecommuniceerd als officiële koppelvlakken/downloadservices (waar we dit bij de downloads van de BGT bijvoorbeeld wel doen en beschrijven in Open API). Wellicht wel iets voor de toekomst maar daar heb jij op korte termijn natuurlijk niks aan… Ik hoop dat er toch een mouw aan te passen is?!

De links naar de tiff-bestanden worden (werden) ook verstrekt in een atom feed, daarmee zijn ze toch gecommuniceerd als officiële downloadservice? En het wordt hier gemeld, dus is het bekend dat er gebruik van wordt gemaakt :slight_smile:

Het is jammer dat de periode maar 2 weken is, voor ons is het vervelend, maar als het niet anders kan dan moet het zo. Ik ga onze software erop aanpassen en proberen of alle gebruikers voor 15 april willen updaten.

In ieder geval bedankt dat het gemeld wordt!

De AHN1 en AHN2 hebben inderdaad wel Atomfeeds maar de AHN3 niet (is gekozen voor een interface oplossing). We hebben ze dus ook niet zo ingericht. Het bericht is omdat we wilden voorkomen dat eventueel ander gebruik dan gecommuniceerd (is wat lastig in te zien) in ieder geval niet helemaal acuut geen response meer zou krijgen :–)

Misschien handig als we contact houden over de voortgang bij jullie? Kan via dit topic maar kan ook via een direct bericht via het forum.

Het lijkt er op dat de bestanden ook een nieuwe Last-Modified header hebben gekregen. Zijn er ook veranderingen geweest in de puntenwolk, of is de mtime verloren gegaan tijdens het overzetten? Een mini-testje op C_01DZ1.LAZ gaf origineel 15 januari 2020 en nu 13 maart 2020 maar dezelfde sha1sum.

Het voelt een beetje zonde om de hele 2,4 TB nog een keer over de lijn te trekken om er zeker van te zijn dat mijn kopie nog up-to-date is… (Ik zou nog kunnen checken op Content-Length, theoretisch.)

De content-length heb ik tijdens het kopieren gecontroleerd. Er zijn geen veranderingen in de puntenwolk. De last-modified is inderdaad veranderd tijdens het overzetten.

We hebben recentelijk MD5 checksums gepubliceerd voor alle AHN3 downloads, zie dit antwoord op het forum. Huidige oplossing is een tijdelijke, uiteindelijk gaan we de checksums in de dowload service ontsluiten.

2 likes