Talk:Key:area:highway
Incorrect tagging in the description
This tagging is not correct:
- area:highway=yes + highway=footway/path/track/...
You never use an highway tag on the same element as an area:highway tag. Instead, Proposed features/area:highway suggests to do this:
- area:highway=footway/path/track/...
That's also the variant most commonly used in the database today, so this wiki page should describe it that way. (If we even need a wiki page at all. In my opinion, this is not yet established at all, and should probably not even have a Key:... page yet.) --Tordanik 20:51, 15 February 2012 (UTC)
Approved feature?
Has this feature been approved? I ask that because there does not appear to have been a vote on the proposal (Proposed features/area:highway). If it has not be approved then should this page not redirect to the proposal as normal? PeterIto 19:45, 20 February 2012 (UTC)
- Don't you think, that it's better to have some page with instructions? area=yes leeds problems with routing so they often replace it by area:highway. It is useful to have page with phrase "please, check routing lines". Dinamik 10:34, 21 February 2012 (UTC)
- There is nothing inherently problematic with the tag area=yes. Any areas can require extra coding, but it is up to the coder to implement crossing from corner to corner, if they choose to do so. Or they can choose to live with "route along the outer edge". We don't tag things wrong just to please a rendered or a router - a highway that happens to be an area, deserves the tag area=yes; these include pedestrian areas, highway=service areas, and could sometimes include even exceptionally big turning circles on residential streets, or wide sidewalks. The area:highway=* is, instead, used when the highway it depicts is a linear feature (even if all highways have a width). Alv 11:01, 21 February 2012 (UTC)
- Umm this was Key:area:highway - the point was aimed more at the edits on Key:area, even if this key's description should be consistent with what's said there. Alv 11:11, 21 February 2012 (UTC)
- @Dinamik: The introduction of area:highway has nothing to do with mapping squares, plazzas or the like. In absolutely no case is it used on something that would previously have been mapped with the highway=* + area=yes combination! It exists so you can map roads where the width is not constant. Also, what Alv said. (Thanks.) --Tordanik 04:05, 22 February 2012 (UTC)
- If this is not an approved tagged approach then the page should redirect to the relevant proposal page or should not exist at all. This is the rule designed to create a clear distinction between a page that describes an approved or widely recognised tagging approach from one that describes a new proposal. The redirect ensures that the discussion happens on the proposal page. From what you have said I believe this page should be a redirect. PeterIto 05:38, 22 February 2012 (UTC)
- I have now converted this page to a redirect to the proposal as per discussion above. PeterIto 17:00, 23 February 2012 (UTC)
- Tags in wide use without accepted use may have their own pages, even if proposals were never created, voted on or failed Mateusz Konieczny (talk) 20:54, 21 December 2018 (UTC)
The waterway analogy
Just for the records, there was the following paragraph in the 'inconsistencies' section of the page until 2018-12-21:
- It has been suggested that such mapping is comparable to the mapping of the water covered area of a river with riverbank polygons although so far no consistent locally verifiable property to delineate area:highway=* areas comparable to the concept of water cover has been suggested.
The statement was a combination of two perspectives. One, to consider the area:highway plus its linear routable way as an analogy to mapping a riverbank polygon in addition to the routable linear waterway. Second, the opinion that such analogy does not work since the road has no verifiable boundaries. Both perspectives were cited from the discussion of the original proposals.
The core problem appears to be the different opinions what to use the area:highway tag for, i.e. the road area without the sidewalk, with the sidewalks, or both in different polygons, or even smaller functional areas. --Polarbear w (talk) 14:34, 24 December 2018 (UTC)
- A lot of the content of this wiki page is strongly at odds with the previously proposed usage of area:highway. Marek's proposal had some important definitions such as the "plumbing principle", and – more closely related to your sidewalk example – the 1:1 relationship between highway areas and (sequences of) highway ways. The latter principle means that where sidewalks are mapped as separate ways, they should get their own area:highway areas, and where they are mapped as tags on a road way, they should be included in that way's area:highway. I've found that those are essential principles when trying to actually render a road's lanes in software. So I would be strongly in favour of editing this page to reflect these definitions, or, if we cannot agree on that, to go back to just linking the different contradicting proposals. --Tordanik 14:06, 2 January 2019 (UTC)
- Usually the wiki page should describe how the tag is actually used. If you look at the values, you see that even the usage is inconsistent. Leader is "footway" with 26k, and the dreaded "emergency" along the major road types each 9-10k. Especially the "emergency" tag indicates that many users do not follow that "plumbing principle", which received criticism in its proposal, but prefer to paint arbitrary sections of the street. Including "shoulder" with 1.2k --Polarbear w (talk) 15:01, 2 January 2019 (UTC)
- @Tordanik Regarding linking proposals I do not support this as this is regressive. It has been eight years since the proposals have been made, and it is time to make some changes which which are progressive and fill those gaps and reduce any ambiguity. Changes in usage have occured over this time, and the opinions expressed in those proposals should be taken with a grain of salt, as they are both dated and in some cases contradict the usage and purpose of other tags, and best practice OSM mapping standards. Further with relation to the original proposals the proposal of flaimo should be favoured over the any other proposal, as that is the proposal which specifically relates to this wiki.
- @Polarbear w Regarding usage, given that area:highway has the subkey (the bit after the semicolon) of highway only the tags of highway=* should be used. *DO NOT USE [highway=emergency] * is neither a commonly used tag or documented at all. Further its meaning would be ambiguous and different should it be applied to a polyline way. This is a case of OSM mappers not understanding the usage of the tagging in accordance with OSM mapping standards. Changes to the article would close such a gap. Further you are mixing proposals, as you are discussing the second proposal which has a different meaning and usage scanario. In anycase a different tagging scheme should be used for such a purpose, such as *DO NOT USE [highway_area=*] *, but for other reasons such a tag and mapping scheme is not appropriate or valid for use in OSM. It is noted that the second proposal is the one which discusses that emergency key, and also that both proposals have completely different usages and case scenarios proposed. The purpose of the first proposal is to map the areas of roadway or path. The second proposal is to map the components of those road areas by functional usage of a road for the purpose of rendering. This should be the subject of a different tagging system if at all, and not this proposal. -- aaronsta 3 January 2019 02:11 UTC
Proposal for revision to wiki article
2 January 2019 14:23 UTC - aaronsta
Background
Hi all, in order to progress this wiki article, and simplify and clarify the usage of this tag to current OSM mapping standards I request feedback on the following suggested revisions.
This feedback should be provided on or before 1 March 2019 to reach a timely outcome, feedback after this date should be in a new discussion section. If no feedback is received by this date these changes will be assumed to be supported, as the proposed changes do not alter or contradict current OSM mapping standards, nor the objectives of current page, simply clarifying existing best practice and filling gaps otherwise open to misinterpretation. With the exception of not using other tagging this proposal otherwise does not propose changes to the current framework and use of area:highway.
I note that the area:highway tag was first proposed in 2011, eight years ago, and its use has since evolved, but also that over this eight year period there has been a lack of any progress, and its use and purpose remains ambiguous, contradictory to OSM mapping practices in some instances, and difficult for any armchair mapper to understand. Further its use has been limited by this ambiguity. I note that I made a change to this article to do revisions, and did not undertake consultation due to the lengthy process, and the typical lack of feedback. Again it was proposed back in 2011, but nothing much has happened since.
The tables below summarise the proposed clarifications, revisions, and reasoning in relation to the article as at 2 January 2019, the above previous discussion, and the orginal proposal pages.
Please provide detailed feedback on the below topics accordingly. Feedback received will be discussed, and subsequently changes are hoped to be made in collaboration and accordance with OSM best practices to the article.
| # | Topic / Issue | Before | After | Change / Reasoning |
|---|---|---|---|---|
| 1 | highway=* tags are routable, area:highway=* are not | difference between highway=* and area=yes and area:highway=* and an associated way are discussed in limited detail. But their usage and if / when they should be used are not discussed. | difference between highway=* and area=yes and area:highway=* and an associated way are discussed in greater detail. Their usage and if / when they should be used are discussed. It is noted that area=yes on a highway tag should only be used with highway=pedestrian.
It is noted that area=yes should not be used in combination with highway=* tags except for highway=pedestrian which is the only approved or commonly used tag used with area=yes. area=yes implies that a routing program can route anywhere in that area, further it creates logistical problems for programmers. It also causes issues with rendering and other problems with usage due to one tag (highway=*) having multiple meanings depending on the specific context in which it is used - something which cannot be easily understood by routing programs, and only by a human. Reference is made to the One feature, one OSM element rule and discussion regarding that topic. Further it creates issues where a way may also be incorrectly mapped in addition to an area both with the highway=* tag, and with the same shared attributes, again refering to One feature, one OSM element. Issues with data redudancy and maintaining the dataset are also highly likely to occur. Vehicles drive and pedestrians typically walk on roads in set routes (cars can only drive on one side of a road, in a lane and cannot do a three-point-turn in the middle of the road and go back to where they started from). |
Clarification of current standards.
Area=yes should not be used as it implies the area is routable. No change. |
| 2 | usage of highway=pedestrian and area=yes | does not refer to linked wiki article
has same meaning as above. defines area which is routable. Does not detail when and if it should be used. |
refers to linked wiki article highway=pedestrian. Has same meaning as before, and above.
Details that it should be used when an area itself is mapped and has attributes. Notes that tags such as name "John Street Mall" should be applied to a highway=pedestrian tag with area=yes but not area:highway. Highlights following key points:
Issues:
|
Clarification of current standards.
No change. |
Original images available at: https://1drv.ms/f/s!AmrDQrCz7JSpgatepsZnJMg8s8TcWA. Link may expire in the future without notice.
The image below shows examples of issues created by using the area=yes tag and which are able to be resolved with the use of the area:highway tag following a revision of the wiki article. In the images of examples of areas the location of the ways is shown in white, and when routing from A to B potential issues that may arise from routing when routing through the area in orange or along the area's boundary in pink. Note that in most instances these areas are actually parking areas which should not be tagged at all under the highway=* or area:highway=* tagging scheme.
Inconsistencies section of current wiki article
| # | General topic / Issue / Concern from discussion | Response |
|---|---|---|
| 1 | It remains unclear if the tag should be used for the full shape of the built highway, or split into functional sub-areas. | Current wiki article provides no comment or guidance. Response is that areas should be created based on their area:highway tag, and their tag should be based on the tag value of the highway=* key they are beneath. Function is the topic of the second proposal, and is otherwise irrelevant as there are current tagging schemes available for use on the highway=* polyline way.
|
| 2 | For road segments with constant width mapping a polygon representation of linear road can be considered unnecessarily redundant to the linear highway mapping and a width=* tag and in violation of One feature, one OSM element.
|
Width and area:highway are distinct and separate concepts. Proposal does not alter, modify, or duplicate the purpose of the width=* tag. Width is to be used on the highway=* way and adds an additional layer of information as does area:highway=*. |
| 3 | Some mappers use area:highway=emergency, where they mean to describe road areas that are painted with white hatching that should be avoided in normal traffic flow, but have nothing to do with emergencies. | Only keys of highway=* should be used. See comment elsewhere. Given that area:highway has the subkey (the bit after the semicolon) of highway only the tags of highway=* should be used. |
Other gaps in wiki article not discussed elsewhere
| # | General topic / Issue / Concern from discussion | Response |
|---|---|---|
| 1 | No comment or guidance on use of a grouping relation with the highway way. | The creation of a relation with the highway way is a topic for another discussion, and no feedback or change is proposed to the article in relation to this issue. |
| 2 | Comment on usage in remote and non-urban areas, and in unpaved and poorly defined areas. | Changes will provide comment on usage in remote and non-urban areas. |
| 3 | Use of no other tags on area:highway ways. | Please see discussion elsewhere. |
The original proposal Proposed features/area:highway.
| # | General topic / Issue / Concern from discussion | Response |
|---|---|---|
| 1 | With reference to road junctions the proposal suggests mapping junctions using a new junction tag value. | There is no functional purpose to mapping a junction. This infomation can be determined by tags which are used on the way, and the intersection of multiple ways. Such a proposal would create duplicate information with reference to One feature, one OSM element, and would serve no purpose to end-users and third parties, as this information should be contained on the polyline way if at-all.
Response is to map road junctions according to the highest highway=* road tag value of that junction with reference to the _link roads scheme and the approved usage to map at the higher road classification.Response fits in and accords with mapping practice for highways. |
| 2 | Proposal proposes addtional keys and values for these areas. | Acknowledged, and discounted accordingly. No additonal keys or values should be used. Again the response complies with One feature, one OSM element, does not create duplicate information which is hard to maintain, and does not do Tagging for the renderer. This information can be collected and rendered using the highway=* ways. |
| 3 | Discussion states that another aspect is the still ongoing debate on how detailed landuses should be mapped, due to a imprecise definition of the tag. This proposal doesn't take sides and therefore won't define if area:highway=* should be mapped over landuse areas or if they can be adjoined at shared nodes.
|
Response does not provide any feedback or comment on this issue, as this is a topic which should be discussed. Please make new topic to discuss this. Response defines the usage and how to map area:highway areas accordingly. |
| 4 | Discussion states that tags like width=* mapped on highways are valuable for routing purposes, but wouldn't offer enough information for correct rendering of non uniform streets.
|
Proposal does not alter, modify, or duplicate the purpose of the width=* tag. Width is to be used on the highway=* way and adds an additional layer of information as does area:highway=*. |
| 5 | Difference between highway=* and area=yes and area:highway=* and an associated way. | The response accords with the current practice and usage of these tagging schemes. It must be noted that even in areas like toll road tollbooths, shipping ports, and customs immigration checkpoints where reallife examples exist there is only one legal direction of travel. You could not do a three-point-turn and go the wrong way back through customs. Nor is it legal to go the wrong direction around a very large cul-de-sac for example. Mapping such a feature would be Tagging for the renderer (it should just be a turning_circle node at the end of a way) and this is infact the very purpose of this tag in separating truly 360° routable ways (area=yes) with area:highway for non-routable areas, in tagging scheme designed exclusively for showing visual information on the map, without causing issues with tagging |
| 6 | Proposal proposes tags specific and whose only purpose is for rendering and otherwise redundant as there are existing tagging schemes, which should be used and applied to the way forming the road or path which uses the highway=* key. | Acknowledged, and discounted accordingly. Again the response complies with One feature, one OSM element and does not do Tagging for the renderer. |
| 7 | Proposal proposes using tagging schemes not intended for use on areas or multi-polygons, and not practically able to be accommodated within the current OSM mapping format. Including mapping out road lines and markings and junctions. | Acknowledged, and discounted accordingly. Proposal would create undue focus on micromapping detail which can and is already accommodated in an existing scheme. Further these tags are not supported or intended to be used on areas or multi-polygons as described. |
| 8 | Proposal is ambiguous and does not propose any specific tagging scheme or how to use the scheme, beyond generalised concepts. | Response clarifies the usage of the tagging scheme not currently done in the current article or this proposal. |
| 9 | --Imagico (talk) 10:22, 2 September 2015 (UTC) summarises key concerns of the proposal. | The repsonse addresses these concerns. |
The second (duplicate) proposal Proposed features/Street area and discussion points. Further note that this proposal is separate from this key which is under the Proposed features/area:highway proposal.
| # | General topic / Issue / Concern from discussion | Response |
|---|---|---|
| 1 | Proposal reflects views of one person, and does not comply with or respect OSM best practice and approved and used mapping standards. | Acknowledged. Elements of proposal which do not comply with current OSM standards have been discounted. Things such as duplicate tagging. |
| 2 | Proposal was a duplicate topic of an existing proposal. | Emphasis placed on original proposal and not this one. |
| 3 | Proposal suggests using tags suitable and approved only for use on nodes, and not for relations and closed polygons. Things like highway=crossing and highway=stop_sign | Acknowledged, and discounted accordingly. Not appropriate or approved for use on things which are not nodes. Discussion feedback and concern expressed over this. |
| 4 | Proposal acknowledges issues with duplicate tagging One feature, one OSM element but does not address them beyond stating that name=* should not be used. | Response complies with One feature, one OSM element. |
| 5 | Proposal proposes duplicate tags to replace current existing tags such as |
Acknowledged and discounted accordingly. Tag should not replace or have any overlap with any existing, approved, and commonly used tagging.
Not appropriate to map area:highway areas for areas not on ground level as for bridges there is already a current scheme for areas (man_made=bridge, layer=1) |
| 6 | Proposal proposes tags which are not highway=* key tag values. | The purpose of a subkey (the second key after the semicolon) is that it has the same meaning, usage and tagging as an existing tagging scheme. area:highway should only use tags of the highway=* key. Otherwise a new more appropriate tagging scheme should be created, like |
| 7 | Proposal proposes tags specific and whose only purpose is for rendering and otherwise redundant as there are existing tagging schemes, which should be used and applied to the way forming the road or path which uses the highway=* key. | Acknowledged, and discounted accordingly. Again the response complies with One feature, one OSM element and does not do Tagging for the renderer. |
| 8 | Proposal proposes using tagging schemes not intended for use on areas or multi-polygons, and not practically able to be accommodated within the current OSM mapping format. Including mapping out road lines and markings and junctions. | Acknowledged, and discounted accordingly. Proposal would create undue focus on micromapping detail which can and is already accommodated in an existing scheme. Further these tags are not supported or intended to be used on areas or multi-polygons as described. |
| 9 | Proposal is ambiguous and does not propose any specific tagging scheme or how to use the scheme, beyond generalised concepts. | Response clarifies the usage of the tagging scheme not currently done in the current article or this proposal. |
| 10 | --Imagico (talk) 10:22, 2 September 2015 (UTC) summarises key concerns of the proposal not otherwise addressed. | The repsonse addresses these concerns. |
What is included in the area:highway?
LeifRasmussen, what is the source of this: "area:highway=*, when used on roads, should cover traffic lanes, bus lanes, and cycle lanes (any detail added to the way corresponding to the area:highway), and should not cover shoulders, parking spaces, and sidewalks."
Is this the "de facto" practice, or a recommendation? --Jeisenbe (talk) 04:56, 12 September 2019 (UTC)
- I believe the rule should be: If it's mapped as a separate way, it should get a separate area. If it's mapped as tags on an existing way (e.g. sidewalk=* or shoulder=*), it should be part of that way's area. This is what was documented in the street area proposal, and it also just makes logical sense. --Tordanik 20:01, 28 October 2019 (UTC)
- OK, so the text should be changed to say "should not cover parking spaces, sidewalks or cycle paths which are mapped as separate ways or something like that? See https://wiki.openstreetmap.org/w/index.php?title=Key%3Aarea%3Ahighway&type=revision&diff=1903749&oldid=1903741 --Jeisenbe (talk) 23:51, 28 October 2019 (UTC)
- Wait a moment, no parking spaces? Does this include parking lanes that are situated on the road (and not on the sidewalks or parking bays)? If yes, this would be really awkward. Maybe explicitly mention parking lanes? --Westnordost (talk) 17:08, 18 November 2020 (UTC)
- The phrasing seems a bit confusing to me. I could imagine not including street-side parking (e.g., as defined in this proposal) in the area:highway=* of the street itself, but getting tagged with their own area:highway=parking_space on the same entity as amenity=parking|parking=street_side, directly connected to the other. So the collective highway area would include them as long as it makes sense, like here:
- Agreed about parking lanes; when parking is mapped as explicitly drawn parking=lane I would include them in the street area:highway=*, like here:
- JeroenHoek (talk) 07:54, 20 November 2020 (UTC)
Rendering support?
It would be nice to add a list of OpenStreetMap renderers that support this tag to the wiki-page. Support in carto-osm is still a long time off, but which renderers do render it? JeroenHoek (talk) 18:13, 16 December 2019 (UTC)
- It's rendered on Dianacht Topo map:
- https://geo.dianacht.de/topo/?zoom=19&lat=48.15112&lon=11.46511
- https://www.openstreetmap.org/way/153916175 maro21 02:07, 23 November 2020 (UTC)
- OSM2World is a great 3D visualiser. However getting it working isn't the easiest, especially if you want it to look good (requires compiling from source for new versions). --GoodClover (talk) 03:49, 23 December 2020 (UTC)
Question: Is it wrong to use this tag on land set aside for road maintenance?
The operator of roads sets aside and maintains lands other than the road surface as part of road structure. A typical example is the slope of cutting or embankment. Is it wrong to use this tag for these lands? If it is a mistake, what should be used as a landuse? Otenkiya (talk) 07:32, 29 March 2022 (UTC)
- landuse=highway can be used for such entire land. area:highway=* is for surface area of carriageway/path/sidewalk. Which value one would even use for "slope of cutting or embankment"? @Otenkiya: Mateusz Konieczny (talk) 07:36, 29 March 2022 (UTC)
If the entire zone is a pedestrian or crosswalk area
Sometimes the entire area is not an X, but a pedestrian or crossing area with no direction.
There are too many different pedestrian directions.
And there are no traffic lights and pedestrians can enter at any time.
Since these attributes are very similar to 'highway=pedestrian', I want to tag this area with 'area:highway=pedestrian'.
What do you guys think?
For reference, someone suggested the tag 'area:highway=footway + footway=crossing'.
Reference 1, Reference 2 --깨몽/dreamy (talk) 15:59, 16 July 2023 (UTC)
- It is not area of highway=pedestrian but rather a pedestrian crossing. I would likely map crossing ways (highway=footway lines or similar going across crossing - through the node where road lines are crossing, forming X in addition to regularly mapped crossing ways). For area:highway=* marking of crossing areas - I proposed Proposal:Pedestrian crossing as an area at some point. Mateusz Konieczny (talk) 13:38, 17 July 2023 (UTC)