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

Support for highway=track #717

Draft
wants to merge 12 commits into
base: main
Choose a base branch
from
Draft

Support for highway=track #717

wants to merge 12 commits into from

Conversation

adamfranco
Copy link
Collaborator

@adamfranco adamfranco commented Jan 20, 2023

As part of #216, this PR adds support for tracks, rendering them as double-tracked dashed lines.

@adamfranco
Copy link
Collaborator Author

Screen shot after the initial commit at #map=14.55/43.98109/-73.08988:
Screen Shot 2023-01-19 at 11 59 00 PM

Compared with highway=construction at #map=14.21/45.11823/-73.11836:
Screen Shot 2023-01-20 at 12 00 53 AM

@ZeLonewolf
Copy link
Member

A zoom-12 track can be found at approximately this location:
https://6ug7hetxl9.execute-api.us-east-2.amazonaws.com/data/v3/#12/41.58391/-71.73213

It's a section of Rhode Island's North South Trail (network=rwn)

Unfortunately this means that most tracks snap in at full opacity, but 
there doesn't seem to be a way to avoid that without route_rank being 
exposed in OMT.
@adamfranco
Copy link
Collaborator Author

Now rendering solid double-track lines for paved track roads. At map=15.15/48.004347/-123.602377
Screen Shot 2023-01-23 at 8 43 30 PM

@ZeLonewolf
Copy link
Member

Should we just go ahead and make path the single-dashed version of what you have for track?

@adamfranco
Copy link
Collaborator Author

Should we just go ahead and make path the single-dashed version of what you have for track?

That's my plan!

@zekefarwell
Copy link
Collaborator

Thanks for working on this! For unpaved tracks, do you think we might be able to do just a dashed double line as is typical on USGS maps? Essentially dashed casing with no fill?

Screen Shot 2023-01-24 at 10 41 04 AM

Thinking about how we implement casing as a wider line underneath a thinner one, maybe this isn't possible in MapLibre. Maybe line-offset could be used to draw two dashed lines, each slightly off center from the actual geometry. I guess that would require two layers though.

@adamfranco
Copy link
Collaborator Author

adamfranco commented Jan 24, 2023

For unpaved tracks, do you think we might be able to do just a dashed double line as is typical on USGS maps? Essentially dashed casing with no fill?

@zekefarwell, this is how it is currently implemented on the branch. There is no fill and only one layer. The line-dasharray property specifies the length of dashes and gaps while the line-gap-width property specifies the offset to either side of the center-line of the line (where the fill would be if overlaying multiple painted lines). With a non-zero line-gap-width we get the double-track pattern. See this example in the code.

@zekefarwell
Copy link
Collaborator

zekefarwell commented Jan 24, 2023

this is how it is currently implemented on the branch

Oh! Sorry I was just looking at the screenshots and it looked to me like there was a dashed fill along with the dashed casing. Now that I've pulled down the branch and zoomed further in I can clearly see that it is two lines. To my eye, at lower zoom the light brown lines blur together somewhat and look like one line. At higher zoom, the separation is clear though.
Screen Shot 2023-01-24 at 11 15 07 AM Screen Shot 2023-01-24 at 11 15 32 AM

Perhaps increasing the contrast with a darker brown or dark gray/black could minimize this effect, or perhaps my eyes are just worse than they used to be 😄. Image compression in the screenshots may also be a contributing factor.

@ZeLonewolf
Copy link
Member

Do we plan to render paved paths differently from unpaved paths?

Is the use of brown to represent something paved a problem?

@adamfranco
Copy link
Collaborator Author

Perhaps increasing the contrast with a darker brown or dark gray/black could minimize this effect, or perhaps my eyes are just worse than the used to be 😄. Image compression in the screenshots may also be a contributing factor.

I played around with a bunch of different spacings and colors and ended up with these lighter colors and narrower low-zoom representation to prevent the visual weight from being heavier than minor roads. I'm sure that there are different balances that would be acceptable, but that was the the metric I was using: visible, but less weighty than minor roads.

@adamfranco
Copy link
Collaborator Author

adamfranco commented Jan 24, 2023

Great questions!

Do we plan to render paved paths differently from unpaved paths?

