Tilematrixset EPSG:25831 van Luchtfoto WMTS is niet correct

Datasets Luchtfoto's
#1

Als ik de Actueel_ortho25 luchtfoto’s wil ophalen in EPSG:25831, dan krijg ik voor alle tiles de melding dat

<ows:ExceptionReport xsi:schemaLocation="http://www.opengis.net/ows/1.1 http://schemas.opengis.net/ows/1.1.0/owsExceptionReport.xsd" version="1.0.0" xml:lang="en">
<ows:Exception exceptionCode="TileOutOfRange">
<ows:ExceptionText>
The requested tile is outside the bounding box of the tile map.
</ows:ExceptionText>
</ows:Exception>
</ows:ExceptionReport>

Als ik op dezelfde plek de BRT-A tiles ophaal, dan krijg ik die keurig netjes geserveerd. Enig vergelijkend onderzoek leert dat de TileMatrixSet definities in de Capabilities van beide WMTS’sen nogal van elkaar verschillen. Hieronder even de eerste twee gekopieerd.

Uit de Capabilties van de BRT-A WMTS:

<TileMatrixSet>
<ows:Identifier>EPSG:25831</ows:Identifier>
<ows:SupportedCRS>urn:ogc:def:crs:EPSG::25831</ows:SupportedCRS>
<TileMatrix>
<ows:Identifier>00</ows:Identifier>
<ScaleDenominator>10000000.0</ScaleDenominator>
<TopLeftCorner>-2404683.40739 8298457.58466</TopLeftCorner>
<TileWidth>256</TileWidth>
<TileHeight>256</TileHeight>
<MatrixWidth>9</MatrixWidth>
<MatrixHeight>6</MatrixHeight>
</TileMatrix>
<TileMatrix>
<ows:Identifier>01</ows:Identifier>
<ScaleDenominator>5000000.0</ScaleDenominator>
<TopLeftCorner>-2404683.40739 8298457.58466</TopLeftCorner>
<TileWidth>256</TileWidth>
<TileHeight>256</TileHeight>
<MatrixWidth>18</MatrixWidth>
<MatrixHeight>12</MatrixHeight>
</TileMatrix>

en uit de Capabilties van de Luchtfoto WMTS:

<TileMatrixSet>
<ows:Identifier>EPSG:25831</ows:Identifier>
<ows:SupportedCRS>EPSG:25831</ows:SupportedCRS>
<TileMatrix>
<ows:Identifier>00</ows:Identifier>
<ScaleDenominator>12694582.752169155</ScaleDenominator>
<TopLeftCorner>209006.82709241798 6236733.705757082</TopLeftCorner>
<TileWidth>256</TileWidth>
<TileHeight>256</TileHeight>
<MatrixWidth>1</MatrixWidth>
<MatrixHeight>1</MatrixHeight>
</TileMatrix>
<TileMatrix>
<ows:Identifier>01</ows:Identifier>
<ScaleDenominator>6347291.376084577</ScaleDenominator>
<TopLeftCorner>209006.82709241798 6236733.705757082</TopLeftCorner>
<TileWidth>256</TileWidth>
<TileHeight>256</TileHeight>
<MatrixWidth>2</MatrixWidth>
<MatrixHeight>2</MatrixHeight>
</TileMatrix>

De TopLeft corners van de luchtfoto’s zijn volledig anders, evenals de MatrixWidth en MatrixHeight. Ik kan de luchtfoto’s dus niet ophalen in EPSG:25831, dat levert alleen een HTTP-400 met hierboven gekopieerde response op. Het verschil in SupportedCRS is naamgeving, dat speelt bij mij geen rol.

Als verder voorbeeld: Twee exact dezelfde requests, voor dezelfde tile, alleen de basis url en de layer-parameter verschilt:

https://service.pdok.nl/brt/achtergrondkaart/wmts/v2_0?layer=standaard&style=default&tilematrixset=EPSG%3A25831&Service=WMTS&Request=GetTile&Version=1.0.0&Format=image%2Fpng&TileMatrix=EPSG%3A25831%3A9&TileCol=1700&TileRow=1403

levert netjes een tile op,

https://service.pdok.nl/hwh/luchtfotorgb/wmts/v1_0?layer=Actueel_ortho25&style=default&tilematrixset=EPSG%3A25831&Service=WMTS&Request=GetTile&Version=1.0.0&Format=image%2Fpng&TileMatrix=EPSG%3A25831%3A9&TileCol=1700&TileRow=1403

levert bovenstaande foutmelding. Zijn verder identieke requests…

Het kan natuurlijk ook zijn dat het andersom is, de luchtfoto-tilematrixset definitie correct en die van de BRT-A verkeerd, dan heb ik het fout gezien :wink:

#2

@sbjager, ik zal het laten uitzoeken en koppel ik daarna terug.

1 like
#3

Misschien wel een goede toevoeging…
Technisch zijn beide services correct :white_check_mark:

De gedefinieerde TileMatrixSet (EPSG:25831) in dit geval is niet een globaal service overstijgende identificatie. M.a.w. deze kan verschillen tussen services (in dit geval de BRTA en de Luchtfoto’s)

