Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

optionsFromCapabilities from 'ol/source/WMTS' does not parse resolutions/scale denominators

See original GitHub issue

Describe the bug When parsing a GetCapabilities XML document from a standard WMTS MapServer implementation, the resolutions do not get inferred. I have to manually provide several parameters to a WMTS source to get things working. Since WMTS is a standard, either MapServer is not following the standard correctly or OpenLayers does not parse the document correctly in every case.

import {optionsFromCapabilities} from 'ol/source/WMTS'

To Reproduce

Note that I cannot provide complete steps at the moment, but I do not want this to be forgotten. So, I am leaving this issue slightly incomplete. This issue tripped me up at least 3 times now, which is why I find it very important. I may be able to fix it myself, but the person who did the initial implementation will probably be faster to do so.

Steps to reproduce the behavior:

Go to ‘…’
Click on ‘…’
See error

Expected behavior Any WMTS XML capabilities document can be parsed by OpenLayers and the layer used easily.

Please see https://gis.stackexchange.com/questions/29671/mathematics-behind-converting-scale-to-resolution to know how to convert the scale denominators to resolutions.

I was using the NZTM (EPSG:2193) projection. We always work around this issue thus far, but every time we need a New Zealand map of our own with WMTS, this trips us up.

Started something here: https://codepen.io/geekdenz/pen/eYJYgQV

Issue Analytics

State:
Created 3 years ago
Comments:9 (4 by maintainers)

Top GitHub Comments

1reaction

ahocevarcommented, Jun 9, 2020

If anyone has a fix, please submit a pull request.

0reactions

geekdenzcommented, Jun 19, 2020

This is caused by the coordinates being in the wrong order in the origin. NZTM uses neu.

This is already fixed in master: https://github.com/openlayers/openlayers/blob/1ef103ed6/src/ol/source/WMTS.js#L475 https://github.com/openlayers/openlayers/blob/master/src/ol/source/WMTS.js#L476

The bug still exists in production here: https://github.com/openlayers/openlayers/blob/v6.3.1/src/ol/source/WMTS.js#L383

A work-around that works is:

let options = optionsFromCapabilities(capabilities, wmtsOptions); options.tileGrid['extent_'] = [274000, 3087000, 3327000, 7173000];

for the NZTM (EPSG:2193) projection in 6.3.1.

Top Results From Across the Web

In OpenLayers 6.9.0 I use fetch WMTSCapabilities but I it ...

This looks like it is failing at this line in optionsFromCapabilities from the OpenLayers source:

Get actual error from ol.source.WMTS.optionsFromCapabilities

optionsFromCapabilities to create a WMTS layer and when I am trying to use a projection that does not exist in OpenLayers it throws...

OpenLayers v7.2.2 API - Module: ol/source/WMTS

Name Type Default attributions AttributionLike attributionsCollapsible boolean true cacheSize number

WMTS Layer from capabilities example

WMTSCapabilities(); var map; $.ajax('data/WMTSCapabilities.xml').then(function(response) { var result = parser.read(response); var options = ol.source.WMTS.