[MapProxy] MapProxy Seeding in a certain scale

Thu Aug 8 03:04:08 PDT 2013

Hi all,

> Scale is always dependent on the output device (100dpi LCD? 200dpi Smartphone? 300dpi plot?). Convert the scale with your expected dpi value to a resolution and use this value.

TL;DR
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 [1]. 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 [2], 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 [8] and they take the PPI value to new levels 
[3]:

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 [4] 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 [5] which correlates to 90.7 
DPI. A pixel on the iPhone 5 for example is actually 0.0779 mm * 0.0779 
mm [6].

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 ;-) [7] 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 :-)

Frank

[1] https://en.wikipedia.org/wiki/Pixels_per_inch
[2] 
http://documentation.apple.com/en/motion/usermanual/index.html#chapter=B%26section=5%26tasks=true
[3] https://en.wikipedia.org/wiki/List_of_displays_by_pixel_density
[4] 
http://appleinsider.com/articles/12/03/13/applecom_upgrading_to_high_resolution_images_ahead_of_retina_ipad_launch/
[5] http://hub.qgis.org/issues/6430
[6] 
http://stackoverflow.com/questions/610193/calculating-pixel-size-on-an-iphone
[7] 
http://mapbrief.com/2013/05/14/pdf-sharing-is-not-data-sharing-a-public-service-announcement/
[8] 
http://www.brandwatch.com/2013/06/smartphone-and-tablet-use-continues-to-rise-the-stats/

-- 
Frank BRONIEWSKI

METRICO s.à r.l.
géomètres
technologies d'information géographique
rue des Romains 36
L-5433 NIEDERDONVEN

tél.: +352 26 74 94 - 28
fax.: +352 26 74 94 99
http://www.metrico.lu