Many, I would even say most things OSM do not enjoy such a majority. Majority and “should be promoted” are not requirements for this kind of development. Sometimes I even think they would be proof that an idea isn’t very enlightening.
That’s where proofs of concept and showcases come in. Since this case is called “strategic”, my simple operational view probably stops me from seeing the rainbow at the end. I’m not against, I just don’t see it, so my options are: get the idea and go with it, or the usual: go ahead, I’ll get out of the way.
Some keep dreaming about routing over areas. Also, it’s rare that we completely separate the geometry from the properties, instead of refining it.
But how to use area tagging isn’t quite what this thread is about, just rendering it. And in terms of rendering, both ways to map parking (should) result in the same outcome. Don’t you agree?
When my home town got turned into a showcase for area:highway I thought just the same: Place notes instead. Meanwhile I learned, urban-micro-area-mappers gladly wait until up to date aerials arrive? So I could not resist to map changes affecting routing, luckily outside of how far the showcase area has grown. If inside, I’d had refrained, the shear amount of detail overwhelms my little mind too much. Openstreetmap needs layers that can be hidden without the dangers of a sparse edit.
Strategic means long term goals? From my point of view, area:highway does not make any sense without a landuse=highway, which it further subdivides. That might help against people using landuse=residential to map the kerbs between pavement and carriageway of a street (in order to make osm-carto look more pleasant to them.)
Ironically, OSM Carto effectively already renders roadway footprints – by virtue of filling in man_made=bridge areas, many of which represent overpasses that carry nothing but a roadway. Unfortunately, the specific treatment it uses is somewhat counterintuitive: the gray box underlaps the very road that the bridge crosses, as if it depicts not a bridge but rather the shadow of a bridge. I think this is emblematic of the difficulty of rendering other roadway areas well.
In fairness, OSM Americana hasn’t quite figured out a fantastic solution for bridge areas either. The closest we’ve come is a sort of casing as long as you don’t look too closely at the ends. It’s only good enough for a fork because bridges don’t otherwise have casings in that style.
To really bring out the benefit of roadway areas in a more detailed style, the renderer needs to merge them with the existing linework for roadways, to eliminate the casing that a highway=* way would normally have. Visually, a label is all that would remain of the linear way. The result would be a map suitable for pedestrians and not unusable for motorists and cyclists.
Unfortunately, this merging might not be straightforward. At the very least, we’d need to ensure that area:highway=* areas are connected to highway=* ways, just as man_made=bridge and natural=waterwater=river areas are connected to their respective linear representations. Alternatively, some kind of relation akin to type=bridge and type=building relations could make the relationship between ways and areas clearer.
Otherwise, if a renderer merely layers on roadway areas as additional information without integrating it into the other layers, then the result will be more information but not necessarily more comprehension.
I think I sort of understand the rendering/layering problem there. The renderer needs information which is totally clear to the human mind but not to a rendering engine.
I don’t actually know if it would help, but I have taken to tagging layer=N on areas e.g. grass under a bridge and over a tunnel. If I were to map the road area as area:highway, I would tag it with the layer same as the road, railway, waterway or wildway (ah sorry, doesn’t exist - yet) it carries. Just because some software might need it in the far future. YNK.
I think the recommendation to attach bridge=yes road sections to man_made=bridge areas also has to do with this layering issue: it says that the road section is on the same layer as the bridge.
So the information is there; a renderer using pre-processing could handle it, but on-the-fly rendering is probably a trifle more complicated.
(Am I talking nonsense, since I’m out of my league here? Please break it to me gently, so I can learn.)
Thank you for acknowledging this. I am currently in the process of micromapping my entire university campus, and previous contributors have used area=yes on basically every single highway on the campus.
Don’t get me wrong, it looks great on OSM Cartio, but when I use CoMaps to route me through campus, it is borderline unusable. This was done by an educated university student, I don’t understand how it is expected that anyone else won’t do the same if they don’t see their changes on the main OSM map.
I am gradually going through and correcting everything on the campus but as a result of using the “correct” specification, I have significantly improved routing, but the map looks quite frankly terrible to what it used to look like on osm.org, purely because I have prioritised mapping it correctly.
Thankfully, CoMaps does make attempts to render this for highway=pedestrian and highway=footway, but (anecdotally, at least) not for highway=service. Just this change to pedestrian rendering makes it look so much better on CoMaps than on osm.org
My aim in leaving this reply is that someone at osm.org will see the harm that they are causing by not rendering the area:highway tag, and that they will take corrective action.
Unrelated JOSM note
Slightly unrelated: Better JOSM support would also be very convenient, at least the default rendering style should also take into account the area:highway mapped areas.
Without links to the area in question, it is hard to understand the points being made.
Mapping pedestrian areas as highway=pedestrian + area=yes is the de facto mapping. If tagging practice switches in favour of area:highway=pedestrian, then Carto might switch.
Unfortunately CoMaps is still somewhat of an outlier among renderers for adopting area:highway=*. But maybe other non-Carto renderer developers would be amenable to a change if asked. It’s also a good thing you retagged the service areas as area:highway=service. Otherwise they would’ve been redundant to the highway=service lines running through them.
It gets worse with multiple bridges over each other
as person who implemented it: that is because it is basically rendered as a building.
I tried to make it smarter and failed, and at that time mapping fake building=yes to mark bridge outlines was a popular mistagging for a renderer. So my reasoning was that rendering outcome is slightly better and correct tagging is no longer discouraged.
BTW, it was hilarious how some people who created elaborate justifications why building=yes is superior over man_made=bridge and how it is totally not mistagging for renderer… Suddenly changed their minds once man_made=bridge areas appeared in Carto.
area:highway= can further discussed individually. Eg =traffic_island seems more significant, and less disruptive.
However beforehand, we could first revive barrier=kerb
In case this is not a rhetorical self-question Remove rendering of barrier=kerb by jeisenbe · Pull Request #3969 · openstreetmap-carto/openstreetmap-carto · GitHub area:highway= does have problem with overlapping areas, and spiting areas. It mixes up physical and functional areas (eg a =bus_stop can be inside a =primary etc roadway area when in-lane, or outside as a bus_bay= ). area:highway= can be split transversely over the cross-section for different attributes (eg surface= , surface:colour= , etc) to supplement *:lanes= on the line.
These 2 problems can compound together. For standalone traffic islands, or medians, conceptually there’s only a single island, or strip of median. But the island or median can have different parts: walkable as crosswalk refuge ( area:highway=footway then), raised not-supposed-to-be-walked, thick solid barriers, and vegetation. This causes there to be not a single area:highway= , or the single area:highway= that does exist isn’t the entire thing.
I credit OSM Carto with getting me hooked on mapping bridge areas in the first place. Until you made that change, I had been content to tag bridge names as name=* on the roadway and didn’t care much for bridge:name=*. After mappers in another city converted their river crossings to areas, seeing the result in Carto prompted me to do the same. As I systematically mapped bridge areas near me, I learned much more about road bridges than I would’ve ever known otherwise. This forced me to revisit my earlier mapping, where I had:
Incorrectly begun bridge=yes at the locations of expansion joints instead of the locations of bridge abutments, which are more difficult to spot in aerial imagery
Mistaken many bridges for overpasses over culverts
Simply never noticed a bunch of bridges
The bridge fills in Carto are far from ideal, but I want to believe that they’ve had a positive effect on OSM. Besides, they’ve had a pedagogical effect, which is always something to celebrate.
Even though CoMaps shows that roadway fills are similarly difficult to get right, I think it’s in our community’s best interest to forge ahead with area:highway=* mapping anyways. A certain portion of the community is standing ready to pour time and effort into it, if only they can get enough instant gratification. Better to give them something imperfect now than wait until the distant future after they’ve moved on.
And I am quite happy how labels for bridges turned out in OSM Carto - it is not ideal everywhere as bridge names will have vastly varied importance and not always bigger bridge is more important, but at least in my experience it works quite well.
The French map style (https://layers.openstreetmap.fr/) renders area:highway reasonably, distinguishing between the roadway and the sidewalk(footway). Maybe this could be an inspiration.
I agree that it’s helpful to visually distinguish the roadway from the sidewalk, though the white fill is still a bit confusing if you don’t know what it’s supposed to represent. This example is a bit contrived but it reflects what would probably occur wherever less detailed mapping transitions to more detailed mapping. Anyways, it’s a starting point.