Binnen de services van PDOK hanteren wij dezelfde TileMatrixSet identificatie met tussen de verschillende services dezelfde parameters, zodat de actie @sbjager die je uitvoert werkt (dezelfde tegel andere 'visualisatie)
Dat de services van de luchtfoto’s ‘anders’ werken is dat deze technisch door Beeldmateriaal worden ingevuld.

#4

Dat begrijp ik niet helemaal…
Als ik gebruik makend van een tilematrixset ergens middenin Nederland van de ene service een tegel kan ophalen, maar gebruik makend van dezelfde tilematrixset (en hetzelfde CRS) van een andere service niet, en op die plek een melding krijg dat de opgevraagde tile buiten de bounding box van de tile map ligt, dan klopt (de inhoud van) die tweede tilematrixset definitie toch niet?
Dat alles is ingevuld met waardes, en een validatie tegen een XSD dus een goed resultaat zal opleveren, wil m.i. nog niet zeggen dat die waardes ook correct zijn.

#5

Het is dus niet dezelfde TileMatrixSet.

Dat de BRTA en Luchtofoto’s eenTileMatrixSet hebben gedefinieerd met dezelfde naam, maar andere parameters (zoals ScaleDenominator en TopLeftCorner) is in dit geval ‘onhandig’.

De naam van een TileMatrixSet heeft geen enkele technische waarde, het is nu eenmaal zo dat deze (iig bij PDOK, 10 jaar geleden) zijn ingericht met een naamgeving die een technische identificatie heeft.

Doordat de oorsprong (TopLeftCorner) verschilt is de tegelmatrix opbouw dus ook afwijkend, zowel verschoven als verkleind en zijn de parameters tussen services niet 1 op 1 te kopieren.

3 likes
#6

Ah ok, bedoel je het zo. Ja, het klopt dat het niet dezelfde tilematrixset is op die manier. Maar het lukt standaard software dus niet om daar correct tiles mee op te halen. En om eerlijk te zijn: als een tilematrixset van de ene service dezelfde naam heeft als die van een andere service, en die naam hetzelfde CRS impliceert, ga ik er van uit dat die tilematrices hetzelfde zijn/zouden moeten zijn… vooral als die een foutmelding oplevert die, gezien de overige resultaten van de software die ik gebruik (Openlayers), niet terecht lijkt te zijn.

1 like
#7

@sbjager ik had beloofd terug te koppelen, maar ik ga ervan uit dat de antwoorden van @wouter.visscher duidelijkheid heeft gebracht. Technisch zijn beide services correct, alleen is de tegelmatrix opbouw van beide services anders. Daar is niks mis mee en hoeven niet gelijk te zijn.

1 like
#8

Nee, dat klopt, ben ik inmiddels ook achter. Jij (en @wouter.visscher :wink: ) hebben gelijk.

Het grote nadeel hiervan vind ik, dat je als client-applicatie dus eignelijk altijd de Capabilities moet ophalen om de correcte matrixset-definities te gebruiken. Je kunt er dus niet, zoals ik wel deed, van uit gaan dat de ene definitie met dezelfde naam, identifier en EPSG-nummer gelijk aan de andere is als ze uit verschillende services komen. En dat veroorzaakt dus nogal wat extra netwerkverkeer, inclusief een behoorlijk berg (XML-)data die je naar je client moet overhalen.

Dat vind ik jammer, dit zijn nou precies het soort valkuilen die het er niet makkelijker op maken om veel services met elkaar te combineren… Misschien een idee voor PDOK om eens aandacht aan te schenken?

Maar goed, alles doet het bij mij wel weer, dus op dat punt geen probleem. Dank voor de terugkoppeling nog overigens, dat word zeker wel gewaardeerd!

2 likes
#9

Ik ook :face_with_open_eyes_and_hand_over_mouth:

1 like
#10

Dat is nu nauw net wat we deden voor alle PDOK services (hier 1 lijn in trekken) :sweat_smile:
Alleen doet PDOK technisch de luchtfotos niet. Wij proxien het verkeer naar de LVB door. M.a.w PDOK heeft gezicht om hoe de capabilities documenten voor de luchtfoto’s zijn.

Wat de technische reden is waarom LVB het zo doet kan ik niet te zeggen. (mogelijk omdat men opbasis van de extern van de data werkt, ipv een NL BBOX + continentaal plat die wij bij PDOK hanteren)
Iets wat @rbhailal en @Jeroen_PDOK een keer kunnen bespreken/afstemmen?

1 like
#11

:+1:

Ah! Kijk, dat wist ik niet. Dat maakt het weer wel wat duidelijker :slight_smile:

Overigens moet ik er wel bij zeggen dat mijn aanname tot dusver wel voor EPSG:28992 prima heeft gewerkt, het ging alleen bij 25831 mis. Dus het overgrote deel komt allemaal overeen. Dat was voor mij ook de reden om te denken dat er iets mis was - maar ja, “assumption is the mother of all f***ups”… :grin:
Het is ook voor mij de makkelijkste manier: een shared basis javascriptje waarin voor een aantal coordinatensystemen (28992, 3857, 4326, en dus ook 25831) een definitie van de projectie, inclusief een tilematrixset, word opgebouwd. Die kan ik dan overal gebruiken icm Openlayers, zo was mijn aanname, totdat ik dus geen luchtfoto’s meer zag op de plek waar ik 25831 gebruik. Ik had wel gemerkt dat de TileMatrixset ID’s van EPSG:25831:RWS:# naar EPSG:25831:# waren gegaan een tijd geleden, maar dat de hele definitie was aangepast heb ik gemist. Maar goed, alles werkt weer :slight_smile:

#12

Voor EPSG:28992 is er een Nederlandse Richtlijn Tiling die voor eenduidigheid zorgt, maar ook daar zijn uitzonderingen op: Topotijdreis.nl houdt zich daar bijvoorbeeld niet aan.

#13

En dat versterkte bij mij dus het idee dat het overal gelijk was, wat dus niet zo is :slight_smile: Het maakte het leven wel makkelijk - totdat je ineens toch net in een iets anders CRS gaat zitten prutsen :smiley:

Dat topotijdreis zich niet aan dat soort standaarden houd, verbaast me helemaal niets…