Reviving the area:highway Rendering Discussion: A Strategic Case for QA and Data Integrity

General talk
, ,
1

Hi everyone,

I am writing this to bring renewed attention to the discussion regarding the rendering of area:highway=* in the standard OpenStreetMap Carto style. I recently left a comment on the relevant issue in the GitHub repository, but given the limitations of that tracker for broader community consensus, I believe this topic deserves a dedicated discussion here.

The Current State of Affairs For over a decade, area:highway has evolved from an experimental proposal to the “de facto” standard for mapping the physical extent of road surfaces. Despite the wiki labeling it as “abandoned,” our database tells a different story: millions of objects, dense coverage in countries like Poland and Germany, and widespread support in data consumers like OsmAnd and StreetComplete.

However, the standard layer on OSM.org remains blind to this data. This disconnect creates a “chicken-and-egg” problem that is actively harming our map data.

1. The “Blind Mapper” Paradox (Quality Assurance) Currently, mappers who take the time to micromap intersections, turn lanes, and varying road widths are working without visual feedback. Unless they use third-party tools, they cannot see:

  • Geometry Errors: Gaps between the road area and the curb, or overlapping polygons.

  • Alignment Issues: Whether the linear centerline is truly centered within the physical carriageway.

  • Landuse Gaps: The unsightly “voids” that appear between landuse polygons (like forests) and the linear road network.

By refusing to render area:highway, we are not just failing to show “eye candy”; we are disabling the primary feedback loop that mappers use to validate their work. We cannot expect high-quality area data if we hide it from the people creating it.

2. Stopping “Tagging for the Renderer” We all know the frustration of seeing highway=pedestrian + area=yes used incorrectly on wide streets or traffic islands just to get them to render. This practice corrupts our routing graphs and confuses data consumers.

The Fix: If area:highway were rendered, mappers would have a legitimate, semantic way to achieve the visual result they want (representing the pavement area) without resorting to tagging misuse. Rendering area:highway is, in effect, a defensive measure for our routing data.

3. Addressing Technical Concerns I acknowledge the valid concerns raised by style maintainers regarding “Z-Order” complexity and database performance. The interaction between road areas, bridges, and tunnels is non-trivial in the current stack. However, looking at the success of OsmAnd, Streets GL, and the Polish Community Style, it is clear these challenges are solvable.

A Proposal for a Conservative Rollout I am not suggesting a radical overhaul that clutters the map at low zoom levels. I propose we advocate for a targeted implementation:

  • High Zoom Only (z19+): Render area:highway only at the highest zoom levels where micromapping is relevant. This minimizes performance impact and visual noise.

  • Simplified Layering: Start by rendering these areas strictly below the linear road network but above general landuse. This preserves the visibility of the routing graph (names, refs, directionality) while filling the visual gaps.

  • Subtle Styling: Use low-contrast colors that match existing highway fills to maintain the map’s legibility.

Why This Matters Now As OSM matures, “completeness” is shifting from adding missing roads to refining existing infrastructure. Micromapping is the future of active contribution in well-mapped regions. By refusing to render the primary tag used for this activity, we risk alienating our most dedicated contributors.

I invite you to read my full comment on the issue and share your thoughts. Is it time we treat area:highway not as an abandoned experiment, but as a critical component of our data model that deserves visibility.

Read My Latest Proposal On The GitHub Issue

13 Likes
2

I honestly don’t think that a raster slippy map like OSM Carto is the best fit for this kind of micro-mapping. Carto is not served beyond Z19 (and stops at Z20).

There are now an abundance of styles. Indeed you suggest that 3 renderers are already show highway areas?

A dedicated project for high-quality micro maps would allow you to explore all kinds of details e.g. kerbs, crossings etc. that will never make it into the standard layer.

1 Like
3

I’d quite like to see this developed a bit more. It was nice to see it rendered in Streets.GL before the project was abandoned.

Apart from the frequent mis-tagging of traffic islands and sidewalks as highway=pedestrian + area=yes, I’ve even seen one of the more prolific local taggers for the renderer abuse highway=service + area=yes instead of area:highway=residential because the former is rendered in Carto. (They also have/had a habit of turning individual natural=tree nodes into very small natural=wood polygons around the tree’s canopy and bending other land uses around that.)

I’d quite like to see a couple of new area:highway values:

area:highway=sidewalk to allow the geometry of the sidewalk to be mapped, but without adding a decorative highway=footway + footway=sidewalk way which breaks pedestrian routing. (We’ve already got area:highway=footway for the cases where a linear highway=footway is present).

area:highway=parking where something like parking:both=lane + parking:both:markings=yes is mapped on the highway, together with the parking rules, but being able to see how much of the public road is reserved for the storage of private property.

1 Like
4

Chooses to ignore the data, I would say. Asking OSM Carto to do anything is a waste of breath, for several years now. Don’t count on OSM Carto to break the chicken-and-egg standoff.

Apart from that, I sort of agree that area:highway is useful, but in reality I only use it for central islands at roundabouts. As soon as a layout gets complicated, it takes an incredible amount of mapping time for no functional result. I have seen work done by others, but it looks like they have tested it once then stopped and moved on to more directly useful things.

I think a well defined use case with limited scope and a demo rendering is the least you need to pull this off. Luckily, it’s not a new tag, so you can define the data side within live OSM.

2 Likes
5

actually the wiki labels it as defacto: Key:area:highway - OpenStreetMap Wiki
it’s the original proposal that is labeled abandoned.

4 Likes
6

