Proposal talk:Street area

area:highway=crossing

I have got a more general problem with using a:h=crossing for defining the area of junctions. We are already using highway=crossing + crossing=* to mark places where pedestrians and bicycles are able to cross a street. a:h=crossing redefines the meaning of this well-established tag! Maybe this is a result of directly translating the German term "Kreuzung" (meaning "intersection/junction/street crossing") to "crossing"? In my opinion, either a:h=street_crossing (to stick with "crossing") or a:h=junction (or intersection/crossroads) has to be used to avoid confusion with highway=crossing. --@themis (talk) 15:43, 19 August 2015 (UTC)

+1 The junction=* tag can be expanded to include things like box junctions which will need have their own area. The crossing=* tags and "crossings" in general should keep their existing meaning. --Peter Mead (talk) 10:26, 2 September 2015 (UTC)

area:highway=bridge

What does area:highway=bridge mean? If area is part of road, we should use area:highway=residential/unclassified/tertiary/secondary/primary/trunk/motorway. For bridges we have man_made=bridge. Dinamik (talk) 12:12, 15 July 2015 (UTC)

+1, I also believe the section on bridge and the area:highway=bridge key have been obsoleted by man_made=bridge. --Tordanik 12:21, 15 July 2015 (UTC)

+1 I also think so. I would tag it like area:highway=primary/secndary... and bridge=yes (in case of a tunnel: area:highway=primary/secndary and tunnel=yes).

So my opinion is that the values of area:highway=* should only be the same as the values of highway=* who are tagged as a way(no area:highway=yes/crossing/bridge/tunnel...) like in this Proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway -- Chrisss Gü (talk) 16:34, 10 August 2015 (UTC)

man_made=bridge with area:highway=<street category> is implemented. Thanks for good suggestion.--Marek kleciak (talk) 09:34, 19 August 2015 (UTC)

area:highway=yes and area:highway=crossing

I don't like the idea of mapping areas of crossings with area:highway=crossing and areas of carriageways with area:highway=yes. It's better to use area:highway=residential/tertiary/secondary/primary/trunk/motorway for carriageways. For areas of crossings we can use additional polygons with, for example, area:street_crossing=yes (area:crossing is for area of pedestrian crossing). Dinamik (talk) 12:16, 15 July 2015 (UTC)

Of course, but look that is duplicating the data from ways. If someone in future will change the highway value, he must change also multiple values on area:highway polygons. It makes lot of extra work to do.--Javnik (talk) 12:19, 16 July 2015 (UTC)

I think, in real life status of highway is not changed very often. When we change statuses, we make a big work in any case (because it means, that something was changed in road network - so we have to change statuses not in one road, but in several ones). Changing of values in areas in such cases is not the biggest work. Some other peoples also think so: "In my opinion, we shouldn't use area:highway=yes or crossing, it is equivalent to mark street areas just as surface=paved. When only area:highway=yes was used, you can not distinguish pedestrian and motorist areas or drop minor streets (e.g. residential, service) in render. So I speaking for the area:highway=[highway tag on linear road] only". Dinamik (talk) 10:57, 17 July 2015 (UTC)

I agree. While it is preferable to distinguish the crossing area please not with area:highway=crossing. This is losing information about the classification. --Jojo4u (talk) 10:58, 20 July 2015 (UTC)

I agree to you --Chrisss Gü (talk) 16:46, 10 August 2015 (UTC)

+1 I think you should use the already existing tag junction=yes instead of area:highway=crossing. --Chrisss Gü (talk) 16:46, 10 August 2015 (UTC)

I added a:h=crossing + crossing=<street category> this should fix this problem.--Marek kleciak (talk) 09:36, 19 August 2015 (UTC)

I support mapping road areas in the same way as river banks are mapped, but with information on the highway type included. As in area:highway=residential/ ... /motorway. A tag selector like that aids the render software dropping minor streets on zoom. I prefer area:highway=junction to area:highway=crossing. Junction means to join, which is what happens. Crossing for me says only the perpendicular intersection of roads, like + symbol - in reality roads have many T and Y junctions, which are not crossings. The area:highway=crossing value would apply to its current use where incompatible highways cross without joining - like pedestrian crossing, railway level crossing, etc.. Craig.za (talk) 08:41, 31 August 2015 (UTC)

