WMTSCapabilities.js - defects

[ca0v]

1st - would be nice if the test code below defaults to the first item in tileMatrixSetLinks instead of requiring exactly one item to exist (remove the == 1 test):

    if (config.matrixSet) {
        matrixSet = contents.tileMatrixSets[config.matrixSet];
    } else if (layerDef.tileMatrixSetLinks.length == 1) {
        matrixSet = contents.tileMatrixSets[
            layerDef.tileMatrixSetLinks[0].tileMatrixSet];
    }

2nd - precedence defect on line 157...missing ():

var units = config.units || (projection === "EPSG:4326" ? "degrees" : "m");

[sbrunner]

For the second your right it's relay bug, I will work on it.

For the first I'm not sure that a good idea if we have more than one tileMatrixSetLinks getting the first is arbitrary !

Witch use case do you have that needs this ?

[ca0v]

Yes, I agree that it is arbitrary but is it more arbitrary then picking the only one? Won't that break code if the service ever adds a second matrix set? I was making the assumption that the first set is the "default".

By allowing the user to provide a TILEMATRIXSET on the query string I am able to determine exactly which set to use and I no longer need to assume a default. Thank you for fixing the precedence defect.

[ca0v]

Found another issue with this file. The createLayer method selects get[0] instead of looking at the constraints. Here's some code that seems to resolve this problem:

    function filter(a, c) {
        var result = [];
        for (var i = 0; i < a.length; i++) {
            if (c(a[i], i, a)) result.push(a[i]);
        }
        return result;
    }

    function getUrl() {
        if (requestEncoding === "REST" && layerDef.resourceUrl)
            return layerDef.resourceUrl.tile.template;
        var c = capabilities.operationsMetadata.GetTile.dcp.http.get;
        return filter(c, function (item) {
            return (!!item.constraints.GetEncoding.allowedValues[requestEncoding]);
        })[0] || c[0];
    }

    return new OpenLayers.Layer.WMTS(
        OpenLayers.Util.applyDefaults(config, {
            url: getUrl().url,
            requestEncoding: requestEncoding,
            name: layerDef.title,
            style: style.identifier,
            matrixIds: matrixSet.matrixIds,
            matrixSet: matrixSet.identifier,
            projection: projection,
            units: units,
            resolutions: config.isBaseLayer === false ? undefined :
                resolutions,
            tileFullExtent: matrixSet.bounds,
            dimensions: dimensions,
            params: params
        })
    );

Interestingly ESRI's JSAPI suffers from this same bug. When you access an ESRI WMTS service using "KVP" you get an extra /tile/1.0.0 added to the URL. Am I misunderstanding the issue?

[ca0v]

Sorry to beat this file but I've run into another issue. http://v2.suite.opengeo.org/geoserver/gwc/service/wmts?REQUEST=GetCapabilities produces this TileMatrixSet. Notice the TopLeftCorner is showing yx (2.0037508E7 -2.003750834E7). Yet this file only declares 'urn:ogc:def:crs:EPSG::4326' as yx. If it is true that 'urn:ogc:def:crs:EPSG::900913' should also be in yx then I guess it should be added to the list.

  <TileMatrixSet>
    <ows:Identifier>EPSG:900913</ows:Identifier>
    <ows:SupportedCRS>urn:ogc:def:crs:EPSG::900913</ows:SupportedCRS>
    <TileMatrix>
      <ows:Identifier>EPSG:900913:0</ows:Identifier>
      <ScaleDenominator>5.590822639508929E8</ScaleDenominator>
      <TopLeftCorner>2.0037508E7 -2.003750834E7</TopLeftCorner>
      <TileWidth>256</TileWidth>
      <TileHeight>256</TileHeight>
      <MatrixWidth>1</MatrixWidth>
      <MatrixHeight>1</MatrixHeight>
    </TileMatrix>

I've also looked at http://sampleserver6.arcgisonline.com/arcgis/rest/services/WorldTimeZones/MapServer/WMTS which is xy (-2.0037508342787E7 2.0037508342787E7) and I think 102100 == 900913 == 3857 so not sure what to make of this:

<ows:Identifier>default028mm</ows:Identifier>
<ows:SupportedCRS>urn:ogc:def:crs:EPSG::102100</ows:SupportedCRS>
<TileMatrix>
    <ows:Identifier>0</ows:Identifier>
    <ScaleDenominator>5.590811458640437E8</ScaleDenominator>
    <TopLeftCorner>-2.0037508342787E7 2.0037508342787E7</TopLeftCorner>

[ca0v]

Can you also look into issues 3 documented above as well?

issue 3: The createLayer method selects get[0] instead of looking at the constraints; working code provided.
issue 4: GeoMedia docs is the closest thing I've found related to this issue. It states, "if the WMS version is 1.3.0, the authority is EPSG, and the EPSG code range is >=4000 and <5000, the default is Y,X, else, the default is X,Y."

[sbrunner]

@ca0v sorry for long time to responds, for issue 3 do you have an example capabilities ?

I needs it to be sure to relay fix the issue, ant to write a test.

[ca0v]

I'm sorry for the very long time to respond! Below is [link to] the example capabilities document you requests.

http://sampleserver6.arcgisonline.com/arcgis/rest/services/WorldTimeZones/MapServer/WMTS/1.0.0/WMTSCapabilities.xml

Sorry, but this introduces a 5th issue! Notice the "RESTful" instead of the "REST" in the AllowedValues. Could you add allowedValues['RESTful'] to the requestEncoding test?

WMTSCapabilities.xml also capture here: http://pastebin.com/PnrVExmV