Talk:Key:area

Discuss Key:area here:

---

Vote

copied from main Key page

• I approve this proposal Ben. 23:36, 25 March 2007 (BST)
• I approve this proposal Kms 08:50, 26 March 2007 (BST)
• I approve this proposal --spaetz 11:02, 26 March 2007 (BST)
• I approve of this proposal. It will be especially good to be able to use highway/pedestrian area=yes. Morwen 18:06, 27 March 2007 (BST)
• I approve this proposal --Etric Celine 18:16, 27 March 2007 (BST)
• This proposal sounds interesting. But could someone please add a definition how the new area tag can be used (values)? With which other tags is it allowed to be used? Maybe a few examples would be nice. Otherwise we will not know what has been approved! RalfZ 18:18, 27 March 2007 (BST)
• I approve of this proposal. Ksbrown^talk 21:49, 2 April 2007 (BST)
• I approve of this proposal. But why isn't there a vote started date on the proposed features page? Bobkare 23:07, 2 April 2007 (BST)
• I approve of this proposal. --Schuetzm 16:24, 3 April 2007 (BST)
• I disapprove of this proposal, for the time being. This is a very generic tag that could have much wider uses than are really developed/discussed here. Should all areas be tagged with this as a strong hint to renderers? What about features that currently have linear and area forms (e.g. water/rivers) should they be altered etc? How much renderer support will be needed to make any linear feature "area-enabled"? Personally I'd like to leave this till map features 2.0, which is promised RSN --Bathterror 11:23, 6 April 2007 (BST)

• Theres no altering invovled here. If something is linear it would stay linear unless you add the area tag. Just like you don't add width= to every single linear way. Ben 16:29, 2 May 2007 (BST)

• I disapprove of this proposal. --inas 02:07, 25 May 2007 (BST)
• I disapprove of this proposal for the reasons stated in my paragraph under "discussion" above. Dmgroom 01:36, 6 May 2007 (BST)
• I disapprove of this proposal due to potential confusion with the existing area data primitive. Thewinch 22:39, 6 May 2007 (BST)
• I approve this proposal I am already using it --Walley 18:34, 24 May 2007 (BST)
• I approve this proposal --Gregoryw 15:08, 25 May 2007 (BST)

Voting seems to have passed this tag. Discussion on the problems people have with it hasn't really got anywhere, so I'll add this to the map features. Ben 23:50, 7 June 2007 (BST)

Map Features 'Elements' listings confusion

It's a bit confusing at the moment looking at Map Features and understanding how area=yes fits in.

All the things (such as highway=residential) listed on Map Features, as way () features... are we saying any of these tags can be used on areas, provided we add the area=yes tag? Does this apply to node features () too? This point should be clarified alongside the area=yes property listing. At the moment the explanation is far too simplistic.

...and then things which are listed as area features () ...would you say these do not require area=yes, since they are areas by default? (renderers certainly don't require the tag for any areas) This point should be clarified.

...and consider things like 'leisure=playground' which are listed as possibly node, possibly area If we are able to override with area=yes on anything anyway, does that area icon really mean anything on the playground listing? Everything is "possibly area".

-- Harry Wood 11:40, 18 October 2007 (BST)

Example images

Nice example images Image:Osmarender area residential.png and Image:Osmarender area pedestrian.png, although actually they're not a straightforward as they could have been. Showing buildings confuses the matter. "Are the buildings building=yes or do they also have area=yes?" ...is the question which springs to mind. I know the answer is that osmarender does not require area=yes in order to render buildings, and the examples are not intended to relate to the buildings at all. But even *I* don't know (as a fairly experienced mapper) whether we are supposed to be putting area=yes on buildings. -- Harry Wood 14:56, 7 January 2008 (UTC)

Old discussion:

I replaced the images, but I agree to this idea. Having it as area=yes means it can be applied to any track or highway regardless of its type. It is a far better solution, and far more open to interpretation and use in all areas than the proposed 'plaza' tag. Ben. 21:04 19th January 2007 (UTC)

Interesting idea. I am not sure yet, whether I like it. :-) What I don't like is the key "area". That seems too generic and too open for misunderstandings. Can we find a better name for it? Joto 09:55, 20 January 2007 (UTC)

