Proposal talk:Area:highway

What's the difference between this and area=yes

Resolved: --Flaimo 09:41, 10 May 2011 (BST)

How does this differ from an area tagged highway=*|area=yes? I think you need to explain why we should not use that widely-supported and implemented tag. I suspect the answer is to do with routing and oneway directionality (area ways are routeable). You should state that these areas are assumed to have routeable linear ways inside them, maybe ☺ --achadwick 19:36, 9 May 2011 (BST)

It has nothing to to with routing at all. area=yes is used primarily for highway=pedestrian. If you would use it on the underlying 2D representations of streets too, routing programs would think, that they can use it for navigation. that is something you definitely don't want. all routing information should stay in the actual way tagged with highway=* (or in the future ways tagged as highway lanes). area:highway is basically just a visual element, like landuse. not even routable ways inside them are necessary (though it would be illogical to map it like that) --Flaimo 09:11, 10 May 2011 (BST)

clarified that is is only for visual purposes. --Flaimo 09:41, 10 May 2011 (BST)

highway=*|area=yes are for roads where you go in any direction, highway=* is for directional roads Mateusz Konieczny (talk) 16:48, 5 April 2016 (UTC)

For future clarity, I'd like to point out that this "directional roads" should not be taken too literally; on most roads, you may move in any direction (turn around, change lanes, cross the road, turn off the road onto properties) but if you do so, you just have to yield to all other vehicles/road users. An area of highway=* that allows vehicles is possible (for example in older quiet traffic residential areas), even if rare and wouldn't be designed/built nowadays. Rules on who gives way to whom still apply, but such rare cases can be accurately described with an area=yes highway. (Naturally, if there are painted or otherwise marked lanes, I'd find it near impossible to imagine an area=yes highway). Alv (talk) 17:56, 5 April 2016 (UTC)

Area relation

Stale

I remember there was some discussion in talk-it about enriching this kind of mapping with the use of Area relations. I think it would be a great tool for mappers, as this would allow us to disregard the (useless) perpendicular segments at the end of a way. --SimoneSVC 10:25, 11 May 2011 (BST)

i have a hard time understanding that proposal (and according to the comments there, I am not the only one). are there any real life examples mapped in OSM that i can take a look at? --Flaimo 11:59, 11 May 2011 (BST)

Look at this way. It is an old attempt at drawing the road as an area. Ignore for a second the tagging on that way and just look at its shape: it is made up by arcs that follow the shape of the buildings and are the actual border of the right-of-way area, and other arcs (straight segments) that are perpendicular to the road and are only there to make a closed line. The second ones are obviously pleonastic and should not need drawing. The area relation, in its simplest form, should allow me to group the first kind of lines under the relation, and consumers should recognise the relation as representing a closed area, without the need to explicitly close it. I hope this is clear enough. --SimoneSVC 13:32, 11 May 2011 (BST)

not really. all i see is a multipolygon. area:highway could also be used in conjunction with a multipolygon. i don't see any area relations that would help me, to understand the concept. --Flaimo 15:13, 11 May 2011 (BST)

As to the problem I pointed, I think multipolygons *should* work too. But what it happens is that, while Mapnik for example handles them correctly, Osmarender acts weird if only I forget to put "outer" on a segment. I'd be happy with better consumer support for multipolygons. --SimoneSVC 16:22, 11 May 2011 (BST)

I have come to this page today while trying to find the page I saw last year with a well developed plan for highway areas that I've been adopting in to my contributions for shy of year now. I did a lot of work initialy in trying to add missing walks and other foot routes into an exsiting area of large estate roads and the scale between a 1m wide footpath and 10-30odd metre wide highway made things very confusing. So after I found the area for highway proposal I found it solved the mismatching representaions. At first to help with backward compatiblity I used the suggested method of simply outlining the area of the highway and leaving all th discripters on the {now} routeing ling [ie. the original way to show the road.] this ment that routers could safly ignore the new type of boundry description, and safely calculate routes (taking into acount all the tagged restrictions on the routeing-way).

By ignoreing the the new area boundry lines simple navigator devices could extract simplified forms more suited to their potentialy smaller capacities.

At the same time a render or very local display can reuse the same orignal osm data to draw maps that show only small areas at a time. say a several buildings a parking bay (made into the varying width pavement/sidewalk/footway with distigushing features to a pedestrian like a postbox, numbered lamppost bench etc.), a front garden (decribed with landuse and barier tags). This to some might seem extreme but it is common to be able to buy maps of even higher detail than this for my country. When the trgectory to store gazters of domestic and bussiness addresses is already common on osm for data uses showing were a font door is at this scale is useful.

I've already had to adopt some of the indoor taging system to get to the entrances of appartments in blocks and Houses of Multiple Ocupation in my survey area so this defines the level I need to work at.

I found that as the definition became unclear to some they began mass-retagging moving tags onto the highway boundry and off the routing line that ment older renderering algorithiums began to make the boundries into new roads compleate with road feature decorations and additional multiple nameing (ie a mess), basic routers became confused with these new ways to direct users on around the same road! on and off footways crossed by the segmented highway areas on the way. I was not amused and largly took it as close to vandalism. -but it did seem to work in their own choice of updated render engine and conform to thier own validator system (which I deduce - hadn't been written to fitten the highway=area proposal properly in the first place).

Since when I've decided to follow the data maps comercialy sold in my contry and laid out the area for each part of the highway like carrageway, footway, cyclepath, grass verges and islands, barriers from headges to crash. Then after giving surface and basic function tags to the areas have then laid over the routing-ways for the cycles, general traffic, and pedestrians, running like normal though the logical middles (place dependant) and tagged these with things like traffic restrictions speed limits and other such normal highway tagging used by routers and others alike.

For some examples of areas still being done I edited as Govanus and the mass retagging is commonly form user mentor (-see way histories for details):-

An early example of the footpath realation problem this I need to go back to this estate and finish a lot of half done things still as I seem to be main contributer for here.

A simple example of a large service road wide enough to turn large cars into the garages on next to smaller features.

A good example of the routing around traffic islands. at a complex junction layout. Note the differences in scale between the differant types of facilities provided. It was also in my mind to be navigating (by a device reading this data), a blind person though maze of islands and missing the bikes!

Finally one last example with some work still to be done around here and just over the block here.

This level of area infomation is helpful when adding the requested lampposts (wanted in germany and for flight-simulator data users).

Some comercial referances I discused intergrated transport layer looks familar :)

the old raster product which was being marketed to parish councils to help map alotment garderns!

a generalised picture form the main master map page highlighted here that shows the kind of suface and function display on comercial large-scale mapping --Govanus (talk) 20:22, 21 May 2014 (UTC)

Usage

Stale

Some comments on the usage section:

• This kind of areas are not for routing, but rather visual purposes (like landuse), therefore use the "area:" namespace and not area=yes.

-- Why should they not be for routing, they are streets? I'd rather put it like this: "Current routing engines cannot route across areas, and it is very probable that there would be some preprocessing required to route across these features. You should use area:highway additionally to centre lines tagged with highway=*."

• Areas tagged with area:highway=* should not be connected with ways tagged as highway=*, otherwise it could lead to errors in some routing programs.

-- I think that it really doesn't matter, but if you suggested Area relations for these you would not need to prohibit connections, because they could not be there (there are no "artificial" connections to close an area if you map it according to this proposal).

• Since mappers use landuse differently, both variations are possible in conjunction with area:highway=*. Either map the area over an existing landuse area or map it besides landuse areas which can be adjoined at shared nodes (This proposal doesn't go into the whole landuse religion thing).

-- I am not sure if I get this comment right, but landuse=highway would logically (look at railway) be all areas belonging to the street, i.e. including ditches, drainage, shrubs and other lateral areas, shoulders, ...

• area:highway=* can be mapped over other areas like amenity=parking. Certain micromapping features, like for example amenity=parking_space should be mapped on the same level as area:highway=* and therefore can be adjoined at shared nodes.

-- Why do you point at parkings? Isn't this valid for all kind of areas? I agree to the second half of this statement though. --Dieterdreist 10:48, 11 May 2011 (BST)

1) the broad consensus in the german thread was that there should be a strict separation: one dimensional highways should contain all the routing information, and the areas should only be used for drawing purposes. i also agree with that. if we start to mix those two up, it would make it unnecessary hard for routing programs, without gaining much benefit. you could argue, that just one highway tagged with area=yes could be used instead of both elements, but that would become a problem sooner or later, when one day separate lanes get tagged in OSM. so i consider area:highway to be a pure visual information to make more detailed maps, but they shouldn't be used for routing.

2) as for the part of connection nodes: i also can't see a problem here from a routing point of view, but i would consider it best practice, just like you shouldn't connect building nodes to landuse areas.

