Add track grade-based styling

[RudyTheDev]

This PR adds different style rendering to highway=track based on their tracktype:

This is similar to how Karto or OsmAnd or others render it - but here specifically changes only the casing dash pattern for grade2-grade5 and "ungraded". grade1 remains as is - matching current paved road style. Ungraded has an dot-dash pattern to indicate it's unknown.

The current track dash pattern is roughly between proposed 3 and 4, which is sort of the median of grade values.

The actual values are like this:

paved/grade1:   solid (this is current use)
track grade2:   10, 4
track grade3:   6, 4
unpaved roads:  4, 4 (this is current use)
track grade4:   4, 6
track grade5:   2, 8
track ungraded: 7, 5, 3, 5

I experimented with a bunch of different layouts and ended up with the example above, which is roughly a linear progression from paved to grade5. It's basically a couple pixel difference, so there isn't much leeway for uniqueness. I played around with some ideas, but I don't think there's a lot of different ways to do it better. Changing main line/stroke looks weird and clashes with life-cycle rendering. Changing colors is not obvious what they mean and is way too distracting. Casing is already used for surface differentiation, so that seems to work best here. Adding line dash pattern looks like it's a crossing or railway or something, but it could also be an option. Perhaps the casing could be a bit lighter and more contrasted. And the dash patterns could be different.

I did not add unique low-level zoom variants, because I think it works fine as-is. I don't think adding even more dash patterns makes anything more legible. If anything, tracks are mostly found in wide expanses of forests and fields, so having them distinguishable at lower zooms is arguably even more useful.

Implementation-wise I added a bit of code to detect an ungraded track, so that the CSS doesn't need an excessive amount of cases and conditions and can specify it in one block.

There are a bunch of other variants and combinations that might be of interest:

There are technically a few dozen different combinations of tags. But I didn't even attempt to come up with unique variants for these, because most of them are either wrong or ambiguous and don't have an obvious expected rendering. Basically, the above examples cover most valid common cases that I can think of and the rest are incorrect or incomplete tagging.

The only part I'm not so sure about is embankment rendering:

These look weird to me at first glance. But then again, embankments look weird on other roads too:

There isn't an exact style for embankment color and pattern that I can see - they seem to be based directly on the casing pattern. I believe this is a rendering limitation? In any case, I don't know that there is anything I can do about it. I'm only concerned here because tracks are commonly embanked, so this might be worth considering further.

No LLM code.

[RudyTheDev]

Here's an example location with a bunch of differently-graded tracks: https://pr-12392--ideditor.netlify.app/#map=16.00/53.1318/13.0282

[tyrasd]

This looks good, thanks.

Maybe tracktype=grade1 should get the thin outline in the same color as the other tracktypes, to make it consistent across all grades?

For the unknown state, I found the pattern looks a little bit too much "chopped". I found that stroke-dasharray: 7, 3, 3, 3, 3, 3; looks a little bit better while still conveying the meaning of “could be any grade”.

embankment rendering

Yeah, that rendering really not ideal (in general). See #12396 for a possible improvement on that, which should also benefit this PR. Let me know what you think.

[tyrasd]

There are a bunch of other variants and combinations that might be of interest

Yeah… there's also the case of e.g. surface=paved + tracktype=grade2 (which could make sense maybe, e.g. really poor condition concrete surface or so). Should we not just simplify this even further, and for highway=track only look at the tracktype for rendering? That might also fix #10780 if I see it correctly.

[RudyTheDev]

Maybe tracktype=grade1 should get the thin outline in the same color as the other tracktypes, to make it consistent across all grades?

Hmm, perhaps? I left it alone because while it would be consistent between track grades, it would be inconsistent with other paved roads. I guess here's some comparisons:

If it's okay to change, then I agree being cased white is better to make it more consistent.

Yeah… there's also the case of e.g. surface=paved + tracktype=grade2

Yeah, that's the sort of semi-ambiguous stuff I mean. Like, in theory we could also pick color based on surface but dash pattern based on grade. I tried it briefly, but you really have to "push" dash patterns and casing color/thickness to make it visible enough:

And I'm not sure this is the way to go.

Should we not just simplify this even further, and for highway=track only look at the tracktype for rendering?

If it's fine to have grade1 ignore generic surface styling, then I suppose we might as well have tracks only styled by grading.

For the unknown state, I found the pattern looks a little bit too much "chopped". I found that stroke-dasharray: 7, 3, 3, 3, 3, 3; looks a little bit better while still conveying the meaning of “could be any grade”.

Yeah, that looks good too. My intention here was to make it really obvious that it's missing a grade, so being "choppy" was intentional. May be a little less "compressed" because it kind of blurs together at a quick glance?

Yeah, that rendering really not ideal (in general). See #12396 for a possible improvement on that, which should also benefit this PR. Let me know what you think.

Yeah, that would be ideal if embankments were a separate "layer". I'll comment there. I won't touch anything embankment-related for this PR then.

[RudyTheDev]

Updated preview for white casing variant:

In-code tracks are now handled separately and do not get surface-based classes, but only work off grade-based styling.

Speaking of, here are a couple example of slightly lighter casing:

I am thinking perhaps #DDD might be a bit better for readability? It didn't matter much before, but background aerial of vegetation can really mess with visibility if one wants to distinguish the grade quickly. (I suppose tracks themselves could be made darker, but I think the main problem here is aerial itself and not the contrast within the track.)

[tyrasd]

thanks for the update.

casing color

agree, #DDD looks like the best for now.

in theory we could also pick color based on surface but dash pattern based on grade. […] And I'm not sure this is the way to go.

That seems like trying to display too much information at once. I think tracktype is the most relevant for tracks, so let's limit it to that for the rendering.

inconsistent with other paved roads.

true, I did not think about that at first. Yes, there's also merit to show a grade1 track the similarly to a (paved) highway=service or highway=unclassified. I guess by changing the casing for all tracktypes to the bright color we did make that inconsistent. 🙈 //cc @k-yle , @tordans : what's your opinion regarding this?

[RudyTheDev]

Here is a comparison for reference: