Support for highway=track #717

adamfranco · 2023-01-20T04:58:03Z

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

adamfranco · 2023-01-20T05:03:37Z

Screen shot after the initial commit at #map=14.55/43.98109/-73.08988:

Compared with highway=construction at #map=14.21/45.11823/-73.11836:

ZeLonewolf · 2023-01-20T05:04:07Z

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.

Required lightening the color to avoid increasing the visual weight.

adamfranco · 2023-01-24T01:46:48Z

Now rendering solid double-track lines for paved track roads. At map=15.15/48.004347/-123.602377

ZeLonewolf · 2023-01-24T01:54:19Z

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

adamfranco · 2023-01-24T02:04:37Z

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

That's my plan!

zekefarwell · 2023-01-24T15:52:46Z

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?

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 · 2023-01-24T16:03:28Z

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 · 2023-01-24T16:22:40Z

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.

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 · 2023-01-24T16:29:05Z

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

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

adamfranco · 2023-01-24T17:07:05Z

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 · 2023-01-24T17:24:08Z

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 · 2023-01-24T17:29:06Z

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 · 2023-01-24T17:45:24Z

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 · 2023-01-24T19:39:46Z

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:

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 · 2023-01-24T19:54:51Z

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

ZeLonewolf · 2023-01-24T19:57:18Z

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 · 2023-01-24T20:22:11Z

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 · 2023-01-24T21:18:23Z

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 · 2023-01-24T21:31:19Z

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 · 2023-02-01T16:48:28Z

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.

zekefarwell · 2023-02-06T17:23:04Z

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 · 2023-02-06T17:54:16Z

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 · 2023-02-06T23:15:42Z

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 · 2023-02-07T02:02:11Z

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.

http://localhost:1776/#map=19.46/44.1418013/-71.7990597
http://localhost:1776/#map=16.45/43.086983/-71.069226
http://localhost:1776/#map=17.98/54.382105/-1.104678 (a ford with surface=concrete)
http://localhost:1776/#map=19/54.2692443/-2.1422997

Thoughts?

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

1ec5 · 2023-02-07T02:19:39Z

scripts/taginfo_template.json

+      "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"
+    },


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

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

1ec5 · 2023-02-07T02:34:03Z

src/layer/track.js

