Osmose drives me mad

If you ever have mapped wood or forest which spans a river or any ‘significant’ road you’re in for a new surprise as now you get intersection warnings.with these ‘major’ highways.

Oh well, some mother do make them, me ignore button is again in overdrive.


Sigh and someone will tell me soon that I got it all wrong, all these 985 mapping days

Osmose is right, though. For the first example, the landuse should not be connected with the highway. In the second example, the landuse should be split and not cross the road.


Sorry bro, looks like that … I believe a majority of mappers support separation of landuse at least at major roads in meantime and well, the area of a busy road is not part of a forest (whereas the area of a forest track would be). Things are changing from time to time … :wink:

1 Like

It depends when this mapping days were :innocent:.
15 years ago on available imagery like Landsat even major streets were not visible in woods. So it was common practice to draw them through huge natural/landuse areas.

1 Like

But can you see the road through the trees?

& what it looks like from below the trees!:


what’s wrong with highway going through a landuse? Do people separate every residential road from the landuse residential? Don’t think so - it would be a mess of the highest order.

Not sharing a node, now that’s I agree wholeheartedly.

1 Like

I’m a little torn on this one. I also often divide on larger roads to separate huge landuse carpets and overlapping, stacked landuses into reasonable, manageable units where appropriate. However, the “warnings” here go way too far in my opinion, @Fizzie41’s example is very fitting here - there are not two independent forests next to the road, but a road going through the forest


That depends on the type of landuse actually. Something that’s more or less “structural”, like residential, industrial, or commercial, I don’t separate on the road, if the road goes “through” it. But a forest, a meadow, an orchard … if it’s not a track, then I’d definitely separate them. And for tracks it would depend on the grade for me and how it’s actually incorporated.

Like so many things osmose reports this is more a “maybe you should consider modelling this different” than an actual error. My recommendation is to go and get a glass/mug of your fav beverage, relax and ignore it.

OT rant: my current fav osmose misreport are missing brackets around conditions in conditionals. These are only required in very narrow circumstances (when the condition contains a complex opening hours expression), but for no good reason osmose nags about them regardless of if they are needed or not.


I do. And I know I’m not the only one.

Unfortunately not everyone is so relaxed and some see every message from a QA tool as an error that needs to be fixed. Not uncommonly to then cause more damage, or only hide the real problems by satisfying the tools


Can one of the above commenting gentiles provide me a OSM wiki link, preferably the one in Oxford English, with this ‘don’t you dare’ prescriptive text?


As for the warnings. Perusing the Italian landscape there’s tens of thousand if not hundreds of thousands of these issues yellow pinned. Maybe it’s just once per street like there’s only 1 warning for multiple buildings on agricultural land plot.

So far,
a) only tertiary roads and up get fingerpointed with the issue, residential not, unclassified anything below that not (yet).
b) landcover over tunnels (cant see why, there must be some peculiarity)
c) landcover below bridges (cant see why, there must be some peculiarity)
d) river’s, and maybe streams, but the 2 years or so I’ve been splitting landcover left/right bank to allow later inserting of the riverbed cover, shingles zones, wetland, flood zones etc.

Many mappers through yesterday continue to map LU and using roads to trace the outlines.
Found massive farmland acreages through which connecting/through roads pass that are flagged.

NOT seen multipolygons that go across, but maybe have not looked close enough. It’s similar to buildings on simple polygons agri lands being flagged but not when the agri land is an MP (could have been fixed but not seen any warning pins appear for that in my zone.)

Disturbing is I’m living in a hill/mountain area where few roads are straight. My favourite cycle way, a tertiary/secondary is 12km up, constantly twisting and turning through forest (though to me it’s wood). A mapping nightmare to split them tracing along the road edges, and not for the renderer, creating ugly whitespace on the maps.

For power line there’s the cutline feature which nicely maps a grassy beam where the powerlines/pipelines/fire breaks etc go without having to resort to area splitting.

Anyway, I’ve inserted a matchstick to hold the ignore button down for this one. I’ll consider applying the method on present and future map additions.

Do people separate every residential road from the landuse residential?

I’m doing it, and there are many others as well

Don’t think so - it would be a mess of the highest order.

why would it? Not at all, it results in very clean mapping, precise as it conveys the borders between private property and public streets, easy to refine and not requiring relations if some land inside the block is used for a different purpose and has to be left out.

I can see that it is more onerous, and that in some context the mappers deem it not worth the effort, but ultimately we are moving there and it is beneficial (more information, easier to overlook and modify, less error prone, locally verifiable and not requiring knowledge of a huge area but just the individual spot)


There can’t be. OSM Wiki is not prescriptive, it just tells the user what the standard mapping method are, but they can be changed (but they must be discussed). As you can see the landuse=residential wiki page says that «It is acceptable to map landuse to stop at the boundary of roads». This because a road is not a residential landuse, but it’s just a road.

