Overnoding natural=*

Last week close by a region was enhanced to “prepare for hiking the area”. Lots of natural=* got created. Complaints were raised by locals, the mappings being of little or no use for hikers. I did a crude comparison of number of nodes of that area and my home town:

  • 1 km² 55,000 nodes in a remote area for natural=*
  • 1 km² 13,000 nodes for a densely mapped city centre for *=*

That reminds me of why I happen to like the woods, there is so much detail there :slight_smile:

OSM-Carto does a very bad job of doing Generalisation there. The area looks like a bee hive. Is that LOD (Level of Detail) something openstreetmap should strive for? How do hiker’s smart watches deal with that?

Do you know if the added info is correct?

Any serious data consumer will need to filter/simplify/transform raw OSM data before sending it to the user’s device. I’m not sure this is something OSM should try to tackle itself, as each consumer will have different needs.

Having said that, avoiding unnecessary detail definitely benefits mappers and editor programs.

Is the detail in this area reflecting physical reality, or is it “fake” detail that implies more accuracy than there actually is?

2 Likes

Well, as far as I can tell, where the aerial shows dark green, OSM-Carto now shows dark-green, where the aerial shows light green, OSM-Carto now shows light green. Where the aerial shows brownish grey, OSM-Carto now shows grey. At single foot resolution.

I see that as a painting. The grey pencil originally was shingle, only after I objected: this is carstic region; got changed to scree. I very much doubt most of the cliffs. Except for very deep ones, cannot be done from aerial alone, in need of high resolution DTM. And also, I am not aware of cliffs made out of scree.

BTW: When planning pathless hikes not in immediate urge, I look from afar at the locality from different points of view, and I am astounded how much different the impression. But I might be wrong, and some people can learn from orthorectified aerials much more than common people can from local observations.

1 Like

Wanting to “leave no blank spots on the map” is a frequent problem in
OSM and I try to talk obsessive landuse mappers into reducing their
level of detail. The ideal map is not one that mimicks an aerial photo;
maps need to abstract. The person tracing aerial imagery must
distinguish between stuff that’s there for the long term, and stuff that
will likely look different on the next aerial imagery update. Many don’t
even try, and “faithfully” trace the aerial imagery. I’d agree with
using the term “painting” for this, and it should be discouraged.

10 Likes

Can you link affected area?

In general “accuracy” that would require different mapping if aerial world be taken 30 seconds later, with different wind direction and trees swaying a bit differently is pointless.

3 Likes

I agree that it doesn’t make sense to reproduce “feature details” that change with every new aerial imagery or that would look different the next day. But deciding which detail is too much and which is the correct abstraction is not possible unless you define the scale. If we want to offer data for a “general purpose” or “every purpose”, without specifying scale, we should accomodate whatever is relatively stable and is verifiable on the ground. We currently have data “thought” for very different scales, and they can coexist as long as you don’t request uniformity or consistency. The question of detail is multifold, an area can have a detailed border but still not be detailed, e.g. here is a farmland landuse that even has a motorway running across and a whole village inside: https://www.openstreetmap.org/way/1229674463 but has some detailed outline parts. Some areas are very fragmented (in reality, every few meters) while others are covered by huge monocultures for many kilometers, having a lot of fragmentation is not necessarily bad or inappropriate, although it can be overdone, I don’t disagree.

Another example is Corine data imported in 2009 in France, not suitable for the typical OSM scale (the boundaries are not observable “on the ground”) but it looks perfectly fine on medium scale renderings.
random sample, I doubt any human mapper would have drawn a “heath” polygon like the selected one here:

1 Like

This one is just wrong, no matter the scale (common for landuse imports, distinct problem from overnoding).

It seems to have more forest and farmland than heath

4 Likes

Yes, but even if it had more “heath”, its shape doesn’t follow anything recognizable on the ground, landuse as we map it (contrary to Corine) is not about statistics (“at least this is the most occurring landcover for this area according to spectral analysis of the reflections”), but about areas that can be seen (shape, extent). The lines we draw should reflect lines you can actually observe on the ground.

There are serious open-source consumers. Can you point at code of one that simplifies naturals and landuses? This is anything but trivial.

1 Like

Organic Maps and OsmAnd appear to. I just did a quick comparison between raw OSM data and how they display it, and simplified geometry / reduced node count is visible in both.

Since you asked, for Garmin maps (for handhelds and smartwatches), the way I do it is here. That tries to extract sensible tagging from when people have tagged things with multiple tags, and the way that it handles the mapping to Garmin search menus tries to (a) make sense and (b) suppress things that shouldn’t be there,

There’s no attempt to deal with overnoding - that’s just passed down to mkgmap, which seems to do a pretty good job of things (if anything, with the settings I use, things are oversimplified rather than the opposite).

While most consumers will make some attempt at simplification (see e.g. here for discussion re a different OSM stack) it absolutely makes sense to not add overnoded data in the first place. Try talking to them nicely about why that’s a bad idea, and maybe point them at this forum.

2 Likes

Thank you for the fascinating insight on state of the art research. Invitation already been sent. Still pondering, how much Generalization should mappers do, contrary to just map paint Bing aerials, as that a job for cartographers/app developers?

One thing I try and do is “not try and provide more detail than can be backed up by the sources used”. Typically when mapping something new I’ll have a wiggly GPS trace, a vague recollection and a couple of sources of imagery that might not agree with each other. Clearly mapping lots of detail that isn’t backed up by those sources make no sense.

At the other end of the scale “crayoning-in” large scale landuse in a way that clearly does not match underlying features is surely wrong. For example, if someone’s adding a natural=heath (for some reason it is often a natural=heath) and they can’t be bothered to align it with existing walls and fences then they’re Doing It Wrong.

Here are four mapping detail levels for the same patch of forest and my thoughts on each.


Room for improvement, but also good enough especially as a first pass.


A few more nodes to more accurately match the forest edge. Usually, the level of detail I aim for.


Smoothing out the curves with more nodes. Also totally fine.


Tracing the exact shape of the tree crowns as seen in this specific aerial imagery, including a clear lean to the left. This is too much detail and not a true representation of the ground level forest shape anyway.


Switching to a leaf off imagery layer shows that this polygon is quite inaccurate as well using far more nodes than necessary.

12 Likes

I don’t disagree with you, but what do you call the “edge” of the forest? The line of the crowns or the tree trunks?

Definitely agree there! Personally, I would probably go image 2 rather than 3.

1 Like

IMO, trunks if the branches are high, or where the low branches end if they can’t be walked under. Either way the main thing is that attempting to trace the exact shape of each tree crown along the edge is far too much detail.

7 Likes

I now looked up an area that WAS overnoded and still is perhaps overdetailed still. My hiking app does not lag there and indeed in smaller zoom levels it does some quite astonishing generalization (not just pure simplification – small patches of wood are concatenated):

Screenshot_far - Screenshot_close

The renderer is (based on) V™ (Vector Tile Map).

1 Like