@Peter_Elderson Unfortunately I have to agree. The project feels stuck in a state where the maintainers’ conservative approach effectively dictates how OSM functions, often ignoring community input. I suspect the only path forward is replacing OSM Carto as the default if it continues to allow a small group to restrict mapping practices.

@dieterdreist You’re absolutely right, my brain was running out of steam when I wrote this post. Thanks for the catch on the wiki status.

@phodgkin I think this is more about the fact that OSM Carto occupies a special place as the default for the OSM website. Because it is the “face” of the map, I put a higher responsibility on it to actually reflect the direction of OSM generally. You’re likely right that I won’t achieve much with the current repo, but if they refuse to adapt to map data, it reinforces the need for a push to replace it as the default.

@rskedgell I also want to see loads more development of the tags! A key step for that is getting them rendered on the OSM website’s default style so mappers see the immediate feedback. I suspect this will eventually require moving away from OSM Carto to a renderer that can iterate faster.

2 Likes
7

We are increasing our use of vector layers. The Shortbread schema that powers our Versatiles colourful layer, which offers immediate response to edits, appears not to have area:highway in its street polygon layer at the moment, but there is a revised version being developed. You would have to ask Maptiler about the other vector layer we currently offer. You can also talk to @pnorman, who is developing a new vector renderer in Street Spirit.

4 Likes
8

CoMaps and Organic Maps render area:highway=footway, thanks for reviving the idea on Carto, I think it would be great to get it rendered. As mentioned elsewhere a big problem I have found is people tagging highway=pedestrian area=yes on things that aren’t pedestrian areas, just so they can be rendered on Carto.

2 Likes
9

The question is just if that direction is being reflected in this thread. It really isn’t a given that a majority considers area:highway something that should be promoted (which is essentially your point).

4 Likes
10

There’s an ongoing discussion about which kind of area this layer is for (including a suggestion to assume that some kinds of highway=* are implicitly areas).

The MapTiler OMT layer shows an open source stylesheet and vector tileset maintained by the OpenMapTiles project. Feel free to request the feature in their issue tracker. (There’s at least one style that would be eager to incorporate highway areas if only the vector tiles would expose them.)

1 Like
11

There is, but that’s not really about area:highway as a way of describing the area taken up by a linear highway, it’s about highways that a mapper thought were implicitly areas but because of the tags used aren’t interpreted by the Shortbread schema as areas. Here is one example; here is another. You could certainly argue that those are “just mapped wrong”; the issue is really about how the Shortbread schema should deal with that data.

Edit: grammar.

12

With regards to rendering area:highway, I’ve looked at that a couple of times in the context of map.atownsend.org.uk. The questions I always end up asking myself are “Which ones should I render?” and “What as?”. In the code for that style there’s a couple of specific cases handled only.

Can someone point to somewhere in UK or IE were information is genuinely missing from a displayed may because area:highway isn’t shown beyond those two exceptions? How should the currently invisible area:highway be shown (or processed in some other way)?

If it’s just a case of “knowing what is in OSM there” then a user-facing rendering may not be the best option - there’s already a query function on osm.org and in future OSM Spyglass may fulfil that role.

However, if there genuinely is information missing from a user-facing map (akin to “not showing a hedge”) then I’d like to see an example.

13

I don’t think I have used area:highway myself so I’m probably not the best person to answer, but perhaps the central paved area of O’Connell Street in Dublin is an example?

At the south of the street, this area is mapped as highway=pedestrian area=yes. Many renderers convey in some way a suggestion that it is an area where pedestrians can wander freely rather than following specific paths - which is true.

A bit further north, this way represents a very similar area in reality, tagged identically for many years. But recently, the tagging changed to area:highway. Some renderers no longer differentiate this part from the background land use.

To be honest I’m not sure if this says anything about area:highway rendering or just means the tag change wasn’t needed in the first place.

1 Like
14

I guess it depends what you mean by “information”. Urban, pedestrian-centric maps conventionally depict streets as two-dimensional spaces – even in the American cartographic tradition that otherwise shows roadways as schematic lines. Information about the shape of a street isn’t as critical to drivers, who generally travel along predetermined paths and can’t turn on a dime. But pedestrians operate at a different scale, so the volume of something as large as a street takes on more importance.

1 Like
15

Interestingly highway=footway + area=yes is rendered in Carto (using the same grey style as highway=pedestrian as an area).

If you can show that tagging practice has shifted in favour of area:highway=footway, then it might be easier to propose adjusting what is currently rendered rather than push for rendering all area:highway (although it is very weird that highway=service is rendered as an area but not, say, residential).

1 Like
16

OSM Carto used to render more highway=* area=yes areas but removed them out of concern about misuse. highway=service area=yes remains as a gray area, not quite a road. It’s analogous to a parking lot but not for parking, what American English speakers might call a “staging lot”.

17

That’s just

amenity=parking
parking=lane

isn’t it?

1 Like
18

The problem with tagging it like that, although you certainly can, is that data consumers will just get parking:both=separate and have to perform spatial queries in order to find out anything useful about the parking. There’s also the disadvantage that Carto renders it the same way as parking=street_side from z18, which I feel is a more prominent than it should be.

We have roads near me which are highway=residential + oneway=yes + oneway:bicycle=no + lane_markings=no + parking:both=lane, from which tags you can infer that you’re at risk of getting doored when you cycle that way.

19

And area:highway=parking doesn’t have this problem, because?
Your issues are real grievances, but changing the tag doesn’t really solve them. Both represent the same thing.

20

Because it only describes the geometry of the on-street parking, not the other properties which are better kept on the highway way and immediately accessible to data consumers.