[RFC] Feature Proposal - landcover proposal V2

General talk Tagging general discussion
,
163

When I wrote, that the proponents had to sort that out, I thought, the proposal was meant to make things easier, for mappers, for consumers; but maybe I mistook something.

164

Mappers and consumers working together. Yeah. That happens. At least in OSM it does.

165

In light of @ZeLonewolf writings, who liked @dieterdreist 's post, I was wondering if perhaps dd was really meaning what I grasped from first reading: Consumers will have to face the music, but what the heck should we mappers care?

166

I think Asa it’s important to think about why we map. Is it to put objects into a database only? To admire our work in a map editor? Not for me.

I map (and write map-related software) because free and open geospatial data is a good thing for humanity. Because, once we have that data, it allows people to make applications and services that make people’s lives better. So I think we we follow this to its logical conclusion, the question we should all be grappling with is how to best facilitate making that happen.

We agonize over designing tagging schemes because they directly impact the ability of data consumers to use OSM data to make those applications and services useful. We agonize over deprecation decisions because it directly impacts data consumers who are already using OSM data. Changing tagging of data that applications and services are using makes working software stop working.

The users of those applications and services don’t have any awareness of a tagging decision made on an obscure web forum that made something slightly easier to organize in the mind of a volunteer mapper. They just know that their app stopped working, perhaps even worse, because of that open map data.

Mappers are the producers, and software developers and end users are the consumer. So you have to enable both the mappers to produce data and the software people to use it.

Right now, mappers can indicate (via several schemes) a place where there are trees. If we break that understanding, we break working software, with the end result being that mappers are still able to map trees.

167

Hello everybody, maybe you will allow me to join the discussion. :slight_smile:

I tried for a long time to understand what I don’t like about this proposal and what exactly to criticize, because I have been thinking about introducing landuse=* tags for quite a long time myself.

The main drawback of this proposal is that unfortunately it is self-contradictory, and does not solve the declared problems. Also it neither makes the key=tag system clearer, nor makes life of OSM data user any easier.

The “proposal” section says that the goal is

to create a orthogonal tagging scheme that separates the tagging of functional and physical objects

Ok, it would be very nice if only it were possible. Unfortunately, this is not possible, because often the use determines the physical properties of an area, and vice versa, physical properties define possible land uses (that is the reason why natural, landuse (and surface) system sometimes seems chaotic)

So in “landcover implications” section we see:

Some current tags imply a landcover and therefore, landcover does not need to be added to these tags.

It’s indeed so, some tags imply landcover and OK, why bother to add additional tags to explicitly specify what is implied? However, it kills the idea of ‘‘orthogonality’’ completely.

For example, I would like to create a map of earth landcovers/vegetation. Can I do it now? Mostly yes. (There are a lot of white areas around the world, but Europe is mapped quite good).

How many keys do I need to process for that now? Mostly two keys are need: natural and landuse. OK, lets imagine that the proposal is approved, transitional period is over and every object is retagged. Will it be be possible to obtain landcover data from just single key? No! It will be necessary to process tags from three keys, natural, landuse, and, additionally, from the newly introduced landcover! So it’s complication, not simplification (and classical +1 standard situation) .

Maybe a landcover proposal must be much more radical to bring value to the users. In my opinion, the landcover system should cover 90% of land surface, ideally all the land. Not just objects that do not imply landcover from other tags. And it’s obviously not possible just with 7 new landcover values.

I do not (yet?) have a readymade solution either. Currently I can just share the list of landcovers which I use in my humble project. They are based on existing natural/landuse tags and their statistics. Maybe it could bring up some thoughts.

2 Likes
168

Thank You, at first I really thought with your like you’d support what I grasped from first reading, as stated above. It was only your latter contribution that allowed me a second reading: That consumers will have to face the burden, not drafters. And with not a lot to gain for mappers, BTW, IMO too. Maybe @dieterdreist can clarify on this?

169

Deprecating existing tags is difficult, even painful for existing OSM stack (software) developers and consumers (as Brian correctly characterizes): it breaks existing toolchains, let’s agree that’s undesirable. For producers / mappers (of data in our stack), yes, some idealized fantasy perfection structure of tagging (or subsets of these one Proposal at a time) chugs along (slowly) but is presently mired in “multiple ways we do / say things.” Developing a “perfect” or “idealized” syntax (as a mature project) is both long-term (we could
) and quite difficult, technically and socially. This sort of improvement is some of the hardest work OSM might cut out for ourselves, we shouldn’t kid ourselves. Deprecation is an uphill climb.

So long as existing software and consumers “consume” our software, changes to tagging, especially deprecations and wholesale moderate / significant changes to wide swaths of our planet’s surface in OSM are being discussed will be socially and technically (linguistically, structurally, in the sense of data science
) difficult. It does, they do, they are.

