Feedback Request: Pros and Cons of Areas or Relations

Posted by Alessa on 22 March 2017 in Maltese (Malti). Last updated on 2 February 2018.

Hello, everyone.

I would like to request some feedback on what users consider pros and cons of doing landuse and landcover tags as areas or relations. To this point, I’ve been tagging regular areas, since this is the standard I learned from doing my homework and studying OSM wiki/forum documentation. For example, this is what I used in the coastal region of Kabyea Essa. I comes out just like I want it and has the data I’d like for later (double plus!). I know that Luciano has been innovative in using relations to this end, and I was curious what the advantages and disadvantages are or might be. I’m not sure I really want to break up a roadway into a dozen pieces per kilometer just to adjust relations, but it might render things better for me.

I will say that areas get to be quite clunky in JOSM when placed against each other like this. It becomes impossible to select a highway or railway that is on the boundary. In many cases, I’ve resorted to just using iD, because it works better for me to do the fine-tuning detail work. At the same time, that could be a user issue.

I appreciate the insight. Thanks!

Comment from Luciano on 23 March 2017 at 00:21

Hi Alessa. You say, “ areas get to be quite clunky in JOSM when placed against each other like this. It becomes impossible to select a highway or railway that is on the boundary.” - THIS is exactly why I started using relations. My basic rule is - NEVER EVER PUT TWO WAYS ON TOP OF EACH OTHER. If you feel the need to do this, it’s time for making relations.

