Sinds vandaag krijg ik fouten bij het aanroepen van de Luchtfoto 2017 WMTS:
Geeft een fout “internal error: invalid request (/wmts)”.
Via:
Werkt wel maar lijkt erg traag te zijn.
Mijn viewer werkt met bovenstaand en dan is het erg vervelend als er helemaal geen images terug komen. Is deze storing bekend of is er iets gewijzigd wat ik kan aanpassen in mijn viewer?
Dat klopt, vrijdag einde van de dag zijn de luchtfotos van 2018 live gezet.
Met deze uitrol hebben we ook de routing opnieuw moeten opzetten, hierbij zijn we voornamelijk gekeken naar de eindpoints die we officieel ondersteunen/adverteren.
Daar lijkt de URL die jullie gebruiken niet onder te vallen. Het lijkt dat een TMS & WMTS request daarin worden samengevoegd (wmts/1.0.0).
Deze URL werkt wel (zonder de /1.0.0): https://geodata.nationaalgeoregister.nl/luchtfoto/rgb/wmts/2017_ortho25/EPSG:3857/11/1059/675.jpeg
https://geodata.nationaalgeoregister.nl/luchtfoto/rgb/wmts/2017_ortho25/EPSG:3857/11/1059/675.jpeg
Ik kan ook niet zo 1,2,3 in onze ouwe capabilities terug vinden of we deze ‘luchtfoto/rgb/wmts/1.0.0’ ook daadwerkelijk ooit naar buiten geadverteerd hebben.
De /1.0.0 zou alleen moeten werken in combinatie met een TMS request zoals: https://geodata.nationaalgeoregister.nl/luchtfoto/rgb/tms/1.0.0/Actueel_ortho25/EPSG:28992/6/35/32.jpeg
Ah, duidelijk verhaal. Ik weet niet hoe ik aan die url kom, maar als ik hier kijk:
Dan is het idd een samenvoeging van wmts en tms.
Is de 2018 luchtfoto definitief beschikbaar? Of komt daar nog een mailing over?
Het kan trouwens aan mijn wifi liggen maar het opvragen van de tiles is erg traag. Kan dat kloppen?
De 2018 luchtfotos zijn nu definitief beschikbaar 
Ik zag de mailing voorbij komen
als ik nog eens nadenk over de door mij gebruikte url dan zou het kunnen dat ik ooit de TMS variant tegenkwam en gewoon geprobeerd heb of de WMTS ook zo werkte. Toen wel, maar nu na het opschonen van de endpoints niet meer.
Heb de url vervangen in mijn applicatie en het werkt weer. Toch gevoelsmatig nog erg traag.
@wouter.visscher: Er lijkt nog iets niet goed te gaan bij de 2016_ortho25 en 2017_ortho25 (niet getest met 2018). Gebruikers van onze software melden dat in sommige delen van Nederland witte tegels worden geretourneerd. Deze worden opgevraagd met de volgende url:
https://geodata.nationaalgeoregister.nl/luchtfoto/rgb/wmts?request=getcapabilities
Als ik deze in QGIS inlaadt dan zie ik op het hoogste zoomniveau in bijvoorbeeld Den Helder of in Zeeland alleen witte vlakken ontstaan. Dit gebeurt niet in het midden van het land of in Limburg. Het is dus niet zo dat er geen tegels terugkomen, anders zou de cache van het vorige zoomniveau getoond worden maar het worden echt witte vlakken.
Zou je eens kunnen kijken wat daar aan de hand is?
Hoi @Anton, ik krijg het niet gereproduceerd in QGIS (3.4)
Welke projectie gebruiken jullie?
Ook in onze monitoring zien we dit gedrag niet terug.
Huidige load is 8k per/minuut en latency van rond de 100ms en iets van totaal (laatste uur) 6 mislukte requesten.
Dit is voor alle ortho25 datasets (actueel/2018/2017/2016 rgb&ir)
Bijvoorbeeld deze aanvraag:
Toont een wit vlak. Het daarnaast liggende vlak bijvoorbeeld:
toont wel de luchtfoto. Alle aanroepen naar links worden wit, alle aanroepen naar rechts worden wel goed getoond.
Ik ziet het, we gaan iets gerichter kijken/zoeken
Hoi @Anton het zou nu goed moeten zijn voor alle lagen.
Er was nog een scale/resolution issue met de settings van onze mapproxies op de laagste lagen van de luchtfoto’s.
Een eerste test lijkt idd het goede resultaat op te leveren. Super bedankt! 
De TMS in WGS84 geeft alleen nog maar witte tegels terug. Zie bijvoorbeeld https://geodata.nationaalgeoregister.nl/luchtfoto/rgb/tms/1.0.0/Actueel_ortho25/EPSG:3857/12/2101/1351.jpeg. Naar wat ik begrijp uit eerdere berichten van @wouter.visscher zou dit de juiste URL-opbouw moeten zijn. Is dit een bug of doe ik iets verkeerd? In RD krijg ik wel resultaten: https://geodata.nationaalgeoregister.nl/luchtfoto/rgb/tms/1.0.0/Actueel_ortho25/EPSG:28992/12/1766/2052.jpeg
Hoi @JaZo,
Gaat het iets mis in een bestaande applicatie?
Wat wij zien met betrekking tot de WMTS & TMS services lijken ze te werken zoals voorheen…
TMS geeft bij ons op EPSG:3857 wel responses terug.
De URL-opbouw die jij gebruikt lijkt correct, alleen de invulling van de {z}{x}{y} parameters lijkt ‘verschoven’?
WMTS RESTful: https://geodata.nationaalgeoregister.nl/luchtfoto/rgb/wmts/2018_ortho25/EPSG:3857/9/263/168.jpeg
https://geodata.nationaalgeoregister.nl/luchtfoto/rgb/wmts/2018_ortho25/EPSG:3857/9/263/168.jpeg
m.b.t. jouw voorbeeld in Leiden
EPSG:3857 zou dan zijn: https://geodata.nationaalgeoregister.nl/luchtfoto/rgb/tms/1.0.0/Actueel_ortho25/EPSG:3857/16/67175/87872.jpeg
En in EPSG:28992: https://geodata.nationaalgeoregister.nl/luchtfoto/rgb/tms/1.0.0/Actueel_ortho25/EPSG:28992/12/1766/2052.jpeg
Het gaat inderdaad mis in een bestaande (door ons ontwikkelde) applicatie. De invulling van z,x,y lijkt inderdaad verschoven bij gebruik van TMS. Het lijkt er op dat het zoomniveau bij mij telkens één niveau te diep is voor de gebruikte x en y coördinaten… Als ik de WMTS RESTful gebruik werkt het in ieder geval allemaal prima, dus dan gaan we daar voor!
De TMS service wordt sowieso afgeraden om in een publieke applicatie te gebruiken:
De WMTS dient bij voorkeur te worden gebruikt in toepassingen voor publiek gebruik. Deze service kent de beste performance. De WMS kan bij een te groot gebruik te traag worden en PDOK kan in zo’n geval toegang tot de WMS beperken.