Concomitantly, OSM copes with multiple ways to do things. That is OSM.

3 Likes
170

I don’t think it’s to be written in stone. Data consumers get data for free, they also have to adapt and use data responsibly. What about a major map provider rendering a map with erroneous interpretation of the tags? That would give OSM a bad look.
Also, breaking old and unmaintained software is not necessarily and always a bad thing.

1 Like
171

Would it be worth thinking about the question, what’s a specific thing someone wants to do with OSM data that they can’t do right now?

If you want to find “areas of land covered with trees” you could treat all areas tagged natural=wood, landuse=forest and landcover=trees interchangeably. You could also exclude areas below a minimum size to catch small groups of trees that have been “painted” using these tags.

If you want to find all the land commercially managed for timber production and landuse=forest doesn’t work because of how often it has been used to just mean covered with trees, then may I suggest produce=timber? Though many commercial tree plantations do not have the tag, at least you’ll know that those areas that have been tagged with it are used for producing timber. More areas deserve the tag, so we should probably go and map some more.

Do we have a tag that is similarly precise (if underused) and means old-growth forest?

The advantage of introducing and promoting new, more precise tags would be that it doesn’t require any tag deprecations.

3 Likes
172

Not found in TI, but certainly could live with a boreal=yes or *=boreal qualifier for old wood, not man planted. The alignment of trees in ‘reforestation’ does give it away.

173

There is a distinction between “virgin forest” (never disturbed by timbering activity) and “old growth forest” (trees were cut, though long, long ago). Wikipedia says “Virgin or first-growth forests are old-growth forests that have never been logged.” There are subtle aspects to this where the words chosen are important (though, many and sometimes blurry). As this (primary forest) is one-third (34 percent) of the world’s forests, let’s be careful to get this (and similar concepts, related tagging
) as correct and agreed upon (clearly) as possible. Yes, this can be difficult, especially the agreement part.

I encounter “old-growth forests”, they are around me, I hike in them, I map them natural=wood. There are additional tags on the “forest” (wooded areas) around here (like leaftype=*), too. Some land around here are timberland (landuse=forest), some are “treed farmland” (there is such a thing, farmland doesn’t necessarily mean “row crops”), some areas are simply “covered by trees” and might get natural=wood without that being primeval (but
second-growth and a substantially-treed landscape of “big trees”? Yes). Mixed in are natural=scrub, scree, bare_rock and much else.

Earth has billions (OK, 1.1-something billion is still billions) of hectares of old growth forest, that’s pretty huge. Let’s develop further tagging changes to this critical planetary resource both carefully and widely.

174

@stevea,@ZeLonewolf and others members, I believe we agree and have already reached the same consensus. The current proposal or similar ones that involve not only additions, but changes to keys with massive use and deprecation of many others, is currently unfeasible due to the way OSM works.

We would then have 2 ways to make the most of our time committed to this (I hope I’m not being too simplistic but rather realistic).

We continue with the content of this proposal with regard to covering information that is currently not possible, meaning the addition of values and keys.
This way we cover more information, there are no conflicts with the current way of mapping, and at most it satisfies the request to organize the content.

The other approach, I quote

Based on what I said, do you agree, disagree, or propose something else?

175

Keeping this at a high, almost abstract level of discussion, Proposals which deprecate tags must acknowledge that wholesale replacing existing tagging is difficult, if not impossible. In such an instance of replacement (such as this one), such a Proposal would need to include methods to deprecate in a sane, versioned, phased approach. The real world of software and databases do this, but OSM has both legacy to support and a future to grow into, and we do this in a crowdsourced way with a foundation of consensus, making this difficult at times.

As I have never (or seldom?) seen such deprecations “go easily” in OSM, it seems a more comprehensive system for deprecation, where how we do this is “regularized” in such a way that continuing, ongoing Proposals “fit into” this scheme, may be long overdue. My earlier suggestion along these lines suggests this, I was surprised it found such popularity in this forum.

On the other hand, many of us feel that any Proposal which include key:value pair (tag) deprecations are simply non-starters, doomed to failure. I do not know how to best resolve this. This seems an intractable problem in OSM, though I am optimistic that on a case-by-case basis (how we always have done things), we can continue to address the issues, despite what appears to be wider acknowledgement that we repeat much of the same difficulties again and again as we develop new taggings.

My apologies if this doesn’t seem to address the problems / issues directly. I feel a lack in my (single-handed) abilities to do that and so I continue to appeal to others to help us better shape our direction.

2 Likes
176

maybe ultimately people do not want to make tags disappear :wink:

I have been looking at landuse=farm, and although this tag was already considered ambiguous in 2008 when I started mapping (see e.g. https://wiki.openstreetmap.org/w/index.php?title=Tag:landuse%3Dfarm&oldid=122797 ), it still had a steep growing curve until it was significantly reduced in 2017:
https://taginfo.openstreetmap.org/tags/landuse=farm#chronology

at the moment there are still 4463 of these around (1906 on nodes) and the number doesn’t change a lot any more.

177

“Undesirable” doesn’t mean “impossible” or “never happens” or even “written in stone.” It often means hassles for many, even as it might provide benefits for some.

I do agree that “breaking old and unmaintained software is not necessarily and always a bad thing.” I think most of us might agree to that with some chin-stroking / serious consideration, as the “real world” does this (over time). My point is that as OSM recognizes that as we continue to want to do this, difficult as it is, we might “fit doing so” into a more structured approach to do so, which I loosely referred to as “versioning,” but which would be actually more complex than simply assigning version numbers to phases of deprecations.

I appreciate the real patience, politeness and open-hearted attitudes I have been seeing here; thanks.

178

Thank you for this reminder of what OSM might consider a “partially or mostly-successful large-scale (global) essentially-but-not-full-scale deprecation” (landuse=farm “becomes” landuse=farmland). I remember in 2015-2017 when this began to occur, I do not recall the specific reasons (something about rampant mis-tagging due to misunderstandings largely in Germany) and it did take me a year or so to get used to using the new tag. Yet, we still do have thousands of the old tag, though it was distinctly chosen by our Standard renderer to deprecate its display.

A useful example, let’s continue to discover what we might further learn from it in the instant case!

179

So would you look with good intentions and support a proposal for a versioning system for OSM?

180

Of course. Though I am largely befuddled at where and how to begin. And again, “versioning” is a loose and maybe not effective way to say it. What we’re talking about is “how OSM might deprecate existing tagging to support newer, Approved tagging in a way that OSM’s mapping / producer community and downstream consumers find acceptable.” In a structured way that can work for additional deprecations, should there be more. (We seem to find ourselves realizing, “there will be more”).

This is a big, big task, everybody, let’s not kid ourselves. With the excellent example of farm → farmland, we do have evidence this can be partially / somewhat / even mostly successful. In one case, for particular reasons, and seems like it has something(s) to teach us.

I suddenly feel like someone at the top of a mountain who has kicked over a snowball, and it is now rolling downhill, gathering both mass and speed. I say it a lot (and don’t often follow through), I really want to step aside. This is hard work and while I don’t shy away from it, success here will only come from OSM’s usual voyage of many more of us contributing to these efforts together.

2 Likes
181

I am consistently confused by the notion, that landuse=forest and natural=wood are exclusive of each other. In my area, large swaths of wooded terrain are not economically interesting. They are there to protect infrastructure from natural disasters, avalanches e.g. They are groomed just as well and owners receive subsidiaries to to that, as otherwise they’d be financially ruined. There are also areas with no trees at all, but governed by forestry law, i.e. landuse=forestry.

I think, there is a lot or romance on subject matter. I fear, this is not helpful in getting to a concise, reproducible recipe for mappers.

I remember a proposal that set out to deprecate landuse=forestry. I quite sympathised with it. It only got approved after dropping the deprecation, see https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dforest – Unfortunately it is of no use at all in my area, conditions are not met.

So, if anything, natural=wood is the most close to landcover=trees, the only difference, landcover=trees is not affected by size of the area, perhaps it could even be used to map a single tree as an area?

182

Yep.

I think the key challenge here is defining exactly what it is that you’re trying to solve. This is where the vast majority of tagging proposals fail. In this case, we’ve got at least three tags that are interpreted by data consumers to mean “a place where there are trees”.

So what are some possible problems?

  • Mappers don’t have a way to indicate that there are trees here. This isn’t a problem, because mappers in fact have three ways to tag trees.
  • Data consumers don’t have a way to determine whether there are trees here. This is also not a problem because data consumers can simply consume all three of the tags that mean “there are trees here” and they’ll accomplish their goal.
  • Mappers will fight over which tag to use to indicate that there are trees here. This is a possible problem, but in practice it doesn’t seem to happen. It turns out that mappers don’t really care that much about which tag is used.


and so on. I can’t come up with an exhaustive list of possible problems, but it’s really really important that you have a coherent problem that you can articulate, has real impact, and everyone can understand, before proposing a solution. Here’s a recent example from the United States of a proposed tagging change where I describe what I think the problem is and why the tagging change should be implemented.

The same analysis can be applied to the problem of how do we create backwards-compatibility and versioning for data consumers. Do you understand the problem? Can you define it clearly for everyone? That is step 1. Only once you truly understand the problem can you start thinking about solutions.

4 Likes