Problematic example

The rendering example at openstreetmap.ru is problematic imo. It shows an example where multiple ways are surrounded by a single area. If you **do** intend to allow this, then that's a big change compared to previous iterations of the area:highway idea. --Tordanik 12:25, 15 July 2015 (UTC)

I also think, that this example is not the best, because area:highway was used to include several carriageways and thick dividers between them. I think, one area:highway can be used in cases, where there is no thick divider between two directions. Dinamik (talk) 12:42, 15 July 2015 (UTC)

Well, I think that the same criteria for physical separation should apply to both highway and area:highway. If the two directions are only separated by a painted line, for example, then there should not be two ways in the first place. --Tordanik 13:16, 15 July 2015 (UTC)

This suggestion is more disputable. De-facto, we use several ways not only in cases with physical separation. For example, we can use it for situations with complicated directions of cars and/or in cases of existing of solid painted line and/or in cases with existing of some restrictions. So, situation with two ways in OSM for opposite directions, divided by solid painted line, with one area:highway for them, looks normal. Dinamik (talk) 14:13, 15 July 2015 (UTC)

The fact that a certain style of mapping is used sometimes doesn't automatically make it correct. But more to the point: If you consider a solid line enough for separating the highways, why do you not consider it enough for separating the areas? If we cannot assume that there is a clear 1:1 relationship between highway (sequence) and area, then things become unnecessarily hard for applications. --Tordanik 15:45, 15 July 2015 (UTC)

What problems will applications have? For example, application sees area:highway=tertiary. The only action is to render area with the same color as tertiary road. When rendering area:highway, application doesn't have to do any analysis of ways, it can takes into consideration only areas. Dinamik (talk) 06:32, 16 July 2015 (UTC)

I'm thinking about more detailed renderings that also show lanes, sidewalks etc. Something like this, but with road areas. That makes it necessary for the application to have more intelligence. Even with only one way per area, some situations will already require somewhat complex code (e.g. a road that splits into two, where you need to figure out the transition algorithmically). If you allow multiple parallel ways, and areas like this, then things become just unnecessarily harder. --Tordanik 08:01, 16 July 2015 (UTC)

My first thought was to write recommendation to use the number of areas, equals to number of ways, but I hardly understand, how it can look like in cases, where one way splits to several, as you said). Dinamik (talk) 11:04, 17 July 2015 (UTC)

We could add for splitting areas tag: crossing=y_junction. See this: http://www.openstreetmap.org/way/366221669

Such junctions are mostly divided by area:emergency, so we could get satisfactory rendering of lanes.--Marek kleciak (talk) 09:55, 19 August 2015 (UTC)

highway=stop vs. highway=traffic_signals

In the concept of micro mapping traffic signals are already mapped at the position where the stop line is, so it is not possible to use the highway key twice on those nodes. I would drop highway=stop and just map stop_line=yes|solid|giveway. Because, why use two tags, when one does the job. Example: https://www.openstreetmap.org/node/1018234490 Flaimo (talk) 11:50, 16 July 2015 (UTC)

Very good idea, I agree! --Marek kleciak (talk) 09:56, 19 August 2015 (UTC)

area:highway=emergency

This is a weird tag IMO. Not all barred areas are useful for emergency vehicles. In Belgium they mean that you cannot drive them unless strictly necessary AFAIK. Emergency vehicles are of course allowed to drive anywhere they can. But if I see the tag area:highway=emergency, I think of emergency access roads. —M!dgard [ talk ] 13:06, 31 August 2015 (UTC)

So perhaps area:highway=barred_area would be preferable? --Tordanik 07:15, 1 September 2015 (UTC)

+1 Barred areas are very common in the United Kingdom. Some wide roads have them in the middle with crossing islands at semi-regular intervals. The area:highway=barred_area would be better. The example picture for area:highway=emergency shows an area where you shouldn't drive, and doesn't look very useful in an emergency. --Peter Mead (talk) 10:19, 2 September 2015 (UTC)

Indeed, this is not designed for emergency purposes, so another tag should be choosen. The UK word should be hatched area.--Jojo4u (talk) 15:17, 3 October 2015 (UTC)

