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.
Mappers and consumers working together. Yeah. That happens. At least in OSM it does.
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?
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.
Hello everybody, maybe you will allow me to join the discussion. 
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
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?
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
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
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
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.
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.
@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?
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
maybe ultimately people do not want to make tags disappear 
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.
â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.
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!
So would you look with good intentions and support a proposal for a versioning system for OSM?
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
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?
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