Increase default highway width to better match physical width at high zoom

[adamfranco]

In the current implementation, road widths stay small as zoom increases, leading to them being much smaller than physical widths at ~z17 and higher.

Current Americana: For contrast, here is Carto:

Above a certain zoom we should start increasing default highway line widths to more closely approximate likely physical widths. As a rough starting point for targets we could aim for showing highways at the equivalent of ~8' driveways, 10' service, 14' residential, 18' tertiary, 22' secondary, 30' primary, and 36' trunk & motorway. (More considered width suggestions welcome.)

Note that this would affect default highway widths. Other techniques to show lanes or more accurate physical widths are also welcome.

[wmisener]

I said this on Slack, but I'll repeat it here to keep things together: I think increasing the road widths at high zoom is a very good idea. The time is ripe to do it too, before the project moves toward rendering more small-scale features like POIs where high zoom appearance becomes more important. Wider roads will also help make the paved/unpaved distinction (#63) easier to see for residential and service roads (classes which you might expect to be more commonly unpaved, at least in the US), as these roads are so thin that I personally sometimes have trouble seeing the pattern right now, even at high zoom. It would also provide more pixel real estate on these ways to denote access (#216) in the future.

[jeisenbe]

Since this style is also intended for Hawaii (and Puerto Rico?) you will also want to consider the apparent width at 18 degrees, where the same pixel represents significantly more width than in the mid-latitudes. And in contrast, in Fairbanks Alaska the rendered road will still be too narrow compared to the actual width, due to the changes in scale with the Mercator projection at higher latitudes.

It is actually possible to adjust the line rendering based on latitude, but the code is complex. See an example at https://github.com/gravitystorm/openstreetmap-carto/pull/1853 which also adjusted runways based on width, though I believe you could use a simpler version to just adjust by latitude.

Also see https://github.com/gravitystorm/openstreetmap-carto/pull/1861 and https://github.com/gravitystorm/openstreetmap-carto/pull/1972

[1ec5]

Since this style is also intended for Hawaii (and Puerto Rico?)

Yes, we intend this style to focus on every part of the U.S., even outside the lower 48. We’ll also be considerate of other parts of the world on a best-effort basis, since the style is being applied to a world map after all.

It is actually possible to adjust the line rendering based on latitude, but the code is complex. See an example at https://github.com/gravitystorm/openstreetmap-carto/pull/1853 which also adjusted runways based on width, though I believe you could use a simpler version to just adjust by latitude.

@jleedev has experimented with interpolating widths based on physical units.

GL JS doesn’t expose the geometry data to expressions when evaluating layout properties. The existing within operator could in principle allow us to vary widths by latitude band, but this operator doesn’t perform very well. The distance expression operator would be much more straightforward, but it isn’t available in MapLibre GL JS: mapbox/mapbox-gl-js#10616.