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...

[Marekkleciak]

This is good comment, that's true. I would suggest colors:

Layer = -5 -> colour=#171717 Layer = -4 -> colour=#282828 Layer = -3 -> colour=#353535 Layer = -2 -> colour=#434343 Layer = -1 -> colour=#505050 Layer =0 -> colour =#5d5d5d Layer = 1 -> colour=#6b6b6b Layer = 2 -> colour=#787878 Layer = 3 -> colour=#868686 Layer = 4 -> colour=#939393 Layer = 5 -> colour=#a1a1a1 Layer = 6 -> colour=#aeaeae

This should be enough for most complicated situations.

[mboeringa]

This is good comment, that's true. I would suggest colors:

I am not entirely sure what adding colors is going to solve. The features will still be stacked incorrectly if not processed and ordered by the style and/or osm2pgsql.

In addition, layer = 6 is not valid according to Wiki. I don't think expanding the allowed values is wise from a rendering point of view. Before you know it, people will tread layer as level, and demand layer = 99 to be rendered as well... The main point though is that each additional supported layer value also results in extra drawing cycles and thematic layers needed to be processed in a style and renderer, whether Mapnik or something like QGIS or ArcGIS. At some point, and with 11 valid layer values we may already have reached this point, this becomes wholly impractical to deal with.

E.g., for my ArcGIS Renderer, I render these 14 thematic layers in a layered fashion using OpenStreetMap's layer = x tag:

• Highway (Lines)
• Highway (Lines) - Bridge
• Highway (Lines) - Tunnel
• Highway (Lines) - Crossing
• Highway (Lines) - Large Scale
• Highway (Lines) - Large Scale - Bridge
• Highway (Lines) - Large Scale - Tunnel
• Railway (Lines)
• Area:highway (Polygons)
• Area:highway (Polygons) - Road Markings (e.g. buslane, emergency etc.)
• Highway (Lines) - Oneway Arrows
• Highway (Lines) - Oneway Arrows Dark (dark version of arrows)
• Highway (Lines) - Oneway Arrows Cycleway (arrows for cycleways only)
• Man Made (Polygons) (bridges, viaducts as areas)

With potentially 11 values for each thematic layer, this may result in 11x14 = 154 ArcGIS Feature Layers in the Table of Contents of ArcMap. That is already pretty gruesome... let alone with more values.

From a practical point of view, I am pretty sure the 11 values from -5 to 5 should cover all conceivable real world situations, as long as people stick to what layer was supposed to solve in the first place - a rendering issue for outdoor highways and railways - and not tread it as level.

[pnorman]

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

Over the last years my support for adding this has become more reluctant. I would oppose adding it because I think it results in bad cartography and the view that a map is a vectorized aerial image, except it has the potential to reduce misuse of area=yes highway=* tagging

With potentially 11 values for each thematic layer, this potentially results in 11x14 = 154 ArcGIS Feature Layers in the Table of Contents of ArcMap. That is already pretty gruesome... let alone with more values.

Some time ago we stepped away from the need to have code for each possible value of layer. This is a good example of why we're not stepping back. Anything that having code for each value poses an unacceptable maintenance burden on what are already some of the most complex layers in the style.

Please note that implementing area:highway is only really useful if this includes proper rendering according to the layer=x tag

Except for some bugs and edge cases I think we've got the use of layer=* we want. What to draw on top of other objects is a cartographic choice, and we've made ours.

[Marekkleciak]

Pnorman, you wrote: " I would oppose adding it because I think it results in bad cartography and the view that a map is a vectorized aerial image, except it has the potential to reduce misuse of area=yes highway=* tagging"

Could you explain why it results in bad cartography?

1. Everywhere area:highway was drawn the result is better positioning of midline vestor of the street, also the footways are collected more carefully.
2. The real problem is, that area:highway mapping is possible only in areas with very good resolution of aerial images. But we get such images step by step. We had the same problem with buildings some years before. The resolution of Bing was not good enough and the results were pretty bad. Now we can map more precisely.
3. Area highway mapping made mostly very experienced mapper. And they are mostly carefully.

And : "With potentially 11 values for each thematic layer, this potentially results in 11x14 = 154 ArcGIS Feature Layers in the Table of Contents of ArcMap. That is already pretty gruesome... let alone with more values."

Please look at this: http://www.darkroastedblend.com/2006/11/incomprehensible-intersections.html I tried to analyse how many levels are neccesarily. Maximum I saw is seven.

I made one mockup: http://wiki.openstreetmap.org/wiki/File:StudyAreaHighwayLevelsRendering.jpg It is just seven. I got it only by adding of black to the basic colour. So, if needed I can prepare color table suggestion for all elements.

