Rendering of area:highway

[scaidermern]

It would be nice to see a rendering of the area:highway key. The rendering rules are similar to the regular highway key, including the highway class, except that this key applies to areas only (and should not be used for routing).

[dieterdreist]

if this should be rendered, there should be no casing (because of arbitrary intersecting lines coming from closing the polygons). Or use the area relation for this (type=area)

[theonlytruth]

area:highway is just a proposed feature. In my opinion the right solution is highway=* + area=yes

So from my side I would wish no rendering of this beta status key.

[dieterdreist]

2013/9/20 theonlytruth notifications@github.com

highway=* + area=yes

no, it is (more or less) agreed that this has different semantics: it is a
non-directional traffic space, accessibile by vehicles (unless highway is
pedestrian) but not a (directional) road. The intention of area:highway was
actually to avoid misinterpretations and to allow clear distinction between
a square and a road drawn as area.

[pnorman]

area:highway is just a proposed feature

That's not a particularly important consideration.

I support adding it because it should help reduce misuse of highway=* + area=yes, but the problem is how to go about adding it on the osm2pgsql side. Thoughts?

[dieterdreist]

Thoughts?

on the German tile server everything is hstore now with a very reduced style for columns, not sure if this performance wise could be an option for the main tile server as well, you surely gain a lot of flexibility

[pnorman]

I've been thinking about that - the obvious issue is that even though you can use a view to get a table identical to the current ones, you want to rewrite any query pulling from the hstore to be more efficient.

Something new like this would be 3.0+, so we've got some time to consider.

[scaidermern]

I support adding it because it should help reduce misuse of highway=* + area=yes

Thats the main reason why I created this issue.

[matthijsmelissen]

Is there support for this to be implemented? Should it be rendered the same as highway=XXX area=yes?

[dieterdreist]

This is a hard question, because given that the mapnik rendering is defacto
determining how people map, implementing this could result in people being
satisfied with only an area mapped (and rendered), therefor breaking our
routing in the long run.

On the other hand it seems reasonable and logical to map highways also as
areas, given the level of detail our map has reached in certain areas (why
should everything "extended" be mapped as area except streets?).

[matkoniecz]

It probably would not look well on lower zooms. Anyway, note that selecting any tagging scheme to be rendered means that only this will be used.

[floscher]

@dieterdreist wrote:
This is a hard question, because given that the mapnik rendering is defacto determining how people map, implementing this could result in people being satisfied with only an area mapped (and rendered), therefor breaking our routing in the long run.

If area:highway is only rendered at high zoomlevels, this would not be a big problem, as the lower zoomlevels would still depend on the linear highways.

[daganzdaanda]

I think sooner or later we will need rendering for highway areas. It's just a logical next step. Already, aerial images are good enough in lots of places.
It should only be visible in z19, and not be used for drawing anything at 18 or less. Then, people will not forget to put in the regular highways :)

What the best tagging is, I don't know. What are the alternatives?
area:highway or maybe landcover=something or...? IMHO area=yes is better only used for pedestrian areas, or maybe not at all if there are better alternatives.

[kocio-pl]

I think this proposal:

https://wiki.openstreetmap.org/wiki/Proposed_features/Street_area

is interesting to deploy, since it's more developed at the general level, however it may lack some tagging. In the (mostly duplicate) #1298 ticket I gave the link to demo rendering script for Maperitive:

https://github.com/javnik36/highway-area-style

and additional proposition:

"I have also the idea to drop colouring by street type then (on highest zoom only) and start rendering them by surface type - I think that plus the real width and geometry would be more useful in micro scale."

[kocio-pl]

I know that we still wait for database update, but there are some real data rendering examples added lately and we could get some ideas how should we render such areas.

[Marekkleciak]

We have for today 62418 area:highway in the map.
We have enough test cases for further discussion. Check cites Szczecin and Wrocław e.g. here:
http://osmapa.pl/w/area/?lat=51.08998&lon=17.01772&zoom=17&ol=QqEFBAG

