Rewrite road layer

[1ec5]

This is a full rewrite of the road layer code. The new code avoids OOP in favor of a simple static object structure, similar to most other layers. We’ll see if we end up needing additional dynamic code generation down the line, but for now this code makes it much easier to see at a glance how paint and layout attributes vary by a variety of cascading conditions.

I’ve done away with the special cases for surface streets at high zoom levels, which greatly complicated the code. This fixes the bugs where some roads fell through the cracks of the layer filters, missing a fill or casing or both. I think we’ll want to reintroduce the wider street-scale streets as a separate layer that’s mutually exclusive of the low-zoom one, since it doesn’t need to vary many of the same properties anyways.

Before	After

There’s still a lot left to do:

• Delete Road class hierarchy
• Restore base road layer
• Restore freeway, state highway variations
• Restore toll road, expressway variations
• Reemphasize arterial and collector roads that aren’t part of a numbered route
• Restore bridges
• Restore tunnels
• Restore unpaved roads
• Recolor freeways under construction
• Sort road features by classification and layer
• Experiment with demoting ramps to minor roads
• Experiment with single offset lines for freeway and expressway casing instead of line gap

Fixes #1.

[1ec5]

While I’m in this part of the codebase, I thought I’d experiment with a fix for something that’s been bothering me for quite some time: ramps and turn channels tend to stick out like barbs or burrs and make the roadway less well-defined. We’ve avoided doing much about this problem in the past out of concern about visually severing freeways from the freeway network at T interchanges. The approach here is to avoid filtering out any ramps but render all of them as understated minor roads.

Before	After

This change also makes it easier to spot mistagged ramps:

Before	After

[1ec5]

I haven’t restored the wide streets with casings at high zoom levels yet. In the meantime, for legibility, the one-way arrows are now offset to the side, similar to road labels. This offset assumes driving on the right and will be somewhat misleading in regions that drive on the left.

I’ve implemented bridges and tunnels. Due to the lack of a casing on roadways in general, bridges have a knockout and a faint casing around the knockout.

Before	After

[Scott5114]

While I’m in this part of the codebase, I thought I’d experiment with a fix for something that’s been bothering me for quite some time: ramps and turn channels tend to stick out like barbs or burrs and make the roadway less well-defined. We’ve avoided doing much about this problem in the past out of concern about visually severing freeways from the freeway network at T interchanges. The approach here is to avoid filtering out any ramps but render all of them as understated minor roads.

I do see the aesthetic benefit to this change in rural areas and at lower zoom levels, but one concern that I have about this change is that it means there's no way to symbolically distinguish between freeway ramps and local streets in dense areas. This is particularly noticeable with system interchanges; the example screenshot of the Spur 366/US-75 directional T is somewhat hard to parse as a result because it looks like local streets intersect the ramps. This is particularly true if the user is familiar with "Breezewood"-like situations where a direct freeway-to-freeway connection is missing and a driver must use a surface street to make a particular movement; the path changing from blue to grey to blue could be misconstrued as an instance of this kind of design.

If it were practical (and I'm guessing this is a change that would have to be made upstream), I would prefer keeping the ramps rendered in freeway blue at higher zoom levels, and then at zoom levels where the "barb" issue is a problem, instead rendering an exit icon. (The legacy USRD standard specified a white circle for this since unlike the white square typically used on US maps, there was no need to rotate it to match the freeway's orientation. This was then accompanied by a green rectangle with white number in it for the exit number).

[1ec5]

This is particularly noticeable with system interchanges; the example screenshot of the Spur 366/US-75 directional T is somewhat hard to parse as a result because it looks like local streets intersect the ramps.

#2 (comment) is slightly outdated. After posting those screenshots, I restored bridge rendering, which resulted in #2 (comment). The ramps are darker than surface streets, and the bridge casing keeps them from appearing to intersect the surface streets.

Here’s what downtown Dallas looks like now:

That said, I’m considering toning down the bridge casing a bit and even unconditionally putting freeways over surface streets at some lower zoom levels, to keep the freeway from getting broken up by barely discernible fragments. If I do this, I’ll make sure not to make the ramps blend in too much.