Certainly I think it would be ideal to differentiate between high-quality/improved-infrastructure paths that are likely to be wheelchair accessible (whether paved, or gravel) and those that are less likely to be wheelchair/stroller accessible. After that the actual smoothness or surface feels less important to me than differentiating on the keys focused on by the Trails Working Group (informal=yes, operator=*, access=*) and sac_scale=* or whatever becomes of the highway=scramble proposal.

It might make sense as a design language to keep some dashing on the paved paths, but maybe with just little breaks instead of longer ones. This seems less needed for tracks as the solid double-track line feels like it would be less likely to occur in densely mapped environments and to conflict there with other features

Is the use of brown to represent something paved a problem?

Good question. It feels okay to me for paved tracks as the brown signifies land-access in my mind, but shifting those to a grey-tone would also be very reasonable and might make more sense.

For paths it becomes a bit trickier because of the ambiguities in usage of highway=path vs highway=footway for both hiking trails and park walkways. Since both might be used in an urban context for paths that aren't "land-access" the brown feels more wrong for them vs tracks.

@ZeLonewolf
Copy link
Member

Good question. It feels okay to me for paved tracks as the brown signifies land-access in my mind, but shifting those to a grey-tone would also be very reasonable and might make more sense.

I was thinking maybe we could play with incorporating some brown into the current rendering for unpaved roads (primary and below), perhaps in the pattern or casing. I just think I'd be surprised to find a paved road where there's a brown line on the map. A paved track doesn't seem really very distinct from a paved service road to me -- they're so close in real-world meaning that they hardly make sense to differentiate.

@adamfranco
Copy link
Collaborator Author

I was thinking maybe we could play with incorporating some brown into the current rendering for unpaved roads (primary and below), perhaps in the pattern or casing. I just think I'd be surprised to find a paved road where there's a brown line on the map. A paved track doesn't seem really very distinct from a paved service road to me -- they're so close in real-world meaning that they hardly make sense to differentiate.

I see the point on paved tracks. I'll think on that and look at more tagging usage as there are also cases of farm tracks with surface=concrete:lanes or surface=grass_paver that really aren't part of the general road network and might be better to be distinct.

For the general road-network's primary-minor unpaved roads, I'm pretty happy with the current representation and am leery of blurring the line between these and tracks. The majority of road-miles in my region are unpaved, so that distinction between unpaved (and likely maintained publicly or privately) and likely-unmaintained tracks is super important to me.

@zekefarwell
Copy link
Collaborator

zekefarwell commented Jan 24, 2023

A paved track doesn't seem really very distinct from a paved service road to me -- they're so close in real-world meaning that they hardly make sense to differentiate.

I agree that track roads and service roads have a big overlap in physical characteristics. However I don't think rendering all track roads and service roads the same but with a paved/unpaved distinction would be optimal. The distinction I'd ideally like to see is more about overall construction quality and maintenance based on the tracktype tag. tracktype=grade1-3 essentially represents an unimproved road and tracktype=grade1-2 represents a higher level of quality and maintenance. Essentially a breakdown like this:

Screen Shot 2023-01-24 at 2 34 38 PM

OpenMapTiles doesn't include tracktype values so that would be required. Also there are probably a bunch of track and service roads that don't have a tracktype, but I think this logic would be reasonable for filling in missing tracktype values:

if highway == track and tracktype is null:
	if surface == paved:
		tracktype=grade1
	else:
		tracktype=grade3

if highway == service and tracktype is null:
	if surface == unpaved:
		tracktype=grade2
	else:
		tracktype=grade1

@ZeLonewolf
Copy link
Member

I really like that breakdown, the only think I would adjust is that I thought grade1 is always paved?

@ZeLonewolf
Copy link
Member

ZeLonewolf commented Jan 24, 2023

There is a subclass attribute in OpenMapTiles that we could conceivably populate. Graded unpaved roads are clearly different from ungraded and I think we might be able to get away with adding that to tiles?

@zekefarwell
Copy link
Collaborator

I thought grade1 is always paved?

In typical OSM fashion it is "Usually a paved surface" 😉 (tracktype wiki page). If there is no surface tag and only tracktype=grade1 then it's reasonable to assume that the surface is paved. However if an unpaved surface value is tagged in combination with tracktype=grade1 I think it's probably best to go with the tagged surface value rather than assuming paved based on the grade1 value.

