Consider using resolution instead of scaleDenominator

[tschaub]

I know that there is a legacy of scaleDenominator in OGC specs, but I'm wondering if there has been any discussion about starting fresh on this spec.

The concept of "scale" doesn't apply well to digital maps. Broadly speaking, a rendering client may not be able to determine the physical pixel size of a display device. Newcomers to the Tiles spec may scratch their heads for a while trying to figure out how the server is supposed to know the pixel size of the display if the client can't even reliably determine it. After digging for a while through other OGC specs, they may discover the magic 0.28 mm "standardized rendering pixel size" and copy this into their code.

Since 0.28 mm will rarely (never? - try to find a 90.7 PX / inch device here http://screensiz.es/) be the physical size of a pixel, the scaleDenominator has no real meaning and only serves as a source of confusion for those that assume it does.

Instead of using the confusing scaleDenominator and requiring that implementors discover the magic 0.28 mm number, tile levels could be described in terms of resolution (number of map units per pixel). It is the resolution that a client needs to know in order to render tiles on a map.

[mcechini]

Map units per pixel would be so much easier and seemingly more intuitive. Though perhaps it's a rite of passage for service consumers and providers to have to work out the scaleDenominator math on their own.

[tschaub]

Ideally, the spec would be developed in a way that minimized dependencies for implementations - both client and server. To interpret scaleDenominator, a client needs to know 1) what OGC considers the standardized rendering pixel and 2) the number of meters per unit for the spatial reference system used by the tile set.

You could say that the first requirement (finding the magic 0.28 mm) is a rite of passage for any worthy implementor. The second requirement, however, imposes an unfortunate and unnecessary dependency on all implementations – the ability to look up the number of meters per unit for any spatial reference system that they might encounter. Perhaps this is not known, but you don't actually need to know anything about the spatial reference system of the tile set to actually render a working, fully interactive map client based on that tile set. You only need to know these three things:

1. how to get the resolution (projected units per pixel) of a tile level (or tileMatrix)
2. how to get the tile row and column number for a given projected coordinate and level
3. how to generate a URL for a tile based on level, row, and column

The WMTS spec makes two of these things harder than they need to be, and this spec looks to inherit that. Step one would be trivial if resolution were advertised instead of scaleDenominator. Step two is made more challenging than necessary because of axis order issues with topLeftCorner (I'll open a separate issue for that). Step three is handled well by both specs (confusion about the proper case for things like tileMatrix and TileMatrix aside).

I understand that there is a lot of resistance to making changes like these. It does feel like this would be the time to at least consider it though. The nice thing about this approach (always thinking about minimizing dependencies for implementors) is that it doesn't take anything away from "heavier" implementations. For example, a "light" implementation could be put together with no dependencies on Proj, the EPSG database, etc. and work happily ignorant of SRS units and axis order. At the same time, a heavier implementation (that has access to things like Proj, the EPSG database, etc.) could still calculate scaleDenominator if it found that useful. In that way, resolution is a building block, while specifying that scaleDenominator be used is more of a hurdle.

[tschaub]

It is somewhat encouraging that someone saw value in adding "Pixel Size" to the "Common TileMatrixSet definitions" in Annex D of the TMS spec. My suggestion is to specify that services provide that value instead of the scale denominator.

If that value (whether named "pixel size" or "resolution") were required by the spec, clients wouldn't be required to determine the semi-major axis of the ellipsoid used in the datum for the tile matrix set's coordinate reference system. Nor would they need to know the conversion between the CRS units and meters. Instead, they could use the value directly in rendering or providing an interactive map interface using tiles. And as mentioned above, clients that do know those things could still calculate the "scale denominator" if they found that useful.

[cholmes]

A big +1 on enabling a 'light' implementation without needing any geospatial libraries or even really knowledge. If OGC API's can have simple, approachable cores that are easy to implement but then have all the 'on-ramp' to the depth of geospatial knowledge encapsulated in the OGC then I think it will be a big win for everyone. And those core, simple specs shouldn't have anything resembling a 'rite of passage'. Sure in extensions and complex stuff, but not for a first time implementor.

[jyutzler]

FWIW, GeoPackage uses pixel size but @jerstlouis encouraged me to add an optional scale denominator to a related extension. I think he should be the one to explain his justification.

[jerstlouis]

My arguments for sticking to scale denominator:

1. Scale is the traditional cartography concept
2. It is agnostic of the raster or vector nature of the data
3. It is what the approved Tile Matrix Set standard specifies
4. It is what the WMTS 1.1 standard specifies
5. Scale denominator are used in styling languages to select styling rules independently of a specific tile matrix set (e.g. SLD/SE, GeoCSS and GNOSIS CMSS)
6. There is a clear equivalence between the scale denominator and a pixel resolution with the assumption of 0.28 mm/pixels as documented in WMTS.

I did find screen sizes quite close to 90.7 pixels / inch on that page, and I think they are still average today for many computer monitors (there seems to be a lot more mobile devices than computer displays on http://screensiz.es/, and most affordable 23" display probably have a 1080p resolution):
Dell UltraSharp U2412M 24" 1920x1080: 94
Dell S2340M 23" 1920x1080: 96
Dell UltraSharp UZ2315H 1920x1080: 96

However, if the arguments for making the change is that it would encourage more flexible and accurate representation of scales, based on the facts that devices these days vary a lot in resolution, then it may be worth re-considering this. The scale is after all something that varies with how you present things, and is not inherent to the data, while the pixel resolution is.

What should be crystal clear is that a "pixel resolution" does not imply that the data is raster-based, and that vector geometry can be generalized as intended to be rendered at that pixel resolution.

Any change would likely require amending the Tile Matrix Set standard. If that is done, I suggest it is made extra clear how to compute the traditional WMTS scale denominator, how a pixel resolution also applies to vector data, and how the WMTS 1.1 and original TMS 1.0 standard was based on 0.28 mm/pixel assumption.

Another thing to keep in mind is that even the pixel resolution is most often only valid at the equator, so the accuracy argument is limited (should that also be clarified, e.g. pixelResolutionAtEquator?).

[tschaub]

Thanks for weighing in, @jerstlouis.

Yes, it is true that there is a relationship between scaleDenominator and resolution. My point is that resolution is what is needed to render tiles (which is what I think a tiles spec should have primarily in mind) and understanding the relationship to scaleDenominator involves what should be optional dependencies.

Rephrasing in case it isn't clear:

• If you require that servers advertise scaleDenominator (and not resolution), you require that clients depend on additional software or services to calculate resolution.
• If you require that servers advertise resolution, clients that want to calculate scaleDenominator for some reason can take on the additional dependencies to do so.

And yes, my definition of "resolution" doesn't imply geodesic calculations. It is literally "projected map units per pixel" - these are planar. A rendering client only needs to apply an affine transform to scale, translate, rotate tiles on a planar display if they know the pixel resolution by this definition. These clients only need to do geodesic calculations if they want to let users measure approximate distances etc. These are not "core" requirements for a tiled map client. Rendering, I would argue, is a core requirement.

[tschaub]

Here is a bit more of a writeup that I hope clarifies instead of confuses: https://github.com/tschaub/tilet/blob/master/readme.md (this was just an exercise to demonstrate how simple a tile rendering client could be if the spec didn't impose unnecessary dependencies).

[spatialillusions]

Has anyone been thinking about physical pixels on a display vs logical pixels?
I can't figure out if it will be possible to as for tiles in a @2 or @3 way similar to https://docs.mapbox.com/api/maps/#retrieve-raster-tiles in OGC API Tiles. It would be really useful for high dpi screens where you otherwise would get tiny tiny labels on your raster tiles, or quite blurry maps.

[joanma747]

Annex D of 2D-TMS exposes 2 columns one for pixel size (so called "resolution" next to the scaleDenominator.
Historically we use scaleDenominator and 0.28 because WMS 1.1-1.3 and SLD uses it. We wanted to be consistent with it.

Pixel size is a "true" for all devices that are directly using "one pixel in the viewport"="one pixel in the tile". This is "one way of doing this" but not necessarily the only one.

In the WMS meeting 2020/08/06 we make a motion:
"We will add "Pixel Size" in projected coordinates (as defined in 2D TMS standard) to the TileMatrix description (UML, XML and JSON encodings). Both Pixel Size and ScaleDenominator will be required
Moved by Jeff Harrison
Seconded by Jerome St.Lou
Discussion: Name? Resolution, Projected Pixel Size,
NOTUC

We will close the issue when this is applied to 2D TMS.

[joanma747]

We recognize that there is a "true resolution" ("ground" resolution) of the data and we expect the API Common will address or provide that in the description of the collection (included in part 2)

[tschaub]

Good to hear that resolution will be required (with this or some other name). Thanks for considering the minimal client / no dependency case.

[cholmes]

Any movement on this? Getting it in the spec? This is a really great decision, would be good to get it published, so that OpenLayers can get add this as a new tile source, and people can start to build simpler implementations.

[joanma747]

Action for the editor: add "cellSize" to tilematrix as well as in TileMatrixSetLimits. Both are mandatory

[joanma747]

I took some time but this is finally done everywhere in the document schemas and examples.

[tschaub]

Thanks for the update, @joanma747.

[tschaub]

For anybody else who may be reading, I'm wondering if changes to the spec like this (adding cellSize or the change to pointOfOrigin and cornerOfOrigin) are being implemented by anybody as they are being specified.

See also opengeospatial/ogcapi-tiles#74