If it were practical (and I'm guessing this is a change that would have to be made upstream), I would prefer keeping the ramps rendered in freeway blue at higher zoom levels, and then at zoom levels where the "barb" issue is a problem, instead rendering an exit icon.

osm-americana#746 discusses junction diamonds a bit. I’d love to replace the ramps with interchange diamonds, but the vector tiles don’t have the necessary data. Instead of the location of an interchange per se, we have only the precise location of each exit at the theoretical gore point:

Once we move off the OpenMapTiles schema, we should be able to implement a postprocessing step on the server side that clusters exits with matching numbers to a single point along the freeway. This would enable us to display a symbol of some sort, though I’m unsure if we’ll be able to easily distinguish between partial and full interchanges.

The legacy USRD standard specified a white circle for this since unlike the white square typically used on US maps, there was no need to rotate it to match the freeway's orientation.

A white circle could be confused with a place icon if we move to that color for smaller places. It’s trivial to rotate the diamond according to the freeway’s orientation, provided that we’re able to show an icon in the first place.

This was then accompanied by a green rectangle with white number in it for the exit number

We can put each exit number in a green rectangle if you consider that to be important for intuitiveness. We had avoided that treatment in the main Americana style because so many route shields around the world (and also at the county level) are green rectangles. In paper maps I’ve seen, exit tabs run the gamut, such as black squares, light blue rounded rectangles, black plain text, or blue plain text in parentheses. The common factor seems to be avoiding anything that looks like a shield.

If we go with a green rectangle, we can mitigate any confusion by keeping the text smaller and offsetting the number away from the roadway. However, it would be somewhat tricky to ensure optimal placement of an offset exit number badge.

[Scott5114]

Could we do something like, if zoom level is less than 13 (seems like a good place to stop rendering interchange symbols and start rendering actual ramps to me, but adjust to taste), grab all of the interchanges currently being rendered, group them by matching the highway (so you don't accidentally grab exits from two different highways) and exit number, take each group's average lat and lon, and then plot the interchange icon there? (possibly with snapping to the actual route line if testing shows it is necessary and it's possible to do, but I would guess that a simple average wouldn't be too far off at zoom level 12 and lower).

There would have to be some sort of collision detection for instances where multiple interchanges stack up close to one another, but OSM-Carto seems to have some sort of handling for this, so I'm guessing that's a solved problem. If you wanted to get fancy, you could also do a regex match rather than a simple string match in the grouping step to group A/B exits within a certain range and generate a combined "123A-B" exit label.

(Sorry if this is way off base with regard to what's actually going on under the hood!)

Also, point taken on the symbology; the yellow numbers do the job just fine, so there's not much reason to retain part of the old style that could actually be ambiguous on this kind of map.

[1ec5]

There would have to be some sort of collision detection for instances where multiple interchanges stack up close to one another, but OSM-Carto seems to have some sort of handling for this, so I'm guessing that's a solved problem.

Unfortunately, openstreetmap-carto isn’t a good reference point for what’s feasible in a vector map. The technologies are very different from top to bottom. That said, MapLibre does have collision detection functionality.

Could we do something like, if zoom level is less than 13 (seems like a good place to stop rendering interchange symbols and start rendering actual ramps to me, but adjust to taste), grab all of the interchanges currently being rendered, group them by matching the highway (so you don't accidentally grab exits from two different highways) and exit number, take each group's average lat and lon, and then plot the interchange icon there? (possibly with snapping to the actual route line if testing shows it is necessary and it's possible to do, but I would guess that a simple average wouldn't be too far off at zoom level 12 and lower).

Averaging the highway=motorway_junction nodes would work fine for a diamond or cloverleaf interchange at a straightaway along the freeway. Certain parclo configurations would result in an average point well to one side of the overpass or underpass, but this misalignment may not be noticeable at the zoom levels we’re talking about. If the freeway curves enough at the exit, the symbol would also be off unless we snap to the freeway.

We could implement an exit symbol layer as a one-off, querying OSM for all the exits and figuring out the optimal coordinates for each label, then baking them into a GeoJSON overlay covering the whole continent. MapLibre can actually cluster points automatically when they’re in a GeoJSON overlay, as opposed to a vector tile layer. However, we’d have to update the GeoJSON file periodically, at which point we’ve sort of reinvented the vector tile generator.

I think ideally we’d get the same calculations added to the basemap’s tiles. The problem is that no one understands that part of the OMT code well enough and is willing to touch it. Maybe leaving the map in a suboptimal state would help build the case for moving off OpenMapTiles, but this workaround would be very cool and demonstrate the need better. 🤔 Want to experiment a bit with generating such an overlay?