Having a generic term is the whole advantage. The tag would go along side something else to state that its an area, not just linear. The other tag will state what the area is actually an area of, this tag doesn't need to be specific therefore. Just like layer=5 is generic cause it can be used for anything. Ben. 04:13 21st January 2007 (UTC)

I agree that a generic term is of advantage here. Denoting an area as such can make sense in many situations.

However, the renderer already knows it's an area by the fact the loop is closed, so I don't see why you need to add any new tags at all. Kleptog 15:27, 5 March 2007 (UTC)

Not true, roundabouts are closed loops, but not areas. I find this to be a good suggestion, it makes it easier to see what is actually an area, now I sometimes have to check the map features page to see if this specific tag should actually be used on an area. --Bobkare

Excellent idea to have area tage. It would alow wide ends to be mared as shown and simplfiy the road endings that are triangular from two forks which are not real (I currently use) to the actual area. Ksbrown^talk 20:12, 6 March 2007 (UTC)

I like that very much, as it would be a very generic solution. I could think of paved areas at the end of roads, but also of squares. They could e.g. be highway=pedestrian area=yes, if they are, let's say like a market square in the middle of the town.--spaetz 13:28, 22 March 2007 (UTC)

The idea is good, and it required, but the tag area=* might be confused with closed ways also known as areas. I propose that the tag should be paved_area=true/yes Bruce89 01:01, 26 March 2007 (BST)

• Paved_area=true/yes wouln't work if the area wasn't paved, so I disagree. Area=yes is similar to closed ways, but then thats its function, it makes linear tags render as closed ways, where the tag can't be an area tag due to instances where it exsists not as an area (roundabouts). Ben. 04:36, 29 March 2007 (BST)

This to me seems like something that could be useful for some of the junctions/crossroads/intersections round here... where two roads cross where each has 2x3m wide bike lanes with a 1.5m wide garden section separating it from the main road on each side, a turn right and bus/taxi lane, each 3m wide on each side, separated from the main traffic ahead/left lanes by a further 1.5m wide garden section, with the main traffic ahead/left lens consisting of maybe 3 in one direct and 2 in the other... plus wide pavements... gives a 40+m x 40+m junction... right now, that would be a big hash of intersecting lines when really, it is just an open area that all the lanes terminate into and resume on the other side... But then again... the big hash could prove useful in making things routable and I guess it should be the renderer that brings them together... Dtucny 05:29, 26 March 2007 (BST)

---

• In relation to RalfZs question beneath: I would use this tag for anything, just as width= is used to tag the width of anything, and oneway can be used on anything that is oneway. Its a properties tag, as I understand it, so therefore the independent key is only there to make it usable with other propertie tags, rather than so it can have many values added to it. Off corse this is just how I understand it, and originally discussed it as... What comes of this disccusion and vote is how it will actually be used. I intend to use it on anything that is more than just a linear way, and that isn't an area by default.Ben. 04:36, 29 March 2007 (BST)

---

Firstly let me say that I have nothing against being able to render areas. But the proposal in its current form of area = yes, highway = residential completely breaks the understanding of what a way marked as highway = residential is, which is a continuous road along which you can drive - highways are highways, areas are areas, and the two are never the same.

• I fail to see why the use of a tag such as landuse =tarmac, which could then be added to an area at the end of any road would not satisfy the majority of the proposed useage of this tag. Dmgroom 01:36, 6 May 2007 (BST)

• Becasue it commonly isn't tarmack. Because the land isn't used for tarmack, it is tarmack. Becasue the highway may be an area, not just the phisical properties of the highway, or a landuse. Because Areas need splitting appart from linnear closed ways. Ben 21:48, 6 May 2007 (BST)

• landuse=turning_area then? Dmgroom 22:19, 6 May 2007 (BST)

---

At the moment all features that would be used for routing are linear. To route through areas will add significant compexity. The only benefit currently explained is a better ability to define an area which looks like it could be a turning circle.--inas 03:00, 2 May 2007 (BST)

