Nieuwe URL’s voor de PDOK luchtfoto

Datasets Luchtfoto's
#1

Per 1 december 2020 heeft PDOK haar service met achtergrondluchtfoto’s voorzien van nieuwe URL’s. PDOK heeft recent haar aanpak voor service-URL’s herzien. Want datamodellen en webservices veranderen en dat leidt in veel gevallen tot nieuwe URL’s. Bovendien is er nu de mogelijkheid om uniforme en eenvoudiger URL’s te maken.

Deze veel geraadpleegde 25 cm PDOK-luchtfoto wordt vanaf heden geserveerd onder de volgende URL's:

25cm RGB luchtfoto’s

WMS:
https://service.pdok.nl/hwh/luchtfotorgb/wms/v1_0?&request=GetCapabilities&service=wms
WMTS:
https://service.pdok.nl/hwh/luchtfotorgb/wmts/v1_0?&request=GetCapabilities&service=wmts

25cm Infrarood luchtfoto’s

WMS:
https://service.pdok.nl/hwh/luchtfotocir/wms/v1_0?&request=GetCapabilities&service=wms
WMTS:
https://service.pdok.nl/hwh/luchtfotocir/wmts/v1_0?&request=GetCapabilities&service=wmts

TMS

De TMS-service wordt PDOK-breed per 1 maart 2021 uitgefaseerd. Bestaande URL’s werken dus nog tot deze datum. PDOK adviseert u daarom met klem om over te stappen op de WMTS services!

De huidige URL’s van de PDOK-luchtfoto blijven gedurende een overgangsperiode van zes maanden beschikbaar tot 1 juni 2021. Daarna neemt PDOK de URL’s definitief uit productie. Gebruikers van de oude URL’s wordt dringend verzocht om zo spoedig mogelijk over te stappen op deze nieuwe service-URL’s.

2 likes
#2

Hoi, ik vind het jammer, dat url’s van services steeds veranderen, buiten dat:
https://geodata.nationaalgeoregister.nl/luchtfoto/rgb/wmts
een prachtige url is, beschrijvend wat het is etc, is het natuurlijk ook vanuit de netiquette wel netjes als url’s niet te dynamisch worden.

Wat betekend hwh trouwens? en waarom heten de foto’s die eerst ‘infrarood’ heten nu ‘luchtfotocir’ (cir?).

Url’s zijn belangrijk, geen tijdelijk identifiers die steeds kunnen worden veranderd.

Er zullen vast gegronde (technische?) redenen voor zijn, maar… toch jammer.

#3

Heel erg eens met Richard.dat de huidige URL een prachtig voorbeeld is van een vlag die de lading dekt:
thema (luchtfoto) / variant (rgb) / servicetype (wmts)

Dat hwh (Het WaterschapsHuis?) er tussen is juist weer een stap weg van die URL-schoonheid.
Ik was juist zo blij dat allerlei verwijzingen naar specifieke software (gwc, mapproxy) uit de URL’s zijn verbannen

Ben daarom wel benieuwd naar de PDOK aanpak van service-URL’s.
Als die nóg mooier is laat ik me uiteraard overtuigen en daarmee inspireren voor URL’s van de VRAA (Veilgheidsregio Amsterdam-Amstelland)

#4

Wordt het hele URL regime omgegooid?

Ik loop wat url’s na in de PDOKservices plugin, en zie bv dat

RCE gerelateerd:
https://geodata.nationaalgeoregister.nl/inspire/ps-ch/wms?request=GetCapabilities
word
https://service.pdok.nl/kadaster/cp/wms/v1_0?request=GetCapabilities&service=WMS

En in de mailing over de Vervoersnetwerken wordt gesproken over:
https://geodata.nationaalgeoregister.nl/nl/rws/tn-cte/wfs?&request=GetCapabilities&service=wfs
en
https://geodata.nationaalgeoregister.nl/inspire/tn/wms?request=GetCapabilities

