Stop landuse labels based on area

[pnorman]

#941 gave us labels which start rendering based on area.We should be doing the counterpart to this and stop rendering when an area gets too big.

As one of the more extreme examples, http://www.openstreetmap.org/#map=19/39.18521/-96.81765

[Continued in all directions]

From that zoom, I have to zoom out 5 times (128x) to see a boundary, meaning placing text in the middle is rather meaningless. I have a 1080p screen, so most people will be 5 or 6 times.

A few options

• Stop rendering labels based on way_pixels
• Scale the label to very large, keeping it a reasonable percentage of the overall size. Requires expr everywhere and Mapnik 3
• Repeat the label. Not technically trivial, and probably would cause issues in some other cases.

[matkoniecz]

I think that labels should be repeated (so it is not necessary to zoom n times to have name of some big area).

and probably would cause issues in some other cases

For example places covered by many big areas.

[matthijsmelissen]

Stop rendering labels based on way_pixels

I would prefer that, but I gave up after running into mapbox/carto#369 and mapbox/carto#370.

[daganzdaanda]

Wow, that is a big military area! I really like the large font at z=10. That area is bigger than Topeka!

I'm with @mkoniecz , "repeat".
Ideally, any viewport of a large area should have a label visible. I'm also thinking of huge forest areas or national parks or lakes.
But I can imagine that your concerns about that solution are well founded.

[mboeringa]

Although a repeating label would definitely be an option, I personally do not find it to disturbing here how the labelling is handled. People are so used nowadays to continuously zoom in and out on stuff, even on their mobile phones, that I don't think it needs to be an issue. Therefore, before making this a real issue and putting effort in it, maybe getting some outside opinion via the mailing lists, might be an idea.

[23cpo]

Another example of overloaded label rendering is military=danger_area:

http://www.openstreetmap.org/#map=9/54.4349/7.4130

But I don't like the idea to render labels more than once. I think that would look cluttered. Maybe it would look better if a non bold font is used for military=danger_area.

I think the rendering of landuse=military is not so bad. Maybe a smaller font-size would help in this case (similar font-size as the surrounding towns) or to define a max. font-size per zoomlevel.

[HolgerJeromin]

The idea was to render the label more than once, but with a really big distance only at a high zoom. For example with a distance of about 2000 px.
So with a normal screen (horizontal size below 2000 px) you would only see one label at most. So it is easy to find the label but with no possibility to look cluttered.

The problem with the data of these "danger area" is, that they are only one month in a year valid...

[pnorman]

I think the rendering of landuse=military is not so bad. Maybe a smaller font-size would help in this case (similar font-size as the surrounding towns) or to define a max. font-size per zoomlevel

You seem to be talking about issues unrelated to this ticket, which is about handling labels when an object is much larger than any reasonable viewport

[matthijsmelissen]

A solution for the Carto bugs that prevented doing this (mapbox/carto#369 and mapbox/carto#370) have been merged today.

Solving the issue here would imply that we need to require the tileservers to run the latest Carto version. @gravitystorm @pnorman Any opinions on this?

[gravitystorm]

I want to ensure that this style can be run on a variety of systems, such as tilemill and kosmtik. So I certainly don't want to depend on anything that is in an unreleased version of carto, and I'd prefer to wait until kosmtik has a release containing that version of carto too (ideally Tilemill but that seems unlikely).

Of course, the OSMF tileservers are a separate task, but after a carto release that should be straightforward.

[matthijsmelissen]

I'd prefer to wait until kosmtik has a release containing that version of carto too (ideally Tilemill but that seems unlikely).

Would that involve more than bumping the carto version in package.json in both respective projects?

[gravitystorm]

I don't know exactly what's involved, tbh.

[matthijsmelissen]

Confirmed that changing the node version in kosmtik can simply be accomplished by changing the version number in package.json and running npm install from the kosmtik directory.

In Tilemill, it should work likewise. Could somebody running Tilemill confirm that?

[pnorman]

We need

• a carto release with the new code
• a kosmtik release requiring the new carto
• a tilemill release requiring the new carto
• new tilemill binaries

[nebulon42]

carto 0.16.0 has been released. Kosmtik PR pending merged (kosmtik/kosmtik#121).

[matthijsmelissen]

Thanks a lot!

[matthijsmelissen]

a carto release with the new code
a kosmtik release requiring the new carto
a tilemill release requiring the new carto

These we have got now.

new tilemill binaries

What is the situation here? Is there any chance somebody is going to create new binaries?

[nebulon42]

Just to be exact there hasn't been a new Tilemill release. The last one was in 2012.
I think you have to ask @springmeyer if he would be so kind to provide binaries.

[matthijsmelissen]

Correct, a pull request has been accepted for Tilemill requiring the new carto version, but no release has been made.

[springmeyer]

@math1985 @nebulon42 - can you use TileMill master? Iv'e been keeping that passing (along with keeping binaries published and update to date for the hard to install deps like node-mapnik). The idea is that you can install like https://github.com/mapbox/tilemill#installation.

[kocio-pl]

I guess we are now old dependencies free and we could use label repeating?

[pnorman]

The issue @math1985 ran into were bugs with selectors when trying to stop labels from rendering at high zooms. He was exploring the first of the three options in my original post

I have no idea which of the original three is the best way to solve this issue, and that's hard to say without exploring what it looks like when implemented.

[matthijsmelissen]

As far as I know this problem has indeed been resolved in carto, so I think it'd be good to implement this now.

[kocio-pl]

Not that I plan to test it any time soon, because I see some other tasks as more important, so please don't hesitate if you want to do it yourself.

[Tomasz-W]

Related to #3284

[matthijsmelissen]

Now carto 0.16.0 is out, I think this should be a fairly simple fix.

[jeisenbe]

@matthijsmelissen are you planning to do a PR?

[matthijsmelissen]

Not at the moment, but it shouldn't be too hard, so feel free to try!

[sommerluk]

Closed in #3764

[jeisenbe]

Thanks @sommerluk.

One issue that is now apparent: aeroway=aerodrome, which last renders at z13, does not usually follow the example set in #3764. Now other features drop the text label at >768,000 way_pixels.

Some aerodromes are still mapped as nodes, so we shouldn't rely on waypixels. But examining the large, high-lattitude airports which are mapped as areas shows that z14 is far too soon to stop rendering aerodromes.

Here's Belfast International, a major airport in a rural area far from the city which takes up a large surface area. Since it's at 56 degrees north, it's almost twice as large on-screen as similar sized airports at the equator; it's bigger than the vast majority of aerodromes with an ICAO and IATA code.

But at z15 it's still only at 524000 way_pixels, so it ought to still render at z14 and z15:

Belfast city airport is also a large, major airport with a full-length runway at high lattitude, but it only hits 36,000 way_pixels at z14, so it should render till z16 (576k waypixels). Note that there is no icon or text currently rendered at z14

Smaller aerodromes should render till z17, especially near the equator. This one is actually a commercial airport with several passenger flights every day, with turboprop planes. Waypixels = 36,000 at z16, so could render even at z18.