• It is not true, that only turning circles would benefit. Also market squares (and other squares), wide pedestrian streets and other stuff would benefit from this. --spaetz 13:14, 2 May 2007 (BST)

• Would you use it for a wide pedestrian street? Wide one way street? Wide street with one-way bus only access? How would this work? --inas 00:28, 3 May 2007 (BST)

• You could use it where ever, but...if there is a specific threw route then you would map that also. The only good point made there is that it may not be needed becasue; if a pedestrianised street is wide but has parrallell sides it could be more efficently mapped as a linnear way with a width tag. A racetrack is a good example of this. Its a very large area, but I would/have mapped it as linnear, although osmarender currently renders them as an area, wich I think is incorrect by itself for the reasons discussed below. Areas would/should add detail, but not replace a route that may be there. Ben 01:07, 4 May 2007 (BST)

• This has infinite uses. The 1 example above is 1 example wich gives the general jist. Where ever a tag is linear but its possible for it to exsist in an area or closed linear form then the 2 situtations require an area tag to split them appart. I use this tag so frequently that I find it quite hard to understand how people think it has a very limited usages. If its complex or not to route threw an area is irelevent, the data must be correct and some areas are areas. There is only 2 other options that I can see for getting the same results as this proposal would make. 1) swamp the area with ways that render linear, so it appears filled. 2) create a closed way variation of each tag were nessessery. Both of these are very bad ideas. If a linear route goes threw an area, then I stick a linear route threw the area and vice versa. Why would a route planner have difficulty with that? If theres no definate route then a route should not be there. Correct data is most inportant. A small turning circle is a bad example. I would say that a small turning circle would be the only place that I Wouldn't use it, as there very small and regualar, so a tagged node would be sufficent, and something along those lines has been proposed recently anyway. If people require some examples of where this tag is frequently needed, then just have a drive round your local farms or industrial estates and observe the huge areas of concrete/gravel/compact mud etc. It work's for every form of highway/track/route I can think of. OSM's data isn't just for routeplanners anyway; Its also for people to be able to use like maps have been used for centuries, hence osmarender/mapnik, and so it should be visually correct also.
• Finally I'm gunna say that the only other solution I can think of to this problem is that closed ways and ways are made fundermentally differnet just as way and nodes currently are, and a way in a loop would then be differnet to a closedway. Then simply creating the closeway would alter the tags value. But since thats not currently a posibility, and who knows if it ever will be, a standard tagging solution should be created wich can always be changed later and all area tags changed easily, rather than there being a scattering of different keys that people have made up. I think this tag should be moved to the standardised page, as enough people agree to it, and people are free not to use this tag if they wish, thats the beauty of OSM! Ben 16:29, 2 May 2007 (BST)

• I see your points. I think I am agreeing with you when I say that ways have been used for two distinct purposes. One is for linear through route plotting for routing and and rendering, and the other is for feature outlines descriptor essentially for rendering only. These are really two distinct things, even though they have a similar implementation mechanism (ways). It is important to both be able to render the map accurately, and to get a through route between two points. When a way is tagged as "highway=" it essentially becomes this first kind of purpose. It is a link, a through route. When it is tagged as (for example) theme_park, it is being used for the second purpose. If what is being proposed here is implemented, then any through-route can become an area. It immediately loses capability. It loses the ability to describe direction for a start. I agree that we need the map to render accurately. What I don't agree with is the changing a highway= through-route descriptor into a feature outline descriptor.

• A route shouldn't become an area If there is a route threw the area. An area is not the same as a route. Just like an area of water isn't a shipping route. The shipping route is on the area of water, and it would be mapped seperatly. If the road is such a crazy shape that a person feals like the area needs adding, then the threw route, (right of way/lane etc), would be added seperate again. Becuase otherwise it would inply that you have to drive around the very edge of that area, wich is obviously incorrect. I would seldomly add area to a highway above a secondary anyway, because for all bigger roads in the UK the extra area would just be a phisical thing, the highway itself would only run over the top of it, or past it. Ben 01:07, 4 May 2007 (BST)

