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:
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.
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.
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)
(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.
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.
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.
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
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?
@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.
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?
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.
‘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!
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.
