Label scaling incorrect with scale factor

[pnorman]

This is from Germany with scale-factor 6, the resulting image scaled by 1/6 to get a result which should look the same except for antialiasing, quality of rendering, and PNG patterns

On osm.org the label doesn't even get placed at that scale

At a 4x higher scale, this is what it looks like

cc @woodpeck

[imagico]

This is from Germany with scale-factor 6, the resulting image scaled by 1/6 to get a result which should look the same except for antialiasing, quality of rendering, and PNG patterns

Assuming that by scale-factor 6 you mean rendering at six times the normal resolution (scale factor to me usually means something different) that seems not quite correct since we make a lot of use of way_pixels for labeling and this i would assume varies with rendering resolution.

[pnorman]

Assuming that by scale-factor 6 you mean rendering at six times the normal resolution

scale factor is a mapnik parameter: https://github.com/mapnik/mapnik/wiki/Scale-factor

that seems not quite correct since we make a lot of use of way_pixels for labeling and this i would assume varies with rendering resolution.

I see a couple options

1. Use way_area directly. We used to do this, but it involves a lot of duplication with a selector needed for each zoom level. We might be able to simplify this if we can use the mapnik parameter zoom in a selector, but I don't think that's possible. @rory had to do something like this when adapting osm-carto to vector tiles

2. Alter the queries so their results do not depend on scale factor. This is my preferred approach, and what should have been done originally, but I don't think we adequately tested output for higher resolution devices.

[imagico]

The underlying cause for the whole mess seems to be that mapnik does not properly separate between map scale and rendering resolution. It makes sense for compact code in the style to normalize way_area with the map scale but it obviously does not make much sense to normalize with the rendering resolution if you want to be able to generate the same map scale in varying resolutions.

[matthijsmelissen]

Do we want to support scale_factor at all?

[pnorman]

Do we want to support scale_factor at all?

Yes, it's essential for print.

[woodpeck]

Essential for print, as @pnorman says, but the issue will already lead to distorted styling when you produce retina tiles.

[talaj]

I think that !pixel_width! and !pixel_height! should be corrected by scale_factor the same way Mapnik corrects scale denominator.

Mapnik has a reference resolution of 90.71 DPI. Scale denominators are calculated against this resolution. When you want to render retina tiles, for example, you have to say to Mapnik that you are going to render with two times bigger resolution (in one dimension) by scale_factor to allow Mapnik to correct scale denominator.

These two parameters should then be rather called !native_pixel_width! and !native_pixel_height! to emphasize they are calculated against 90.71 DPI.

[Tomasz-W]

@kocio-pl Is this issue still up to date after last Mapnik update?

[kocio-pl]

I don't know about rendering scaling problems.

[imagico]

Should be fixed by #3657.