• If there is always another through route defined for every highway "area" the area can simply be ignored by the router, and used by the renderer, so using the tag this way does solve the routing problem. I think two problems remain. The first is, my understanding is every highway tag on a way currently implies a route. Making this change would alter this, now only highway tags without the area tag will be routes. Map features are currently distinguished from map routes by this tag, and this is a good thing. The other problem is by overloading the highway tag with this new meaning adds to the confusion. Ways are already overloaded with being both routes and features. Is it intuitive that every time that highway is tagged with an area tag, that a second way tagged as a highway is required for the route? Would a tag like landuse be better if it is a map feature being defined? --inas 22:24, 5 May 2007 (BST)

• There wouldn't always be another through route.
• A highway tag on a way, Without an area key would still just be as it is now. Nothing would be altered at all in that sence. This just makes it posible to make an area an area, rather than a loop. Wich is good because a route planner can tell that its an area, and if there is a lack of a threw route it can be worked out that you don't need to drive along the way around the edge of the area, because it knows its an area. If there are 2 ways, 1 tagged as the area, then the route planner knows to follow the linnear.
• A second way going threw would/should only be added if there is a threw route. Just like everything mapped...only add whats there and vice versa.
• Landuse is incorrect for a couple of reasons. 1) It would involve there being a landuse= value for everything that can exsist in an area form. 2) Landuse as I see it means that the area that you have marked is primerally used for that featuer. I.e Landuse=wood would be used for wood, rather than there just being a natural=wood there.
• Concerns that a person may misuse a tag is no reason to stop other people using it correctly, and there is definatly a very common usage for this tag, and it has many advantages.
• The only concern I can relate to is that an area tagged as motorway would be incorrect but I'm shore people can work that out!. In this case I would tag the area as tarmack, and the threw route as motorway. But for lesser roads and ways that don't have such definate lanes this isn't a problem. (e.g. a pedestrianised area isn't linear in reality)Ben 03:23, 5 May 2007 (BST)

• This feature would immediately break every current version of renderer and router currently using the OSM data, because it is not just a an additional feature, it a change to the model. Highways are no longer routable elements with direction, they can also be feature descriptors if they have the area tag (think of all those additional IF statements in all that code to check for this!). Just because you want to reuse many types of highway to be an "area", doesn't mean you should overload the highway tag to do this, and not use another feature tag. One day when another type of area which isn't currently defined as a highway, needs an area, there will need to be another type of highway defined. Can you confirm that the area feature being proposed, will never be a routable element? --inas 22:24, 5 May 2007 (BST)

• No. This feature would not break every renderer. I have it in my osmarender version, and it made no problems. I stuck it in , and theres no problems. I didn't know that there were currently any routeplanners useing osm data, so I cannot answer that, but making data that is simplified, and inacurate/unpresise just so its suitable for a very basic routeplanner is not the way to go. Using incorrect keys, and swamping them with infinate values is also not a good idea. This will not overload the highway tag, it is an independent tag, just as the width tag doesn't overload the highway tag. Some ways are not linear, some ways are linear with a shape that is more than a width. As I have said, I use this tag freqently, and it comes up so commonly I can't for a second agree that there is no real need for it. I can't see any problems from what you have said, that are not currently there. I.e. an area tagged as area would be treated differently if tagged. But if not, then the route planner would take you around the edge of it. Therefore the routplanner would itself need to work out that its an area, wich is inposible, because it may just be a loop (roundabout/circular are of tarmack). I'm just repeating myself now, so I don't really wish to drag this on any more. This is how others do it, and how all drawing/modeeling programs work. dot/line/shape/area. Dissapproving and preventing progress is really disapointing, espesially since there is a great lack of alternative ideas. I wish to get on with mapping the world, not sit around holding up a developing tagging scheme. Although I don't particaully agree that voting is the way forward, but rather solving things by discussion, this is a dead end, so I think this has had enough support to be shifted to the standardised page. If so/If Not, I intend to use this tag until I see better. So on my part; that is it on the matter, as its just getting repetative. Ben 22:15, 6 May 2007 (BST)