Best, Marek

[mboeringa]

Some time ago we stepped away from the need to have code for each possible value of layer. This is a good example of why we're not stepping back. Anything that having code for each value poses an unacceptable maintenance burden on what are already some of the most complex layers in the style.

Totally agree, and this why I developed an automated routine to generate each ArcGIS Feature Layer for a particular OSM layer = x value from a single base ArcGIS layer file as a copy of that base layer, which seems to be a bit of an analogy of what carto currently appears to be doing according to your words ("we stepped away from the need to have code for each possible value of layer").

So I essentially automatically "clone" the symbology from a base layer file. This means users only have to maintain symbology once for each thematic layer, so in the example I gave, there are just 14 base ArcGIS layer files to maintain, not 154 for each permutation of thematic feature layer and OSM layer value...

Since I auto-generate the copies of the ArcGIS feature layer - which only exist as part of an ArcMap document, not on disk - from a purely technical point of view, it would be no problem to support e.g. 100 OSM layer values (0..99).

I'll leave it to your imagination what the practical consequences would be of trying to render 1400+ layers...

I tried to analyse how many levels are neccesarily. Maximum I saw is seven.

So, basically, with these extreme examples, we are still safe with 11 available OSM layer values (-5 to 5).

In fact, from a practical point of view, it is a misconception that to render the data properly visually, you need to make all flyovers their own distinct OSM layer value. E.g., if you look at the underlying data from this Atlanta junction:

http://www.openstreetmap.org/#map=17/33.61748/-84.48647