Anyway, roadways shouldn’t be the boundaries of landuse areas, in my personal opinion - there should be a parallel way on each side of the highway demarcating the landuse. I know this runs against OSM current practice in tagging, but I strongly feel that a highway “way” should exist solely for the purpose of routing, and shouldn’t do “double-duty” as various sorts of boundaries - after all, this is not how the real world is actually put together, wherein roads and highways are, in fact, areas, not just lines on the ground. Thus a road has two sides, with a third conceptual path down the center defining the route. If you look at VERY DETAILED mapping in OSM (I’m thinking of, maybe, Oslo (, you can see how this works out: there is a way down the middle of streets for routing purposes, and each side of the street also has a way delimiting the width of the street. Currently, the render doesn’t handle this well, but you can see it nicely in JOSM. If you look at the level of detail in the Naver Maps application (Korean market) you can see the same result, with excellent rendering. Here is a general link to naver maps ( - you’ll have to zoom around on your own, because it doesn’t seem to provide the functionality of presenting geocoordinates in the URL.

Comment from Alessa on 23 March 2017 at 00:37

Thank you for the reply, Luciano. I understand what you are saying, especially for urban use. I’ve peaked even at places like Gobras City, where this is done as you say. That makes sense. I’m wondering about a more rural area, like Kabyea Essa: I think what you’re suggesting is that I keep the land cover like scree and heath a meter or so away from the way that forms the highway. I see how you did this in Tarrases. I assume then that you prefer the gaps in the mapping to overlapping lines on JOSM.

Comment from Luciano on 23 March 2017 at 00:47

Yes, I have been thinking that in a sense, the highway is its own landuse - and in the openstreetmap schema, it might even be thought of as the “default” (untagged) landuse. Thus, in Tárrases, I left the highway areas untagged. I actually DO like how this looks in the render, but it’s not, strictly speaking, very realistic.

I’m planning on trying something different in Comala. I’ve been moving in the direction of trying to separate the VERY confused way the OSM schema mixes up landuse (a human concept, e.g. residential, industrial, farmland, etc.) and landcover (a natural concept). I am hoping to build two entirely separate and essentially overlapping sets of relations, one for landcover, and one for landuse. I have no idea how this is going to end up looking on the render. Then things like highways will run “through” these two sets of relations (as they do in the real world) with detailed width-of-streets tagging (curbs) in urban areas.

Comment from Alessa on 23 March 2017 at 01:01

Thanks, Luciano. That makes sense. I was thinking about that myself. I’ve also thought that it could be refined that way, too. I might try experimenting with some things too. This brings me back to my original question, however. What is the benefit of doing these as relations as opposed to areas?

Comment from Luciano on 23 March 2017 at 01:26

Maybe the best argument is that simple one: avoiding having overlapping ways, which strike me as an abomination - not only are they hard to deal with in editing tools (although there ARE ways to deal with them), more importantly they represent a bad practice from a database consistency / integrity standpoint. Given my former career as a database designer, these feelings have a religious intensity for me.

From a utility standpoint, there can be some advantages, too. If I have all my landcovers “enrolled” in relations, then as I refine my concept for a given area I can make quick-and-dirty transformations of the groundcover, just to explore “how it would look.” Thus I could turn all my “natrual=wood” into “natural=scrub”, if I wanted, simply by editing a single relation. Or I could create multiple relations for different types of forest (e.g. conifer, deciduous, etc., or even more detailed) or for different types of farmland (e.g. rice cultivation, corn cultivation, etc.) in ways that aren’t reflected in the render but that might have some impact for how I conceptualize my imaginary country, or that could drive future GIS data documentation (in the wiki via the very useful “ExternalData” extension) of e.g. forest cover types or cultivar types in my country.

Comment from histor on 23 March 2017 at 09:13

As Luciano wrote: A street is in real life not an abstract line, but a small but long area - broad in towns with footpath at both sides roundabout 20 m. So in zoom-levels of 17 or more this “broadness” of a street is to see! Therefore the land at the sides of the streets I draw with its own ways and own areas like []. Between the street and the area of landusing-tags or natural-tags us a small piece of nothing. If you want, in this untagged area you can draw the foothpath at the side of the street, a cycleway or a tree_row. But to do this, it makes the map too full, I think.

Areas you can simply draw as way around. But if an area has an “island” inside, a relation is the better way (see the Ayuntamento # 4 in my link). And yes, I avoid to set two ways in the same nodes. Even fences are parallel to the landuse.

Comment from martinum4 on 23 March 2017 at 09:38

There’s an commandline plugin for JOSM that allows you to create offset lines to any line, that way you can create the lines for your landuses quite easy, i use it for creating dual-oneway-roads, railway tracks and power lines (layout all the curves nice once, then just use offset to get the same distance between them everywhere) it’s way easier than my previous approach (setup node distance once and then copy paste them)

Also I agree with Luciano regarding OSM-Style-tagging of landuses, in OSM i always remove the landuses from roads when i encounter them, no shared nodes!

Comment from wangi on 23 March 2017 at 09:42

“Even fences are parallel to the landuse” If you have the physical boundaries mapped then the landuse should be a relation, using these ways.

It is very common for administrative boundaries to run down the middle of rivers or roads - in these cases the admin relation should use the road / river ways.

Comment from histor on 23 March 2017 at 09:58

If between the grass of the meadow and the fence is a gap is a nearly philosophican question. I do not like the confusion of two ways along the same nodes. Therefore the fence is parallel to the grass in short distance.

And indeed - will you make for every small area of landuse an own relation instead of only an area?

Like all, what men do, OSM is not perfect. The tagging of roads only as a line has some handicaps in mapping as a boundary in the ideal-line of the street or the streetcar-rails in the middle of the street.

Comment from martinum4 on 23 March 2017 at 10:29

you can actually use rivers or roads in boundary relations, it works :) for the most of small landuses i usually just use areas because relations would be kinda overkill

Also, there’s people in OSM that already map the areas for highway. You can also place the line of the road somewhere else and correct the actual position of the lanes via placement=*

Comment from Ūdilugbulgidħū on 23 March 2017 at 13:37

Land cover for Shadze-Ma uses multipolygon relations. All ways are shared between adjacent land uses. The whole country is covered, with no gaps. Overlying this are roads and other transport ways. Therefore some ways do lie on top of others, more or less, but not at finest scale - it is always possible to select different ways at high zooms. For example, where landuse changes from grassland on one side of a country road to agriculture on the other, the land cover polygon boundary way would lie under the road way (although nodes are not shared). If there is grass both sides of the road, with agriculture beyond, the polygon boundary way would be offset from the road. (In retrospect, I could have made ‘transport corridor’ polygons for roads, as for railways (landuse=railway), but there is no tag that I know of for this. For rural roads, I suppose natural = grassland is the most appropriate tag for roadside verges, embankments etc., where these are wide enough.) Land cover is very generalised in OSM, landuse = residential - what does that actually mean? It is a zonation category, rather than a description of what is there, the gardens, trees, buildings too small to map etc. But it is mixed in with natural = x, which I suppose is a meant to reflect an actual vegetation type.

Login to leave a comment