high-DPI support

[jfirebaugh]

TileJSON should have a means of:

• indicating when a source supports high-DPI versions of base tiles, and at what DPI multipliers (@2x, @4x, etc)
• specifying how URLs for high-DPI tiles are constructed

Without such a specification, consumers must have hard-coded knowledge of a source's support for high-DPI tiles and typically resort to string munging to generate the appropriate URLs. These are exactly the sort of deficiencies that TileJSON is designed to eliminate.

One approach would be to have an array-valued property that lists supported DPI multipliers and a new interpolation key for tile URL templates. E.g.:

{
  ...
  "dpis": [1, 2, 4],
  "tiles": ["http://example.com/{z}/{x}/{y}{r}.png"]
}

Where it is specified that {r} is replaced with the pixel ratio ⇢ string mapping of 1 ⇢ "", 2 ⇢ "@2x", 4 ⇢ "@4x", and consumers may decide which of the pixel ratio options to use based on device characteristics. Alternatively this mapping could be explicitly supplied:

{
  ...
  "dpis": {
    "1": "",
    "2": "@2x",
    "4": "@4x"
  },
  "tiles": ["http://example.com/{z}/{x}/{y}{r}.png"]
}

These approaches introduce a backward compatibility issue however, in that existing TileJSON consumers will not be prepared to interpolate a new template value and thus cannot consume TileJSON that uses it.

cc @yhahn @mourner @tmcw

[jfirebaugh]

srcset may be a good example to follow here.

[stevage]

IMHO, the first approach is a bit limiting, and the second one a bit cumbersome. The srcset approach would lead to something like:

"tiles": ["http://example.com/{z}/{x}/{y}.png 1x, http://example.com/{z}/{x}/{y}@2x.png 2x"]

On the plus side, it's backwardly compatible. On the downside, now you have a commafied list inside an array of strings and extra parsing to do.

Something like this maybe?

"tiles": ["http://example.com/{z}/{x}/{y}.png"],
"tiles-2x": ["http://example.com/{z}/{x}/{y}@2x.png"]

shrug

[Bibi56]

{r} is shorter but {ratio} is used in MapBox SDK, maybe we could add the ratio range, and the formula.

"tiles": ["http://example.com/{z}/{x}/{y}{r}.png"],
"ratios": [1, 2, 3, 4],
"r": "@2{r}"

"tiles": ["http://example.com/{z}/{x}/{y}.png{r}"],
"ratios": [1, 2, 3, 4],
"r": "?scale={r}"

This is backward-compatible. "ratios": [1], resp. "r": "@{r}" could be default values.

For ratio=1 , we can assume the substitution to use is the empty string "", right? Or do we prefer to specify the default?

"r1":"?scale=1" would enable the easy tilesize extension "tilesize":"&tilesize=512".

Is it needed? In that specific case we could say:

"tiles": ["http://example.com/{z}/{x}/{y}.png?{r}tilesize={ts}"],
"ratios": [1, 2, 3, 4],
"tilesizes": [256, 512],
"r": "scale={r}&"

[GretaCB]

Thanks for everyone’s thoughts here. This proposed change will be considered as part of the v4 push #35