• You have missed my point, if you think that using width tag is overloading the highway tag in the same way as this tag would do. Taking some time to develop the best tagging scheme before mapping the planet may save time and effort later. Tags like landuse have been suggested, and so far I haven't seen an example of what you are trying to achieve that couldn't be done just as well with this tag. --inas 02:19, 25 May 2007 (BST)

---

Bit late but I think areas would be better drawn as in the above image. The highway doesn't stop at the border of the area it continues into it. The example perhaps isn't the best one. Consider if the area was halfway along the street instead of at the end. --Thewinch 01:45, 24 June 2007 (BST)

• If there is a through route that goes through the area then having a linear route as well would seem logical. I only ever leave it just as an area if there is no definate route to take. In the original example there is no through route, so continuing the linear route into the centre of the area doesn't do much bar require more segmetns/nodes. It is inportant that the road leading up to the area links to the area though rather than just continue into the centre, becuase otherwise the 2 elements don't connect at all. Ben 00:48, 5 July 2007 (BST)

Why doesn't this area show up on Mapnik?

http://www.openstreetmap.org/?lat=39.26609&lon=-76.55945&zoom=17&layers=B000FTF - it shows up in Osmarender, but Mapnik won't draw it. --NE2 22:08, 11 February 2010 (UTC)

Mapnik only accepts area=yes with a few selected highway tags, motorway isn't one of them. And that's correct behavior, imo - there simply are no motorways where no direction of traffic is defined (so you can freely move from any point of the area to every other point). --Tordanik 11:06, 12 February 2010 (UTC)

Yes this should not be mapped as an area. I can see why you're tempted to do so though. It's an classic example of the level-of-detail problem we have with OpenStreetMap. If we go down the super-detailed mapping route, then sometimes it feels like we should be mapping everything as an area. Take that approach to the extreme, and even a post box occupies and area! We have to draw a line somewhere, and with roads at the moment we're never really mapping them as areas unless they're a town square type area "(so you can freely move from any point of the area to every other point)" as Tordanik says..In the case of big wide roads, this can be frustrating. You've mapped your post boxes and your individual benches and trees in the area, now you want to show where the big road is exactly, so it all shows up nicely on the zoomed in map. The only easy half-solution is to add a width=* tag to it. Not rendered at the moment, but maybe it could be. ...But representing roads as areas is a problem we can only tackle by drastically rethinking the OSM datamodel. In the meantime I suggest you try not to let it annoy you. Use the width tag, and move on to mapping somewhere else.

-- Harry Wood 11:34, 12 February 2010 (UTC)

Me (and some others) have drawn some other very wide and/or unusual shaped sections and intersections, too, (mainly just to show other mappers that the chosen representation as ways is the most descriptive choice), but tagged them as landuse=lanes or landuse=lane. If someone comes up with a use case for that data, it's then available. Alv 12:38, 12 February 2010 (UTC)

OK, I retagged as landuse=highway. --NE2 13:50, 12 February 2010 (UTC)

List of tags used with area=yes

I disagree with the attempt to create a list of tags that can be used with area=yes. As expected, it's missing a lot of possible cases. For example, it is incorrect that only highway=pedestrian can be used together with area=yes. It can also be used with other highway values, such as service, living_street, path and foot-/cycle-/bridleway. I wouldn't even be surprised to see it used with highway=residential in some cases. --Tordanik 20:31, 17 February 2012 (UTC)

There is an opinion, that using area=yes, for example, with highway=service is incorrect, because it creates problems for navigators, because they think, that we should use border of area for route. Using area:highway at area for cosmetic purposes with linear highway= for routing purposes is better. Dinamik 22:57, 17 February 2012 (UTC)

