Hello all,
We have completely rewritten the proposal based on all the feedback we received. It should be much clearer now what we want and especially, why we think this change is a good idea. This rewrite should clarify a lot of the things.
We would like to receive feedback.
For reference, here is the link again:
https://wiki.openstreetmap.org/wiki/Proposed_features/landcover_proposal_V2
Give a specific situation where this proposal would improve something. Specific as in: What part of the map? Link it.
I like landcover=trees because it is neutral regarding origin. There was long thread in Polish community part about how to map man made parks with large tree groups. Recommended - and widely used - natural=tree has implication that it is natural while parks are man made. Mapping trees individually doesnât have sense in big landscape parks like:
Uuuhhh, the trees in the park are still natural though arenât they?
Trees themselves - yes. But their placement, species, etc. were chosen by man. So park is not natural. I donât agree with that argumentation and use natural=tree but I understand arguments against.
There are multiple situations where landcover can or has already improved the database.
For example, take this ring between the walkable pavement and the water feature:
https://www.openstreetmap.org/relation/16167148#map=19/52.23369/5.94640
Another case would be in eco systems. Take this forest for example, this forest is named: âSpiegelbosjeâ and its boundary includes both the trees and the grass of this forest.
https://www.openstreetmap.org/relation/15595046#map=18/52.24011/6.10490
If a forest consists only out of trees or there is not enough time to map the individual landcover of a forest the landcover=trees can be added to the forest outline. Then if a mapper in the future wants to add more detail they can remove the landcover=trees and add individual features that describe the landcover in more detail.
Yeah sure. The park isnât natural, but the tag is for mapping the trees. Not the park. Thatâs like saying if I put a barn in a cow pasture that the pasture is now a building. They arenât mutually exclusive and we donât map or tag them like they are.
Historically, several tags have been used for this - landuse=forest (one of the many contradictory interpretations of that tag) landuse=forestry (not much used), boundary=forest (also not much used, but documented).
You can use landcover=concrete right now, without accepting the âlandcoer proposal V2â.
You have not provided an example of how the proposal improves anything. The proposal is not just âlet just use the landcover keyâ.
I still see nothing that this proposal enables us to do better than can be done currently. To me, this proposal is just reorganizing tags with other tags that do the same thing.
I apologize that you might not currently see any improvement. However, I hope that you can understand that to have spent all these hours on this proposal means that we do see that improvement.
While the usage of landcover is quite substantial alone, this proposal is necessary to deprecate tags that are de facto landcovers like landuse=grass.
We welcome and value all constructive feedback on this proposal. But, addressing concerns rooted in fallacy arguments or resistance to change can be challenging.
The goal of the proposal is to create a consistent, understandable and logical tagging scheme. For new, and experienced mappers, understanding and mapping landcover/landuse can be difficult. Different tags, are located in various keys, there are duplicates in various keys.
We want to introduce a clear separation between functional and physical tags. This has several advantages:
As an example, take a forest. A forest is an ecosystem, proposed tagged with natural=wood. That ecosystem consists out of many other objects. You have large areas of landcover=trees ofcourse. Beside that, there can be clearing of landcover=sand or landcover=grass. Through that forest can flow a stream mapped with natural=water. There can be famous trees in that forest, individually mapped with natural=tree as POI etc. The natural=wood describes the natural entity forest which then consists our of smaller layers of landcovers and other entities. The natural=wood should ideally also not be rendered as a fill. The landcovers should be rendered. The forest should for example render a line marking the extend of the forest.
At first, the proposal might look as just moving some tags but that is only to support the goal of creating a better tagging system for OSM in the long term. It is true that I can now also map an area of grass. However, you often have to ask, what is the function of the patch of grass while this is not always known. Instead of incorrectly chosing one of the grass tags, you can also choose to map it as landcover=grass. That is something you can objectively say. The proposed tagging scheme supports the various levels of detail based on that the user wants to map and what is known.
In that case I make a hole in the natural=wood and tag it with natural=sand. For the river, I make a cut and put natural=water. What is the benefit in adding, on top of this, another tag for the whole âecosystemâ?
That is a good argument to start using landcover=grass. Only that.
The fundamental problem with the Landcover 2 proposal is that it is meant to push a very specific ontological view, including separating ânaturalâ from âlandcoverâ (that is mostly an arbitrary distinction). It is not written in mind with specific real-world problems to solve. Your proposal article in the wiki is all abstract talk.
From the Wiki proposal page:
The tag it self however does not describe the landcover. For this, landcover values like sand should be used. If the beach consists out of multiple landcovers (e.g. sand and rock), the individual landcover polygons should be mapped inside the polygon of natural=beach. This is a good example of the division between natural entities and landcovers.
Wrong. A beach is by definition an area of sand. Bare rocks against the sea is not what a beach is.
There is also natural=beach;surface=shingle. But yes, a bare_rock beach I never seen.
Thereâs places in the mountains along streams where the water goes over large rocks that people lounge around on. Maybe you could technically call them beaches since I think thereâs a double entendre there with something being beached as in âbeing stranded on the shoreline.â No one ever uses the word that way IRL for people laying out on rocks next to a waterway. At least not that Iâve seen.
I suppose thatâs what he meant. If a beach had a sand part and a pebble part, but the whole thing was called âBeach Xâ, then currently, there would be no proper way to tag it, because youâd have to settle for a single surface. Your options would be
surface=sand;pebbles, but that wouldnât tell you where these areas areA similar problem was just solved recently by introducing boundary=forest. Thereâs definitely a need to distinguish between âwhatâs the surface covered with?â and âwhere am I?â. Currently, this only works if the tagging-keys are different (like leisure=park), but you quickly run into issues with natural=wood.
A park usually consists of several parts: landuse=grass (ouch), natural=scrub, maybe some natural=wood, and of course some (high)ways through it. You can put all that into a park, because they keys donât clash. But if you wanted to add shrub/scrub areas to a natural=wood, youâd have to âcutâ them out of the wood, even though they are part of it. Like a park, a wood can consist of scrubs, shrubs, sometimes even heath, grass, sand, and so on. You could use landuse=forest to work around it, but the example shows that a forest, like a park, doesnât only have a single vegetation, and some people want to map these fine details.
Of course, thereâs also the benefit that couchmappers no longer have to map the function of grass, but rather hey, âlooks like grassâ. And later on, the SC-mapper is being asked âwhat type of grass is this?â. Well, just throwing in my 2Âą
Than that area of sand is no longer part of the forest. It is a hole in a forest, like an enclave and no longer part of the larger forest. If you gave a forest a name, that piece of sand is no longer part of that named forest while it definitely should be because it is what makes up the total forest.
Which is meant to make the tagging system more consistent and better to understand. We believe that this improvement is beneficial for OSM in the long term. The current tagging system is a patch work of mixed tags and cannot be extended in a logical way. See for example the discussion about natural=shrubbery. The discussion went for quite some time about which key to use. If the proposed tagging scheme was in place, the discussion would not have been about which key to use.
And what do you mean with real-world problem? If a tagging system is not clear, it should be able to change.
Finally we arrive at a specific problem that your proposal solves: Named forests. However, that already was solved by introducing boundary=forest as said above.
It is not clear for you.
If you do not know what âreal-world problemâ means and why a proposal must solve such problems to make sense, then explaining would be a waste of my time.
The authors here seem to forget that the burden is on them to convince us (mappers) that their proposal makes sense. We can reject their proposal on the mere grounds that they simply did not give a good enough reason to adopt it.
I suspect a lot of the places where landcover is useful (to the degree that it is) could just as well be or are being mapped using other tags that admittedly arenât perfect like with the example of barrier=hedge or whatever it was. I donât think just because some details of those tags need to be ironed out that it justifies creating a whole competing tagging scheme.
Although there was one example someone brought up in another discussion a while back where landcover might be useful. In that case it was an orchard where farm animals graze on the grass underneath the fruit trees. I think it was being mapped with landuse=orchard + landcover=grass. Which makes a lot more sense to me then something like landuse=orchard + natural=grassland does.
In that case, I would put both landuse=orchard + landuse=grass using multipolygons.