3) my initial idea was something like landuse=traffic too, but most people in the thread opposed to that. they argue, that streets are something, that is put on top of the land and therefore on top of the landuse. the landuse definition is another big problem, that is why i didn't want to touch this topic with area:highway.

4) i tried to read the area proposal, but i didn't understand it. can you provide some mockup screens or maybe some elements in the OSM database that have been tagged like that already? maybe that would help me understand the concept.

5) the parking part is just an example. i can't possibly go through all elements and decide whether you map area:highway over them or connect them.

--Flaimo 12:31, 11 May 2011 (BST)

How the proposal is set up

Stale

Please try to reduce the proposal to the necessary and relevant parts and remove the "novel" aspects. IMHO there is not point at all in having a rendering section. Also the advantages section doesn't seem to be concentrating on actual advantages, e.g. It would be useful for timetables at public transport stop positions for example, or other "you are here" maps.. This has very very few to do with public transport. You are concentrating on details like zebra crossings. Please name the obvious and big advantages like accurate representation of the shape of the street, detailed barrier mapping, detailed complex crossings, detailed routing e.g. for disabled. The current state of the proposal makes this look like a "paint nice maps" feature, where instead this could lead to a huge improvement for all aspects of OSM data usage like routing as well. --Dieterdreist 10:57, 11 May 2011 (BST)

rendering suggestions can be made according to Creating_a_proposal#Page_details. I'll try to rephrase the rest, though routing is not part of the proposal and barriers and crossings are not part of the value list (only the values under the categories roads and paths). other highway values should be handled in separate proposals. for now the 2D rendering of the highway itself should be the priority. --Flaimo 12:37, 11 May 2011 (BST)

