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

name of bridge is too prominent #2984

Closed
fgregg opened this issue Dec 15, 2017 · 27 comments
Closed

name of bridge is too prominent #2984

fgregg opened this issue Dec 15, 2017 · 27 comments

Comments

@fgregg
Copy link

fgregg commented Dec 15, 2017

This name of this minor bridge seems too prominent (Franklin Delano Roosevelt Memorial Bridge):

https://www.openstreetmap.org/#map=14/41.8893/-87.6121

screenshot-2017-12-15 openstreetmap

@kocio-pl
Copy link
Collaborator

What would you like to do with that problem?

@kocio-pl kocio-pl added the roads label Dec 15, 2017
@kocio-pl kocio-pl added this to the Bugs and improvements milestone Dec 15, 2017
@matkoniecz
Copy link
Contributor

From looking at the map it seems to be not a minor bridge - carries major road over quite big river/canal.

@kocio-pl
Copy link
Collaborator

We're rendering all the bridge outlines the same way, if I'm right. The only visible difference is if the name is short or long, not how big or important the bridge is.

BTW - I can't confirm the name of the bridge, could anybody show the source?

@fgregg
Copy link
Author

fgregg commented Dec 15, 2017

Here's the source for the name: http://chicagoloopbridges.com/bridges12/MS12/LSD12-1.html

@kocio-pl
Copy link
Collaborator

kocio-pl commented Dec 15, 2017

Tag name=* should contain the "common default name", not the official one (we have official_name for this). In this case it might be rather "North Lake Shore Drive Bridge", but this is not totally clear for me. But tagging is outside the scope of osm-carto and if there is no general rendering problem, we will close this issue.

@fgregg
Copy link
Author

fgregg commented Dec 15, 2017

I'd say that I expect that prominence of the name to be relative to the size of the area, as it seems to be true for many other areal features.

@kocio-pl
Copy link
Collaborator

I don't think longer/wider bridge needs to be rendered with bigger letters. We would need some classification of importance, but this is also tagging issue IMO.

@fgregg
Copy link
Author

fgregg commented Dec 15, 2017

I don't quite understand. If the name was "North Lake Shore Drive Bridge" it would still very visually prominent.

Are you saying you disagree that this is too visually prominent (I think that's a a reasonable view, I'm just trying to understand what you are saying)?

@kocio-pl
Copy link
Collaborator

I was trying to check if tagging should be changed to fix it. I think the name can be sometimes very long (both versions are 5 words long, instead of typical 2 or 3) and it's a local problem, like in this case. I don't see general rendering issue here.

@matkoniecz
Copy link
Contributor

not how big

It is considered. Label size scales with area of man_made=bridge object (tiny bridge will be rendered later than big one, this way one rule may be used for all kinds of man_made=bridge features - from gigantic to tiny footbridges across stream).

@matkoniecz
Copy link
Contributor

@fgregg are you sure that it is a minor bridge? How, in your opinion, label for bridge of this size should be displayed?

@fgregg
Copy link
Author

fgregg commented Dec 18, 2017

@matkoniecz I think it should scale with the area of the bridge. I think there's usually a relationship between the size of the bridge and the prominence as a landmark (I'm sure there are plenty of exceptions -- the Charles Bridge of Prague comes to mind as a small bridge but very important landmark).

As a local, this bridge is not a landmark that people know the name of. It is definitely less of a landmark than Navy Pier, Grant Park, Millennium Park. These are all features which are both larger than this bridge and which do not show a name at this zoom level.

Even if this a major bridge, there are 19 other bridges in downtown Chicago. They all have names and they would all have the same visual prominence as this bridge if they were added to the map.

@matkoniecz
Copy link
Contributor

matkoniecz commented Dec 18, 2017

I think it should scale with the area of the bridge

It scales with bridge area. Larger man_made=bridge areas have earlier and larger labels.

@kocio-pl
Copy link
Collaborator

Even if this a major bridge, there are 19 other bridges in downtown Chicago. They all have names and they would all have the same visual prominence as this bridge if they were added to the map.

So Chicago might be special, but here is somewhat close example with 3 named bridge outlines within ~300 m distance in Warsaw and it doesn't seem to me as too prominent:

https://www.openstreetmap.org/#map=15/52.2391/21.0378

London example with more such bridges also does not make me feel overwhelmed (while railway and ferry networks do):

https://www.openstreetmap.org/#map=15/51.5058/-0.1000

Rome is even less busy with 2- and some 3-line long bridge labels:

https://www.openstreetmap.org/#map=15/41.8969/12.4699

Do you know any place where there are many named bridge outlines and it looks too busy?

@fgregg
Copy link
Author

fgregg commented Dec 21, 2017 via email

@daganzdaanda
Copy link

Hm, I just noticed that we start showing the bridge names at z12. At that zoom, the name will only fit when there's a lot of open space / water around the bridge, like with the Golden Gate Bridge. More bridge names show up at z13, and this sometimes looks cramped or "uneasy" in cities. It might be because the label does not follow the direction of the bridge, so it looks like a suburb or other place label.
Maybe we should not start showing the name until z14 or even z15?
Or make the font size smaller at z13 (and z12), to reduce the visual impact?
Or use italics to differentiate from place names? Would that fit with our current use of italics?
Or could we make sure the name at z13 only shows up when there's more empty "buffer"?

