[styles] Add rendering for road area:highway

[JokelaR]

This PR covers the area:highway half of #7207 and adds rendering for values of area:highway= matching most public roads:

• motorway
• motorway_link
• trunk
• trunk_link
• primary
• primary_link
• secondary
• secondary_link
• tertiary
• tertiary_link
• unclassified
• residential

The priorities and style colors are all matched with the respective highway= tags.
Current state of the PR is with the styles sequestered in their own /clear/include/Road_areas.mapcss file, which is relatively imported in the other styles' style.mapcss files.

highway-footway, highway-footway-area, and highway-footway-bicycle priorities have been bumped up to make sure they are still visible when crossing a highway area.

This PR also contains a style rule for [highway=pedestrian][area], but that seems to need further work before it works correctly.

Example of an area with full area:highway coverage

Example of an area with partial area:highway coverage.

Example of a layered area.

[biodranik]

Thanks!

1. Are there roads that were not routable before due to this issue?
2. What about the routing? Does it work?
3. What about a linear feature? Is it still there, above or below the area feature?
4. Does a long-tap on it work?
5. The main idea was to support routable areas and improve the routing, how close are we to it? CC @vng
6. What are other issues or improvements left/discovered?

[JokelaR]

Hi,
This PR is limited to style changes focusing on the area:highway= tags. These tags only describe the physical shape of the road outline, and thus are usually disregarded by routers (they come with a centerline highway= tagged way for routing).

Linear features are still rendered as before, and provide a convenient source and centerline target for labels and one-way arrows on roads with mapped area:highway= without any extra work needed.

As for issues, I could not seem to apply an area rendering style to the non area: prefixed pedestrian areas (mapcss rule area|z12-[highway=pedestrian][area] did not seem to apply, instead it'd just render the perimeter of the pedestrian area as if it was a linear way (this is current live app behavior)).

[vng]

I have mixed feelings here. We did the same 10 years ago. And got negative feedback and reverted it.
Probably, OSM data with area:highway=XXX is much better now ..

@pastk @Zverik WDYT?

[map-per]

I don't really like it. It's inconsistent with the rendering of area:highway=footway, for which a way less intrusive background shade is used.
And in general I don't think that there is much value in rendering area:highway for cars, as road shapes are very predictable. It's not like pedestrian areas that often have sophisticated shapes.

[Zverik]

Yeah my opinion is the same, area:highway is an interesting experiment but not suited for any kind of public use. It is confusing to see, since it's not widely mapped, has no purpose, and generally is a weak attempt at replicating satellite imagery.

Also supporting the tag would prompt people to map highways as areas, complicating updating roads everywhere.

If you want highways as areas, just add imagery.

[JokelaR]

While I do agree that it a high workload tag to support, I find the idea that aerial imagery is a simple replacement for it unconvincing. Single source satellite imagery tends to have a very variable quality, trending towards unusable in northern latitudes.

Similarly I find supporting displaying tagged areas where they are present meaningful in the same way that displaying landcover data is meaningful, as a complete map. The use case is having an accurate picture of the environment you are navigating while still having the visual abstraction of a map.

[Zverik]

On imagery, how do you map highway areas on OSM when the imagery is missing? It's not something you can survey and bring home. Well, apart from professional surveying with teodolytes, which is typically not done for OSM.

[JokelaR]

By using local high quality aerial imagery that is not really suitable as-is for consumer map use (think without manual setup per city). That being said I don't think the process requirements of mapping a specific tag is in scope for discussion on a PR for rendering it.

[RedAuburn]

I like it, maybe it can only be rendered at high zooms?
Apple Maps, Google Maps etc. do something similar.

[Zverik]

We should also consider that adding those to the style increases the download size for maps. If we have few highway areas, they would look out-of-place, unexpected. If we have many, the download size would grow and we need to rationalize the benefit of having those, besides "anything present on the map helps navigating".

[JokelaR]

I have my doubts that the area:highway dataset would result in a meaningful increase in storage usage. building= shapes are a more major contributor to dataset size in urban areas.
That being said, if you have ideas on how to accurately assess the impact I'd be open to it.

[RedAuburn]

How about rendering of road width then? I think it'd be really cool/useful to display lanes & markings etc.

[biodranik]

It would be great to focus our energy on important and beneficial features/improvements that help/target most of our users in the first place. Ilya mentioned several cons already. I would add a slower map rendering here too. Faster map downloads/updates are also critical to reach an experience comparable with Google or Apple maps in the future.

It would be great to keep OM's focus on its simplicity, speed, lightweight, and low battery usage.

Rendering width is a great idea btw, is it widely used?

[Misalf-git]

It seems to me area:highway for roads may be useful, as it provides visual hints (especially important if location is not available).
If map size and/or performance is a problem (or even if not), maybe a downloadable "Detailed Roads" map layer would solve that?

[matheusgomesms]

Just to give some context, this is what NYC looks in Apple Maps, high zoom level:

Google Maps does the same, in a lesser fashion.

Edit: I would try to add the lanes on top of that, if it's possible. Because otherwise, while I like the idea, seems like a giant lane to me.

[JokelaR]

I would try to add the lanes on top of that, if it's possible. Because otherwise, while I like the idea, seems like a giant lane to me.

You're very unlikely to see physically accurate lane markings on any OSM project for a long while, if ever. area:highway= tags can accurately depict the footprint of the road, but not its internal markings. A combination of width= and lanes= can approximate the lane geometry, but it'll always have messy transitions between way segments that have different lane counts because there's no tagging system for how steep a lane ending or beginning is, for example.

[matheusgomesms]

I was thinking of an approximate representation, such as divide width (obtained by geometry) by number of lanes (lanes=* tag). Also use turn:lanes on top of that as well.