(apologies for this diversion - it’s not specific to “landcover” per se, but)
Essentially, you need to create two new geometric objects. One is for the whole area; one is a doughnut shape.
One way to do that is like this (that’s on the dev server). I’ve created a multipolygon for the “here are the trees” part and used a separate way for the “here is the forest area” part - but of course the outer for the multipolygon and the way for the “forest area” share the same nodes.
An alternative might be to have the outer way as a member of two multipolygons - one the “here be trees” part (with an inner) and one for the “forest area” (with no inner). Both will result in geometrically correct results, but people will argue about which is easier to maintain (FWIW I prefer the former, with shared nodes)
Well, 2 ways sharing the same nodes 100% is kind of Mr Ed. Hello wood… I’m full of it, trees that is.
For sure it has to be practical and workable and not some higher art of wizardry… if you 're on board and get me you’re OK, else better leave OSM to the pros.
I don’t think I will trace a forest twice. Forest has implicit landcover, so only the enclosed areas with different landcover need to be indicated. They should not be cut-outs in the explicit landuse, but they should be cut-outs in the (implicit) landcover.
I still don’t know if that’s feasible, for a renderer.
I said “you need to create two new geometric objects” because there are two geometric objects here - a circle and a doughnut. However, the geometric objects in whatever representation a data consumer uses don’t map one to one to OSM objects. Software such as osm2pgsql converts in this example 3 OSM objects (a relation and two ways - plus lots of nodes) into one geometric object - a multipolygon for the “here are some trees” thing.
Where two geometric objects have exactly the same boundary (as in this example) it absolutely makes sense for them (and the OSM objects that make up the geometric objects) to share OSM nodes for that boundary.
Generally speaking, no it isn’t; at least not 100% reliably.
Renderers might be able to say “always render things with a tag of A over the top of things called B” - that’s how (to take one example) OSM Carto always displays building=yes over the top of place=island. Another option is to say “always display smaller things over larger things” - in some circumstances OSM Carto does that too, and sometimes expiicit layer or level tags might be processed to hint as to what should appear on top of what else.
However, there are always exceptions. You might think “a pond should always be drawn on top of a forest, with no trees in it”, but trees growing in water absolutely exist, and OSM needs to handle that case. Some few trees growing in an area that is mostly grass is of course very common as well.
This means that “the area where there are trees” and “the area that we refer to as the forest” are two different things, and we can’t rely on implicit assumptions. The proposal doesn’t really cover this at all.
(I apologize in advance for longish post, but I’ll try to summarize and format for easier reading).
I’d hazard to guess that many people who are apposed to the proposal do not say “thanks for addressing the problems” because:
they don’t think there is a (significant) problem in the first place
even if they think that some small part of proposal might make sense, the all the other things (i.e. mass-deprecation of massively used tags) are making the situation so mindbogglingly worse that thanking people for it is the furthest thing on their minds (if you’ll excuse the parable to drive the point: one does not feel compelled to thank the mass-murderer of your whole family because they’ve brought flowers to the funeral).
they feel that must follow the situation lest the lack of active opposition is seen as “implicit approval” thus leading to terrible outcome] of such proposal actually being accepted (“The price of liberty is eternal vigilance”, “The only thing necessary for the triumph of evil is that good men should do nothing” and all that - such things have happened in the past in OSM too!) - thus they feel quite annoyed that they have to waste their time.
Some suggestions:
about the “but the new tags would be looking cleaner”leitmotif of the proposal: While I absolutely agree that is very fine and important idea when creating the new tags, it is completely reversed situation for existing tags in massive use and is horrible idea there. See Due diligence section of proposal process, and especially Everything is more complicated than expected. Please do not shrug this away, but give it serious consideration. To paraphrase Carl Sagan : “huge deprecations require huge improvements that the proposal would bring”, and the improvements offered are tiny, not huge. See this post in particular for details of problems with such proposals and why deprecations are a big deal.
wiki.osm.org is not Wikipedia. Tags are not natural English. Often they are partly based on British English, but the meanings are often subtly or not so subtly different, or even completely dazzling to professor of English. And this is OK. Let me repeat: That is OK. There is no need to fix that. It is not broken. Traffic signals are not Highways. Yet we use highway=traffic_signals, and that is OK and does not need fixing. Nor do we sell slaves specialized in cutting hair at shop=hairdresser. Etc. Trying to “fix” them to more appropriately resemble English language will bring huge amounts of pain for absolutely tiny amount of benefits. Please don’t do that.
one of the advantages being promoted is that it will make it easier for new (and advanced users). That is almost (but not completely) totally wrong. Basically all new users (and big percentage of advanced ones) will not use raw tags. Especially new users will use apps like iD or StreetComplete and click on Surface (or quest named What is the surface of this?) and choose Grass. They wouldn’t even know what the raw tags used are, whether it is surface=grass or landuse=grass or surface:wikidata=Q643352. Even advanced users of JOSM and Vespucci will use presets vast majority of the time. IOW, You’re attracting all that wrath of people by deprecating hugely popular raw tags with proposed new tags with same meaning, for almost no benefit at all (certainly no benefit to new users, nor majority of advanced users).
adding a new way to tag things won’t automagically make the old way go away (even with deprecations). To the contrary, it will lead to both new and old ways being used, thus actually increasing complexity and making the mapping harder to use, which is contrary to the stated intention if I understand it correctly. Obligatory xkcd: Standards
Here is what I would suggest as a way forward (since you asked). Please heed this paragraph seriously, it is the most important - instead of trying to push this lump sum mix of deprecations (which many people are against) and potentially useful usecases: scan this discussion for messages of people who are opposed to the proposal, and see what they (grudgingly) accept might be somewhat useful in some cases, as well as what they omit from their objections. Those are the things that might reach the community consensus. Trim OUT of proposal everything that is not on that non-objectioned list, and keep it focused only on new tags which would allow one to tag something which has so far been IMPOSSIBLE to tag. That way, you’ll get a lot of buy-in. To quote Antoine de Saint-Exupéry: “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away” - heed that advice, and you can get it good.
If that passes, later you can choose (or not) to attempt another proposal for more controversial things (safe in knowing that even if those controversial things do not gain community approval, at least the most useful part of the proposal would’ve been already accepted, instead of expected result that after all that time and effort the people are forced to reject even good part of the idea because it is mixed with all the bad stuff).
(general) regarding too heated discussion: someone could make a thread (and link it here) to change proposal process so that negative pre-votes are possible (i.e. leaving vote before voting period starts. It can always be changed if the updated proposal changes people mind, up until the end of the voting period).
Especially in such prolonged proposals like this one, it is very taxing for vigilant watchers to follow and worry that if they take the offline vacation such proposal might pass (especially as only tiny minority of OSM mappers ever participates in wiki proposal voting). Leaving no votes before the proposal is finished would allow people to vote no in advance, unsubscribe from such threads, and stop wasting their time, thus reducing such negative outbursts of people who’ve just been fed up more then enough. It would also have additional benefit of showing if a proposal is bad idea, so proponents might decide to not waste more of their time on it.
While I do not condone harsher voices that might’ve been used in the discussion, I can understand why people can feel such prolonged “beating of a dead horse” as kind of passive-agressive behaviour (“winning” by tiring out “opponents” until they can’t afford to waste any more time and give up. That is not“getting community consensus”). It might benefit the proposers to put themselves in other side shoes (as I try to put myself in proposer shoes, and would recommend other to do too). Not everyone has infinite amount of time to waste on such minutia.
My understanding is that for trees growing in water, and for grassy wetlands and the like, we have a separate natural= value, and that sparse trees on grass are mapped as natural=tree. If it is mostly trees, it counts as wood or forest, which includes the grass, scrubs, herbs, soil or undergrowth beneath the trees.
No need to apologize, thanks for basically summarizing some of the views of opposers. Based on this and the discussion in the past days (and before ofcourse), Tjuro and I are going to have a critical look at the proposal taking into consideration your advice on how to move forward.
I agree with your last sentence and it was never our intention to do this but I understand given the scale of the proposal it might feel so to people.
In my area there is a mapper who is very prolific. The edits are almost all based on aerials. He got banned for life for abusing semantic tags for embellishment and now is using throw-away accounts for his edits. I’d prefer him to use the landcover key, after all it seems to be especially aimed at aerial mappers with no or little local knowledge. But that won’t work out for two reasons:
landcover does not render
landcover and landuse/natural compete
Reason 1 is due to the obvious yet never (in public, only PMs) stated (instead supplanted ridiculous arguments that went unbelievable to the community) intent of the very person (He is using OSM like a painting app and prefers the green brush (e.g. meadow will always win over farmland.))
Reason 2 is a bit more difficult. OSM has no layers. Making landcover and landuse/natural compete will bring lots of problems. I expect @Cartographer10 to sort that out.
To augment reason 2, a significant part of the problem is that OSM has never defined semantics of overlapping areas, and the “right” answer depends on the combination of tags. While having a building within landuse=residential is completely fine and universally understood, and having a natural=water within leisure=park indicates a pond within a public park, things get murkier from there: should we exclude a landuse=orchard from the surrouding landuse=farmland? What about landuse=meadow within natural=wood? If the surrounding area is named, does the name extend to inner areas? etc. And those are just simple use cases.
Personally, I consider “embedded” areas (inner being a true subset of the outer) as generally fine if a bit unclear and/or lazy mapping, but intersecting areas are generally mapping errors that should be flagged by QA tools.
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.
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.
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?
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.
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?
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.
