What I meant with “compete”: Some landuses and naturals are to be deprecated for landcover – Overlapping semantics? Currently, nobody cares about landcover, it is hard enough to choose from landuse/natural. With a third prime-mover it will become even more complicated to know, what is a whole in one but not in the other, what is shared with one, but not with the other.
I have to correct myself, I have indeed seen that, on location here: Jamaica Beach in Sirmione lake Garda - OpenStreetMap - I’d say, surface=rock is missing in data there.
So for patches of moss or ferns in a forest, mappers may use a landcover=* area, is that the idea? Or do the trees have to be sufficiently sparse before we can go from landcover=trees to landcover=moss?
I would realy favor if landuse=* would describe the use of the land and landcover=* the coverage of the land. The current situation with e.g. a landuse=grass for an area covered with grass is a mess. I realy appreciate that you @Tjuro and @Cartographer10 put so much effort into this proposal and that your answers here stay objective.
There where some objections saying that this proposal would not improve anything. I do not agree with that. The meaning of lanuse=*/natural=*/landcover=* is not realy clear. As of now, landuse=forest and natural=wood have in theory different meanings. But as there is no tagging scheme for an area covered with trees of an unknown use/unknown origin, these tags are sometimes missused. Implementing the already in use landcover=trees for these areas would fill this gap.
And I know that these tags are used a lot. Changing them is nothing that can just happen over night. The wiki page of landcover=* suggests to double tag landuse=forest and natural=wood with landcover=trees for now. I like that. That way we can implement the landcover=* tag without destroying the rendering in established renderers. As soon as landcover=trees gets used more, a request for rendering it in carto is much more likely to have success.
The current situation is chaos that grew over time. “That is how we have always done it” is not an argument against change. The fact that the current situation is not systematic is an argument for change.
5 Likes
The argument against change is that data consumers are using the current tagging, today, successfully. So if you wish for every data consumer to change, you need a really compelling argument that’s stronger than simply that you would like it to change or that it would be better organized or that you would find the new scheme less confusing. OSM isn’t just used by hobby projects, it’s used by real companies that pay real programmers and data schema changes on features with millions of usages cost real time and real money.
1 Like
That’s about as likely as Shergar winning the 12:15 at Newbury 
People have tried to do this, and haven’t succeeded, mostly because the weren’t able to persuade enough people that it made any sense. There have been successful tag changes in the past - highway=ford to ford=yes is one that springs to mind. That did make sense because there was an obvious problem previously - if a way was tagged highway=ford how did you know where it was primary, secondary, whatever?
For those of you that aren’t British, please allow me to translate from British into English:
I consider this a false conclusion. Adding new capabilities isn’t the only way to improve a data model. Making it easier to understand, to teach, or to work with is also an improvement even if no extra information can be recorded as a result of the change.
I’m unsure whether this proposal really meets the goal of producing an unambiguously cleaner model, so this is more of a general thought. But if a change would indeed make the OSM data model more accessible, I believe that the one-time cost of old-timers having to get used to a change would be worth it. Arguing otherwise amounts to treating OSM as a legacy project – which is self-fulfilling, because allowing idiosyncrasies and technical debt to pile up will make OSM increasingly less attractive.
5 Likes
OSM is a legacy project. More than that - any project which has actual users is to some extent a legacy project. This doesn’t mean “no data model can ever change”, just that there has to be a better reason for it than “the words we use for tags don’t 100% correspond to the normal English meanings of those words”.
I gave an example of a change that was both sensible and successful above. To give an example of another change that would be beneficial - it’d be great if OSM objects were inherently either lines or polygons. Currently with closed ways you have to either rely on an area=yes tag, guess (style dependent) or do a bunch of special casing of combinations.
Something the “landcover as well as landuse” fans forget is that often one area has many different uses and many different “covers” too - something might be used for grazing sheep, it might also be used as a floodwater overflow, and as well as the sheep there might be apple trees too?
Bold highlights are mine.
I think you’re glossing over a fundamental problem we have in OSM is that there is no facility for data model or data schema change. We just simply change things (or not) and leave it to data consumers to just deal with it.
If we are serious about having the ability to change the data model/schema over time, then the one feature that would make this able to happen without friction is some kind of versioning and backwards compatibility layer.
As a data consumer, I have no way to say “I’m consuming OSM version X” and expect any reasonable degree of stability. And there’s no way for OSM to say "We’re making version X+1, and in that version these tagging schemes will be replaced with those tagging scheme.
So now that I’ve described the problem, we just need to sit back and wait for @NorthCrab to solve it for us.
Please pass the salty snacks.
In my ~15 years of this project, I’ve seen many “version X has simply become version Y” instances, they are nearly too large to enumerate. Many (like wood / forest, a flavor of landcover…) still “rage on.” My reaction has been to be an “old-timer” and “get used to changes.” I do not complain, and up until now, have said very little to nothing about this — I simply absorb a fair amount of re-adjustment to new schemas. In short, this is what is expected of OSM, not only as a contributor to its data (literally changing how we tag compared to past taggings) but to “suck it up” when such changes occur. I attribute this to the plastic nature of our map, though at some point, things can become so “goopy and liquid” that the map might become unusable with many ambiguities of its haphazard development.
Without getting too lost in the weeds, many times I’d say these changes result in “the new is better than the old.” There truly is a reality that we sometimes don’t exactly get things right the first time, and a 1.0 (schema, way of doing things) becoming a 1.1 (or 2.0) with significant improvements is welcome and refreshing. Yet, other times, there are seemingly intractable problems, often rooted in deeply semantic linguistic and cultural differences in both the concepts we attempt to map and the tags we choose to do so. (Wood / forest, landcover / landuse, the underlying meaning of what is and what could be, are perhaps foremost example of these). A few years ago, boundary=forest_compartment and related tags (which took three ballots to succeed, IIRC) was a small victory. Yet, we still have more work to do.
There has been friction. I suspect there will continue to be friction, though I hope we can keep that minimized to the extent it induces rancor instead of progress. We might develop some sort of more-formal versioning approach, I think this shows a lot of promise, as it can be both a technical and a social solution to what often freezes OSM into brittle, sometimes outright broken data models and process which seems difficult or intractable to improve.
“One-off” proposals (like this one) are simply bandages on a longer-term wound that doesn’t seem to be healing very well in OSM — the chaotic nature of our anarchic process. We would hugely benefit from a worldwide, project-wide methodology to make fundamental changes to rather ambiguous tagging that has evolved, and skidded into fairly ugly ambiguity in some cases. A “1A” first step would be to identify (major) problems (like landcover), a “1B” would be suggested methodologies on how we go about fixing these. It’s possible we leverage existing methodologies (Proposals / voting, wiki tuning, mechanical edits…), it’s possible we wholesale re-invent, it’s possible we develop some new versioning scheme, it’s possible we find a blend that works. But this “technical debt” continues to pile up, and longer-term, it hurts OSM both presently and into our future.
I don’t have ready-made solutions to offer, but I do roll up my sleeves in earnest as I attempt to identify that this is truly difficult (social, technical) work, and it needs doing. I don’t want to rush this, I would much rather we “get it right.” Landcover is only the tip of this iceberg. Thank you for reading.
13 Likes
Thank you so much for your well thought out words! 
How would one go about this? Where should this be brought into discussion? I feel like this is a very important point, and we should all(!) talk about the way we want to do things.
And even if the decision would be to stay decentralised and “do your thing”, then we still talk about the problems of this approach and possible remedies.
1 Like
I don’t know; as I say, I don’t have anything ready-made. I am very encouraged by your response and that my post received as many thumbs-up as it did — more than any other post I’ve ever made here.
It may be appropriate for a new thread to emerge that begins to address these issues. This is a very long-term goal, and one which will take a lot of people, a lot of effort, a lot of listening and a lot of give-and-take. To start with, OSM already has some quite well established processes (like our Proposal and voting process, wiki development, et cetera). Things like a formal versioning process would need to be well discussed, well understood, widely agreed upon and to be well documented. I have been an ambitious and productive OSM contributor, but that’s a great deal of work and to spearhead such an endeavor takes vast dedication and indeed, leadership. I’m not sure I’m correct for that role (right now).
Again, if others want to pursue this, I think a new topic (thread) here in our Discourse / community forum is a good direction to take it in as a next step. I remain listening, both here and whereever this discussion may go, as I do have a great deal of passion to see OSM improve along these lines. But I don’t know how to go about it, except to offer a spirit of helpfulness and future contribution as a listening member and my longer-term perspective in the project. Thank you for your kind response.
1 Like
Apart from being sensible and intelligent, it was a very welcome change from the general tone of this discussion.
Sounds good. On which board should we post it? Would you be willing to do a small write-up? Is there anything to discuss beforehand? I think that the scope should be thought out.
Speaking of others, please, chime in (if you like)!
If I am being overly pushy here, please tell me and I’ll stop. Your text was actually so motivating to me that I want to start with the process; even though it will be a long way and depends heavily on others.
I’ll ask you to continue to show initiative yourself, as I think you’re doing great so far. You are welcome to copy-paste any or all of my post, quoting it, linking it, et cetera. While it is several paragraphs, I tried to make it as concise as possible (though the iceberg is indeed quite large), to provide a possible “jumping-off point,” and it appears that’s what you are proposing to do. I am encouraging you, or anyone else, to do so.
You might start a thread in the General talk Category titled something like “Longer-term suggestions for difficult tag disambiguation, possibly a formal versioning process” and introduce a pointer back to this topic’s posts right here. I am not performing some sort of “hit and run” here, “fleeing the scene,” rather, I am encouraging more support for these ideas to come forth and hopefully flourish. I’ve gotten the ball rolling, it would be good for others to throw some shoulder into this, as I don’t want to be a single point of contact for what is clearly a widely-shared set of ideas that seem to resonate with a good-sized segment of our community. Let’s let this continue to unfold, so far so good.
Sticking to landuse / landcover, in particular the seemingly intractable problem of wood vs. forest, is a good place to start. (1A, 1B, “landcover as a general problem to solve with a worldwide solution…” are components of this — icebergs are big).
I think I understand. I’ll be waiting and letting our conversation stir a bit here before making the new post. As you can imagine, I am not super keen on doing this “alone”. More voices, different voices, critical voices are needed here.
What we need is not rush, it is dedication and commitment. Indeed:
1 Like
It’s not the mappers who bear the cost of tagging changes, it’s data consumers. It’s very easy for mappers - they just update their editor, since most people don’t work with raw tags.
Most tagging changes so far involve tags not used by any data consumers or seldom used ones. Some tagging changes involve data consumers noticing flaws in the model.
With the features involved, virtually every rendered map using OSM data will be changed, many analytic uses, and pretty much every use I can think of except routing will be changed. And by changed, I mean broken in most cases.
The idea that users will change their logic in advance is, put simply, absurd. Of the ones we know about, we have no way of notifying most them, and we don’t even know about most users who will be impacted. The first they will know is when their maps or data analysis or whatever they’re doing breaks. In most cases, this will go to a team that has responsibility for many services, and in some they won’t have touched the maps service it’s just worked for the last five years.
Some of those will look at it and decide to go with a commercial provider under the mistaken assumption that they won’t have their software break because of a data change they weren’t expecting.
I dislike getting involved in tagging disagreements for a number of reasons, one of which is that I am a maintainer or developer of many map rendering styles. However, as a maintainer, I have been trying to adopt the principle that a “style should not adopt practices that would result in making consuming OSM data more difficult for most data consumers”. An example of this would be troll tags.
I cannot see a situation where would support the changes in this proposal in a style I maintain. I might have to reluctantly accept it, such as if a client told me to “fix the broken OSM data”, but I would not endorse it.
We gain no improvements in what we can map. We break almost everyone’s usage of our data. And who would see any gains? The small number of people who look at raw tags would be the only ones seeing the new tag keys and values. Most mappers won’t see any change, except as everything breaks.
8 Likes
You paint an accurate picture of the current state of affairs where we’re unable to make improvements without incurring massive costs for each change. But surely, the conclusion cannot be to stop improving the OSM data model. Even if we can live without changes that only affect people looking at raw tags (which includes data consumers who may consider adopting OSM in the future, and for whom an idiosyncratic and messy data model is a turn-off), all these same costs are incurred by, and therefore deter us from, making changes that do introduce new capabilities.
Therefore, my conclusion is that we need a better process for making changes to the OSM data model. This might very well involve a versioned specification for at least the “core” of the OSM tagging data model, which I expect would make it both more feasible to make changes to the data model and make tracking those changes as a data consumer less onerous. (After all, what’s the current alternative? Watch a few thousand wiki pages and sift out the substantial changes from the formatting tweaks?)
Of course, pulling that off would require the OSM community to demonstrate an uncharacteristically high level of coordination.
7 Likes
For the avoidance of doubt, this proposal is NOT an improvement to the OSM data model (or even much of a change, actually). It’s just an administrative thing that would require “busywork” for no gain by almost all data consumers.
That does make sense…
5 Likes