Fully agree that "emergency" is the wrong description. The UK Highway code calls them "white diagonal stripes" and regulates in Rule 130 that they must be used, except in an emergency - thus their purpose is to separate traffic, not to provide for emergencies. In an emergency or necessity, I can break other rules as well, such as crossing a double white line to pass a stationary vehicle, etc.
German traffic law (StVO) simply says "Who is driving a vehicle, must not use the barred area" ("Sperrfläche / sign 298"), not mentioning any exceptions or emergencies.
In general, it is very questionable if the area:highway tag should be used to map road markings. --Polarbear w (talk) 09:27, 16 September 2016 (UTC)

If you're going to ignore road markings you might as well have a massive area with surface=asphalt. The whole point of area:highway is to break that up into smaller, useful, areas. If there's an area of asphalt you are not allowed to drive on then that distinction should be mapped. --Peter Mead (talk) 11:40, 22 September 2016 (UTC)

Please, keep in mind: area:highway can be used for autonomous driving. Such data uses street outline shape and need such areas as well. Despite of that: Our own generalization rules makes midlines of some crossings different to the reality. See e.g. this: http://www.openstreetmap.org/way/368373068 "Emergency" helps to show this situatuin more detailed.
Regarding wording: "emergency" or "barred_area" or an other name: why not, we should discuss that. by Marek kleciak 10:34 16 Sep

Due to the imperfection (or fuzziness) of natural language, there are at least two ways to interpret area:highway=emergency and one of these is source for the critism on tagging barred areas with it:

• is it an area dedicated for emergency vehicles ??
• is it an area to be used in case of an emergency by arbitrary vehicles (more similar in meaning to the access tag) ??

I guess marek had the later in mind while the people identifying this as a misnomer probably think exclusively of the first option. I agree that this may be fixed by finding a more suitable value and doing a (agreed and consented upon) mechanical edit to change all current uses. --Cmuelle8 (talk) 12:17, 16 September 2016 (UTC)

I tried to find description for areas, which are a part of the street (asphalted or concreted) which are barred. For instance this: http://www.openstreetmap.org/way/273229241 I know, the word "emergency" is not the best, so we can discuss about better one. Marek kleciak (talk) 14:31, 16 September 2016 (UTC)

I've read reserved somewhere in conjunction with those proposals too. This might seem a little unspecific at first, but it opens the intuitive possibility to further specify it using a secondary tag, i.e. area:highway=reserved reserved=emergency_lane _or_ area:highway=reserved reserved=barred_area. But there might be better ways to do it. --Cmuelle8 (talk) 13:47, 16 September 2016 (UTC)

Somewhere in the highway codes the purpose was described as separating traffic. Thus area:highway=separator would be possible. --Polarbear w (talk) 08:51, 17 September 2016 (UTC)

The US MUTCD uses terms like "buffer area". Some variations on this would be "buffer", "buffer_area", or "painted_buffer". Germyb (talk) 22:39, 18 September 2017 (UTC)

I think emergency for these exclusion zones is outright wrong. This value should be reserved for emergency lanes (for traffic) and emergency roads (for emergency services). I think the appropriate value would be exclusion or exclusion_area. --Peter Elderson (talk) 08:50, 19 December 2023 (UTC)

I'm thinking about a better road_marking=* scheme that would allow to simply tag these restricted areas as e.g. road_marking=restricted_area (or "barred_area" or similar). In my opinion, the "underlying" area:highway=* value should correspond to that of the other road in this area, because it's often just a marking on the carriageway. Supaplex030 (talk) 10:59, 19 December 2023 (UTC)

The direction tag within the barred area is pointless, since there are different styles for such area painted on the roads, ranging from a thick solid line without filling, over hatched lines to hatched chevrons. It also provides no value for data consumers, beside mimicking aerial imagery on rendered maps. --Polarbear w (talk) 09:26, 10 October 2016 (UTC)

Incorrect picture

Proposed_features/Street_area#Common_approach - File:StreetsLogicalLevel.JPG should be modified. Currently it is incorrect with too many polylines (separate lines for cases where there is no physical separation) Mateusz Konieczny (talk) 19:22, 31 August 2015 (UTC)

The same applies to picture from Proposed_features/Street_area#Logical_connection_points Mateusz Konieczny (talk) 19:24, 31 August 2015 (UTC)

Some general critique

On the mailing list i suggested to work over this proposal in general and restart the RFC once this is done due to the general problems in the basic design of this proposal. Since this suggestion is not accepted i here try to summarize the basic critique in more detail. I hope this makes it clear why a fresh restart would be a good idea - it will be difficult to address this without completely reworking the proposal.

Note this does not constitute a full critique of the ideas behind this proposal - this is very difficult to do due to the actual propositions regarding mapping and tagging being very vague in the text.

Preliminary remarks

This critique is about the tagging proposal as it is brought forward to be approved as a suggestion how things should be mapped in OSM. It is not meant in any way to affect the ability of mappers to freely use the tags mentioned in the proposal in a way they find useful as part of Any tags you like. It is also not meant to imply that the basic idea of a proposal clarifying how mappers can represent something like 'street areas' through polygons in OSM in general is a bad idea.

The proposal process is meant to ensure approved proposals meet certain quality criteria and are suited as guidelies for mappers to decide how to map certain things and that - if followed - lead to better usable data for all data consumers. I will explain here how this proposal currently fails to meet this requirement.

General characteristics of the proposal

The proposal primarily outlines a concept of map rendering that can probably be best described as simulated aerial images. While most maps render roads in a more or less abstract form focusing on their primary function, namely providing traffic connections, this styling tries to generate a depiction much closer to the real world appearance by using very limited geometric abstraction and also limiting coloring and patterns to locally observable properties and not depicting things like functional importance of roads within the road network. This is a fairly unusual concept but it certainly has its uses as an intermediate solution between maps and aerial images.

Weak points of the proposal

In the following i will address the most important general problems of the proposal from my point of view. There are probably more but as i will explain it is currently very difficult to properly identify what is actually proposed here in terms of tagging.

The proposal starts with a general 'vision' for road mapping in OSM that essentially reduces data to what is considered useful for either routing or rendering in the specific type of visualization brought forward in the proposal. This essentially already disqualifies it from meeting the requirements of a proposal as mentioned above, namely to give suggestions to the mapper that - if followed - lead to better usable data for all data consumers. The proposal essentially states upfront that it is only considering the needs of a specific type of visualization and tries to maintain usability of data for routing (although there is no specific consideration for this later on) and ignores all other applications. It therefore seems to be meant to actually codify extensive mapping for the renderer for a certain very specific type of rendering with no demonstrated use for any other applications.

The illustrations in the proposal to a large part compare visualizations of very different rendering intents. At no point it is shown to what extent the rendering intent advocated in the proposal can be accomplished based on the currently established mapping practice for roads. Also it is nowhere demonstrated that the proposed mapping is actually a requirement to produce the advocated type of rendering and not just something that would be convenient as a basis for the developer of such a renderer.

In particular the comparison between

and

must be considered highly manipulative and misleading since it compares a standard style rendering that is not meant in any way to aim at the simulated aerial imagery visualization style with a hand drawn picture of the same area where it is fairly doubtful if it is even possible to generate this algorithmically based on data mapped using the proposed tags.

The proposal generally mixes rendering ideas (which have little use in a tagging proposal) with tagging concepts, even in the tagging section. This further underlines this being exclusively designed to cater certain rendering ideas. This mixing makes it difficult to determine how much of the proposal is actually about proposing tagging but overall at least 2/3 seem purely about rendering. This is highly unusual for a tagging proposal - which generally at most contains a short section with rendering examples.

Important things missing

The proposal almost completely lacks specific instructions for the mapper and definitions for the proposed tags. The only thing that can be concluded in terms of definition is that area:highway=* is apparently meant to be applied more or less to the same kind of thing as existing highway=*. Practically this is however not of much use since the definition of values for highway=* is mostly functional and does not in any way enable a mapper to decide what area to map with area:highway=*. The proposal fails to provide even the most basic definition on how the 'street area' is defined.

The proposal also lacks any clear instructions on how areas to be mapped with area:highway=* are supposed to relate to traditionally mapped roads. It seems to imply that roads are supposed to be still mapped in the established way as well but it does not clarify if both are considered required or if either of them is considered optional. It mentions common supplementary tags like name are not necessary to be applied to street areas but this is too vague for a proposal. It should be clearly stated they should not be applied if that is the intent.