i rephrased most parts, dropped some details like the parking stuff. please reread --Flaimo 19:40, 11 May 2011 (BST)

landuse=highway

Resolved: i tried to explain it in the proposal now --Flaimo 19:43, 11 May 2011 (BST)

Why area:highway and not landuse=road or landuse=highway? This tag obviously marks an area used for a road, like landuse=residential, for example, marks an area used for residential buildings. And it would be more understandable by novices. --Zverik 13:36, 11 May 2011 (BST)

see point 3) two topics above. --Flaimo 14:20, 11 May 2011 (BST)

i also tried to explain it in the proposal now. please reread --Flaimo 19:43, 11 May 2011 (BST)

Areas are NOT for routing

Resolved: --Flaimo 21:49, 11 May 2011 (BST)

I think, the mainidea should be, that this Areas are NOT for routing. I think it is ineluctable to tag both separate.

1) The Ways as Area for creating Zoomlevel 19, or 20 2) The Ways as Line for routing.

Bad: landuse=highway and highway=secondary (Bad for existing routingprogramms) Bad: area=yes and highway=secondary (Bad for existing routingprogramms) Good: area:highway=secondary (No Problem for routingprogramms)

I think its a great idea, to tag 100% correctly. -- DennisB, 11.05.2011

it is clearly mentioned in the proposal, that it would be for visual purposes only. a seperate landuse=traffic value could be discussed separately. --Flaimo 21:49, 11 May 2011 (BST)

Junctions

Unresolved

We probably want separate areas for separate roads (unlike on the sample image), but in the case of two streets of the same type crossing, how would we tag the junction area? This is not an issue for T-junctions (the straight on road can be drawn on) or major roads crossing minor roads (the major road can be drawn on the junction area). It is an issue at probably all other junctions of two roads of the same (or at least not clearly hierarchically ordered types) and all types of junctions with more than two roads (except possibly for roundabouts as there are already rules about to which road a roundabout belongs).

the mockup screen is a bit outdated, since it is from the thread in the german forums. of course you would split the areas for each highway value. as for the junctions, i would say it depends on the situation, but i would say the area with the lower highway value is the one that gets split up and the one with the higher value stays a continuous area. another possibility would be, that junctions become a value of their own: area:highway=junction --Flaimo 19:33, 13 May 2011 (BST)

Proposal: Only if two ways are from the same type and nobody has to observe the right of way junctions should be tagged as junction. --DennisB 21:08, 18 May 2011 (BST)

Road surface marking

Resolved: clarified on how pavement markings are calculated --Flaimo 16:33, 15 May 2011 (BST)

How to specify the road markings? --Dr&mx 09:08, 15 May 2011 (BST)

You can use the surface key http://wiki.openstreetmap.org/wiki/DE:Key:surface cause this key is allowed at higway=* --DennisB 10:38, 15 May 2011 (BST)

i think he meant the white lines drawn upon the streets, not the surface material itself. this topic is currently also discussed in the german forums. personally i think, that pavement markings shouldn't be handled by this proposal at all, since the information could be derived from the overlying ways (or later lanes). renderers could combine the information tagged on the ways and the physical dimensions from the areas tagged with area:highway and calculate the markings this way. --Flaimo 12:41, 15 May 2011 (BST)

exactly. White lines. I decided that you propose change highway tag to area: highway

helpful stop-valve on the level of detail

OpenStreetMap has a long tradition of mapping lots of detail, and having tag proposals to match. If anyone wants to add particular details, nobody's going to stop them (certainly not me, I've always supported people's desire to map details) So of course some people go crazy. They map park benches and trees, and fences, and we all have a good laugh about it.

But there are two things which have always acted as helpful stop-valve on the level of detail we try to go to. Surely we cannot possibly map roads as areas, and surely we cannot attach sidewalks to all the roads. If we start to do that in one area then suddenly every highway in our database has a bunch of new ultra-detailed (and rather boring) mapping tasks associated with it.

So we draw the line there. You have to draw the line somewhere right? Well maybe not. Does it frustrate you that post boxes are represented as nodes and not areas? Like mapping trees as individual nodes? how about other plants? How about... blades of grass?

It would be stupid to place a node for every blade of grass in your local park. It's too much detail. But why is it too much detail? The answer is because you cannot reasonably expect other areas, even neighbouring areas, to be mapped to that level. as I said here, it's sensible to look at the wider area and think about how you (and others) might aim to achieve a consistent level of detail across that area. It's surprising how much detail you can gather when there's lots of people involved, but there are limits to this reasoning

-- Harry Wood 01:41, 18 May 2011 (BST)

Also check out part of my SOTM 2011 talk - blossoms, weeds, and blades of grass which talking about this level of details problem - Harry Wood 12:23, 18 May 2012 (BST)

Propose to use this option only in difficult places, such as junctions with 5 or more ways. On the normal way enough tag width and number of lanes. But can this option would take more resources? --Dr&mx 06:36, 18 May 2011 (BST)

