Ik krijg dezelfde foutmelding. Kan iemand de foutmelding verklaren?
Hoi @Duncan
Gezien je reageert op een ouwe post met de ouwe brt WMTS URL:
https://geodata.nationaalgeoregister.nl/tiles/service/wmts....
Kan je proberen over de nieuwe URL wel werkt?
https://service.pdok.nl/brt/achtergrondkaart/wmts/v2_0?request=getcapabilities&service=wmts
Zie ook:
Hallo @Wouter,
Ik heb de nieuwe URL geprobeerd, maar deze geeft dezelfde foutmelding, zoals in de vorige bericht beschreven (namelijk failed wmtsâŠ)
Dit is de URL die ik heb geprobeerd te laden als bron in Geoserver (https://service.pdok.nl/brt/achtergrondkaart/wmts/v2_0?request=getcapabilities), maar als ik dan een van de lagen publiceer in geoserver, dan krij ik in de voorvertoing dus en foutmelding en krijg ik de lagen neit te zien in QGIS.
Los van de failed wmts melding in de output van de service.
Kan je ook zien of er meer informatie terugkomt in de systeem logging van Geoserver?
Kan de geoserver uberhaupt met de wmts service connecten (mogelijk proxy probleem?), of gaat het mis met het ophalen van het plaatje, enzâŠ
Iets van Java Stack Traces oid kan veel helpen om te achterhalen wat mogelijk het issue is.
Geoserver kan met WMTS services omgaan. De historische topotijdreis wordt wel gepubliceerd in Geoserver.
De volgende foutmelding krijg ik:
18 Jan 11:53:36 ERROR [tile.loader] - Failed to load image: https://service.pdok.nl/brt/achtergrondkaart/wmts/v2_0?REQUEST=GetTile&VERSION=1.0.0&SERVICE=WMTS&type=KVP&tilematrixset=EPSG%3A28992&TileRow=0&format=image%2Fpng&style=default&TileCol=1&layer=pastel&TileMatrix=01
java.io.IOException: Server returned HTTP error code 400 for URL https://service.pdok.nl/brt/achtergrondkaart/wmts/v2_0?REQUEST=GetTile&VERSION=1.0.0&SERVICE=WMTS&type=KVP&tilematrixset=EPSG%3A28992&TileRow=0&format=image%2Fpng&style=default&TileCol=1&layer=pastel&TileMatrix=01
Als je kijkt naar de response van het request (de 400)
lijkt er iets mis te zijn met de encoding van de tilematrixset, als je de waarde daarvan aanpast van
EPSG%253A28992 â EPSG:28992 (of EPSG%3A28992) dan krijg je wel een plaatje
(de links die je post âlijkenâ goed, maar het onderliggende request, de daadwerkelijk URL die gebruikt wordt is kapot)
https://service.pdok.nl/brt/achtergrondkaart/wmts/v2_0?REQUEST=GetTile&VERSION=1.0.0&SERVICE=WMTS&type=KVP&tilematrixset=EPSG%3A28992&TileRow=0&format=image%2Fpng&style=default&TileCol=1&layer=pastel&TileMatrix=01
Zover ik kan zie lijkt je Geoserver een fout request/URL te genereren of dat op basis is van âonsâ Capabilities document of iets in je Geoserver configuratie kan/durf ik niet te zeggen.
Edit: ook nog ff snel getest met geoserver (kartoza/geoserver:2.22.0) met âdefaultâ settings (WMTS via interface toevoegen, next, next, next drukken enzâŠ) krijg ik het wel aan de praat. (en zichtbaar in QGIS)
Kan je je geoserver configuratie delen de betreffende datasource en layer? (zonodig via een PM)
Helaas heb ik hetzelfde probleem.
Geoserver genereert de URL
https://service.pdok.nl/hwh/luchtfotorgb/wmts/v1_0/2025_orthoHR/EPSG%3A3857/04/6/6.jpeg
Deze werkt niet; de URL
https://service.pdok.nl/hwh/luchtfotorgb/wmts/v1_0/2025_orthoHR/EPSG:3857/04/6/6.jpeg
werkt wel.
Is al duidelijk of dit een probleem is met het capabilities document of met Geoserver?
Is er een work-around voor dit probleem?
Als ik de standaarden voor URLâs probeer te begrijpen dan kom ik tot de conclusies:
- gereserveerde karakters moeten %-gecodeerd worden
:is op bepaalde plekken in de URL gereserveerd, op andere niet. In de URLhttps://service.pdok.nl/hwh/luchtfotorgb/wmts/v1_0/2025_orthoHR/EPSG:3857/04/6/6.jpegis de:naEPSGgeen gereserveerd karakter (zie RFC 3986: Uniform Resource Identifier (URI): Generic Syntax | RFC Editor) en hoeft niet %-gecodeerd te worden. Geoserver doet dat wel.- tegelijkertijd is er veel discussie over hoe de standaarden op dit punt geĂŻnterpreteerd moeten worden (ik heb er heel wat gelezen voor ik tot mijn conclusie ben gekomen).
In de Geoserver configuratie is er in mijn beleving op dit gebied niets in te stellen. In het capabilities document staat niets wat naar verwachting zou kunnen leiden tot %-encoderen van de :.
Toch zie je bij de Geoserver issues dit probleem niet opduiken. Blijkbaar zijn andere servers genegen de %-encoding van de : te accepteren. De server van PDOK luchtfoto klaagt niet over een ongeldig karakter in de URL, maar parst de URL verkeerd waardoor een melding komt mbt onbekende laag.
Het lijkt goed om de service aan te passen zodat 1 van 2 dingen gebeurt:
- de juiste foutmelding geven âongeldig karakter : in de URLâ
- de URL wel accepteren en er een %-decoding op los te laten zoals veel andere servers wel doen
Zou de laatste optie niet de beste zijn?
Goed dat je er op terugkomt. We gaan er nog een keer naar kijken en komen binnenkort met een reactie.
Ik heb dit besproken. We willen dit gaan aanpassen (dus de %-encoding toestaan). Dat willen we goed doen, dus het kan even duren. Als we een aanpassing hebben doorgevoerd laten we dat hier weten.