I think this is not the right behaviour for a collaborative project.

As @SimonPoole says this actually defeats the purpose of much landuse mapping.

What you appear to be mapping is private residential property. It would be as convenient, and more useful, to map the dedicated public highway areas. I know people like how it looks, but it is extremely difficult to edit such data (as I have found over the weekend). Landuse in OSM is used for a whole range of purposes both inside and outside the project. This kind of detailed splitting of landuse often negates the value of such polygons.

Historically almost all landuse maps have used a minimum feature size, usually of a few hectares (25 has for Corine). They do so for several reasons, but mainly because most use cases are not based on micromapping details, and such detail would complicate computational models already of a high degree of complexity.

The EEA’s Urban Atlas which used a smaller feature size is the only one I can think of which had did split highway areas from residential areas, and a major use case was modelling surface run-off (for obvious reasons as the road surface is sealed). Long ago I showed that using simple rules of thumb about highway width this data could be reproduced from OSM with a high degree of correspondence.

The big issue is micromapping residential landuse makes it much harder to re-create larger landuse polygons, whereas the more detailed landuse can be created from larger polygons with some simple transformations.

1 Like

Because at least landuse=residential and the similar other values (industrial, retail etc) were intended to add generalized large areas used for residential (industrial, retail, …) purposes including all expected objects. Using it in a mico-mapping fashion (instead of using other area objects for that) essential removes all meaning from it, and begs the question why are you using it at all if you don’t want to use it for its intended purpose.


Some of the points debated in this thread have been listed as “open questions” on the wiki for many years. The issue of connecting landuse areas to roadways is very polarizing, especially because it’s so awkward to select overlapping ways in JOSM (even if they aren’t connected) and it’s only slightly less awkward in iD. You’ll hear many justifications for one approach or another, but editor ergonomics have clearly hardened feelings. I don’t remember there being as much controversy over it a decade ago, when Potlatch was in vogue, with its superior behavior around selecting and following ways, and JOSM users favored a plugin that turned roadways into members of landuse multipolygon relations. :scream:

Personally, I’ve gone through quite a conversion over the years. Originally, I avoided connecting anything to landuse areas, until another mapper pointed me to something on the wiki endorsing landuse–roadway connections. That became the standard practice among the two or three of us who mapped in Ohio, more or less alone for several years. I reasoned that the highway way is an abstraction: though we align it to the centerline, it still represents the whole roadway, the edges of which do connect to areas classified by landuse.

However, in recent years, as the local community has grown, newer mappers became very frustrated with the increasingly tangled connections between landuse areas and roadways. One year, the local authorities put many new roundabouts, which required delicate surgery on the existing roadways. It was too much – the community reached a clear consensus to stop attaching the landuse areas to roadways. The map is still a messy mix of styles in this area, but over time it’ll transition to the less connected style.

This is not a pure victory for the never-connect-landuse camp. Boundaries still sometimes connect to roadways and landuse areas when they represent things that are defined in terms of each other in the real world. (I assume this is only relevant in some regions but not others.) And now that we aren’t consistently extending landuse areas to the centerline, we have to decide where the areas should end: at the fence? At the sidewalk? At the curb? Some sloppy mix of the three?

But even back when I was attaching landuse areas to roadways, I never attached natural=wood areas to roadways. In fact, I spent a lot of time ungluing them from roadways. natural=wood and other landcover tags represent something physical, rather than something abstract indicating the land’s predominant usage. There has to be a good reason for mapping a physical object at a distance from its true location or distorting its size and shape.

At the same time, it makes no sense to me that natural=wood would represent the tree trunks but must not represent the branches and leaves that happen to extend over the roadway. As shown above, tree cover can certainly envelop the roadway, to the point of it being effectively covered=yes.


Osmose is a tool to find issues in OSM data. It’s not always right and you can ignore or mark false positives. See the Osmose wiki or FAQ for more info.

Best regards, Hanna from CodeIT

1 Like

(replying to the thread title, not any of the posts)

If “Osmose drives you mad” why not stop using Osmose and use something else instead?


@Andy, I’ve just removed all bookmarks to the IMO abomination. Noticeable the Neis report has stopped updating the level 1/2/3 links… I’m always zero there. Could be technical, could be a signal too.

At any rate

Separation from roads

It is acceptable to map landuse to stop at the boundary of roads, and it is also acceptable for landuse to overlap road area on roads where the right of way is not significant enough to warrant a break in the landuse area.
… It is better to have the landuse boundary stop at the edge of the road, the edge of right of way, or overlap the road completely.

Ha, the bolded speaks to me.

The data consumers meanwhile ignore forests crossing roads of any significance, high or low long as not any tree is ‘mapped too close’ as it sometimes gets flagged. Oh, and there are motorway areas that intersect with motorways, but bridge and tunnel areas don’t, yet.

My mug of fav bev is in the left hand, the right hand used to push the answer button with the mouse.