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

Enabling Rendering Support for Narrow Roads #4948

Open
cmoffroad opened this issue Apr 3, 2024 · 3 comments
Open

Enabling Rendering Support for Narrow Roads #4948

cmoffroad opened this issue Apr 3, 2024 · 3 comments
Labels

Comments

@cmoffroad
Copy link

cmoffroad commented Apr 3, 2024

Background

While OSRM facilitates routing through narrow roads, many rendering engines like openstreetmap-carto still lack support for visually representing them.

As a result, mappers have been misusing alternative tags (e.g., service=alley) to influence the renderer, reminiscent of past practices such as re-tagging of unpaved roads as highway=track.

Enabling the rendering of narrow roads not only resolves this longstanding issue but also incentivizes mappers to correctly tag features such as lanes and other pertinent attributes.

Solution

I reckon having different rendering categories for narrow roads might be complicated visually. So, my suggestion is to start by reducing the width of the geometry by e.g 50% when lanes=1.

Additionally, we could explore supporting additional conditions such as:

  • !lanes + lane_markings=no
  • narrow=yes
  • width<=3 or width<=4

Looking forward to receiving feedback from the community. Let's work together to improve rendering support for narrow roads 😃

@imagico
Copy link
Collaborator

imagico commented Apr 3, 2024

Overall, our depiction of roads and the classifications we display is primarily functional and not physical. That is not set in stone and a good argument could indeed be made to transit from a functional classification to a - partly or fully - physical characterization at the higher zoom level. This is also common in many traditional paper maps.

We have discussed - and ultimately decided against - ground unit rendering in general a long time ago in #1290/#1853. That makes the mentioned idea practically impossible. I would welcome revisiting that decision. But it should be clear that this would involve substantial complexity in the style. There is no native support for this in any of the tools we use (and neither in any other commonly used automated map rendering tools i know of btw.) - so we would need to do all of this by hand. #1853 gives a bit of an idea what this entails.

The idea that shines through in the suggestion to just universally reduce the line drawing width of roads classified as narrow by a fixed factor would not work well. We use different line widths on white roads for functional classification:

  • highway=tertiary
  • highway=unclassified/highway=residential
  • highway=service
  • highway=service + service=driveway (or other minor service roads)

Intermixing that with a line width variation based on physical characterization would be highly confusing.

Visualizing lanes at high zoom levels is a different matter - but would of course work better in combination with ground unit rendering. How this could look like was shown here.

Related to #1290, #1853, #3795.

@imagico imagico added the roads label Apr 3, 2024
@cmoffroad
Copy link
Author

@imagico, much appreciated for providing all the explanations and context!

Overall, our depiction of roads and the classifications we display is primarily functional and not physical. That is not set in stone and a good argument could indeed be made to transit from a functional classification to a - partly or fully - physical characterization at the higher zoom level. This is also common in many traditional paper maps.

I'm on board with your point, and having unpaved surfaces (#3399) demonstrates the importance of both functional and physical attributes at higher zoom level.

The idea that shines through in the suggestion to just universally reduce the line drawing width of roads classified as narrow by a fixed factor would not work well. We use different line widths on white roads for functional classification:

  • highway=tertiary
  • highway=unclassified/highway=residential
  • highway=service
  • highway=service + service=driveway (or other minor service roads)

Intermixing that with a line width variation based on physical characterization would be highly confusing.

What was the underlying rationale for grouping various highway classifications under the same color?

Visualizing lanes at high zoom levels is a different matter - but would of course work better in combination with ground unit rendering. How this could look like was shown here.

Amazing work! I'd be thrilled to see some of these proposals incorporated!

I was actually curious if there are alternative ways to visually represent lanes, and it seems like you've already found a solution: ;)

image

@imagico
Copy link
Collaborator

imagico commented Apr 7, 2024

What was the underlying rationale for grouping various highway classifications under the same color?

The principal limitations in the number of colors that can be clearly discerned while forming a consistent and intuitive color scheme and being distinct from the other colors in the style. We discussed this quite in depth back when the current color scheme was developed.

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

2 participants