@adamfranco
Copy link
Collaborator Author

adamfranco commented Jan 24, 2023

Longer term, if OMT gets smoothness and tracktype values added, I'm thinking of a sort of cascading evaluation system where the worst values win:

  • Starting with: (tracktype=grade1 or surface=paved) and smoothness <= bad ==> "paved track"
  • If empty tracktype, tracktype=grade2|grade3, surface=unpaved, or smoothness <= very_bad ==> "unpaved track"
  • If tracktype=grade4|grade5 or smoothness <= horrible|very_horrible ==> "4wd track"

Any of those worse tracktypes or worse smoothness values would knock even a paved track into a lower category. For example, a way with tracktype=grade1+surface=paved+smoothness=very_horrible would still get the "4wd track" treatment -- I'm not sure what that would be maybe some sort of slick-rock 4wd trail or other agricultural track that requires high-clearance for some reason.

@ZeLonewolf
Copy link
Member

A more typical approach in OpenMapTiles would be to group together the tagging into renderable attributes. I would suggest that from this discussion there are actually 3 surface categories that we really care about:

  • Paved roads
  • Unpaved, but graded roads
  • Unpaved and ungraded roads

@wmisener
Copy link
Collaborator

wmisener commented Feb 1, 2023

Just saw this, looks great! Re: @zekefarwell's point about the dashes blending together when you're zoomed out, I wonder if it would be better to have tracks as a single dashed line when zoomed out, which can switch to the very nice two-track line you have as you zoom in. One thing that struck me in your samples is that due to that blending, the tracks visually appear much thicker than residential and even tertiary roads. This is also the trick the rest of the roads use, when they switch from being black lines to black with white fill at z>15.

@adamfranco
Copy link
Collaborator Author

Even without testing for brunnel=ford, the current implementation of the river fill showing through the track makes visual sense.

http://localhost:1776/#map=15.99/44.078913/-73.121379
track-ford

I guess that leaves the open question: Is the knockout enough?

@ZeLonewolf
Copy link
Member

Have to say, those track bridges look awesome!

@zekefarwell
Copy link
Collaborator

I think the knockout alone works fine for roads and railways at low zoom as it reduces clutter. At higher zoom I think showing bridges more explicitly in some way makes sense for tracks as well as other highway types.

@adamfranco
Copy link
Collaborator Author

I think the knockout alone works fine for roads and railways at low zoom as it reduces clutter. At higher zoom I think showing bridges more explicitly in some way makes sense for tracks as well as other highway types.

Good point on zoom-dependent rendering! A slightly wider black casing could be added to all highway bridges, or for roads that already have a black casing, a background-color+casing to give similar looking standoff to that of tracks and rail.

@1ec5
Copy link
Member

1ec5 commented Feb 6, 2023

We had originally considered a dark casing around road and rail bridges too, but it got complicated because there needed to be a bit of a gap between the roadway and casing, and traditionally the casing would’ve splayed out on either end too. It got really confusing with rail because the railroad ties made the bridge look like a pontoon bridge or something: #476 (comment).

I could see an argument for applying a dark casing only for tracks on the basis that tracks lack a solid longitudinal stroke, unlike roads and rail. In that case, what we’re communicating is that the track temporarily becomes more like a normal road as it traverses a bridge.

Regardless of how we treat bridges, if there’s enough precedent for marking a ford explicitly with a symbol, perhaps we could explore that in a separate issue.

@adamfranco
Copy link
Collaborator Author

It's subtle, but I've added support for brunnel=ford on ways.

Side-note: OMT doesn't have ford=* nodes yet, so node-tagging will need to wait for future work. Ford nodes will be useful to have as they are a significant way of mapping fords.

Here are some examples of making fords on tracks the water-line color.

Thoughts?

What do you think about the legend labeling? Too verbose?

"object_types": ["way"],
"description": "Track roads have a two-track line pattern that is dashed if unpaved and solid if paved.",
"doc_url": "https://openmaptiles.org/schema/#transportation"
},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also add an entry for ford=yes, as well as a second entry for surface that describes the stylistic variation on tracks.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the feedback. Added these taginfo entries in ab1e133.


