dpi dependant scaling

[Tobias]

As my favorite app that supports mapsforge (Oruxmaps) has now a beta which is based on 0.4, I found some issues with dpi dependant scaling:
- It's always assumed that a theme is made for 160dpi. My theme is made for 240dpi (with 320dpi and 480dpi variants), but is scaled of course on a 240dpi device. Maybe we need a base-dpi tag in the theme so that it's not blown up out of proportion?
- This is also a reason that I think this should be configurable by the user, as font multiplicator. Some users like it bigger, some smaller.
- Consistency with other maps is broken.The zoom number used to be the same at all maps for the same visible screen area, so if for example I want to compare an offline mapsforge map with an online satellite map and switch, it isn't showing the same area anymore (at the same zoom).
- What is seen on tiles or rendered with the theme is dependend on zoom-appear in the map or zoom-min in the theme. Even when I can use a different zoom factor to see the same part of the map on the screen I'm not able to see the same details.
For the last two issues: maybe with dpi dependant scaling the zoom number should also be scaled, but I don't know if that makes any sense.
Best regards,
Tobias

[Ludwig]

- This is also a reason that I think this should be configurable by the user, as font multiplicator. Some users like it bigger, some smaller.

This is already the case, the tile size is computed both from the device scale factor and the user scale factor. The user scale factor can be set by an application (and thus by a user if the app decides to give this a configuration setting). (See DualMapViewerWithDifferentDisplayModels in Samples).

- Consistency with other maps is broken.The zoom number used to be the same at all maps for the same visible screen area, so if for example I want to compare an offline mapsforge map with an online satellite map and switch, it isn't showing the same area anymore (at the same zoom).

The zoom factor is an abstract concept: at zoom 0 the world is one tile, at zoom 1 the world is 2x2=4 tiles, etc. That is the key assumption of any tiling mechanism, the tile size is not fixed (event though the standard is 256). So tile numbers are actually the same (give and take numbering conventions), even if their sizes are not. If you wanted to introduce more tiles for the same zoom level you will break this. (We are actually constraint also by the map file tiling mechanism).

On an actual device we are actually closer to displaying the same information on the actual area by changing the tile size, obviously if you look at the tiles pixel-by-pixel not. 

If you look at maps downloaded with a fixed tile size (like standard OSM tiles), they have the problem that they are either too small when viewing them on a high dpi device or lack sharpness when scaling them up. 

 

Hope that makes some sense.

Ludwig

[Emux]

- It's always assumed that a theme is made for 160dpi. My theme is made for 240dpi (with 320dpi and 480dpi variants), but is scaled of course on a 240dpi device. Maybe we need a base-dpi tag in the theme so that it's not blown up out of proportion?

I think it starts from the fact that 160dpi is the baseline density assumed by the Android.
Anything below or above is considered with multipliers.

Also a theme should be able to be used at 160dpi, as the tablets with HD resolution.

- This is also a reason that I think this should be configurable by the user, as font multiplicator. Some users like it bigger, some smaller.

What property do you mean as configurable?
The tile size is already configurable e.g. Samples.

- Consistency with other maps is broken.The zoom number used to be the same at all maps for the same visible screen area, so if for example I want to compare an offline mapsforge map with an online satellite map and switch, it isn't showing the same area anymore (at the same zoom).
- What is seen on tiles or rendered with the theme is dependend on zoom-appear in the map or zoom-min in the theme. Even when I can use a different zoom factor to see the same part of the map on the screen I'm not able to see the same details.
For the last two issues: maybe with dpi dependant scaling the zoom number should also be scaled, but I don't know if that makes any sense.

I understand what you're meaning and it depends with what we want to compare with, other raster maps?
This has to do with the variable tile size that mapsforge now supports.
The standard 256x256 px is used at 160dpi, at other densities the tile size is different.
e.g. at 240dpi the tile size is 256 * (240 / 160) = 384 px
So everything draws larger: roads, buidling, labels etc.
But still it's not mandatory, developer can have tile size as variable in its app.