everybody is free to map as vague or detailed as he or she likes. that's not your decision to make where to draw the line. only because a way of mapping detailed something exists, doesn't mean you have to apply it to every element whenever possible, otherwise we would have millions of natural=tree nodes everywhere. also, who says, it has to be mapped by hand. maybe someone wants to import existing data in the future. if you want to discuss the longterm direction of OSM, you should discuss it in the forums or the mailinglists. a proposal for a specific tag, isn't the right place for that. --Flaimo 12:28, 18 May 2011 (BST)

"that's not your decision to make". Well that's a good point. We've set things up so that we wouldn't really expect anybody to try to block progress towards more and more detail. That's why this level of detail problem is a big problem. I have no solution to it. You have any suggestions? How we can we stop a gradual progression towards the day when somebody suggests we map every blade of grass.

I don't see a problem in having different levels of details. Where more people map, higher level of detail is possible. The people should map whatever they want, as long as they document it and don't try to reinvent tags (thus the wiki). If they are doing something stupid, they will fail anyway (to maintain it, to achieve it), the tags won't get community support (as many other people will agree with you that blade of grass is not a good way to spend the mapping time). The tag will just be used in a small area and gets ignored by all tools. So what? Resources is not an argument. I can hardly see why stopping persons from mapping more details locally will motivate them from mapping primary roads in Africa. This simply does not work this way. If you think you can police people, then the result will most probably that they leave the OSM project.

Your thinking is dominated by a single whole-world-renderer like Mapnik. But Mapnik is just one use of the data. OSM is mainly free geoinformation data for a lot of different uses. Currently it is easy "as 1-2-3" to create a nice map for my hometown with already existing tools. And if more level detail is available, I can generate better maps with parking lanes, benches and lanes for my invitations for a party. And for this purpose it is completely irrelevant if a single road in India is mapped or not.

I have also seen your argument below that detailled tags "confuses new mappers" (fundamentally this is true for every tag, isn't it?). Thus you are probabily right, but this issue should not be solved by stopping all new tags! It should be solved by better documentation, which is IMO the root cause. If the area:highway as "advanced" tag would NOT point out that for simple highway the highway tag is used (and instead give the impression this is the way to map roads), then the documentation would be inappropriate. Because I see these alternatives, for me the "confusion" argument is no reason to stop new tags in general.--Martinq 13:57, 18 May 2012 (BST)

The reason I raise this very general problem in relation to this tag idea, is that we've a whole tonne of roads in our database so there's a natural built-in resistance to the idea of suddenly deciding that we can represent road differently. It's a helpful stop-gap.

-- Harry Wood 12:23, 18 May 2012 (BST)

This is not another, new way to represent roads, it is an option to provide more information in addition to the highway represented as way. It does not break existing applications like routers, etc. There is zero impact on anything that already exists. The whole tonne of roads is not affected. So I don't understand you. Are you afraid we document tags where you have the feeling they won't have support by the community? But then you could relax and just wait and see how the tag will fail to get used instead of fighting here against it. Let the community judge by use/disregard -- but not here in the wiki where less than 1% of the community participates.--Martinq 13:57, 18 May 2012 (BST)

also you are completely wrong about mapping footways as mentioned in your link. they should be mapped as separate ways whenever possible, because as sidecar tags to highways they are of no use for navigation software for blind people. the esthetic look of the map is also not a factor. we are not mapping for renderers. if you don't like footways, addapt your own map style and just don't display them on your map --Flaimo 12:33, 18 May 2011 (BST)

I don't understand what you're saying. To my mind, the idea of mapping sidewalks (AKA pavements) is a similar kind of proposal, with a similar kind of problem. It's extra data that we can go around and attach to every road in our database, which takes this to a whole new level of detail. Whereas if we were to accept that we're not doing that, then that's a useful line in the sand. There's limits to the detail we're adding. There's a another reason why sidewalk mapping is tricky, which is a datamodel problem. Since you (or a blind person) can route as a pedestrian from any point along the sidewalk, onto the road, or across the road, it's incorrect in a routing sense, to represent it as a separate way. It would need to be connected at every point along it. That's off-topic for this conversation, except to say that of course this could be solved by also representing sidewalks as areas. So that all just gets a bit silly. Should we represent blades of grass as areas in fact? This would help the ants with their routing. Where does it end? -- Harry Wood 12:23, 18 May 2012 (BST)

I think it's shortsighted to say that it's never appropriate to tag individual park benches, trees, or sidewalks. Sure, maybe not in areas where the roads are all misnamed and misaligned, and no buildings or POIs exist, but if those things have been mapped, I think it's perfectly appropriate to add these finer details to create a rich map. And the suggestion that this is comparable to mapping every blade of grass is just absurd. I think (correct me if I'm wrong), that all OSM contributors and users would agree we should only map objects that have some level of spatial permanence. Trees have a life expectancy of between 10 years in urban areas and over 100 years in rural areas, park benches should certainly last at least a few years, and sidewalks have lifespans in the decades. All these items are not only useful landmarks, but are also of use to those who want to analyze the value of urban trees, to find a place to sit, and to walk in a safe manner. -- Joshdoe 15:00, 18 May 2011 (BST)