[kocio-pl]

Starting with basics, I like general colors used on osmapa.pl, related to physical features:

• dark grey pattern for roads
• red for cycling paths
• white-and-grey pattern for footways/pedestrian area
• light grey for traffic islands.

Any other ideas?

[Ircama]

• red for cycling paths

One think I would invite to consider (or at least to avoid precluding) is a future possibility to accommodate the representation of signed walking routes together with the already implemented rendering for highways. Being able to get over this challenge will provide new exceptional value to the map for many users. This is currently a default representation in traditional topographic outdoor maps targeted to hiking and mountain biking, where signed routes are generally represented with some kind of vivid or cardinal red color
(e.g., http://www.cicloweb.net/iti1gardavr.jpg or
http://3.bp.blogspot.com/-rChlsq-Mb1M/VoZlBPNdFqI/AAAAAAAAFDk/CUzXh5xomY0/s1600/Boccaor-Val%2Bd%2527Archeset-Val%2Bdelle%2BMure.jpg).

Related tags to be processed are here http://wiki.openstreetmap.org/wiki/Hiking and here http://wiki.openstreetmap.org/wiki/Walking_Routes. Namely, osmc:symbol, ref, symbol, operator, network in case of highway=track or highway=path, which should generate red routes with optional road shield and related refs text.

So, providing space for such color within routes (including cycling paths) would be really good IMHO.

[kocio-pl]

I think that cycling paths can be also orange. But first I'd like to know if we plan to render any routes - I guess universal style is not about searching and guiding, rather explaining the space.

I think we have public transport and cycling layers on OSM.org exactly because of this, we need probably another layer just for hiking there. In the meantime there are some independent specialized maps like Hike&Bike or OpenTopoMap.

[Ircama]

In the meantime there are some independent specialized maps like Hike&Bike or OpenTopoMap.

Yes I know. I really admire the achievements of those specialized maps.

[mboeringa]

Please note that implementing area:highway is only really useful if this includes proper rendering according to the layer=x tag. If this tag is not respected in the rendering, many complex highway junctions with multiple flyovers will become illegible random stackings of highway areas.

Additionally, it is likely man_made=bridge must be rendered according to layer=x as well.

Both of these can be a major challenge to implement. I have succeeded in adding this functionality to my ArcGIS Renderer, and this was quite a job, but I don't know what the consequences are for the carto style...

[d1g]

@pnorman, I would say more if area:higway=* will get support in openstreetmap-carto I would expect drop in area=yes together together with highway=*.

area:higway was never supported by openstreetmap-carto, right?

[ZLima12]

This seems to have been forgotten about. I don't think that the average user would consider this to be too much detail, especially if it is only rendered at the highest zoom level. In some public parks, for example, this could add a nice level of detail.

[imagico]

One option to address this (kind of) would be to render area:highway polygons in a uniform styling in (or immediately above) the landcover layer. That would be a bit like #3872 (which we gave up on highway polygons) but with uniform styling and only for the area:highway polygons.

This way we would be able to provide visual feedback on the mapping but without running into the various problems mentioned above.

[jeisenbe]

without running into the various problems mentioned above.

Would there be no casing? How would we handle situations where multiple layers of area:highway= are mapped on top of each other, e.g. where there are bridges or tunnels?

[dieterdreist]

sent from a phone

On 4 Feb 2021, at 02:43, Joseph E ***@***.***> wrote: Would there be no casing? How would we handle situations where multiple layers of area:highway= are mapped on top of each other, e.g. where there are bridges or tunnels?

in architecture, when there are hidden lines which you want to show (and this is important, because all hidden lines would often be too much), you draw them above, but in a dashed style. This style draws tunnels below (necessary because they also have a fill) which leads to situations where they are completely covered. Christoph’s suggestion would work, but would lead to multiple lines for the same road, which would lead potentially to confusion or ugly rendering in some zoomlevels (appearing as “double casing”)(resulting from (even partial) overlap of highway lines and areas. Rendering areas between highway fills and labels (including symbols like oneway and stop), and only in highest zoom levels, would IMHO lead to a better looking result, particularly when sidewalks and carriageway are represented with individual areas, or explicit kerbs are drawn. The higher level of detail would overrule the highway centre line display (potential problem could be people refraining from fixing the highway grid because it visually works with areas alone)

[dieterdreist]

sent from a phone

On 4 Feb 2021, at 02:43, Joseph E ***@***.***> wrote: How would we handle situations where multiple layers of area:highway= are mapped on top of each other, e.g. where there are bridges or tunnels?

the areas should respect explicit layer tags, as should bridges and buildings ;-)

[imagico]

Would there be no casing? How would we handle situations where multiple layers of area:highway= are mapped on top of each other, e.g. where there are bridges or tunnels?

It would all be flatly rendered in uniform color in or directly above the landcover layer so there would be no layering issues, artefacts due to interference with linear highway mapping or added complexity in the already complex roads layers.

An overall outset casing would be possible but IMO probably not desirable - it would hardly provide additional feedback, would add noise and could be prone to confusion and ugly interference with line feature rendering like barriers.

The idea would be to acknowledge and provide basic feedback on the data that is being entered but equally acknowledge and not try to ignore that neither consistency in established mapping conventions nor our technical constraints here in combination with our goals allow more specific rendering.

[dieterdreist]

sent from a phone

On 4 Feb 2021, at 12:57, Christoph Hormann ***@***.***> wrote: It would all be flatly rendered in uniform color in or directly above the landcover layer so there would be no layering issues, artefacts due to interference with linear highway mapping

in lower zoom levels these would usually be covered by the linear highways, but in levels like 18 I imagine artefacts due to linear highways covering partly or almost the road areas, you would have tiny bits visible here and there below the highways and their casing.

[Marekkleciak]

We could use color table with different grey colors for area:highway= and layer =< n>
For instance:

If somebody her could try the look in one complicated situation?

[imagico]

in lower zoom levels these would usually be covered by the linear highways, but in levels like 18 I imagine artefacts due to linear highways covering partly or almost the road areas, you would have tiny bits visible here and there below the highways and their casing.

That depends on the highway type and latitude. For footways/tracks the polygon rendering would be visible fairly early already - like in case of the example mentioned in #4316. In case of larger roads it would be visible starting at z16-z18 depending on latitude. It would not be more of an artefact than with existing landcover rendering where it is not mapped up to the road center so it shows as negative space.

[matkoniecz]

We could use color table with different grey colors for area:highway= and layer =< n>

This is problematic as layer tag is solely about relative layer of object at the same location. This would unilaterally redefine this tag to have different semantics.

[ZLima12]

If anyone needs a good test case for this, see this park that I mapped. I think it would look great here.

[krolinventions]

@pnorman Sorry for creating a new issue, I though the others which are years/decades old would perhaps be outdated.

What would the next steps for me be if I would want to pursue this (and put some effort in)?

Would you accept a PR? I would not mind giving it a try even if it turns out that it would have to be declined (for example, because it turns into a mess).

Would I have to find consensus on the way this is mapped or are we fine in this regard?

Is there another place I should go to discuss this?

[imagico]

What would the next steps for me be if I would want to pursue this (and put some effort in)?

To bring forward any new arguments on the matter here without reiterating discussions we already had. In addition to the discussion above there is significant further context to consider, a summary of some of it can be found in #172 (comment). Other aspects are mentioned in #4948 (comment)

Generally speaking the OSM-Carto road rendering system is complicated - but despite this complexity has numerous limitations. A discussion of most of this can be found in https://imagico.de/blog/en/navigating-the-maze-part-1/.

Would you accept a PR?

I would strongly suggest to discuss whatever concept you have for rendering before investing into a concrete implementation. Various arguments regarding various ideas have already been discussed so make sure you take them into consideration.

Would I have to find consensus on the way this is mapped or are we fine in this regard?

Is there another place I should go to discuss this?

A renewed look what the de facto semantics and use patterns of these tags would definitely be helpful, not only for OSM-Carto. Documentation on the OSM wiki is largely consisting of prescriptive ideas on tagging rather than documentation on how tags are actually used. Last time i looked a lot of area:highway essentially implemented manual buffering of constant width roads while there does not seem any consensus (or attempts to build consensus) on if that is a suitable way of mapping or not. In terms of aggregated use numbers all area:highway tags together are currently used 268k times. Compared to that the width tag on highway=* (which we don't render either) is used 2.75M times.

By far the most commonly tagged value of area:highway is footway - which bears the question of the semantic delineation between area:highway=footway and highway=footway on polygons (which we render - with the constraints of our current handling of road polygons). This is especially the case since many of the area:highway=footway polygons in the database contain junctions.

Discussions on how things should be tagged and mapped should go to different places, ideally where a broad range of mappers can be reached.

[krolinventions]

@imagico Thank you! I've read those links and I'm not discouraged yet.

I would try the simplest possible solution. The area should be drawn just before (below) the road. I would not mind the way of the road showing over top of the road area. For cycle paths and footpaths this is completely fine and this will even make the map easier to read. A future enhancement could be to detect if there is road area and use a less obtrusive way of drawing the way itself.

I've tested highway=footway area=yes. Those don't show up for me. The only thing I can get to show up is highway=pedestrian area=yes. See https://www.openstreetmap.org/changeset/150052388#map=19/52.16667/4.47920 for an experiment with area highways.

I've done some initial research in some cities on the area=yes and the area:highway using overpass, and the vast majority of the area=yes usage is pedestrian zones. Which isn't surprising as there is consensus over those. This means that for all other highway types the area:highway is much more common.

It looks like that for half of Manhattan all the sidewalks are mapped as highway=pedestrian area=yes so maybe I should just use that for now and see if I get complaints. Changing the tags on an area isn't that much work anyway if the consensus shifts.

I'll report back if this works well enough for me or if I really need cycle paths and traffic islands to show up. Leaving the road itself as a void works fine for me, I don't care too much about cars anyway.

[dieterdreist]

sent from a phone

On 15 Apr 2024, at 21:28, Gerard Krol ***@***.***> wrote: I've done some initial research in some cities on the area=yes and the area:highway using overpass, and the vast majority of the area=yes usage is pedestrian zones. Which isn't surprising as there is consensus over those. This means that for all other highway types the area:highway is much more common.

it is not the same, area=yes means non linear traffic space, area:highway is not telling you this, it can also represent linear space.

[imagico]

I would try the simplest possible solution. The area should be drawn just before (below) the road.

Rendering all area:highway=* polygons flatly below all roads (essentially like a landuse=road mapping) has already been discussed - see #180 (comment).

I've tested highway=footway area=yes. Those don't show up for me.

It quite clearly does:

https://imagico.de/map/styleinfo/#style=osmcarto&section=tags&key=highway&value=footway&ftype=polygon
https://www.openstreetmap.org/way/436187783

[krolinventions]

@imagico I see you mentioned it, but I don't see what problems with it were discovered? The replies to it look positive to me.

I wonder what went wrong with highway=footway area=yes for me. I probably just tagged it wrong.

@dieterdreist I know it's not the same - but it's not too wrong and at least it shows up. GraphHopper seems to route along the edges sometimes but that's not too distracting. Actually on a sidewalk you can walk wherever you want anyway. If Carto gets support for area:highway I'd definitely switch to that.

[imagico]

I see you mentioned it, but I don't see what problems with it were discovered?

No one has so far made a compelling case how this would be beneficial for the goals of this project. It was brought up as a potential way to avoid the various technical problems mentioned while still formally adding rendering support for the tags. That does not mean it is a good idea.

The most important question you would need to answer is probably: What existing consistent mapping practice is the rendering supposed to support and is it realistic for the suggested design to actually do that?