• If there is a linear road, then using highway=* + area=yes for the area covered by that road is incorrect. But if there is a square, plaza, or other large area without clearly defined traffic flow or road markings, then using area:highway=* is incorrect - in that case, highway=* + area=yes is in fact the only correct representation! These are two different situations, and the difference is not merely cosmetic. A good navigation software would understand both, and treat them in a slightly different manner (for example, tell you to "follow X Road", but "go across Z Square").
• I'm aware that most of our current navigation programs are quite primitive and will route along the border of an area instead of directly across it. But that's not the fault of our data - there are well-known algorithms for dealing with routing across areas. The solution here is to improve the affected programs. --Tordanik 23:23, 17 February 2012 (UTC)

• It was exactly because of this sort of uncertainty that I created a stub list in the first place and I still think that it will be a very useful resource to help us discover what the rules are. Without a clear list somewhere every downstream user of OSM data will have to trawl through a similar slow learning process. Can I urge any who are aware of more 'possible cases' to add them to the list so that we can get some idea of how complex it is?
• Can I suggest that we move this discussion of whether different types of highway should be rendered as areas to the Highways page?

-- PeterIto 09:43, 20 February 2012 (UTC)

• Alright, if I remember any other features where area=yes is relevant, I'll add them to the list. My problem with the list is that it doesn't say that it is a stub. I don't want anyone to claim a few months from now that x=y cannot be used with area=yes just because nobody who was aware of the tag x=y had this page on their watchlist.
• Moving the highway-related aspects of this discussion is fine with me. Regarding that topic, I've restored a section of the old content about the meaning of area=yes on highways, and inserted a remark that it is not clear yet for which highway values it actually applies. Oh, and for the record: While I've not removed Dinamik's "there is an opinion" remark for now, I still disagree with it (see above). I just want to give him an occasion to reply. --Tordanik 17:49, 20 February 2012 (UTC)

I think area can be used with any way type. You can create linear way for nav + area for visualising. For example, why we have river + riverbank ... when is there more logical tagging river linear way (for navigation etc.) + river with area tag for riverbank. Same for highways. As bonus, when nav sw know that, can say "hey, there are two or more ways in same area => we can move to any way" and then you can made many nice things. --Jezevec 17:26, 4 April 2012 (BST)

We have waterway=river for line of river and waterway=riverbank for drawing its banks. In situation with roads we have highway=* for line of road and area:highway=* for the area of road. Dinamik 22:32, 4 April 2012 (BST)

Yep, and we have chaos in tags, because we have 10+ tags for same things. And with that, if someone need for example write renedering rules, then must know all possibilities + tags for areas without area tagging (landuse ...). So I mean, better for all is using uni tags. Not that chaos with ... runway + area=yes, area:highway, riverbank ... 3 totally same things with 3 totally different tagging scheme. When someone ask me today for area tagging, what can I say him? "It's depend ... on moon phase...???" --Jezevec 18:46, 29 April 2012 (BST)

I don't think, that there are tags for the same thing. waterway=river is a line of river (this tag only shows the direction of stream and exact location. waterway=riverbank is a tag for riverbanks (tag shows precise location of riverbanks). At the same manner highway= is a tag for routing lines (tag shows only routing direction and exact location), area:highway= is a tag for border of carriageway (tag shows precise location of borders). Different levels of abstraction - different tags. Dinamik 19:53, 30 April 2012 (BST)

Navigators

area and area:highway for pedestrian squares

Variant a) of tagging is worse for navigators: some of them don't know, that you can go across square. If we choose variant b) with area:highway and routing line, navigators know, how people can go across the square. When we mark concrete routing lines with highway=<tag> for navigators and area:highway=<tag> for cosmetic purposes (to draw area), it is easier for navigators. Perhaps, namely because of these reasons some people "don't like" area=yes+highway=<tag> and replace area=yes to area:highway=yes or area:highway=<tag>. This situation is the worst, because routing brokes in all programs. So it is better to write for such people, that if they replace area=yes+highway=<tag>, they should obligatory add routing line. Dinamik 17:35, 21 February 2012 (UTC) So your suggest

WTF? Why not use B but with highway=pedestrian area=yes? --NE2 17:45, 21 February 2012 (UTC)