I didn't say you should never tag individual park benches or trees. I said people go crazy and do those things. I do it sometimes. It's fun, but it's a point on a sliding scale towards a nutty level of detail. The "blade of grass" point is not to say that mapping these things is the same as mapping every blade of grass. It's points on a sliding scale. Take a step back and ask yourself how far do we go, because obviously there is a limit. Obviously blades of grass would be too much. ::It's odd that you would say I'm being shortsighted. At the same time User:Flaimo complains that I'm not really speaking on any particular issue with this tag proposal, and that's kind of true. I'm pointing out a bigger issue, and asking "roads as areas" ...is that a line we want to cross?

-- Harry Wood 12:23, 18 May 2012 (BST)

Harry, nobody wants to forbid that highways are mapped as ways. This proposal is about opening the chance to map highways as areas whereever a user wants to. And as all mapping activity is voluntarily, it is not senseful to argument that anyone would *expect* any mapper in the neighbourhood or elsewhere to map in the same level of detail.
This was not valid when we were happy if at least all the motorways where in the map in industrial countries, and it is still valid when one gets bored because he searches for a new task when the housenumbers are done.
Professional GIS map highways as areas and surely that is where we will end up in OSM, too, because it fulfills needs.
We will have powerful mapping tools, that make the transformation of a 4 way crossing with cycleways and footways on all sides a funny task.
And if there are no sighted mappers interested in mapping single stepstones in the pavement, there will be blind mappers to jump in.
Why stop progress?
For me it makes sense to have a good discussion and a good proposal *early* in the process, because only with good data models we will succeed to map details in a way that they can be rendered or used for routing.
So if it is realistic to map sidewalks as areas in 2 or 3 years in some areas, we should *now* bring it on the way.
--Lulu-Ann 17:01, 18 May 2011 (BST)

On the point about *expecting* mappers to do things. Yes I think that's a obvious response to the level of detail problem I'm describing. "Why is it a problem? If people want to map insane levels of detail, let them!".

As I say here, it’s a problem because its a waste of time and energy of the mappers doing it, but It becomes more a problem when people encourage others (including confused new mappers) to follow their lead. This happens within the tagging proposals and documentation, and also blogs and other communication channels with examples images etc. All mapping is voluntary but new mappers get confused by this stuff, and we squander their energy and enthusiasm if we fail to map the world because we're simply attracting more mappers mapping more crazy levels of detail.

-- Harry Wood 12:23, 18 May 2012 (BST)

"It would be stupid to place a node for every blade of grass in your local park. It's too much detail. But why is it too much detail? The answer is because you cannot reasonably expect other areas, even neighbouring areas, to be mapped to that level" - I completely disagree that it is a valid reason. Mapping individual blades of grass is bad idea primarily because it changes too fast, in the same way as mapping temperature or traffic jams is unwanted in OSM. Unless something really unexpected changes we will always have unmapped areas, well mapped areas and places mapped to absurd detail. Mateusz Konieczny (talk) 16:45, 5 April 2016 (UTC)

Road adjacent to an area

Resolved: --Flaimo 21:48, 18 May 2011 (BST)

What if a road for which an area:highway is to be drawn is adjacent to an existing area?

You can consider this example: [1]. Here the pedestrian area "Viktualienmarkt" shares its nodes with adjacent ways, like "Frauenstraße". Now if someone added an area:highway to Frauenstraße, should this be the new boundary of Viktualienmarkt or should Viktualienmarkt extend to the way which is used for routing? The second option would cause overlapping areas while the first one would make routing across the pedestrian area impossible. -- Marko Knöbl 17:21, 18 May 2011 (BST)

The area:highway Areas are not for routing. The area for "Viktualienmarkt" represents an area with streets and buildings. So I think the both areas have to overlap. Of couse, if the "Viktualienmarkt" is endig before the street, the areas shoul not overlap. But I dont know how the reality there is. --DennisB 21:16, 18 May 2011 (BST)

dennis is right, area:highway is for visual purposes only. all routing information stays in the ways tagged with highway=*. highway=pedestrian is a bit of a special case, since it is the only highway value, that currently is used as an area. You would connect other ways tagged with highway=* to it. you can add an additional area:highway=pedestrian to highway=pedestrian without any side effects though. --Flaimo 21:48, 18 May 2011 (BST)

great idea

I used to mark this kind of situations as a highway tag on a way and the same highway tag on the area around it, together with an area=yes tag. But this always seemed a bit weird for me. Now with the separate tags, it looks more clear.

landuse=carriageway

Example render (in Maperitive)

Since it is impossible to cover all surfaces of the road network by one polygon, will have to split the area into parts. I do this on the boundaries of the crossroads. Also, I use multipolygons because carriageway edges are the edges of landuse=residential.

will cause mapping chaos

Although I find the result visually pleasing I think this is the worng approach.

Firstly you state that this is just for visual purpose. I think in this case the effort should be to make better renderers, not to overlead the database with unecessary data. The width=* tag can be used for rendering, only at junctions there would be troubles.

Secondly, and a way bigger concern, is how will this efficiently be mapped and maintained? Many user are unable or unwilling to even make rectangular buildings, this proposal will be even more complex if visually pleasing results are the goal.

1. How do you expect that perfectly parallel lines are (efficiently) mapped like in your mockup?

2. The areas will have to be closed polygons. Where does a Polygon start / end? Is the junction a separate polygon or which street does it belong to etc.. Currently it looks like the whole street network in a certain area would be a single (multi)polygon, which is very hard to maintain and ensure accuracy. edit: missed already existing "Junction" topic --Realadry 12:29, 2 September 2011 (BST)

