Drop rendering for highway=unclassified and highway=residential areas

[matkoniecz]

Expected behavior

highway=unclassified + area=yes is not rendered

Actual behavior

highway=unclassified + area=yes is rendered as an area

Links and screenshots illustrating the problem

Based on #3985 research it appears that there are nearly no (or maybe not even a single one) highway=unclassified + area=yes that is mapped correctly.

[jeisenbe]

This would be an easy fix for a new contributor.

[lgiard]

Shouldn't the same thing be done for highway=residential too ? I see a few contributor abusing of highway=residential + area=yes because it is rendered, but it is screwing routing at many intersection (vehicle are routed along the outside of these area...).

I'm sorry if it was discussed earlier, i didn't find a decision about the other highway type.

[matkoniecz]

Probably.

Is there case where highway=residential + area=yes is a valid tagging? I made such check for unclassified, and it seemed clear that every single checked object was invalid.

https://overpass-turbo.eu/s/PP3 can be helpful in such reserach (navigate to an area, click "run" button) (overpass turbo interface is broken on mobile devices, you need to be on PC)

[lgiard]

From what i saw in Belgium : all the highway=residential + area=yes should either be area:highway=residential/... (example at a crossroad) or wrongly tagged (like a parking "square" in the center of a village that's clearly not a road as it is separated by kerb...). Some of them are also wrongly mapped, but that's probably due to their age (some were mapped 7-8 years ago). Normally residential road are always linear infrastructure, they can have turning circle or a widening for car parking near your house, but it is still linear logically. I don't see any example that should be an area and still be residential road. It is pretty similar to unclassified in my opinion.
And there is the problem that many routing algorithm will often fail with this as they will announce non-existing turn (to follow the area border).
From discussing with one mapper that use this tag, he said to me that he use it because it is nicely rendered for crossroad, etc... So that's a problem in my opinion. He should use area:highway=* in that case even if not rendered (yet).

Examples where routing have problems :

• Like that (it depends from where you come, and on the algorithm avoiding these area or not) : https://www.openstreetmap.org/directions?engine=graphhopper_car&route=50.47236%2C4.22604%3B50.47235%2C4.22524#map=19/50.47232/4.22578
• Or like this one which is more problematic as there are no lines crossing the area : https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike&route=50.91028%2C4.51508%3B50.90988%2C4.51409

[polarbearing]

I can imagine a residential road ending in a place larger than a turning circle, leading into several properties. Thus you'd have some omni-directionality as required for valid area=yes.

[jeisenbe]

Can you show an example of this in the database?

[polarbearing]

https://www.openstreetmap.org/way/764251889

[lgiard]

What would be the advantage in comparaison to a simple "turning circle" or a line ending there ? You can logically connect every footway to the end node if it is only a line and it represent it more or less the same thing. And this area should be mapped as area:highway=* if we follow the wiki general rules about highway, as it is a widening of the road to allow parking but still logically only the end of the road as a "node" (if we just thing of road graph - it doesn't matter if it should end 5 meters away no ?). There are so many bad usage promoted by the current rendering, that i find it is always bad use maybe. :p

[polarbearing]

No you cannot add footways since there are no footways in reality. The asphalted area is adjacent to the plots of the terraced houses.
No is is not just a widening to allow parking.
Let's analyse this case:
If that were in Germany, they would add the blue rectangular sign for 'living street' to tell drivers they have to carefully drive around children playing hopscotch. Now, this is in Ireland, they did not put up that sign, but drivers drive carefully around children playing hopscotch.
Residential roads are not only used by cars.
All OSM-highways with slower traffic (service, pedestrian, footway, living street, residential) can have areas for which area=yes is valid, indicating omnidirectional traffic, that are not just widenings of a linear structure (for which we agree that area:highway=* applies).

[jeisenbe]

Aerial imagery:

So there is parking on every side of this area, though perhaps the parking spaces belong to each townhouse rather than being considered a large parking lot? I see there is a car double-parked out in the main roadway area too, which is only twice as wide as the access road.

The enlarged area is about the usual width for a suburban American residential street - 20m with sidewalks. If this were circular it would look like a suburban "turning circle", so I could also see using that tag instead.

While this example may not be incorrectly tagged, I think the current rendering as a white square and dark casing is rather misleading.

Since we otherwise render highway=unclassified and highway=residential identically, I would support removing the area=yes rendering for both at the same time. While the mapping may not always be wrong, the current rendering is not helpful and much of the data is poor quality.

[polarbearing]

the parking spaces belong to each townhouse rather than being considered a large parking lot?

Yes, it's individual front yards, with small walls separating them.

[polarbearing]

If the example is too small for you, have a look at objects tagged as square.
overpass highway=residential and area=yes and place=square global.

Procedure-wise, what I don't understand why, once a topic is agreed, we add another topic that is controversial, and blocks the first one.

[lgiard]

Sorry at first i didn't see that as controversial. ^^' As the area=yes tagging was never approved by the community except for pedestrian apparently. It is not described on the wiki, nor discussed anywhere as far as i know, and most example that i saw are pure "mapping for renderer" that would generally be better without this area mapping for routing, ... (especially as most of them are duplicate tagging : both area AND line are on this place). If that's only for rendering and mapping that the highway extent over an area, the tag 'area:highway=' is there for this purpose no ? ^^' The highway= tag is only a "logical" tagging of a road (via an abstraction on a line), not an exact mapping.

Is there a place=square which is really a complete residential road ? I didn't find an example. But then if that's the case why not only render this area=yes if there is "place=square" too (i don't know if that's easy or possible ?!) ? It would avoid any mapping for the renderer that's apparently the main reason to use this tag at the moment.

[1ec5]

For what it’s worth, this roadway in Cincinnati has been tagged as a residential highway area for quite some time. The protrusion has its own name and is only used for one direction of traffic, except when entering or exiting one of the adjacent properties. There are other cases where a residential highway area was used to clarify that there’s a big area of pavement where cars can go pretty much wherever, but the most likely paths have been mapped as non-area ways. It’s entirely possible that these cases deserve area:highway mapping, but I’d imagine that there are other examples like them that have been tagged similarly over the years.

[matkoniecz]

big area of pavement where cars can go pretty much wherever

In this case such tagging is correct, but cases where it actually happens is heavily outnumbered by tagging for a renderer (at least as far as I know).

The claim is not "highway=residential + area=yes is never correct", the main claim is that rendering it has more negative effects than positive.

[jdhoek]

I am saddened by the recent trend of removing rendering of any feature that is being used wrong by mappers without providing any alternative for those who use them correctly. There are valid use cases for having low-level roads like residential, unclassified, service, and pedestrian render as areas when they can, may, and are used to cross in unbounded directions.

In this example four residential streets meet in a square without any markings. The middle of this is mapped as an area, but the rendering is now dropped, despite it being correct there. Traffic can cross in nearly any direction there, there is no obstruction or sign in the middle of the square.

Visually rendering this as a single area also helps users of the map orient themselves.

[HolgerJeromin]

This is the place from the comment above:

[Zverik]

removing rendering of any feature that is being used wrong by mappers without providing any alternative for those who use them correctly

https://wiki.openstreetmap.org/wiki/Key:area:highway

[jdhoek]

removing rendering of any feature that is being used wrong by mappers without providing any alternative for those who use them correctly

https://wiki.openstreetmap.org/wiki/Key:area:highway

I understand pointing out area:highway, but that is a different beast entirely. area:highway is for mapping the whole area of a way, but it is not expected to be fully routable.

highway=* with area=yes on the other hand is explicitly routable, and makes no claims about mapping the whole of the way area per se. In the example I posted the area mapped thus is routable. If I were to map area:highway as well it would be larger and touch the landuse=residential areas around that square.

In many countries anything above highway=tertiary won't have such freely unmarked routable areas (although it's possible I suppose), but I think that residential and unclassified at least should be rendered if pedestrian and service are.

[Zverik]

I understand that area=yes with a highway marks a freely routable area. Of course nothing forbids you from mapping such area — it's just it won't be visible on this specific rendering style.

To me, a concept of a freely routable area for cars seems weird. While it's okay for pedestrians to go where they please, cyclists and cars virtually always drive along implicit or explicit "navigation lines". The latter are marked as lanes, while the former usually restricted by surface geometry and destinations.

For example, in both aerial images above, cars are supposed to keep to areas' edges. It would look out of place for a car to cross a square diagonally. Technically possible, of course, but it won't be something you'd expect to see in your plotted route.

The map is not an accurate representation of a territory. When we see a wide sidewalk, we draw a line. When we see a high building, we draw a flat rectangle. Map is about finding rules, connections and relations between objects, to explain and to help navigate the world. Mapping roads as areas does not help with that goal. Presenting roads as areas turns a map into a satellite imagery knock-off.

[jdhoek]

it's just it won't be visible on this specific rendering style.

Then why render highway=service? It gets abused just as highway=residential does.

For example, in both aerial images above, cars are supposed to keep to areas' edges.

I'm sorry, but you are mistaken there. It is valid and legal for a car to move diagonally from the north-east to the south-west (or north-west to south-east), or to use the space to turn around, as long as other traffic isn't impeded. And people do. This is an unmarked square. There are plenty of areas where there are only rigid lanes to route along, this isn't one of them.

Technically possible, of course, but it won't be something you'd expect to see in your plotted route.

It would be exactly what I would expect from advanced navigation software.

Presenting roads as areas turns a map into a satellite imagery knock-off.

While I am a supporter of area:highway, this issue is not about rendering the area of ways, but about rendering the freely routable areas, and being consistent with highway=pedestrian and highway=service. This is within the scope of the general purpose OSM-Carto.

It also adds valuable information to users of the map in terms of orientation points; it literally helps explain the world.