I think, it will be better, if we will be polite and will not use profanity in our dialogs. I added variant with routing line and area=yes+highway=pedestrian. But we should remember, that variant area=yes+highway=pedestrian at area and highway= at line has an disadvantage: navigators in such cases can define border of area as routing line. Dinamik 18:40, 21 February 2012 (UTC)

I do not understand why we need to have this discussion. If they don't know that you can go across a square, their programmers need to tell them. It's not an unsolvable problem at all, you learn established solutions for the task at computer science courses. But maybe this image helps to illustrate why it is a pretty weird idea to have human mappers manually perform a tedious task (drawing all possible routes across a square) that can routinely be performed by computers. --Tordanik 03:34, 22 February 2012 (UTC)

I agree with Tordanik that it is not the job of the mapper to introduce a load of extra ways to get round deficiencies in current routers. It is for routers to get better at routing across areas and they will do in due course - it is not a very difficult problem and as Tordanik indicates it is virtually impossible for a mapper to do a proper job for an area with any complexity. PeterIto 05:55, 22 February 2012 (UTC)

Proposed features/area:highway

I believe that this article should restrict itself to describing current tag usage in a simple way suitable for new users and then provide a link to any relevant proposals for new tagging methods. As such I have adjusted the article to make a very clear distinction between current practice and a new proposal. Please can we discuss this policy issue here before making further substantial changes to the article.PeterIto 06:03, 22 February 2012 (UTC)

Separate areas from road that surround them

The page says:

Note that multiple tags on the same closed way can result in the way being used to define both a closed area and also a polyline; for example a closed way tagged landuse=grass and highway=tertiary should be interpreted as a tertiary road enclosing an area of grass.

In my opinion, this is wrong. While it may be ok with other line features (barriers, for example), a road's way represents its center line, so no feature should be attached to a road's nodes, especially land uses: there's no gras in the inner half of the road.

I suggest we remove or at least rephrase that line. --SimoneSVC (talk) 12:26, 4 July 2013 (UTC)

You are right. I've tried to improve this by choosing a different example (fence) and also pointing out that it is a somewhat hack-ish solution to start with. Does that solve the issue for you? --Tordanik 15:52, 4 July 2013 (UTC)

barrier=hedge on a closed way in default map style

From article "(note: current mapnik style implies area=yes for barrier=hedge on a closed way (!) - to map a hedge as a linear feature, non-closed ways are needed)". this is untrue --Mateusz Konieczny (talk) 13:39, 29 November 2014 (UTC)

First, do your research. Indeed it was and still is true, as can be deducted by a simple look at the map and associated data in question: implied hedge areas --Cmuelle8 (talk) 01:15, 30 November 2014 (UTC)

"First, do your research", I did and even linked to it. Hedge on closed ways is *not* a problem. Only hedge on a closed way that also has a tag implying area=yes results in problems Mateusz Konieczny (talk)

The problem you're describing in your second sentence is a subset of the one in the first. So yes, hedge on a closed way is a problem.

In theory it may work, yes, but practice has shown that it's not safe to use: It's proven to be error-prone - for data consumers and producers alike. Even more so as long as Way suggests to break "one feature, one element" paradigm. Assuming this may be fixed by tomorrow, there won't be any time soon for mappers to pick up on this specific issue.

Practically and currently it's useless to assume a hedge on a closed way will remain an exclusive tag. Anytime it's possible for a next editor to add a landuse or similar area-implying tag, e.g. thinking this has been forgotten in a previous edit. --Cmuelle8 (talk) 18:21, 30 November 2014 (UTC)

- (there is a related problem of interpreting linear and nonlinear feature tagged on the same closed way). See https://github.com/gravitystorm/openstreetmap-carto/issues/961#issuecomment-61508627 for an example. See https://github.com/gravitystorm/openstreetmap-carto/issues/971 for a problem cause by incorrect tagging linear and nonlinear feature on the same OSM element. --Mateusz Konieczny (talk) 13:39, 29 November 2014 (UTC)

.. and, for completeness sake: See http://josm.openstreetmap.de/ticket/10551 we've all seen it, you were the one reporting it. --Cmuelle8 (talk) 01:15, 30 November 2014 (UTC)