In summary I think it's a visually pleasing but an extreme ammount of work for just a visual effect which can be attained by other means (i.e. advanced renderers).

-- Realadry 12:00, 2 September 2011 (BST)

1) "unnecessary data" is subjective. what might be unnecessary to you might be crucial to others

2) width doesn't work, because it would require to split up ways every couple of centimeters if the sides of the road aren't parallel

3) maintenance argument: could be applied to any element in OSM, so i don't see a valid point here. according to you we should eliminate all buildings too, because not every one is mapped and maintained perfectly?

4) how to draw parallel lines would be the mapping programs job

--Flaimo 12:52, 4 September 2011 (BST)

2) I think width is sufficient to show a visual difference, which is apparently the goal here. Splitting is not necessary. If width can be mapped on points, the change of width in between 2 points can be interpolated and visually shown.

3) These highway areas could only be mapped where high resolution imagery is available, since this type of data requires high accuracy to have an advantage over width=*. If parts of a road have areas and suddenly a part is missing it, it would cause no benefit over not having it at all. Buildings can be mapped from low res images or even survey and are not only for visual purpose.

Maintenance is also hard because if anything on the map changes it is a lot of work to adjust these areas accordingly. It's more than just dragging the area few pixels.

--Realadry 14:18, 4 September 2011 (BST)

Carriageway or highway?

There is a technical difference between the carriageway (North American English:roadway) and the highway (also 'road'). The first is specifically 'that part of the highway primarily for the use of motorised vehicles' and the later includes one of more carriageways, and also any verges and footways that make up the 'highway'. I believe this tag is actually intended to be used for define the dimensions of the carriageway. Is that correct? PeterIto 13:11, 6 April 2012 (BST)

i guess carriageway is used as a collective term here. are:highway relates directly to the highway-key, which means, that you would map area:highway=primary separately from area:highway=footway for example. --Flaimo 17:33, 8 April 2012 (BST)

I would have assumed that there is one area:highway=* for each highway=* way. Is that how you intend it to be used? --Tordanik 18:07, 8 April 2012 (BST)

yes, i think it should correspond with the underlying (or overlying) logical highway values. this way you can render sidewalks for example (see mockup). --Flaimo 18:58, 8 April 2012 (BST)

It's just that not all mappers draw sidewalks as a separate way. With an 1:1 mapping between highways and area:highways, there would logically only be a single area:highway=primary for a highway=primary with sidewalk=both (or one of the other approaches of mapping sidewalks as tags). So the answer to PeterIto's question whether an area:highway=primary is limited to the carriageway or includes sidewalks depends on the open question whether sidewalks should be mapped as individual ways. --Tordanik 14:20, 9 April 2012 (BST)

Comparison with the proposal for highway=junction

I just stumbled across this proposal and discovered a few similarities with this one. While I definitively do not want to map all roads as areas, I agree that in some circumstances it is necessary and yields some advantages. I restricted the other proposal to (large) junctions, because in my opinion we could gain there most. Beside the improvements for rendering I also suggested that within such area it would be allowed to map ways a little bit differently in order to make it easier to map large junctions and to drastically reduce the need for restriction-relations. This is something that is missing from this proposal.

Maybe we could find a way to join both proposals? --Imagic 07:59, 18 April 2012 (BST)

this proposal already covers junctions with area:highway=junction and offers the exact same benefits without the potential problems that could occur if you use the highway key directly. --Flaimo 09:35, 18 April 2012 (BST)

You missed my point: this proposal doesn't say anything about different mapping within a junction. My proposal does. And this is the core of my proposal - make it easier to map large junction. --Imagic 13:29, 18 April 2012 (BST)

i can't see anything new in your proposal. ways tagged with highway=* in combination with turn restrictions are mapped like that already anyway, so that only leaves highway=junction which is the same as area:highway=junction. --Flaimo 14:30, 18 April 2012 (BST)

Did you read this: "Additionally it should be possible to dramatically reduce the number of turning restriction relations on junctions, if we allow intersections of ways within the junction area without connecting nodes." This needs some changes in editors and applications like keepright - otherwise they will display warnings about intersecting ways. I don't care about the name of the key. area:highway=junction is as good as highway=junction. Important is the changed mapping within junctions. I'm not aware of the fact, that JOSM, keepright or anything else is behaving differently when an area:highway is present. --Imagic 15:09, 18 April 2012 (BST)

well, then you can leave out highway=junction and refer to this proposal here, but keep the rest of your proposal. no need to add anything to the area:highway proposal for that (and avaid an unnecessary backlink dependency) --Flaimo 17:02, 18 April 2012 (BST)

OSM is not a CAD system

When I read this (and other, similar proposals to add CAD-like features to OSM), I really would like to invite the proponents to step back a moment and look at the overall implications of this tendency.

Just two simple considerations, which do not address any technical detail:

• Consider the overall number of active OSM mappers (I guess one tenth of the registered users, to be optimistic) to maintain the world road network with that level of detail - and you see immediately that this can only be done in small, limited areas.
• Many areas in many of the well-mapped countries still have holes in the street network, not to speak of the minor viability like paths and cycleways - should we not concentrate on these glaring holes?

