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

[WIP] Unify dasharray-based highway=* rendering #4771

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

sommerluk
Copy link
Collaborator

Unify dasharray-based highway=* rendering

Currently, we have a couple of highway=* values for which we use a dasharray-based rendering: bridleway, cycleway, footway, path, track, steps. Steps is a special case.

We have many different dasharry patterns which are difficult to distinguish. Furthermore, they do not represent the same secondary tags on different primary tags: on trank, it’s six different values for tracktype (one for each tracktype and “no value”), on bridleway it’s nothing, and on footway and cycleway, it’s three different values for surface (upaved, unpaved, no value). That’s highly confusing. Having so many pattern makes them difficult to distinguish.

We could try to unify the other dasharray-based renderings:

  • Use only three different patterns on all these values: paved, no value, unpaved.
  • Use the same line width (on the same zoom level) on all these highways.
  • Use exactly the same pattern values on all these highways.

This would also simplify our code base. It would also be conforming to what we do yet on roads (paved/unpaved as secondary tag). This would make the map more readable.

The question is if a unified line width would work well-balanced when some colors like red (footway) or blue (cycleway) get more attention than brown (track).

Fixes #4322
Closes #4692 (mutually exclusive)

This isn’t a ready-made PR, but rather a sort of mock-up for discussion, if this approach could work.

Test rendering with links to the example places:

Before
old

After
new

@imagico
Copy link
Collaborator

imagico commented Jan 19, 2023

Some comments:

@pnorman pnorman marked this pull request as draft January 19, 2023 20:05
@sommerluk
Copy link
Collaborator Author

@imagico Given that you have implemented this yet in your style, and it seems to work fine, could you make a PR?

@imagico
Copy link
Collaborator

imagico commented Jul 31, 2023

I am not sure we have consensus to get rid of the purple boundaries. Previous discussion on this was non-conclusive - see #3489.

Also note that in the AC-Style i stopped rendering nature reserves. I have also been thinking of in addition also not rendering subnational boundaries any more. This would put a much clearer focus in the map on the verifiable geography.

If there is consensus now to move anything that cuts this Gordian knot in terms of colors that would make the AC-style road color changes feasible i would gladly make a PR.

@dch0ph
Copy link
Contributor

dch0ph commented Dec 30, 2023

[matching screenshots at Z16]

image

image

More to provide food for discussion rather than proposing this as a solution, here's a take on unified dash patterns. This uses casing dash patterns to show tracktype and unifying highway=service (minor) and highway=track (both involve two-axled vehicles after all). [This allows legal state (e.g. the red dashing for public footpaths) to be shown, where a track is also a right of way.] Paths / footways are then brown dashed (with the same scheme, just different colours, for bridleways and cycleways).

This does involve a fair bit of lua wrangling to generate a proxy tracktype (which determines the dashing), typically from surface. Default dashing is used when a tracktype is not obvious, avoiding the need for an "unknown" styling.

Overall the style reflects UK Ordnance Survey mapping, and so may not translate well to other places.

Note the lack of purple admin boundaries!

@imagico
Copy link
Collaborator

imagico commented Dec 30, 2023

Without knowing exactly what the different line signatures in your example are meant to depict - a dashed casing is not going to work because we already use that for our tunnel rendering.

@dch0ph
Copy link
Contributor

dch0ph commented Jan 3, 2024

Sure, it would need to be part of an overall design:

image
(grey fill and short dash pattern used for tunnels)

compared to:
image

Personally I find the former easier to "read" (agricultural track passing under a railway line, with highway=path leading off).

As stated, I'm not proposing this as a way forward, just noting that a coherent design is possible.

@imagico
Copy link
Collaborator

imagico commented Jan 3, 2024

Just to make this clear: Showing a mock-up of a design idea in a very specific context at a specific scale is not a demonstration that this is a workable approach in general.

In any case this is the wrong place for such a suggestion.

Exploring new design concepts to improve our rendering of roads would be valuable. But because of the large number of design variants, the very diverse geometric contexts this needs to work in and the need to maintain an intuitive level of consistency across the whole road system this is not an easy matter.

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

Successfully merging this pull request may close these issues.

Stop rendering tracktype for highway=track
3 participants