At some places the proposal seems to imply certain suggestions/requirements regarding the use of the currently established tagging for roads but this is left open. It is unclear therefore if the proposal modifies the current rules for road mapping or if it just adds new rules without modifications to the existing ones.

Mapping guidelines are placed here:

http://wiki.openstreetmap.org/wiki/Proposed_features/area_highway/mapping_guidelines --Marek kleciak (talk) 12:01, 30 September 2015 (UTC)

Questionable analogies

The proposal works with two analogies that are both very questionable:

The river analogy

It is written that this is the same approach like in case of rivers with use of midline or area for different zoom levels which is wrong on several levels:

• in case of rivers it is clear that the rivers are fully mapped by the waterway line in OSM. The 'river area' is clearly optional.
• the river line and the river area map two distinct and individually well defined concepts - the line is representing the water flow and navigation route while the area is representing the water covered area.
• the waterway and water area data have no specific appropriation in terms of rendering.

This proposal differs substantially in all these aspects so the analogy is quite misleading here.

The 'plumbers principle'

The real world principle of plumbing can be best characterized by use of geometrically standardized connection pieces and line pieces standardized in diameter but flexible in length and possibly form to build a pipe network. This has nothing to do with what is suggested in the proposal, it actually comes much closer to the current road mapping system in many aspects. What is described in the proposal is more like the 'bricklayer principle' - building larger structures from very basic components (bricks) which here equate the nodes and segments between nodes that polygons are built from. The suggestions outlined in this proposal essentially boil down to suggesting that different parts of the brick walls forming the pipe network are painted in different color. There is nothing in terms of geometric standardization and parametrization which is so characteristic for the concept of plumbing. So putting this forward as an execution of the principle of plumbing is misleading.

--Imagico (talk) 10:22, 2 September 2015 (UTC)

Use of "junction=*"

If "junction" is used twice with "highway" and "area:highway", existing applications may fail (e.g. counting "junction=roundabout").

The use of "junction" as area is inconsistent with the definition in Key:junction witch defines nodes and ways only.

In my opinion a juction area includes footways and cycleways as well. In the current proposal, a cyclist may cross a juction area one or two times, turn left and cross the same juction area again.

--Seawolff (talk) 22:53, 3 September 2015 (UTC)

That "larger" definition of junction isn't very useful here, though. The way it's currently defined, software can work with it (possibly except some conventions like ending the junction at stop lines, which could be altered somewhat without breaking the proposal).

You are right that using the "junction" key is a potential conflict, and using some other key might be better. Perhaps the ability for software to check whether e.g. junction=roundabout is on a road or road area is enough, though? --Tordanik 09:38, 4 September 2015 (UTC)

I think, the "larger" definition of junction is advantageous. OSM is not a map painting project only. OSM data structures should include all kinds of ways, not only streets.

Witch applications needs the "street only junction?"

The intersection of a larger juction and the area:highway can be easily calculated while the opposite way is very complex.

A proposal should not change the definition of existing tags by the way. Potential conflicts has to be discussed in the proposal.--Seawolff (talk) 11:25, 5 September 2015 (UTC)

In the United Kindom pedestrian crossings are at least a couple of metres behind the stop lines on the road which delineate the junction. So in that country at least junction areas would not includes footways. The proposal does include diagrams where crossings are inside the junction. --Peter Mead (talk) 09:35, 7 September 2015 (UTC)

Rename to Proposed_features/area:highway plumbers principle

I propose to rename the page to Proposed_features/area:highway plumbers principle since I always struggle to find "street area" in comparison the the other propsal which is named after the tag.--Jojo4u (talk) 13:00, 4 October 2015 (UTC)

Name for junctions

Junction areas need the possibility to add names because street junctions are often named. This proposal should incorperate Tag:junction=yes#How_to_use_on_an_area.--Jojo4u (talk) 14:58, 4 October 2015 (UTC)

Use turn or turn:lanes

I think you should represent some of your roads using turn=* or turn:lanes=*. --Fernando Trebien (talk) 14:12, 14 January 2018 (UTC)