resolution {r} param

[DanielJDufour]

It wouldn't require a specification change, but perhaps we could add to the description of XYZ href, that {r} is optional as well:
https://leafletjs.com/reference.html#tilelayer

[m-mohr]

Thanks. Is this Leaflet specific? I don't see such a parameter in any other mapping library I have looked at (Mapbox, Openlayers).

[DanielJDufour]

Marblecutter has something similar but calls it "scale": https://github.com/DanielJDufour/marblecutter-virtual/blob/master/virtual/web.py#L110

[m-mohr]

How should this be handled if {r} is not supported by the library of choice? Thinking about how to include this without breaking stuff for non-Leaflet or making things too difficult.

[DanielJDufour]

That's a good point. I'm not sure there's a perfect answer, but here's a couple options to consider:

1. adding another field like server-tech to the extension spec that says what technology the server uses: geoserver, marblecutter, titiler, lambda-tiler, etc
2. recommend people just hardcode in any special parameters like url and resolution/scale, so just do https://example.org/tiles/{z}/{x}/{y}@2x.png?url=https://path.to.tif
3. create a new "type" XYZParam and add a new field: xyz:params, that points to an object with parameter information like:

{
    "r": {
        "description": "resolution",
    },
    "bands": {
        "description": "comma separated ordering of bands"
    }
}

conclusion

After more thought, I think Number 2 makes the most sense (would be a hassle to support all the different libraries and params). If/when the community comes together and creates a standard for xyz tile service parameters (e.g., bands, expr, etc.), we can add more to this extension.

What do you think?

[cholmes]

Yeah, I think I like 2. the best. Would be good to call it out specifically though, and perhaps even have an example with it.

[m-mohr]

Okay, option 2 sounds good to me. Happy to accept PRs if anyone wants to give it a try.

[m-mohr]

Implemented.