A completely different, and more technical consideration: Overloading the map with detail in some areas and not in others, makes a map that for the user of the rendered map is not a pleasing product. The end user expects a map of uniform quality, and OSM is not such a map. In order to make it look like one, the high-detail areas have to be filtered down by the renderers to the level of the lower-detail areas.

We are a community of free individuals, and we don't have an overall body that defines the policies of OSM (and I am happy about this), but that requires the individual contributors to keep the overall picture always in their mind .

Sorry to be disruptive, but if we want to make OSM the map of the world, we need to keep these aspects in mind.

--voschix 13:04, 17 May 2012 (BST)

Good point...so there are many places in the world with missig primarays. Lets stop mapping minor roads in Europe and continue after all primarys are well maped. ;)

If a mapper is interested in mapping area:highway, why not? I don't think he wouldn't travel to bad maped parts of the world and map some primarys. A mapper will map eerything he is interested in. I tried mapping some area:highway as one of the first, but I think there are better things to map in the same time, but others may deside different. Aighes 20:18, 17 May 2012 (BST)

I agree with everything voschix is saying here. It's similar to the points I was making above #helpful stop-valve on the level of detail and in my SOTM talk. "OSM is not a CAD system" is a good way of putting it too.

As for your reply Aighes... that's the other extreme of course. But seriously it would actually be good to make sure all the primary roads are mapped in the world! Given that we're only seriously able to map highways as areas where we have good aerial imagery for armchair mapping... we should remember that we are able to do armchair mapping anywhere in the world, so if we document tags like this, we're distracting people with silly details when some of that energy might otherwise be spent helping to achieve some basic coverage of cities in China. A more worthwhile aim in my opinion. Very good point. Glad you made it :-)

But of course lots of mappers only get passionate about mapping close to home, and if that includes surveying, then that's very much a good thing. It's the OpenStreetMap way. Definitely not arguing against that. So if it's not attractive/interesting to forget about our local neighbourhood and help map primary roads in China, then let's think about a more reasonable middle-case on this sliding scale. I've mapped around my office in quite a lot of detail. All POIs. All building outlines. At lunchtime today I could sit and map the junction immediately by my office as an area, with positions of all the curbs (I could even go out and look at it, but not sure if that helps) but that would be a silly thing to do. Why? because one day I'd hope that we have a good even coverage of the whole of central london with POIs and building outlines, so it's far more sensible for me to scroll across and armchair map some building outlines a little further afield, or head out on my bike and seek out some missing patches of POI details. I need to work on evening out the coverage not adding insane levels of detail to the map in funny little patches.

And what about if you've mapped all buildings and all POIs in your city? Well we already have other fairly insane details as tags. Have you mapped every address? Have you mapped every pedestrian crossing with traffic light details. And the farmland neighbouring you city. How's that looking? If you've really done all of that (and this may apply to some germans) then I can find support of this proposal understandable, but I think you need to realise you're in a massive minority and for the rest of us, this kind of proposal is creating a distraction from the task of creating a good even map.

-- Harry Wood 12:47, 18 June 2012 (BST)

I don't share your fundamental objections towards mapping something like this. That's because ...

• coverage of a feature doesn't have to be globally consistent to be useful. If I'm making a map of Germany, then the quality of the Chinese road network is completely irrelevant. Of course there are some use cases that are best served by a global dataset, but many others just don't need that.
• coverage of a feature doesn't have to be even locally consistent to be useful. Most of the roads are pretty boring - their outlines tend to be parallel to the centre line, and a width tag or even just a default assumption based on the highway value is close enough to reality. So it might make a lot of sense to map highway areas just for the few roads with "interesting" shapes.
• perception of priorities varies between mappers. You seem to have a clear hierarchy of significance in mind. But I don't think that highway area shapes are less interesting than some of the examples in your last paragraph. For example, I consider house numbers not that important on short roads. Painting most of the countryside brown also doesn't add that much to the quality of a map imo. And POI cause a lot more maintenance effort than road shapes because they tend to change much more frequently. But to each their own, right?

--Tordanik 15:38, 18 June 2012 (BST)

"each to their own" is fine until you start seeing lots of new mappers following the example, or generally getting confused or put off by the amount detail they're "supposed" to be mapping, or you start seeing renderers adopting these tags which introduce new massive imbalance to the data coverage.

So the examples of address numbers and painting the countryside brown, I agree those things are verging on being a silly amount of work and silly amount of detail to put into the map ...which is why it's even sillier to start proposing this sort of thing. We already have some pretty silly tagging schemes to work on! It's true there's a clear hierarchy of significance I have in mind, or a clear "sliding scale" of significance, and I can appreciate that other people would place things in different positions of that sliding-scale. But to my mind this proposal is a leap onto the silly end of that scale. There's something in what voschix is saying about CAD. Maybe that's why this kind of idea seems particularly crazy to me. But there's no line drawn, and no precedent for drawing a line on levels of detail, so I don't know how we ever will. :-/

It's fine if some of the more important or interesting junctions are mapped as areas, but I just know that's not how the data will develop.

-- Harry Wood 16:53, 18 June 2012 (BST)