(let op: bij wfs blijkbaar databronhouder in de url, bij de wms niet?

Dit wordt een klus…
Het zou mij evt ook helpen als jullie in mailings en communicatie zowel de oude als de nieuwe url tonen, dan weet ik ook wat ik uit de lijst moet gooien.

#5

Dat is geen URL-regime, maar een API-strategie! :wink:

#7

Kijk anders ook even hier, PDOK communiceerde hierover in maart van dit jaar https://www.pdok.nl/-/nieuwe-url-strategie-bij-pdok

#8

Ik kan me best vinden in de nieuwe url aanpak, maar data-eigenaar hoeft daar echt niet bij:
• de naam van de eigenaar van de dataset is ook onderdeel van het pad (m.u.v. de basisregistratie);

Dat lijkt mij typisch iets om in de metadata te plaatsen. Data-eigenaarschap zegt namelijk niets over de inhoud van de service. En mocht het data-eigenaarschap veranderen, dan moet de url worden aangepast. Lijkt mij niet passen bij het idee ‘open data’.

Bij deze dus een pleidooi om ‘eigenaar dataset’ uit de url te verwijderen en alleen in de metadata op te nemen.

#9

PDOK kent zowel een URI- als een API-strategie, in de volksmond beter bekend als de PDOK URL-strategie. Deze strategie is door PDOK vorig jaar in samenspraak met onze klanten en gebruikers opgesteld. Natuurlijk staat PDOK open voor feedback op het huidige beleid. De in dit topic vermelde feedback nemen we dan ook graag mee in de overwegingen voor een eventuele volgende versie van de strategie.

#10

Dan heb ik ook nog feedback :slight_smile:

Een deel van de gebruikers van onze software heeft “last” van een hardnekkige ICT afdeling die op voorhand alles dichttimmert en mondjesmaat url’s vrijgeeft. Ik heb het idee dat dit niet altijd op domeinniveau gebeurt, bijvoorbeeld *.pdok.nl.

Omdat er nu al drie sub-domeinen worden gebruikt (api.pdok.nl, download.pdok.nl, service.pdok.nl) kan het zijn dat gebruikers de ene bron wel kunnen aanspreken en de andere niet. En dan voor elke nieuwe sub-domein weer in gevecht moet met de ICT.

Ik heb geen verbetervoorstel hiervoor maar ik meld het toch maar even :slight_smile:

#11

Helaas heeft dit ons overvallen op een heel ongelukkig moment. Afgelopen zaterdag 28 november zijn wij voor een klant in productie gegaan met een applicatie die gebruik maakt van de luchtfoto’s en op dat moment bleken de luchtfoto’s het niet te doen in de applicatie. Ik wist wel dat er onderhoud aan de luchtfoto’s was geweest op maandag 23 november, maar deze wijziging was ons onbekend.
De reden dat de luchtfoto’s het niet deden in de applicatie lag in de CSP-instellingen van onze applicatie. geodata.nationaalgeoregister.nl was daarin wel opgenomen als toegestaan domein, maar service.pdok.nl niet. Gelukkig is het geen showstopper geweest en hebben we vrij snel een nieuwe uitrol met aangepaste CSP-instellingen kunnen doen, maar de timing kwam voor ons heel ongelukkig uit.

Pas via de e-mail ‘Geoforum samenvatting’ van afgelopen zaterdag 5 december ben ik bij bovenstaand bericht van 1 december terecht gekomen. Voor ons was het beter geweest als we ons hier eerder bewust van waren. Inmiddels heb ik me geabonneerd op de attenderingsservice, hopelijk helpt dat voor toekomstige wijzigingen.

Overigens vind ik het wel bijzonder dat in de pdok viewer de luchtfoto-kaartlaag nog wel via geodata.nationaalgeoregister.nl opgevraagd wordt, althans. Zou deze niet ook via service.pdok.nl moeten lopen dan?

#12

@jpvermaas_enigmatry dit hadden we beter moeten aanpakken v.w.b. communicatie, waarvoor excuses! Fijn dat jullie zo snel konden schakelen. In de Viewer moeten we inderdaad nog over op service.pdok.nl, dat gaan we nog aanpassen.

#13

@Jeroen_D, bedankt voor de terugkoppeling!

#14

Ik ben nu bezig onze software aan te passen aan de nieuwe url’s. Even voor de duidelijkheid:

Ik neem aan dat de url die nog op Nationaal Georegister staat komt te vervallen? Deze dus:
https://geodata.nationaalgeoregister.nl/luchtfoto/rgb/wmts?request=GetCapabilities

Wordt de NGR pagina nog aangepast? Of is de nieuwe url niet de vervanging van de NGR link?

Daarnaast gebruik ik de luchtfoto in een eigen viewer en roep de tegeltjes op met deze url:
https://geodata.nationaalgeoregister.nl/luchtfoto/rgb/wmts/2019_ortho25/EPSG:3857/{0}/{1}/{2}.jpeg

Verandert die ook naar zoiets als service.pdok.nl/hwh/luchtfotorgb/wmts/2019_ortho25/EPSG:3857/{0}/{1}/{2}.jpeg ?

#15

Beste @Anton ,

Ja, de url https://geodata.nationaalgeoregister.nl/luchtfoto/rgb/wmts?request=GetCapabilities op Nationaal Georegister komt per 1 juni 2021 te vervallen.
We zullen de url’s op de Metadata Data NGR pagina z.s.m. wijzigen. Die op de Metadata Service NGR pagina zijn reeds gewijzigd.

Het klopt dat u de url in uw viewer kan veranderen. Ik merk dat u de parameter v1_0 bent vergeten.
Hieronder een juiste url wijziging als voorbeeld:
https://geodata.nationaalgeoregister.nl/luchtfoto/rgb/wmts/2019_ortho25/EPSG:3857/0/0/0.jpeg —> https://service.pdok.nl/hwh/luchtfotorgb/wmts/v1_0/2019_ortho25/EPSG:3857/0/0/0.jpeg

groetjes Rinaldo

1 like
#16

Helemaal top! Ga ik toepassen.

#17

Ik mis nog uitleg over hoe de nieuwe requests moeten worden opgebouwd. De url is duidelijk, wat ik zelf kon vinden in de GetCapabilities: geen png meer maar jpeg, dat er een nieuwe parameter ‘wmtver’ is bleek uit de Exception die ik terugkreeg en ‘1.0.0’ als waarde daarvoor was een gok. Nu mis ik volgens de Exception nog een parameter ‘styles’, maar daarover staat niks in GetCapabilities. Waar is dat allemaal terug te vinden?

EDIT: never mind, ik zat nogmaals hier te kijken:
WMS reference — GeoServer 2.24.x User Manual en nu als styles waarde eens een lege string geprobeerd. Dat blijkt te werken.

Tot dusver:
https://service.pdok.nl/hwh/luchtfotorgb/wms/v1_0?&request=GetMap&wmtver=1.0.0&layers=Actueel_ortho25&styles=&bbox=92072,437094,92372,437394&width=1200.0&height=1200.0&format=image/jpeg&srs=EPSG:28992

#18

Daar staat het inderdaad uitgelegd.

Kun je overigens niet beter WMTS gebruiken ipv WMS? Dat is een wat nieuwere techniek en het schijnt sneller te zijn. Het heeft wel andere parameters nodig trouwens.

#19

‘Uitleg’ is een groot woord, een voorbeeld zoals voor de vorige bron nog online staat zou niet misstaan om de drempel wat te verlagen. Maar goed, bij deze dus op het forum een werkend voorbeeld, is wel vindbaar denk ik.

WMTS is inderdaad sneller, maar WMS is momenteel niet de bottleneck in mijn toepassing, en een stuk simpeler te documenteren. Maar bedankt voor de tip!

#20

Het is niet heel simpel allemaal, een goed voorbeeld helpt zeker.

Maar ik heb gemerkt dat bij het implementeren in eigen software het wel handig is om meer informatie te hebben. Ik had ooit wat voorbeelden van PDOK met werkende url’s maar na een tijdje bleek dat die voorbeelden alleen werkten omdat bepaalde verplichte parameters automatisch werden toegevoegd bij de aanroep. Toen er bij een url-wijziging strikter op gecontroleerd werd, werkten de voorbeelden niet meer en moest ik alsnog dieper in de materie duiken.

Hier kun je veel meer documentatie vinden en downloaden:

En aan de rechterkant nog veel meer standaarden (KML, CityGML, GeoTiff, enz).

Onder het kopje ‘Downloads’ op elke pagina vind je de PDF documentatie voor de nieuwste versies bovenaan. In die bestanden vind je informatie over alle parameters en of ze verplicht zijn.

Het is wel veel leesvoer maar het verheldert veel.

#21

GetCapabilities geeft overigens niet de benodigde parameters aan die bij de service horen, dat volgt uit de documentatie van de standaard.