We have to consider that we're speaking about vector maps and their versatility to change their drawing.
Raster tile sources like Mapnik are difficult to read at HD devices as they have fixed tile size 256.
At the same zoom level a raster tile source and a vector one with the current implementation will have different viewable range.

--
Emux
Cruiser - Atlas

[Emux]

This is already the case, the tile size is computed both from the device scale factor and the user scale factor. The user scale factor can be set by an application (and thus by a user if the app decides to give this a configuration setting). (See DualMapViewerWithDifferentDisplayModels in Samples).

Or you can change the tile size at Samples settings with the "Display Scale".
Then at "Tied MapViews MapDB/Mapnik" example you'll see vector and raster to use the same tile size.

Eventually we should consider the case that the zoom level to become float instead of fixed byte values.
This could work better with vector than raster maps where there is blurring at intermediate zooms.

[fzk]

I see a trend for displays with higher resolutions:

Tablets:

Nexus 7 (2012), 7 Zoll, 1280*720, 210 ppi

Nexus 7 (2013), 7 Zoll, 1920*1200, 323 ppi

Smartphones:

Nexus 4 (2012), 4.7 Zoll, 1280*768, 318 ppi

Nexus 5 (2013), 4.95 Zoll, 1920*1080, 445 ppi

I think the library has to handle the impact that the difference between 210ppi and 445ppi implies. In other words: Scaling (eg. the width of lines) must be done automatically by the library. Fixed bitmaps (icons) are a problem. Scaling makes them ugly. But here comes SVG with the possibility of lossless scaling. Right?

Questions:

- How is scaling handled yet?

- Where are the problems now?

- What is planned in order to solve the problems?

- And what has to be done by the library integrators?

Cheers Klaus

[Emux]

And there is also the new trend with QHD devices > 500 ppi !

As I remember at mapsforge 0.3.X we could change the text size.

From 0.4.X there are more ways to handle the device scale:
- Variable tile size (affecting all graphics as analyzed at previous post)
- Variable text size
- SVG symbols (default size at 160 dpi is 20x20 px)

Also there has been a refactoring in the code to have more elements scaled based on device dpi,
like various render theme properties, scale bar etc.

[Tobias]

Am Freitag, 20. Juni 2014 12:13:17 UTC+2 schrieb Ludwig:

- This is also a reason that I think this should be configurable by the user, as font multiplicator. Some users like it bigger, some smaller.

This is already the case, the tile size is computed both from the device scale factor and the user scale factor. The user scale factor can be set by an application (and thus by a user if the app decides to give this a configuration setting). (See DualMapViewerWithDifferentDisplayModels in Samples).

Great, thanks, I didn't look at Samples for that. Other apps I tried didn't have that implementation.

Hope that makes some sense.

It does, thanks. But as it used to be the same tile size for every map including mapsforge, it used to be an equivalent to a map scale, which made it easier for the user to compare maps. Maybe raster maps should be automatically scaled too.

No matter what - zoom level is used in the maps and in the themes with zoom-appear and zoom-min, and this is affected by different tile sizes, which can be problematic.
I think that tile resizing for different displays is a good thing, but there are some implications which change previous behaviour.

Am Freitag, 20. Juni 2014 12:14:48 UTC+2 schrieb emux:

I think it starts from the fact that 160dpi is the baseline density assumed by the Android.
Anything below or above is considered with multipliers.

Also a theme should be able to be used at 160dpi, as the tablets with HD resolution.

But if a theme is designed for a different dpi, wouldn't it make sense to put that dpi in the xml so that the map is scaled accordingly?
 

[Emux]

Maybe raster maps should be automatically scaled too.

They can be scaled, but it's better to let the developer or user to decide what he wants.
See the "Downloading Mapnik" example and change the tile size with the "Display Scale" at Settings.
The raster map scaling can easily produce blurry graphics which are equally unreadable.
Eventually the tile providers have to start producing tiles at different sizes for the modern devices.

e.g. MapBox has already "retina" tiles for high DPI devices
You can try them at Cruiser Beta (comparing with Cruiser)