The OSM dataset is not *just* for making a streetmap. Housing numbers are essential for routing, so I find it bizarre that you call it silly. I recently considered using OSM building data to do a GSM signal coverage simulation of a city. There's a copy of a building survey lying here on my desk, and I was thinking that it would be cool if I could have gotten that out of OSM. I've added hiking trails and ski pistes, points of interest and monumental trees. Much of this is not useful for a street map, but who knows what applications OSM data will be used for in the future.

Therefore, I draw no line, but aim to map at all scales. The shape of a road fits nicely into that.

-- JDub 14:18 11 October 2012 GMT+2

What do you mean you aim to map at all scales? all scales? So you'll be mapping every blade of grass in your local park then? Of course you draw a line at some level of detail. The difficult question is, can we as a community somehow agree to draw a line at some detail level? Clearly we cannot. There will always be somebody making a tag proposal which pushes towards a greater detail level, thereby creating the problems I've described. I'm not arguing that high-detail data isn't useful. You make the point that house number data is useful for routing. I don't doubt it, but you're missing my point that it sits somewhere on a sliding scale of detail levels, and for some cities it feels like a silly (unattainable) detail level. -- Harry Wood 15:36, 12 October 2012 (BST)

Been thinking about that, and came across this by chance now. I'd say that the "line at some level of detail" comes from manual updateability; nobody can map the blades of grass before they wither in the fall, i.e. they can't keep up with the changes. Not even with a team. If there were only a single living grass blade in the desert where you lived, one would consider that a mapworthy thing. "The line" would be in different levels for features of different change rates. And mapping the farm coverage is a reasonable (second, maybe third pass) goal in many countries; considering that here the state mapping agency considers "unoccupied" areas in their db as "wood"(ed area). Alv (talk) 12:27, 30 September 2015 (UTC)

"this can only be done in small, limited areas" - I think that nobody disputes that part. Personally, I mapped two areas with area:highway - because this data was needed for some purpose, so I mapped it within OSM. I see little to no point point in mapping it in other places, because it is unlikely that it will be actually useful to somebody Mateusz Konieczny (talk) 06:27, 23 January 2019 (UTC)

Combine with lanes=* and width=* tags

Just because not all intersections and roads need highway areas to be mapped, some would benefit from it. My proposal would be to, at closer zoom levels, use area:highway=* if available, then use width=*, if available, then an approximate width generated by multiplying lanes=* with a standard lane width, and then finally, if none of those tags are available, use a standard width for the highway type. This way, complicated intersections that would benefit from it can be mapped individually, while the rest of the roads are interpolated by the tags.

Here is an example of an intersection rendered in maperative that cannot be easily descrived with width=* tags:

Intersection example

(note that maperative will always draw ways on top of areas. Ideally they would be hidden behind the highway area.

area:highway and bridges

How would that work? Presumably there would a man_made=bridge area and area:highway slightly smaller than that. Tagging area:highway+bridge=* seems odd as bridges are expected to be linear ways. One way to make it work seems to combine it with Proposed features/Simplify man made=bridge mapping like this: the area:highway would be tagged with location=bridge+layer (+level where appropriate).

Also its time for man_made=tunnel I guess. RicoZ (talk) 11:04, 30 September 2015 (UTC)

validator rules

validator on osmapa.pl ( http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway#Rendering ) has some complaints that are based on undocumented rules. Maybe it would be a good idea to mention them here of such rules are desirable and useful? Mateusz Konieczny (talk) 16:41, 5 April 2016 (UTC)

Very useful in some cases

For cases like the small "square" by my home, this would be very useful. The square is walkable, has some stairs to the street, has a tunnel to another square, a ramp also connecting it with the street, a square to the other side of the ramp, another square behind (to which it is connected by two different stairs), and more ramps and stairs around. Quite a mess to map all of this AND have all the connections correctly done, precisely because the highways are not areas.

http://www.openstreetmap.org/#map=19/28.45064/-16.28774

It is almost impossible to map it correctly, except by mapping highways (more specifically the ramps and stairs) as areas. --Envite (talk) 20:47, 8 June 2016 (UTC)

aaronsta 02 January 2019.

I must emphasise that the situation you describe is very common, and you have misinterpreted this proposal. It should be mapped using the area=yes tag and highway=pedestrian tag on a multipolygon relation or closed area. Look at any correctly mapped example of a pedestrian plaza area.

Where there are steps, map lines using highway=steps joining two separate areas with area=yes tag and highway=pedestrian. Join those areas with highway=* lines to the wider road and path network. You do not need to use area:highway in this instance, and doing so would create problems with routing.

On-street parking spaces

In my direct vicinity, there is a varying degree of on-street parking. In the simplest example, where parking on the side of the street is allowed without any further regulation, it's clear that the street area includes the area where one can park. However, when the street area is covered in asphalt while a whole lane of the street on either side is in cobblestone to indicate an area where can be parked, then should that be included in the street area or not? On some streets, there is even trees planted in the asphalt of the street, to indicate that this shoulder area should be used for parking only. What should be included in the street area in this case? --Pbb (talk) 11:32, 14 September 2017 (UTC)

How area of zebra crossings should be tagged?

For now I use area:highway=crossing but I am not sure is it a correct solution.

Mateusz Konieczny (talk) 06:28, 23 January 2019 (UTC)