@dieterdreist
Copy link

dieterdreist commented Dec 21, 2017 via email

@sommerluk
Copy link
Collaborator

The current code for the labels at

#bridge-text {
is

  [man_made = 'bridge'] {
    [zoom >= 12][way_pixels > 62.5] {
      text-name: "[name]";
      text-size: 10;
      ✂
      [way_pixels > 250] {
        text-size: 11;
        ✂
      }
      [way_pixels > 1000] {
        text-size: 12;
        ✂
      }
      [way_pixels > 4000] {
        text-size: 13;
        ✂
      }
      [way_pixels > 16000] {
        text-size: 14;
        ✂
      }
    }

and it seems to work well. The labels show up starting at way_pixels > 62.5 – independent (!) from the zoom level (but never before zoom >= 12). So on all (!) zoom levels, there is the roughly the same amount of free space and water (≙ way_pixels) around the labels that shows up on this zoom level.

All in all, the current behaviour regarding zoom levels and label text size looks fine to me. Note that until now, there has not been posted a screenshot showing a cluttered map. I’m quite sure that this won’t change either after @fgregg will have added the missing bridges in Chicago, because most of them will only show up on higher zoom levels because they are smaller.

It might be because the label does not follow the direction of the bridge, so it looks like a suburb or other place label.

Maybe. On the other hand, if it would follow the direction of the bridge, it might also be complicate to read…

Maybe we should not start showing the name until z14 or even z15?
Or make the font size smaller at z13 (and z12), to reduce the visual impact?
Or could we make sure the name at z13 only shows up when there's more empty "buffer"?

No. As explained above, the font size for bridges does not depend on the zoom level, but yet on way_pixels (the “buffer”). The currently smallest size is 10, and we should not go below this because of legibility. Also z12 is not too early for big bridges, maybe even z11 could be a good idea.

Or use italics to differentiate from place names? Would that fit with our current use of italics?

Most bridges are bridges over water, so mostly the bridge label will render also over water, and that makes it easier to differentiate from place names. But yes, it might be an option to switch to italics. Currently, we do no have a clearly defined policy the the usage of italics, so this would not “break” anything. It could be worth to try!

@sommerluk
Copy link
Collaborator

I also support the comment #2984 (comment) from @dieterdreist

@daganzdaanda
Copy link

When I wrote "buffer", I thought about a zone around the label, in which the displacement algorithm is triggered. Don't know how it works and if it would be possible to say that one kind of label will need more space around it to get shown.

@daganzdaanda
Copy link

Island labels are using italics - this could be a bit irritating if we were to try them for bridges, too.

@kocio-pl
Copy link
Collaborator

Italics are used for areas mainly, I would continue using standard font for bridges, since they are more or less linear features. We can however tune way_areas, font sizes and zoom levels if it's needed.

@matkoniecz
Copy link
Contributor

To do that we would need list of random places with description whatever rendering is too prominent, good or not strong enough.

@kocio-pl
Copy link
Collaborator

As for me, I haven't noticed the place where they are not strong enough yet.

If I was trying to tune it, I would rather make all of the label sizes small and universal (10 or 11 probably) and use only zoom levels to make the difference.

Another thing to see would be to check if we can make pedestrian and train bridges less prominent than general/car bridges (in this case train bridge should be not visible instead of general bridge on all the zoom levels).

@sommerluk
Copy link
Collaborator

If I was trying to tune it, I would rather make all of the label sizes small and universal (10 or 11 probably) and use only zoom levels to make the difference.

I do not think it is useful to show the labels of very big (currently z12) and very small (currently z18) bridges starting at the same zoom level. Showing the “Golden Gate Bridge” at z18 is yet pointless for orientation, and showing very small bridges like “Pont de Lokoa” at z12 also.

Also the current scaling of the font size (corresponding to the size of the bridge object itself) makes sense to me – like other features, where our rendering relies on way_pixels, bridges can typically vary extremly in size, so there is no single size that would fit all bridges.

Given that

  • no one has posted a screenshot of bad rendering so far
  • the original point of this issue was about adding more bridges in Chicaco what could make the map more cluttered, but the bridges have been added in the meantime to OSM and the map is not cluttered (because these bridges are smaller and show only up on higher zoom levels)
  • personally I think the current solutions works technically and typographically well

I think this discussion is kind of pointless and this issue should be closed.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Dec 22, 2017

I do not think it is useful to show the labels of very big (currently z12) and very small (currently z18) bridges starting at the same zoom level.

Well, this is not what I've proposed - I was talking about the same label size and different zoom levels.

There are only about 4 bridge outlines in Chicago right now. They are not all visible not only because of their size, but also because they're so dense, that their labels are in conflict, so only some of them will be visible on early zoom levels.

I think this discussion is kind of pointless and this issue should be closed.

If @matkoniecz thinks it's OK, it could be closed. Otherwise it should probably be renamed to something more general (like "Tuning rendering of bridge outlines").

@matkoniecz
Copy link
Contributor

Closing as it seems that label reverting is generally considered as ok and there is only one example of place where anybody considers it as too prominent.

Closing, may be reopened of there are more problematic locations.

Tell me if I am wrong here, I may be biased in this case.

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

No branches or pull requests

6 participants