Add support for retina (scaling) TMS token

[zdila]

On CONTRIBUTING page I found no retina tile parameter. Editor iD has it implemented as {r} or {@2x}. Please add support for it.

[rbuffat]

@zdila Is this an optional tms parameter? E.g. a source can work with or without this parameter? Is there cross-editor support for this parameter? If it is an optional parameter, is there a way to specify it without breaking the compatibility with an editor that does not support it?

CC @Klumbumbus @simonpoole @quincylvania @systemed @bryceco

[zdila]

It is an optional parameter. If omitted then it is the same as @1x.

In ideal world editors not understanding {r} or {@2x} should remove this placeholder.

I have only checked editor iD which supports it and JOSM which shows error that {@2x} is not valid TMS argument.

I am not sure how to add a support for it and keep the compatibility. Maybe compiling geojsons for different editors?

[zdila]

Just for the reference - JOSM: https://josm.openstreetmap.de/ticket/20030

[zdila]

BTW some tileservers support other scales and they can be also fractional. For example please see one particular tile:

• https://outdoor.tiles.freemap.sk/14/9155/5649 (same as https://outdoor.tiles.freemap.sk/14/9155/5649@1x)
• https://outdoor.tiles.freemap.sk/14/9155/5649@2x
• https://outdoor.tiles.freemap.sk/14/9155/5649@3x

[grischard]

Since it would be a new parameter, existing editors wouldn't just strip it, and would get 404s if they call 0.png{r} instead of 0.png or 0.png@2x

Maybe something like the srcset html attribute could work, or a second url source?

Editors can also use the category to decide if they want to overzoom by default, for example on aerial imagery.

In any case, this should be done together with the JOSM team.

[rbuffat]

In any case, this should be done together with the JOSM team.

Ideally, there should be a consensus among all osm editors. Is there somebody else that should be included in the discussion?

[rbuffat]

There seems to be a small number of sources that support @2x, but my test script could also be a bit buggy, so there could be more or less.

Source ids returning a 512x512 pixel image for @2x:

Freemap.sk-Outdoor
IBGE_Nomes_Ruas
IBGE_Salvador_Streets
mapbox_locator_overlay
wikimedia-map
Arenda_OAM
Maxar_19-20_Australian_Bushfires_PreEvent
ARA_Bushfires_2020
IBGE_Setores_Rurais
IBGE_Setores_Urbanos
IBGE_DF_Addresses
US-TIGER-Roads-2017
Mapbox
US-TIGER-Roads-2014
US-TIGER-Roads-2019
US-TIGER-Roads-2018
City_of_Melbourne_May_2018
City_of_Melbourne_Feb_2019

Source ids returning a 768x768 pixel image for @3x:

Freemap.sk-Outdoor
Arenda_OAM
wikimedia-map
Maxar_19-20_Australian_Bushfires_PreEvent
ARA_Bushfires_2020

[zdila]

Following sources certainly don't support it (I know, because I am from Freemap community):

• Freemap.sk-Hiking
• Freemap.sk-Ski
• Freemap.sk-Car
• Freemap.sk-Cyclo

[rbuffat]

@zdila Thanks, there was a bug. I updated the list above.

[simonpoole]

Would someone be so kind and explain what the point of supporting this for aerial imagery is (contrary to maps with labels, where the reasoning is clear)?

[zdila]

@simonpoole Aerial imagery sources (non-hybrid, without labels, icons and other added symbology) should only be flagged that they are scaleable witout issues. Then rendering on HDPI (2x) can be easily done by taking 4 tiles from zoom+1 and rendering them in 2x2 grid in the place of the original "non-HDPI" tile.

[andrewharvey]

Another good reason here for versioning releases. Can auto-strip it for the current version, but add a breaking change not for the next major version.

Although some sources have a convention eg @2x other sources you might need a whole new URL entered.

Would someone be so kind and explain what the point of supporting this for aerial imagery is (contrary to maps with labels, where the reasoning is clear)?

I don't think it's needed in that case. But we should still support it for all the non-imagery maps in the index.

[rbuffat]

Since it would be a new parameter, existing editors wouldn't just strip it, and would get 404s if they call 0.png{r} instead of 0.png or 0.png@2x Maybe something like the srcset html attribute could work, or a second url source?

Probably, the most elegant solution is to encode it in the url, the question is what the best way would be. E.g. for the freemap outdoor example, the following variants work:

https://outdoor.tiles.freemap.sk/12/2249/1460 https://outdoor.tiles.freemap.sk/12/2249/1460@1x https://outdoor.tiles.freemap.sk/12/2249/1460@2x https://outdoor.tiles.freemap.sk/12/2249/1460@3x

I don't know if there is a guarantee that, if e.g. a service offers @2x variant, also the @1x works. Thus, probably it would be a good idea to encode the known working resolutions.

Maybe something like `https://outdoor.tiles.freemap.sk/{zoom}/{x}/{y}{r:1,2,3}?

Editors that do not wish to use higher resolutions could simply drop the {r} token. We could integrate this token in the URLs but drop it automatically in the imagery.* files until every editor supports it.

[rbuffat]

More on a general note, is there a platform where such topics can be discussed and developers of all OSM editors listen to? E.g. a specific mailing list?

[andrewharvey]

More on a general note, is there a platform where such topics can be discussed and developers of all OSM editors listen to? E.g. a specific mailing list?

https://lists.openstreetmap.org/pipermail/dev is for all OSM development and developers building tools for OSM data, not specific to editors.

[simonpoole]

Editors that do not wish to use higher resolutions could simply drop the {r} token. We could integrate this token in the URLs but drop it automatically in the imagery.* files until every editor supports it.

I suppose this could be solved the other way around, add a list of supported resolution tokens in the config. Assuming that ELI clients simply ignore json fields they don't recognize, for this to work there the client will need hardwired information on the semantics of @2x and @3x, but currently it would seem they need that anyway.

[zdila]

Other option could be extending properties with additional URLs for every supported scaling (even fractional). This would make it backward compatibile with old (current) software:

{
  "properties": {
    "url": "https://outdoor.tiles.freemap.sk/{zoom}/{x}/{y}",
    "scales": {
      "2": "https://outdoor.tiles.freemap.sk/{zoom}/{x}/{y}@2x",
      "3": "https://outdoor.tiles.freemap.sk/{zoom}/{x}/{y}@3x"
    }
    // ...
  }
  // ...
}

BTW @2x is a common standard identifying scale in URL but there are other. For example Strava heatmap uses tile dimenstion:

• https://strava-heatmap.tiles.freemap.sk/both/bluered/13/4574/2807.png?px=256
• https://strava-heatmap.tiles.freemap.sk/both/bluered/13/4574/2807.png?px=512

[simonpoole]

Other option could be extending properties with additional URLs for every supported scaling (even fractional). This would make it backward compatibile with old (current) software:

If we do something like that, integrating alternative URLs (we currently can't model this, but JOSM has them) in general would make sense imho, so something like:

{
  "properties": {
    "url": "https://outdoor.tiles.freemap.sk/{zoom}/{x}/{y}",
    "scale": 1, // optional if 1
    "alternatives": [
      {
        "url": "https://outdoor.tiles.freemap.sk/{zoom}/{x}/{y}@2x",
        "scale": 2
      },
      {
        "url": "https://outdoor.tiles.freemap.sk/{zoom}/{x}/{y}@3x",
        "scale": 3
      },
      {
        "url": "https://somewhere.different.sk/{zoom}/{x}/{y}",
        "scale": 1
      }
    ]
    // ...
  }
  // ...
}