[RFC] Feature Proposal - landcover proposal V2

Given the slightly aggressive tone in your message, I only want to say the following.

For the past few months, neither Tjuro or I have promoted discussion on this topic (my last response was on 19 march until somebody else started replying again a few days ago). We are not forcing anybody to respond on this topic. If people respond with questions or discussions points, I am willing to respond to that but I am not forcing people to respond. So don’t accuse us that we are wasting people people their time. Statements like that are very unfriendly, negative and not contributing to a healthy discussion.

We are with all best intentions trying to improve the tagging scheme of OSM and addressing problems that people have said are indeed problems. And given the RFC status, the proposal is not finished so if people have additions or want something to change, feel free to address. But meaningless responds are not helpful.

7 Likes

Sigh.

1 Like

From the proposal, there’s going to be massive editing in the lowlands since meadows of today are tagged a landuse=grass

Still do not find answers, not the least of them being if the data consumers have been proactively made aware of the massive conceptual change. Are the Netherlands going to turn largely white same as with fell in other parts of the world?

Today mapped a new natural=wood area as a simple polygon plus tagged it with landcover=trees as the outline is identical. Inside is a grass covered patch. Tried to make the grass patch ‘inner’ to the landcover=trees without cutting a hole in the ecosystem of natural=wood. Thoroughly failed. Maybe there needs to be 2 ways mapped similar to a horse riding ring which has a railing on the outline and the grass patch landcover=grass made inner to the second wood outline with the ‘key’ of landcover=trees.

Edit: After uploading

image

This sounds quite off-topic and in fact some kind of aggressive to me. The qualitiy of OSM can surely be improved by survey and mapping work but for sure as well by refining poor tagging. This forum is one of the places to discuss about these issues. If you don’t like the topic you don’t need to take part. Just activate the “muted” button and that’s it.

If you want to blame someone of wasting “everyones” time you should probably address @Ferrocarriles_de_México - he was the one to reopen this topic after 5 month by picking against the proposal. @Cartographer10 spent a lot of time by posting reasonable replies, although

Maybe it would have been better to stop replying at some stage, but blaming him to waste other participants time seems very much unfair to me.

9 Likes

The thread is for an ongoing proposal precisely asking for feedback. Like you said:

Fair enough … to avoid any misunderstanding, I did not want to blame you, just reflected to the negative comment of @SomeoneElse.

If an OSM tag is inconsistent and has been used for very different but similar things, then it absolutely makes sense to propose more consistent tagging. This thread elsewhere is a good example.

However, this proposal is not like that. It says:

The following tags should be deprecated and replaced with their landcover=* equivalent:

This is not “refining poor tagging”. The only effect will be that all of the people who use those existing tags as mappers and data consumers (with millions of uses - I’ve added the taginfo links above) will have to change how they work, with literally no benefit, since no extra information will be recorded.

4 Likes

This is your personal opinion. Apparently other users see this in another way. And even if your opinion is the only correct one does not authorize you to tell other participants to stop wasting everyones time by making their point.

I do not want to reopen this discussion another time, but simply summarized I’d say, the way we are tagging the surface of our planet is a mess. It has grown historically by putting more and more values into the big pot with the keys “landuse”, “landcover” and “natural”, even “leisure” and “surface” have their share, overlapping each other here and there and not always being what the key defines. A clear and consistent structure could well improve the whole landuse/landcover tagging scheme but I understand the resistance against a complete restructuring is to strong. No wahalla from my side … if not now, maybe later :wink:.

I think it was meant as general comment that if tagging is not clear, it should be possible to refine tags.

But on another note, stripping away context and placing quotes from the proposal does not help discussion and is onconstructive. We wrote a large section on why we think this re-ordening is justified and why it helps osm in the future.

Instead of saying, take this paragraph and say i dont like this you can also say: thanks for addressing the problems however i dont agree because…

That will actually feed a usefull discussion. It can still get heated and that is fine, but atleast it is constructive and respectfull to the people who put into it trying to improve something, even if the out come is that a proposal does not work.

You can reply with that to anything. It also goes for your comments. It adds nothing to the discussion to note this obvious fact.

3 Likes

People can freely quote your proposal to criticize it. There is nothing wrong with that. You do not get to make rules against that.

You seem to think that we owe you some special consideration just because you put time into something. That is simply not so.

1 Like

That is actually my biggest concern. I see the purpose of this proposal, but forests would then have a big landuse=forest (multi)polygon and a smaller, but 95% overlapping landcover=trees (multi)polygon. We probably all know that overlapping (multi)polygons are not so easy to handle, so I think this could become very difficult, not only, but especially for beginners.
As far as I can see, this aspect is not simplified by the proposal, but mad even more difficult.

1 Like

I completely agree. Maybe it would make sense to define it in a way that it won’t need “cutting” out MPs. Something like: landuse=forest and natural=wood imply landcover=trees, so if a landcover=* is found completely inside another implied landcover, it overwrites it.

No, it doesn’t. It says that a tree is a natural object.

“it overwrites it” is not clear to me.

I would think:
landuse=forest and natural=wood imply landcover=trees. If a different 'landcover=*` is found inside the implied landcover, the inside landcover “wins”.

I’m not sure how renderers can handle this. It’s kind of the same situation as with a wood containing a pond (not cut-out as inner), where some rendering show ‘swimming trees’ while others show a treeless pond.

In the early proposal stages, we did discuss the different types of landcover implications. What I devised was hard vs soft implicated landcover:

Hard implication would mean that every square meter of a functional area would be covered by a specific landcover. This is a result of a close dependency regarding the function and the object carrying that function. A good example of this is landuse=meadow and landcover=grass.

Soft implication however would mean that for a specific function to be carried out a function would be expected to have some part of its area covered in a specific landcover. The main difference being that other landcovers can assist in the function. A good example of this is forest and trees. Not every part of a forest would be trees, but you do need trees for something to be a forest.

Some mappers intentionally not make specific areas ‘inner’ to woodland to get the trees to render through such as picnic sites mapped as area, or a climbing_adventure zone. Fine by me.

In the meantime I’ve reverted to grassland opening in the wood to the ‘classic’ tagging. So far though no complaints about a ‘featureless’ object but that could be because the outline was given an inner role not to have the trees swimming in green.

Good this was left to simmer on the stove as ready for prime time it’s not.

(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)

1 Like

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.