export const legendEntries = [
{
description: "Land access track",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This diplomatic wording is more appropriate in contexts like id-tagging-schema and the OSM Wiki, where it’s important for mappers to apply the right tag and not apply the wrong tag. But we have much more latitude in a legend, where the reader just has to get the gist of what distinguishes this entry from the ones above it. For comparison, the entry for expressways condenses an entire highly technical wiki article into just a few words. That’s what you’ve done here, but out of context, “land access” raises more questions than it answers.

In my opinion, even a description as simple as “Unpaved track” or “Unpaved off-road track” would suffice. I don’t think the reader would be left with the impression that they’re looking at running tracks or railroad tracks (which has its own section). Many print maps say things like “Vehicle tracks” or “4×4 tracks”, but we aren’t distinguishing by mode of transportation here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"track" isn't really a word we use for that here though. The closest American-ism is a "two-track road" in my vernacular.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

“Track” or “tracks” is a word in American English. It’s more general than highway=track (e.g., train tracks, farm tracks, animal tracks), but still close enough that the reader would not be mislead by seeing these lines described as tracks. As a preset name, it would cause mappers to dilute the tag, but dilution doesn’t happen quite like that with a map legend.

Part of the reason we’re in this quandary is that conventional transportation maps don’t even distinguish this notion of a highway=track. They do distinguish local roads by surface or access with captions like “unpaved local road” or “trail”, or they omit them from the map in the first place.

Utah DOT 2007 Hallwag California NMDOT 2010 compact Clermont County Engineer (Engels) 2004 Arizona Office of Tourism 2021

This outdoors-oriented atlas exemplifies the kitchen-sink approach:

Benchmark Arizona

* Other roads in urban areas are typically paved public streets. In rural areas they include local back roads, rough 4WD routes, private roads, and logging roads. Some of these roads are usable, but others are closed to public use, or seasonally impassable, or both. Inquire locally before attempting to drive “Other Roads.”

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the feedback. Shortened to Unpaved track and Paved track in 15a832e.

filter: notFordSelect,
},
{
description: "Land access track - ford",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far we’ve omitted brunnels from the legend because taking them out of context can be confusing. (A road bridge, for one thing, looks just like a normal road on its own.) We’d need to add some functionality to the legend to place another linear feature across the spotlighted feature. But I think the ford treatment you’ve implemented looks intuitive enough on its own.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now I've left the ford-specific legend entries to avoid the case of ford-styling ending up in the legend when both unpaved ford and non-ford are present (such as at this location) as well as allow a concrete ford surrounded by unpaved tracks to get an entry noting that it is paved (such as at this location). Maybe this isn't ideal, but dropping any filters and sometimes showing blue for tracks felt particularly wrong.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I certainly agree with filtering out fords from the general track entries, but in the absence of the crossing lines capability I described above, it’s probably less confusing overall to omit any entries about the fords.

The main issue is actually that the legend is depicting the track as a single dashed line, whereas it’s actually two parallel lines. I assume that’s because it doesn’t honor the line-offset and line-gap-width properties. If we fix that, then at least the ford entry won’t look like an intermittent creek.

If we keep the ford entries around, we might be able to combine them into one entry. There are other examples where we avoided breaking out combinations of attributes – for example, there’s only one expressway entry, even though multiple classes of roads that render differently can be expressways. This works because the entry clearly is about a particular aspect of the line, not trying to visually represent every possible expressway.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#770 tracks the incorrect implementation of line-gap-width in the legend.

@ZeLonewolf
Copy link
Member

Is there anything we can do to make y-intersections seam up a little better?
image

@jleedev
Copy link
Member

jleedev commented Feb 7, 2023

Is there anything we can do to make y-intersections seam up a little better?

Link to that location?

@adamfranco
Copy link
Collaborator Author

Is there anything we can do to make y-intersections seam up a little better?

This extension-beyond seems to be a pretty rare occurrence as I've looked at lots of Y-intersections that don't have this behavior. I did find a replica of the issue at http://localhost:1776/#map=21.55/37.9287078/-107.6257251
Screen Shot 2023-02-07 at 9 51 26 AM

I wasn't able to find any combination of line-cap and line-join that improved the look, e.g.

  layout: {
    "line-cap": "butt",
    "line-join": "bevel",
  },

I checked this particular case to ensure that it was actually mapped correctly as a junction and not an overlapping line. Given that line-cap: butt should be squared off at the exact end of the line the only remaining cause for the extension beyond the junction is a rounding error or line-simplification somewhere in the vector tiles or rendering that is causing these two lines to not actually share a single point.

@adamfranco
Copy link
Collaborator Author

adamfranco commented Feb 7, 2023

With significant, but not exhaustive searching of the globe, I've so far turned up only two cases where a track layers at level=2 on top of another bridge at level=1. Both are tracks crossing over aqueducts:

I'm wondering: How valuable it would be to add/validate support for proper track-bridge layering that rarely if ever exists in the world, versus naively assuming track-bridges are one layer above 0 which is almost always the case?

@adamfranco
Copy link
Collaborator Author

A more typical approach in OpenMapTiles would be to group together the tagging into renderable attributes. I would suggest that from this discussion there are actually 3 surface categories that we really care about:

  • Paved roads
  • Unpaved, but graded roads
  • Unpaved and ungraded roads

The area around Stuggart, Germany makes an interesting case to examine for the value of keeping the paved track rendering visually distinct from other minor roads. This area has tons of highway=track+surface=paved going through vinyards. (example photos). The distinction between these and the rest of the road network might be useful or it might not be, but if rendered the same it would be difficult to pick out the actual residential roads.

https://www.openstreetmap.org/#map=15/48.7803/9.2848
http://localhost:1776/#map=14.24/48.78033/9.28484
Stuggart tracks

This is quite different from the infrastructure I'm familiar with in the US. Given how rare paved tracks are in the US I'm leaning toward keeping the rendering between paved tracks and minor/service roads distinct if only to let the eye pick up on the distinction that there might be a difference (e.g. surface=concrete_lanes to keep tractors from sinking into the mud).

"key": "ford",
"value": "yes",
"object_types": ["way"],
"description": "The color of track roads changes from brown to blue for ways tagged as fords.",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A more direct way of saying this is that the ford blends in with the waterway it crosses.

filter: notFordSelect,
},
{
description: "Land access track - ford",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I certainly agree with filtering out fords from the general track entries, but in the absence of the crossing lines capability I described above, it’s probably less confusing overall to omit any entries about the fords.

The main issue is actually that the legend is depicting the track as a single dashed line, whereas it’s actually two parallel lines. I assume that’s because it doesn’t honor the line-offset and line-gap-width properties. If we fix that, then at least the ford entry won’t look like an intermittent creek.

If we keep the ford entries around, we might be able to combine them into one entry. There are other examples where we avoided breaking out combinations of attributes – for example, there’s only one expressway entry, even though multiple classes of roads that render differently can be expressways. This works because the entry clearly is about a particular aspect of the line, not trying to visually represent every possible expressway.

@ZeLonewolf
Copy link
Member

ZeLonewolf commented Feb 7, 2023

Good news, I looked at the raw data and it turns out it's actually in the tiles that way. Also it's at zoom 21 which is like blade of grass level detail. So I think we can safely ignore this as a red herring.

image

@1ec5
Copy link
Member

1ec5 commented Feb 7, 2023

Good news, I looked at the raw data and it turns out it's actually in the tiles that way. Also it's at zoom 21 which is like blade of grass level detail. So I think we can safely ignore this as a red herring.

Some of the imprecision might be a consequence of the tiles only covering up to z14 (compared to z16 in Mapbox Streets). At z20–z22 there’s increasing amounts of weirdness that I’m guessing comes down to floating point imprecision in the shaders.

Duane

@adamfranco
Copy link
Collaborator Author

After evaluating all 1,216 highway=track+bridge=*+layer=2|3|4|5|6 I found that the vast majority of these are using a layer value larger than needed and that almost all could be layer=1.

That said, there are a few cases where a larger layer value is accurately used:

As well, I found several extant cases of a track-bridge actually crossing above another highway bridge:

While not extensive, track-bridges should be stacked appropriately with other bridges. I'm not sure if they are stacking correctly now just because tracks are more minor and being rendered after the other bridges or if it is because the bridge layering is actually working correctly. Layering will certainly be needed for path/footway bridges as those are much more likely to interleave other bridges than the comparatively rare highway=track bridges.

@ZeLonewolf
Copy link
Member

#925 removes one-way arrows from tracks and path (which are disjoint from line rendering for tracks and paths). If there isn't a near-term plan to proceed with track rendering, I would recommend approving that PR in the interim, however, I assume that would conflict with this PR.

@adamfranco
Copy link
Collaborator Author

I unfortunately don't anticipate having time to work on this in the near-term, though maybe once stick-season gets fully underway and I'm not trying to maximize being outside 🧗 / 🚵 / 🛶 in the evenings I'll be able to get back to it. Easy enough to revert the track portion of the one-way change at that point.

@wmisener
Copy link
Collaborator

Reading back through this, the rendering samples look quite good to me. What more work actually needs to be done here? If, as the checklist at the beginning seems to indicate, the only things left are support for track_type and uneven zoom behavior due to upstream OMT issues (and maybe also tunnels?), I think it's worth considering just merging this as is and turning those outstanding issues into separate tail-work. I think it would be really nice for the style to render tracks, even if there are still possible future optimizations, and this PR seems very close to production-ready to my eyes.

@ZeLonewolf
Copy link
Member

@wmisener if you wanted to take on reviving this PR, resolving the current conflicts, and documenting the outstanding track/path issues, I think that work would be welcome. The branch is in the repo so you could fork from there.

@adamfranco
Copy link
Collaborator Author

I welcome reviews and any contributions that move this over the finish line. I think the bridges with layer > 1 & tunnel support is the only big thing left. These would be especially important for paths that are more likely to have stacked bridges, so doing this now for tracks can aid that future path work. Or it can be follow-on since these are pretty rare for tracks.

@wmisener
Copy link
Collaborator

I can try to take a hack at it! Unfortunately I've been quite busy myself recently, so there's a chance I won't really have enough time either soon. But I've made a fork to work on in case I do.

@wmisener wmisener mentioned this pull request Sep 25, 2023
@wmisener
Copy link
Collaborator

Tried out a tunnel rendering, which is just the normal track dashing with a slightly lighter color. This is following the tunnel rendering for other line signatures, like railways and waterways. Played with the coloring to get it to both show up and contrast with normal track rendering, and settled on darkening the track rendering slightly to improve contrast. This is definitely subject to change. The background being a little off-white makes too light a brown really fade. A casing is another possibility, but that hasn't been done for any other tunnel yet and we'd need to make sure it looked different than whatever bridge rendering is settled on
Unpaved track:
Screen Shot 2023-09-28 at 10 32 54 PM
Paved track:
Screen Shot 2023-09-28 at 10 33 31 PM
The effect is fairly subtle when zoomed out:
Screen Shot 2023-09-28 at 10 44 44 PM
But more apparent when you zoom in:
Screen Shot 2023-09-28 at 10 44 54 PM

@wmisener
Copy link
Collaborator

Regarding layering, as with the bridges above, it's hard to find good examples in the wild. A few with valid layer=-2 values:

  • Under a waterway
    Screen Shot 2023-09-28 at 10 34 36 PM Screen Shot 2023-09-28 at 10 39 30 PM

These appear to not layer correctly, but I note that Carto seems to fail at them as well:
Screen Shot 2023-09-28 at 11 06 18 PM

  • Under a railway
Screen Shot 2023-09-28 at 10 42 31 PM
  • Under a motorway and another track (http://localhost:1776/#map=17.2/60.452613/5.702925):
    Screen Shot 2023-09-28 at 10 52 43 PM Screen Shot 2023-09-28 at 10 58 17 PM
    Here you can see the layering is definitely not rendering correctly: I colored the tunnels black in the second screenshot to make it more visible. The N-S track is layer=-2, while the E-W Bergensbanen and the motorway Langhelletunnelen are layer=-1, but the tracks are definitely on top of the motorway. Note that Carto gets the layering here right:
Screen Shot 2023-09-28 at 10 53 13 PM

The question that remains is whether it really matters to get the stacking right here, given the fact that (I assume) correcting this introduces significant code complexity. I'd think proper layering matters less for tunnels than bridges: tunnels get a faint rendering anyways, and I doubt there will be many track intersections within tunnels. With bridges on the other hand, you can see the stacking from the ground. What really needs to be found to test this is a situation where a track is layer=1 and another bridge is layer=2 above it.

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

Successfully merging this pull request may close these issues.

6 participants