A post on the #Mapproxy
mailing list (http://osgeo-org.1560.x6.nabble.com/MapProxy-Seeding-in-a-certain-scale-td5071082.html
) came up concerning scales in raster maps. I think this concept is heavily broken:
The scale isn't the scale and a screen doesn't have dots so it doesn't have DPI. Don't do scale dependant calculations on fictional units.
This whole scale and DPI thing related to scale calculations is something that bothers me for quite some time already. It's actually a difficult topic and in most of the cases I think we're making the wrong assumptions all the time.
The DPI setting is something that appears in almost all mapping software for years already. I know Mapserver, Mapnik, Mapproxy, OpenLayers and Leaflet have settings for this or assume a certain default value. Mostly this value ranges from 72 to 91 to 96 and expresses also an evolution in screen resolution from CRT to TFT and even further to those nifty highres devices we carry all around with us - or maybe not all of us ;-).
I don't know what you are doing with your maps regarding the output format (I'm speaking of screen vs. paper), but I think it is safe to assume that at least users of Mapproxy and OpenLayers are targeting the screen and not the paper. And that's the crux of the matter - a screen doesn't have any dots. It doesn't have a DPI value at all! A screen has pixels, that's why there is a PPI unit after all . So it's not OK to assume that the screen as an output format has an arbitrary DPI value at all - because it hasn't.
I know everbody needs a good scale for a map and that is how we work with maps in relation to the real world - we use the scale. But when we are using maps on the screen things start to get complicated because screens have so different attributes regarding the number of pixels and their size. This makes them so different from paper output formats and relate them to the real world units we need for scale computations. And another thing: pixels aren't always square , so it's not safe to assume that you have the same scale in east and north direction of your map.
Let's talk about those nice tablets and smart phones out there. Their usage is rising enormously  and they take the PPI value to new levels :
Iphone: 326 PPI
Ipad: 264 PPI
MacBook Pro 13" Retina: 227 PPI
Kindle Fire HD 7": 216 PPI
Kinlde Fire HD 8.9": 254 PPI
Samsung Galaxy S4: 441 PPI
Samsung Nexus 10: 300 PPI
Have a look at the list and see for yourself. The always assumed 72 DPI is just plain wrong and its even getting wronger with every new generation of devices. This leads not only to problems concerning the content of the map you are serving  but also to problems with the scale you have in mind - because it isn't anymore the scale you think it is.
The OGC falls into the same pit, even if they think they're more clever. They define that a pixel is 0.28 mm*0.28 mm  which correlates to 90.7 DPI. A pixel on the iPhone 5 for example is actually 0.0779 mm * 0.0779 mm .
A raster map with 256px (your typical tile) has a OGC dimension of ~ 72 mm and a iPhone 5 dimension of ~ 20 mm - that's less than a third of the OGC dimension!
So when you say you deliver e.g. a map at a scale of 1:20.000 to your users you probably don't!
So what's the actual impact on your applications / maps with this wrong scale? I guess it would be OK if we would accept a certain DPI/PPI value as the default and take the scale as a ratio of real world units towards this default value. But not as the "scale" we're used to. Because then everyone is referring to the same ratio. But this isn't the case [5 again]. So what's happening is that your carefully selected and scale dependant cartography styles don't work anymore. You promise a map at a scale that you don't deliver.
So what to do then? Unless you don't want to deliver all your maps as a PDF document ;-)  I guess the resolutions are the way to go. Mapproxy has them, OpenLayers and Leaflet have them. Relate the pixel (your native output dimension on the scree) to ground units. Let the client do the scale calculation because he may know more about the real world dimensions of the device he's running on than your server does. But I think it would be best if we would avoid the scale at all in our maps when we output raster data - or we need to put a constraint on the map that relates another dimension to your map to make a scale valid. Because otherwise it isn't.
I'm sorry for this long post, but this is something that bothers me already for quite some time. Thanks for reading :-)