+
+export const legendEntries = [
+  {
+    description: "Land access track",


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.

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

“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.

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

* 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.”

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

1ec5 · 2023-02-07T02:36:07Z

src/layer/track.js

+    filter: notFordSelect,
+  },
+  {
+    description: "Land access track - ford",


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.

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.

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.

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

ZeLonewolf · 2023-02-07T02:46:28Z

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

jleedev · 2023-02-07T14:51:48Z

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

Link to that location?

adamfranco · 2023-02-07T14:58:30Z

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

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 · 2023-02-07T16:36:05Z

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 · 2023-02-07T17:13:49Z

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

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).

1ec5 · 2023-02-07T17:40:46Z

scripts/taginfo_template.json

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


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

1ec5 · 2023-02-07T17:53:33Z

src/layer/track.js

+    filter: notFordSelect,
+  },
+  {
+    description: "Land access track - ford",


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 · 2023-02-07T20:30:17Z

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.

1ec5 · 2023-02-07T20:43:54Z

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.

adamfranco · 2023-02-08T19:20:42Z

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:

A bunch of cases of track bridges at layer>1 going over canal bridges which are at layer=1:
- https://www.openstreetmap.org/way/839089830#map=19/45.47289/8.56759
- https://www.openstreetmap.org/way/165309888#map=19/48.18210/10.09368
pipeline bridges at layer=1:
- https://www.openstreetmap.org/#map=19/51.39150/12.06847
Some cases where a track-bridge is at layer=2 where it goes over a non-bridge at layer=1
- railroads at layer=1, but on the ground (or an embankment):
  - https://www.openstreetmap.org/#map=19/49.11312/11.27888
- above-ground pipelines at layer=1 but without bridge=* tags:
- Several cases of tracks going over the top of dams and locks at layer=1
  - https://www.openstreetmap.org/way/197663898#map=19/48.29303/16.35625

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

Track bridge over a highway=trunk bridge:
https://www.openstreetmap.org/way/243973064#map=19/46.22451/-78.06824

http://localhost:1776/#map=18/46.22451/-78.06824
Track bridge over a highway=tertiary bridge and a highway=trunk bridge:
https://www.openstreetmap.org/#map=18/39.53351/8.92838

http://localhost:1776/#map=17/39.53351/8.92838
Track bridge over a highway=primary bridge:
https://www.openstreetmap.org/#map=19/46.41790/14.26905

http://localhost:1776/#map=18/46.41790/14.26905
Track bridge over itself in a spiral:
https://www.openstreetmap.org/#map=19/44.63032/-92.84005

http://localhost:1776/#map=18/44.63032/-92.84005

Note that the edits have happened to extend the track after the last vector-tile build.
Track bridge over a highway=path bridge:
https://www.openstreetmap.org/#map=19/51.49569/6.87844

http://localhost:1776/#map=18/51.49569/6.87844

Paths aren't rendered yet, so not sure how this will work out.

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 · 2023-09-18T01:13:13Z

#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 · 2023-09-18T20:05:09Z

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 · 2023-09-19T02:36:40Z

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 · 2023-09-19T20:23:25Z

@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 · 2023-09-19T20:34:41Z

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 · 2023-09-22T14:40:51Z

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 · 2023-09-29T05:59:30Z

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:

Paved track:

The effect is fairly subtle when zoomed out:

But more apparent when you zoom in:

wmisener · 2023-09-29T06:22:22Z

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

These appear to not layer correctly, but I note that Carto seems to fail at them as well:

Under a railway

Under a motorway and another track (http://localhost:1776/#map=17.2/60.452613/5.702925):

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:

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.

To satisfy code_format

Add initial support for tracks as double-track dashed lines.

47174eb

adamfranco added the highway-lines label Jan 20, 2023

adamfranco self-assigned this Jan 20, 2023

Change min-zoom for tracks to reflect earliest entry into OMT.

cab046c

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 mentioned this pull request Jan 20, 2023

US National Forest shields #246

Open

adamfranco added 2 commits January 23, 2023 20:04

Extend dashes to better match US FS topo style.

3cde280

Required lightening the color to avoid increasing the visual weight.

Add solid double-track rendering for paved tracks.

4e98493

Add track names to the transportation-labels layer.

3d8a28b

adamfranco mentioned this pull request Jan 24, 2023

Smoothness in Transportation layer openmaptiles/openmaptiles#1418

Open

Merge branch 'main' into tracks

d9222d7

adamfranco added 2 commits February 6, 2023 20:48

Make fords water-line colored.

abe2c7c

Prettier coding style fixes.

530ac4c

1ec5 reviewed Feb 7, 2023

View reviewed changes

adamfranco added 2 commits February 7, 2023 10:09

Add taginfo for ford and track surface.

ab1e133

Shorten legend names.

15a832e

1ec5 reviewed Feb 7, 2023

View reviewed changes

ZeLonewolf mentioned this pull request Sep 19, 2023

Don't render one-way arrows on highway features that aren't rendered #925

Merged

wmisener mentioned this pull request Sep 25, 2023

Add bridge rendering #934

Draft

wmisener added 2 commits November 23, 2024 22:06

Merge branch 'main' into tracks

77c1a22

Update transportation_label.js

5b3ba34

To satisfy code_format

Support for highway=track #717

Are you sure you want to change the base?

Support for highway=track #717

Conversation

adamfranco commented Jan 20, 2023 • edited Loading

adamfranco commented Jan 20, 2023

ZeLonewolf commented Jan 20, 2023

adamfranco commented Jan 24, 2023

ZeLonewolf commented Jan 24, 2023

adamfranco commented Jan 24, 2023

zekefarwell commented Jan 24, 2023

adamfranco commented Jan 24, 2023 • edited Loading

zekefarwell commented Jan 24, 2023 • edited Loading

ZeLonewolf commented Jan 24, 2023

adamfranco commented Jan 24, 2023

adamfranco commented Jan 24, 2023 • edited Loading

ZeLonewolf commented Jan 24, 2023

adamfranco commented Jan 24, 2023

zekefarwell commented Jan 24, 2023 • edited Loading

ZeLonewolf commented Jan 24, 2023

ZeLonewolf commented Jan 24, 2023 • edited Loading

zekefarwell commented Jan 24, 2023

adamfranco commented Jan 24, 2023 • edited Loading

ZeLonewolf commented Jan 24, 2023

wmisener commented Feb 1, 2023

zekefarwell commented Feb 6, 2023

adamfranco commented Feb 6, 2023

1ec5 commented Feb 6, 2023

adamfranco commented Feb 7, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ZeLonewolf commented Feb 7, 2023

jleedev commented Feb 7, 2023

adamfranco commented Feb 7, 2023

adamfranco commented Feb 7, 2023 • edited Loading

adamfranco commented Feb 7, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ZeLonewolf commented Feb 7, 2023 • edited Loading

1ec5 commented Feb 7, 2023

adamfranco commented Feb 8, 2023

ZeLonewolf commented Sep 18, 2023

adamfranco commented Sep 18, 2023

wmisener commented Sep 19, 2023

ZeLonewolf commented Sep 19, 2023

adamfranco commented Sep 19, 2023

wmisener commented Sep 22, 2023

wmisener commented Sep 29, 2023

wmisener commented Sep 29, 2023

adamfranco commented Jan 20, 2023 •

edited

Loading

adamfranco commented Jan 24, 2023 •

edited

Loading

zekefarwell commented Jan 24, 2023 •

edited

Loading

adamfranco commented Jan 24, 2023 •

edited

Loading

zekefarwell commented Jan 24, 2023 •

edited

Loading

ZeLonewolf commented Jan 24, 2023 •

edited

Loading

adamfranco commented Jan 24, 2023 •

edited

Loading

adamfranco commented Feb 7, 2023 •

edited

Loading

ZeLonewolf commented Feb 7, 2023 •

edited

Loading