you will notice that despite an apparent 3 or 4 road "levels", the highest OSM layer value used is just layer = 2! This is a good example of proper usage of what layer was supposed to do: solve a render issue, not define absolute heights or levels, by only using a higher layer value for the extent two road lines cross, not over the entire length of a flyover (which isn't necessarily wrong, but may lead to technically unneeded higher maximum layer values, in the sense of not needed for properly stacked visual rendering).

[Marekkleciak]

Exactly. In my opinion different colours for level=* are not neccesary if we used outline shapes for area:highway elements. See mockup:

http://wiki.openstreetmap.org/wiki/File:MockupAreaHighwayWithStreetOutlines.jpg

[dieterdreist]

2016-09-16 11:18 GMT+02:00 Marekkleciak notifications@github.com:

Exactly. In my opinion different colours for level=* are not neccesary if we used outline shapes for area:highway elements. See mockup:

+1, (thin) outlines are desirable for these areas, at least in certain (high) zoom levels, they can show the borders of them (e.g. curbs) also in case there are many adjacent areas (and we decided to use the same color for all of them)

[polarbearing]

area:highway is not even an agreed mapping method, it is used in two separate proposals which are immature and contain questionable tags and analogies, see the dispute about area:highway=emergency or Plumbing principles. That needs to be sorted first.

From my perspective it is mostly a playground for couch mappers who have already drawn all building outlines in their area and want to vectorise more from their aerial imagery, with limited usability.

[Marekkleciak]

Well, I assume, the most of mappers do already their work using aerial imagery.
Regarding a:h=emergency: I wrote in the link above my point of view. In fact, we have in the zoom level 19 rendering of a lot of more or less useful details but exactly the streets, and we have the name OpenSTREETmap have no good representation.

Please look at this: http://www.openstreetmap.org/#map=19/48.87373/2.29567 The mapper collects already the most information needed for rendering of area:highway but we don´t do it.

There is also an other point: Please keep in mind, by all differences, about "wikipedia effect". In areas, where everything is collected, mapper stops to map. Extending of map rendering with area:highway would give us all new impulses.

[d1g]

area:highway is not even an agreed mapping method

@polarbearing AFAIK there no second proposal that actually tries to replace or enhance Marekkleciak efforts.

Proposal from flaimo merely states "uh oh we don't have tagging for 2D roads" with area:highway=* as the only tag in scheme: https://wiki.openstreetmap.org/wiki/Proposed_features/area:highway#Values - it is unclear what should we do about priority (major/minor service road) or with pedestrian areas.

To me, it is the only method. We need at least one tagging scheme for highways as areas. Details how we should tag splits roads/footways on crossings can be improved over time.

or Plumbing principles. That needs to be sorted first.

"Questionable analogies" by Imagico has nothing to do with tagging/carto style IMO. But yes, feel free to improve descriptions/language/wiki: "Road crossings are separate from roads" - is it better than "Plumbers principle"?

[mboeringa]

it is unclear what should we do about priority (major/minor service road) or with pedestrian areas.

In my personal opinion, there is very little use of rendering road classification (as in motorway,trunk,primary etc.) at the maximum zoom levels where area:highway rendering is applicable. Road classification is most useful at mid to small scales.

Instead, in my ArcGIS Renderer, I actually render area:highway indirectly: in reality, I render "surface=x", but only for those features additionally tagged with area:highway.

Showing surface=x is exactly what most large scale (cadastral) maps do. They don't usually show the road classification at all, think of detailed CAD drawings of a planned new neighbourhood, but surface types (set, concrete, asphalt etc.) instead.

By rendering surface=x combined with area:highway=x, there is a nice positive incentive to tag both, which really should enhance the usefulness of this data in the OSM database for different purposes.

[polarbearing]

I'm not against the area:highway in general, it just has to be consolidated into an agreed mapping style first, avoiding bizarre extremes as tagging the angle of the hatch painting of the road.

My fear is that it might tempt some people to start mapping every segment of the white lines.

And yes, taking analogies e.g. from graph theory is better than from plumbing.

[d1g]

as tagging the angle of the hatch painting of the road

It depends whatever local highway code has rule for it. If yes, we potentially can use this data to simulate traffic or at least to have less uncovered questions "how to tag X from highway code". Real problem with that if highway code (read: infrastructure) is different across countries.

[pnorman]

Could you explain why it results in bad cartography?

A map chooses what data to represent and is a representation of the world. We don't strive to be a reproduction of an aerial photo, which is mostly what I've seen with area:highway examples.

I want to remind everyone to stay on topic - uses of area:highway or similar tags which aren't related to OpenStreetMap Carto (e.g. simulations) are off topic here.

[Marekkleciak]

Paul, look at this: http://taginfo.openstreetmap.org/tags/area=yes#combinations highway=* with area=yes ->240 314 elements highway=footway with area=yes34 766 elements

You wrote: we don´t strive to be a reproduction of aerial photo. May be, but many users do exactly this using wrong tagging which disturb the most of routing engines.

[d1g]

We don't strive to be a reproduction of an aerial photo

You simply can't reproduce real world without "colour" information (or very low-level details tagged by material science experts: too many reasons about why paving stones may/have different "colours".

All fresh asphalt looks the same, give it 10 years in rural area and it will be hard to distinguish from the surrounding soil.

If you render everything as fresh asphalt in dark grey/black then you go unrealistic route already IMO: making all roads eye-candy when they (or some of them) are unmaintained IRL.

I have to agree with @mboeringa it make sense to render it at z18+ levels and there clear advantage to use this (h:area) approach at 19+ levels.

At 10-15 you want to find yourself in the city At 15-18 you can scan several kilometres of the surrounding and plan your actions At 19 fine details of the roads can be rendered instead of their generalizations

Other area features already rendered in detail at z19: kerbs, parkings, linear barriers

[Marekkleciak]

I agree with that as well. At zoom level 18 area:highway is not neccesary.

[dieterdreist]

2016-09-19 2:15 GMT+02:00 Paul Norman notifications@github.com:

A map chooses what data to represent and is a representation of the world. We don't strive to be a reproduction of an aerial photo, which is mostly what I've seen with area:highway examples.

it is your interpretation that people mapping precise geometry of road surfaces are striving to reproduce aerial imagery. As aerial imagery is reproducing (more or less) faithfully the actual geometry of the real world, it is clear that some resemblance between them and a mapped road surface occur (they are both representing the same thing). It is a question how you want to use the data which representation works better for you, and for some uses you will have great benefit from a faithful surface representation, e.g. when looking at sealed surfaces, when doing surface routing, etc. while for others you would need a graph model. For nice high zoom rendering it is surely beneficial to have actual surface shapes, hence this style should (IMHO) support it.

[kocio-pl]

If you render everything as fresh asphalt in dark grey/black then you go unrealistic route already IMO: making all roads eye-candy when they (or some of them) are unmaintained IRL.

It will simply be closer to reality than currently. Water in the river may not always be blue, but so what?

I see it from a different perspective: how much more realistic is red/yellow/white line with constant width at z19?

[d1g]

I see it from a different perspective: how much more realistic is red/yellow/white line with constant width at z19?

Many users said that highway classification by importance (this is what rendered using different colours in highways=*) is meant to quickly orient yourself in unknown city. It is not good for routing defaults (compared to surface), detailed rendering e.t.c

Well we can disable ordinary linear roads at z19, they are not able to capture uneven widths of the roads (parking, lanes, other reasons)

[mboeringa]

Well we can disable ordinary linear roads at z19, they are not able to capture uneven widths of the roads (parking, lanes, other reasons)

I don't think that is an option. It would mean missing roads for large parts of the globe at Z19. Maybe a switch at a future Z20 zoom level (currently not available), would be an option, but I solved it by overlaying the area:highway features on top of the line rendering in my personal renderer.

That, however, requires the line-version road widths to be less than the average comparable area:highway feature of the same highway class to completely hide the line representation for optimal cartography. That is probably not the case in Carto, as Carto uses pretty wide roads at high zoom. In my personal renderer, linear ways are admittedly much narrower.

I actually need the linear representation below the area:highway features to still provide the street name labelling, although I could potentially solve this by creating a new layer without symbolization but with labels, but this way I keep having (linear) roads at highest zoom levels even where area:highway is missing (which is by far the majority of the globe of course), they just disappear below the corresponding area:highway features.

As you can see, even from a simple cartographic point of view, it is not such an easily solved issue and also heavily depends on the base style already in use upon implementation.

Anyway, these are samples from my ArcGIS Renderer to give some ideas. I only show the area:highway features from a scale of >= 1:2500. Notice as well that in the third image, area:highway = x and man_made = bridge features honour the OMS layer = x tag:

[Marekkleciak]

congratulations! It looks really good. I like it.

[Marekkleciak]

User Tomasz_W sent me this: http://wiki.openstreetmap.org/wiki/File:Tomasz_W_Bridge_area_mockup1.png http://wiki.openstreetmap.org/wiki/File:Tomasz_W_Bridge_area_mockup2.png http://wiki.openstreetmap.org/wiki/File:Tomasz_W_Tunnel_area_mockup1.png http://wiki.openstreetmap.org/wiki/File:Tomasz_W_Tunnel_area_mockup2.png http://wiki.openstreetmap.org/wiki/File:Tomasz_W_Tunnel_area_mockup3.png

He is thinking abour better visualisation of bridges and tunnels from area:highway point of view.

[pnorman]

We talked about this at the SOTM hack day and decided to close the issue

• Implementing this change by rendering all objects of all types by layer tag is out of scope of this issue, and not an option for technical reasons. It is not practical, even if it is desirable.
• If we were to implement this change, it would be a simple rendering, probably just rendering the area in the colour corresponding to fills. None of the examples fit well with the rest of the OpenStreetMap Carto style.
• Making a map is about what data not to include as much as what to include.
• Rendering highways mapped as areas obscures the bridge and other topological information. Transparency is not an option.

[mboeringa]

I appreciate the difficulties of implementing something like this, probably as few others, having developed and implemented area:highway renderer in my own ArcGIS renderer. It was only after some careful deliberation, that I realized my models could probably be adapted to do this.

Nonetheless, I wonder what PR you are referencing? I think this issue was just about exploring the potential for it. I don't see any concrete PR, just ideas and some (mock-up) examples, including my own.

[Marekkleciak]

1. "Implementing this change by rendering all objects of all types by layer tag is out of scope of this issue, and not an option for technical reasons. It is not practical, even if it is desirable."

-> Exactly. And it is not necessarily. We need only one color value with outline for the following elements: street as general, footway, cycleway, bus stop, taxi stop, "emergency" or "dashed" areas.

1. "If we were to implement this change, it would be a simple rendering, probably just rendering the area in the colour corresponding to fills. None of the examples fit well with the rest of the OpenStreetMap Carto style."

-> Yes, we should implement as the first step a simple rendering of area in the colour corresponing to fills. Examples:

https://wiki.openstreetmap.org/wiki/File:MockupAreaHighwayWithStreetMidlines.jpg https://wiki.openstreetmap.org/wiki/File:MockupAreaHighwayWithStreetMidlinesBright.jpg

1. "Making a map is about what data not to include as much as what to include." Yes, we speak only about the highest zoom level. There is an important aspect: We don´t show turn:lanes as well. The polish rendering, let´s say here: http://osmapa.pl/w/area/?lat=51.76106&lon=19.48626&zoom=18&ol=Qq show that. You should go in the left corner down and use all options except the last both.
2. "Rendering highways mapped as areas obscures the bridge and other topological information. Transparency is not an option." -> This is the problem we have always, when we render a map. See e.g. here: http://www.openstreetmap.org/#map=19/22.28453/114.19181 I suggest use of area:highway rendering for the highest zoom level only.

[d1g]

@pnorman, Paul, even without colours we would be happy to see area:highways=* rendered (even most popular subset of it's classes)

If we were to implement this change, it would be a simple rendering, probably just rendering the area in the colour corresponding to fills.

That would be great to have, why decline it?

I would happy to see just outlines of such areas (without fills, without coloured fills) Similar to kerbs/berriers and other infrastructure https://github.com/gravitystorm/openstreetmap-carto/issues/180#issuecomment-247914821

[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.