And anyway, bug in data consumer is not a proper reason to change tagging (see Tagging for the renderer) --Mateusz Konieczny (talk) 13:39, 29 November 2014 (UTC)

Right, but picking up One feature, one OSM element should be, should it not? And anyway, you're missing out on the fact that one of the main data consumers -the osm.org map- actually got bugfixed on this one, _because_ it follows what has been documented in this wiki. You can clearly see an area icon to the right denoting that this feature may be area-mapped using either a closed way or a multipolygon-relation. The documentation does not state that it is necessary to tag an additional area=yes to recognize such closed ways as an area. In fact, the icon for a closed way polyline is missing.

Also, the behavior of implying an area, if barrier=* is tagged on a closed way, is in sync to what Overpass does, another heavy data consumer.

If you really want a contradicting definition look up Way. However, this page also suggests combination of linear and area tags on the same element, a root cause of existing misinterpretation of closed ways. In the light of "one feature, one osm element" paradigm this page seems rather outdated.

It boils down to: If you want a linear hedge, use a line, i.e. a non-closed way primitive. If you want a hedge area, use a multipolygon.

This will avoid future changes to the interpretation of closed-ways carrying this tag and is not prone to mixing different feature tags on the same element as Way unfortunately suggests. --Cmuelle8 (talk) 01:15, 30 November 2014 (UTC)

ares connected to streets

I would like to know your general thoughts on the topic of areas connected to ways for more than a single node.
Imagine this scene: A street is going from north to south. There is a grass area on the left and a scrub area on the right. The nodes for the area border along the street are shared with the street. I have seen this kind of mapping very often and in my opinion it's not a good mapping style. Buildings are also not connected to streets even they are right next to them. Streets are not connected to waterways even when they run alongside of them. It not just causes problems with more than one editor, but is also mapped incorrectly. After all, a street is nether a place where grass scrubs grow (to follow the thought experiment). If a small grass lanes next to the street with a width of ~5 meters is worth beeing mapped, then the street which has ~15 meters should deserve it's own area (just like waterway=riverbank).
The main problem I found is that in many situations it is not possible to select the street, but only the area. It seems that the only way for selecting the street, that works 100% of the time, is to delete the area, select the way and undo the deletion. If the way is longer than the area, you can still select the way pretty easy, but if a way is sandwiched between to other ways and areas on both sides just run past the short way (eg. a bridge) it's difficult or impossible to delete the short way reliable --TBKMrt (talk) 22:08, 25 March 2019 (UTC)

Opinions on this will potentially vary between various regional and national communities. I only have first-hand knowledge of the situation in Germany, where most mappers (at least those active on the forums and lists) dislike connecting areas to road centerlines. Instead, it is recommended that areas are drawn with their actual extent, i.e. end at the edge of the road. --Tordanik 17:19, 23 April 2019 (UTC)

In Poland connecting areas to road centerlines is considered generally as a poor idea. It is also preferable to map areas with their real size and shape Mateusz Konieczny (talk) 18:09, 23 April 2019 (UTC)

Thanks for your feedback! --TBKMrt (talk) 20:33, 5 June 2019 (UTC)

wrong description

The current description desribes area=yes, the description for area=yes/no should be different. maro21 21:25, 8 June 2021 (UTC)

Tag:area=yes redirects here, so I requested deletion of that redirect - see https://wiki.openstreetmap.org/w/index.php?title=Tag:area%3Dyes&diff=2162778&oldid=309544 Mateusz Konieczny (talk) 11:48, 9 June 2021 (UTC)

I don't think we should move the page, because Key:area describes area=yes and area=no. I've just wanted someone to change the description. maro21 19:32, 11 June 2021 (UTC)

I altered the description accordingly. --Tigerfell  (Let's talk) 12:14, 31 July 2021 (UTC)

Too hard to make separate things using the same corners

But it is so hard and various editors to make a fenced sports pitch, using the exact same nodes, as two separate entities, instead of putting all their tags on the same entity. Jidanni (talk) 23:10, 4 May 2023 (UTC)