Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop landuse labels based on area #1028

Closed
pnorman opened this issue Oct 7, 2014 · 29 comments · Fixed by #3764
Closed

Stop landuse labels based on area #1028

pnorman opened this issue Oct 7, 2014 · 29 comments · Fixed by #3764

Comments

@pnorman
Copy link
Collaborator

pnorman commented Oct 7, 2014

#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
image
[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
Copy link
Contributor

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
Copy link
Collaborator

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
Copy link

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
Copy link

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
Copy link

23cpo commented Oct 9, 2014

Another example of overloaded label rendering is military=danger_area:

dangerarea

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
Copy link
Contributor

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
Copy link
Collaborator Author

pnorman commented Oct 9, 2014

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
Copy link
Collaborator

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
Copy link
Owner

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
Copy link
Collaborator

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
Copy link
Owner

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

@matthijsmelissen
Copy link
Collaborator

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
Copy link
Collaborator Author

pnorman commented Mar 1, 2016

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
Copy link
Contributor

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

@matthijsmelissen
Copy link
Collaborator

Thanks a lot!

@matthijsmelissen
Copy link
Collaborator

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
Copy link
Contributor

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
Copy link
Collaborator

matthijsmelissen commented Aug 5, 2016

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

@springmeyer
Copy link
Contributor

springmeyer commented Aug 5, 2016

@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
Copy link
Collaborator

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

@kocio-pl kocio-pl added the text label Dec 15, 2016
@pnorman
Copy link
Collaborator Author

pnorman commented Dec 15, 2016

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
Copy link
Collaborator

matthijsmelissen commented Dec 15, 2016

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 kocio-pl self-assigned this Dec 15, 2016
@kocio-pl
Copy link
Collaborator

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
Copy link

Tomasz-W commented Jul 3, 2018

Related to #3284

@matthijsmelissen
Copy link
Collaborator

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

@jeisenbe
Copy link
Collaborator

@matthijsmelissen are you planning to do a PR?

@matthijsmelissen
Copy link
Collaborator

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

@sommerluk
Copy link
Collaborator

Closed in #3764

@jeisenbe
Copy link
Collaborator

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:
z15-belfast-international-before-waypixels-524418

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
z14-belfast-city-airport-waypixels-35864

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.
z16-bandar-udara-oksibil-inspector-way_pixels-35973

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.