Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add rendering to landcover=grass and landcover=trees #2548

Closed
polarbearing opened this issue Jan 13, 2017 · 111 comments

Comments

Projects
None yet
@polarbearing
Copy link
Contributor

commented Jan 13, 2017

landcover=* was proposed by @dieterdreist in 2010, and two of the values are in significant use meanwhile, landcover=trees (9632) and landcover=grass (6273). Landcover=* is an orthogonal definition to landuse=*, allowing to map the physical cover as opposed to the actual use of the land.

The reason that these two values are flying already, is that the current use of landuse=grass and landuse=forest is a misnomer in many cases where small areas covered with grass or trees within a real landuse are to be tagged. CF the recent discussion on the tagging list.

I guess the key needs to wait for the database layout change, however I suggest that we already discuss how to render. My proposal is, initially, to render the same as other grass rendering (see #1372) and wood/forest.

@imagico

This comment has been minimized.

Copy link
Collaborator

commented Jan 13, 2017

I have no definitive opinion on this at the moment but the mere use numbers say very little about how widely these tags are accepted in mapping and what they are used for.

It would be important to:

  • know how many of the features with this tag carry another area tag we already render and which would therefore not be rendered differently.
  • know how many mappers are using this tag - spatial distribution in taginfo indicates concentration on central Europe for both tags but this might be by just a handful of mappers or thousands.
  • have a clear definition of the tags on the wiki including practical instructions when to use these tags and not more established ones.

Especially the last point is important IMO since we should not support meaningless proliferation of tags, i.e. creation of synonyms without a difference in meaning in practical use. Especially for trees the different opinions on the meaning of common tags seem to already cover what landcover=trees is meant to indicate. See also xkcd.

@dieterdreist

This comment has been minimized.

Copy link

commented Jan 13, 2017

@polarbearing

This comment has been minimized.

Copy link
Contributor Author

commented Jan 13, 2017

@imagico

This comment has been minimized.

Copy link
Collaborator

commented Jan 13, 2017

because it's the only way to map groups of trees that is supported by this style

Don't put this all on this style. Styling decisions here affect mapping practice but they are not the only influence.

This style aims to support mappers in consistent use of tags. But it should not be our aim to push new tags against existing ones in pursuit of more systematic key semantics. So if landcover=grass and landcover=trees are actually improvements over existing tags both in definition and in practical use (like leaf_cycle/leaf_type compared to wood=*) we should support them but not if they are just a rebranded version of the smallest common denominator of natural=wood/landuse=forest and natural=grassland/landuse=grass/meadow.

So the question to ask is probably: Does landcover=trees indicate anything that is not also indicated by natural=wood and landuse=forest?

Personally i think it is more important to show additional tags specifying additional information on such areas (like the mentioned leaf_cycle/leaf_type) but that of course in no way conflicts with the subject of this issue.

would better be expressed by landuse=highway and a landcover tag

We don't currently render landuse=highway i think but in general if we add rendering of landcover=grass and landcover=trees i don't think this should supersede other area tags we render (like natural/landuse/leisure etc.)

@aceman444

This comment has been minimized.

Copy link

commented Jan 13, 2017

The issue probably is that if you have some main landuse (e.g. residential or farmland) and you put a patch of trees onto it via landuse=forest, but logically you still want the original landuse to be at that spot logically (even more supported by the transparent forest rendering now (e.g. you can have trees and water at the same place)). But algorithmically, you can't have 2 landuses at the same place, so probably the forest wins in applications. Landcover fixes this problem, you can have a semantical landuse at a place, but there is physically a patch of trees (landcover). I support the idea of the new tags.

@imagico

This comment has been minimized.

Copy link
Collaborator

commented Jan 13, 2017

@polarbearing - that is a useful first indicator but number of people who last touched a feature with a certain tag is not the same as the number of active users of course.

@aceman444 - within this style the key used does not really have an influence here - we order by way_area independent of the key used. So if we'd add support for rendering landcover=trees it would not matter if you'd tag an area natural=wood or landcover=trees - it would render the same. I don't know of any other applications that have a problem with overlapping areas using the same key either, this happens so often in real life data that such an application would be pretty useless.

@jojo4u

This comment has been minimized.

Copy link

commented Jan 13, 2017

I liked the more comprehensive proposal by Rudolf more. It's also based on scientific classifications categories.

@aceman444

This comment has been minimized.

Copy link

commented Jan 13, 2017

@imagico but logically it is nonsense to have overlapping areas, unless they really have both properties (like natural=water+natural=wood). But you can't have landuse=residential+landuse=forest at the same spot. That such data exists looks like bad mapping, sometimes caused by the bad existings tags (like you only have landuse=grass at your disposal, natural=grass is something else).

@imagico

This comment has been minimized.

Copy link
Collaborator

commented Jan 13, 2017

Please leave the tagging discussion out of this.

@pnorman

This comment has been minimized.

Copy link
Collaborator

commented Jan 14, 2017

we should not support meaningless proliferation of tags, i.e. creation of synonyms without a difference in meaning in practical use. Especially for trees the different opinions on the meaning of common tags seem to already cover what landcover=trees is meant to indicate.

👍

@dieterdreist

This comment has been minimized.

Copy link

commented Jan 14, 2017

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Jan 14, 2017

I feel this is result of taking this purpose to the extreme:

It's an important feedback mechanism for mappers to validate their edits and helps to prevent unfavorable fragmentation of tag use.

Guarding against unfavorable fragmentation is so hard, that we forget it can be favorable in some cases (like making important changes in tagging without breaking things). And because this style is not only about "consuming" data, but also about giving feedback, it's in effect invalidating any change.

@imagico

This comment has been minimized.

Copy link
Collaborator

commented Jan 14, 2017

I feel this is result of taking this purpose to the extreme

So far i don't think anyone has suggested anything extreme in this thread.

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Jan 14, 2017

Do you consider any fragmentation favorable at all?

@imagico

This comment has been minimized.

Copy link
Collaborator

commented Jan 14, 2017

I think i made my view quite clear:

we should not support meaningless proliferation of tags, i.e. creation of synonyms without a difference in meaning in practical use.

This style aims to support mappers in consistent use of tags. But it should not be our aim to push new tags against existing ones in pursuit of more systematic key semantics.

If and how this applies to the tags suggested in this issue i don't know yet - which is why i mentioned above that additional information would be important.

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Jan 14, 2017

I understand only that you are trying to keep things consistent (and that was clear from the beginning). But I still don't know if you ever consider any tag fragmentation useful (in particular to help make tag change smooth)?

@imagico

This comment has been minimized.

Copy link
Collaborator

commented Jan 14, 2017

The term is from @nebulon42 IIRC - in the context it is used in there i read it as meaning the same as what i described with meaningless proliferation of tags.

@mboeringa

This comment has been minimized.

Copy link

commented Jan 14, 2017

A couple of considerations here:

  • Like others pointed out: landuse=forest and landuse=grass are more or less de-facto already used as "landcover". I know there are issues, but I do think this is the general trend.
  • Many other styles interpret these tags in a similar way as Carto. Making a breaking change - or at least one that potentially has a big impact on how people will tag these features in the future - in Carto, will mean a lot of others styles will need to follow suit. Therefore, this is not just about this style, but a wider issue.

What I totally miss in the discussion regarding landuse / landcover, is that the main problem regarding the current use of landuse=forest/grass is not so much the fact that people use it as landcover while the word "landuse" reflects a legal or administrative status related to some "boundary", but that there is no tagging scheme for these type of "administrative boundaries" not in the hierarchy of "countries/states/districts/provinces etc"...

Instead of developing an alternative landcover=x, I think it would be more logical to develop a new tagging scheme for these types of "administrative / legal / management / toponym boundaries" currently not supported in any of the regular tagging schemes.

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Jan 14, 2017

My question was as wide as possible and I still don't understand: is there anything that could be more important to you than strict consistency? I try to get where the common ground could be, and what circumstances could be legitimate as an exception from this rule? I understand you don't find such exception now - but what would be enough for you to accept it?

@matthijsmelissen

This comment has been minimized.

Copy link
Collaborator

commented Jul 22, 2017

Can we have some examples of this where landcover and landuse are used in parallel? Note that the Netherlands had a not-so-good import so this might not be the best example.

I'm in particular in interested in the intended usecase of the people who liked this issue - @kocio-pl, @d1g, @stragu, @de-vries, and @Tomasz-W.

My personal opinion: I don't see a real difference between landcover=grass and landuse=grass. Note that the latter is about 500 times as popular.

@Tomasz-W

This comment has been minimized.

Copy link

commented Jul 22, 2017

@math1985 For me, it's about mess with tags in OSM. Tags for physical covers of ground (eg. grass, meadow, etc.) should be separated from tags describing usage of this terrain (non-physical, eg. residential, industial, etc.). It wasn't separeted at the beginning, so now a lot of mappers are confused by mixed functions of this 3 keys: landuse=, natural=, surface=*. In this situation, I think that allowing landcover tags is a step in good direction, and a chance to get rid of doubts for mappers in future.

More here: http://wiki.openstreetmap.org/wiki/Landcover

@aceman444

This comment has been minimized.

Copy link

commented Jul 22, 2017

@math1985 maybe e.g. if you want a patch of grass (or trees) in a landuse=residential, having landuse=grass inside landuse=residential is a bit against logic. Every spot should probably only have a single landuse defined, not a stack of landuses. Would you exclude that patch of grass from the residential landuse via a multipolygon? No, nobody does that. Using landcover solves this problem. There can be a landuse defined for a spot, but there may be different things on the ground in reality.

You can see this already in carto where landuse=forest was actually changed to mean landcover and now draws trees on top of residential landuse, water, whatever.

@matthijsmelissen

This comment has been minimized.

Copy link
Collaborator

commented Jul 23, 2017

I still don't think I fully understand this. Do you guys propose replacing the tag landuse=grass entirely with landcover=grass? Or are there situations were landuse=grass is appropriate?

@mboeringa

This comment has been minimized.

Copy link

commented Jul 23, 2017

Honestly, I don't think this is going to solve anything. The problems of missing administrative / legal / management / toponym "boundary" types not defined in the Wiki, are not going to be solved.

The main Wiki page of the landcover key (http://wiki.openstreetmap.org/wiki/Landcover) itself is poor as well. It doesn't actually list a good consistent tagging proposal, but instead resorts to listing existing practices and displaying a series of (international) classifications of landcover (NLCD92, LCCS), that have no real relation with OpenStreetMap and current mapping practices. This is highly confusing and will lead to inconsistent tagging, it is simply unclear what any user should do with this information only superficially related to OSM.

Only on second inspection can you end up on the proposal pages, that seem better defined. However, again, the pages don't solve the "boundary" type problem. They even re-define tags like landuse=forest as going to be deprecated by landcover=trees. This misses the whole point of administrative or legal boundaries (e.g. forest area X managed by company or government agency Y and named Z).

It is likely that we will end up with just another key that has the same problems as the existing natural and landuse keys, that is: administrative, management and legal boundaries and landcover tags intermingled and tagged on the same OSM node / way / relation features.

Considering this switch will have a huge impact on many map styles, and leads to even more fragmentation in tagging practices in a likely long transition period, I am not convinced of its merits given these unsolved shortcomings.

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Sep 16, 2017

I've made initial coding for this issue, but it's not working currently and I plan to take a second look later, so it's still not ready for PR:

master...kocio-pl:landcover

@pelderson

This comment has been minimized.

Copy link

commented Mar 6, 2019

landcover tags are highly controversial

Not the basic landcover=[trees|grass] tag.

landcover tags are widely discussed

That's good. Many rendered tags are widely discussed.

landcover tags are without support of community of OSM mappers

There is massive support for the basic tag itself, but the lack of rendering is seen as a problem. Discussions focussed on all kinds of ideas and schemes around meaning and implications of landuse/natural/landcover and different value systems. This has little to do with rendering landcover=grass as grass.

landcover tags are without support of community of OSM mappers discussing about tagging

Same as above. Ample support for the basic tags landcover=grass and landcover=trees if they are likely to be rendered.

landcover tags are without support from any major editor

Editor support is not essential and will follow once the main renderer announces.

landcover tags are hundreds times less popular than typically used alternatives

Installed base is very large and landcover tags are not rendered. Still the usage is growing.

landcover tags are mostly added by bot edits (confirmed, single import in Paraguay added 96k of 170k present tags, source of remaining 74k objects requires further research)

If the import is ok, it's regular usage. The usage counts 6K users. Growth curve is gradual apart from a few steep climbs.

landcover tags are not used on regular basic by vast majority of mappers
landcover tags are liked and wanted by small fraction of mappers

Not being rendered or supported by editors and tools guarantees that the majority of mappers do not use them. Still the usage grows, both in objects and in users.

...this map style is not obligated to render all tags that won votes and to not render unapproved tags
It's a choice. Got that.

@lgiard

This comment has been minimized.

Copy link

commented Mar 6, 2019

The landcover tag has never been controversial, the controversy is always about the landuse tag and people hijacking the landcover discussion to discuss about landuse=forest polemic.

The landcover=trees is straightforward, people uses this tag for "area with trees" (where other landuse or natural=wood doesn't apply) and request to be rendered exactly the same way the natural=wood or landuse=forest tag (if you want to use it to replace forest itself, it should be discussed on the mailing list). That's all, what's so problematic with that simple request ? It is widely used (without counting import), and slowly but surely growing (the only problem is double tagging at the moment so that the polygon get rendered).

We don't ask to change the whole tagging scheme here, just to render two tag with at least 10k+ uses (for landcover=trees & landcover=grass), that get legitimate use for their "original purpose" i.e. as a simple landcover feature.

To summarize the problem we face : the renderer (here) demand usage by the editors first; the editors demand the rendering first and the tagging mailing list demand the other two. So how do we advance ? That's really a question i'm asking, if you want us to lead the discussion elsewhere (i completely understand your point of view), how can we get support from you (renderer team) or the editor team ? What's are the objectives things that need to be achieve before a rendering can be applied ?

@Adamant36

This comment has been minimized.

Copy link
Contributor

commented Mar 6, 2019

I am inclined to lock discussion here because participants keep doing exactly what they have been asked not to in #2548 (comment), i.e. arguing what is the best way to tag certain things and key semantics.

To quote @matkoniecz "Use and meaning of both tags is exactly the same." Telling him he's wrong about that and how isn't arguing semantics or what the best way to tag something is. Its saying the tags are different. Which they are.

Go ahead and lock the issue if you want though. It will be a nice little self fulfilling prophecy that you and @matkoniecz can point at to prove its a controversial subject, when your the ones that are making it that way.


landcover tags are highly controversial

Their controversial because you keep ignoring the counter arguments and saying they are. All the conversation I've seen it was pretty mild and there was a good balance of people for and against it. Know where is anyone outright against the tag. Most of the complaints are just about the lack of usage. That doesn't make the tag controversial though. Your making up the controversy to deflect from counter evidence and as a way to more easily dismiss other people's opinions that disagree with you.

landcover tags are without support of community of OSM mappers

There was plenty of people in the mailing list discussion that said they use it. There's also people here that support it, but might not use it per say. Personally I don't because its not rendered, but 100% would and let other people know about it if it was. I've had lots of conversations with mappers who said they would use it if it was rendered also.

landcover tags are without support from any major editor

The only reason iD Editor was against it is because of the low numbers compared to the other tags. It had nothing to do with the tag itself though. JOSM also has a plugin for it. So its supported, just not built in.

landcover tags are hundreds times less popular than typically used alternatives

Again, they aren't "alternatives." They are different tags. Repeating it over and over doesn't make it true. "Popularity" doesn't have anything to do with it either.

landcover tags are hundreds times less popular than typically used alternatives.

again, its not about the tag be popular or not in respect to another "similar" tag. Tags have different usage numbers. That's life. They are different tags though.

landcover tags are mostly added by bot edits (confirmed, single import in Paraguay added 96k of 170k present tags, source of remaining 74k objects requires further research)

Like I said above, just solve the problem by having @woodpeck revert the imports. That's what's done in every other situation. There's nothing unique about it here.

landcover tags are not used on regular basic by vast majority of mappers

Because they aren't rendered and people don't know they exist. Its another case of self fulfilling prophecy. You don't render something, so its not used, so you continue to justify it not being rendered because its not used.

landcover tags are liked and wanted by small fraction of mappers (this is my guess and it may be wrong

It is wrong. Plenty of people on the mailing list said they use it and it had a lot of uses before the import. You were involved in all those discussions. You shouldn't act like you weren't. I also used your OverPassTurbo query to check America and none of the uses I found there were imports. So Your obviously ignoring the counter evidence that people use it to push your narrative that its all bot edits. They just don't use it as much as the "established" tags. That doesn't mean its not being used though or that everyone is against it like your claiming.

either move https://wiki.openstreetmap.org/wiki/Proposed_features/landcover to vote stage or create a new proposal for landcover and held vote for it - I expect it to result in a clear rejection

It probably would be rejected at this point since its 7 years later and a bunch of people, mostly you, have been lying this whole time about how the tags are meant to replace the established ones when known, including @dieterdreist in this issue, said they were.

though note that this map style is not obligated to render all tags that won votes and to not render unapproved tags

Yeah exactly, your going to refuse it being rendered either way for whatever reason. If it wins a vote or not. Your clearly the only one pushing the agenda here.

especially for controversial tags duplicating existing ones that are far more popular. especially for controversial tags duplicating existing ones that are far more popular.

Again, its not duplicating existing tags. Your obviously being intentionally misleading about it at this point. And again, its only controversial because your making it that way and keep saying it is.

how many new forests/grass areas are mapped by humans with landcover=* tags? In general botlike edits adding landcover to mapped features may easily boost usage count despite lack of real use among mappers.

Again, there was 10,000 edits by actual people before the import and plenty of since then have said they either currently use it or will if its rendered. Keep using the "bot" straw man though.

landcover tags comes from a single import in Paraguay, what is the source of remaining ones? How many were added by human edits?

Because you don't know where they came from, they must be nefarious right? Almost every time I've talked to you about anything, it was because you thought someone was doing something nefarious. 99% of there wasn't anything bad going on though. There probably isn't in this situation either. If there is some bot edits though, just have them reverted. Tags are imported and reverted all the time. I'm not sure why its an issue. I know plenty of places where the "alternatives" to this tag have been imported without discussion or anything. Why don't you have a conniption and remove rendering for them because of it?

Strawman. I'm mainly pointing out that landcover tag usage is growing rapidly despite not being rendered by the main rendering platform. I can't see why the vehement opposition to rendering this harmless (non-destructive) tagging addition which is already widely used.

Straw men is all they have. Nothing @matkoniecz has said is based in any facts. He obviously doesn't care though. There's zero legitimate reason to not render the tags. They have rendered plenty of other tags that were both more controversial (especially since this controversy is completely fabricated) and had more serious issues. Including massive imports. @matkoniecz himself was perfectly fine with rendering something a while back that was like 50% imports.

I'm sure the issue will keep coming back, it's a reasonable enough request.

It totally will. There's zero wrong with the tag and there's clearly benefit to rendering it. Otherwise @dieterdreist wouldn't have proposed it. I bet he knows way more about this stuff then @matkoniecz does.

@Adamant36

This comment has been minimized.

Copy link
Contributor

commented Mar 6, 2019

The landcover tag has never been controversial, the controversy is always about the landuse tag and people hijacking the landcover discussion to discuss about landuse=forest polemic.

Exactly. Its not a controversy in the first place. Except when certain people make it one by going off landuse=forest and the other similar tags.

how can we get support from you (renderer team) or the editor team ? What's are the objectives things that need to be achieve before a rendering can be applied ?

You probably can't. @matkoniecz clearly doesn't want it rendered. Which is why he said even having an improved vote might not be enough (after he said to have it voted on). He intentionally set the bar to "editors have to support it first" because he knows its not going to happen unless it gets wider usage, which it won't unless it gets rendered, and the cycle continues. But it gives enough to justify not rendering it.

P.S. I see your thumbs down SomeoneElseOSM. I'm aware I'm probably being a little backhanded. So I'm fine with it. Feel free to leave a comment along with the thumbs down if you want. I've said all I need to about the subject.

@matkoniecz

This comment has been minimized.

Copy link
Collaborator

commented Mar 6, 2019

@lgiard

the editors demand the rendering first

Can you link me to such requests in JOSM, Vespucci and iD? As far as I know JOSM, Vespucci and iD are happy to add support for features not rendered anywhere, barrier is typically much lower than for rendering in this style (for multiple reasons). And from just found iD ticket - rendering is not even mentioned.

It would answer one of questions that was asked

how landcover=grass and landcover=trees is supported in iD, JOSM, Vespucci and other editors? If not - is it because it was never requested or is it something that was rejected? What was the reason for rejection? Support in editors is certainly the first step before supporting in rendering, especially for controversial tags duplicating existing ones that are far more popular.

@matkoniecz

This comment has been minimized.

Copy link
Collaborator

commented Mar 6, 2019

@Adamant36

It probably would be rejected at this point since its 7 years later and a bunch of people, mostly you, have been lying this whole time about how the tags are meant to replace the established ones

First of all, thanks for confirming my suspicion that landcover tag is rather disliked by general OSM community.

On topic of deprecation - see https://wiki.openstreetmap.org/wiki/Proposed_features/landcover with

The 'landuse=grass' tag should be deprecated with landcover=grass taking its place.

See also https://wiki.openstreetmap.org/wiki/Proposed_features/landcover#New_tags_and_deprecated_tags - section titled "New tags and deprecated tags" that proposes to deprecate multiple tags.

Is there a better documentation of landcover proposal?

BTW, note that comments like "a bunch of people, mostly you, have been lying this whole time" is against basic and obvious rules of not being rude. It is also against our code of conduct - see https://github.com/gravitystorm/openstreetmap-carto/blob/master/CODE_OF_CONDUCT.md Please avoid this kind of comments. Even if such comments would be correctly describing situation it still would be preferable to mention it in a less aggressive way.

@Adamant36

This comment has been minimized.

Copy link
Contributor

commented Mar 6, 2019

First of all, thanks for confirming my suspicion that landcover tag is rather disliked by general OSM community.

I don't think that's what I did. People can be for tag because its a good tag, but against a certain aspect of its implementation due to disinformation. As I've said already, I haven't seen anyone that's outright against it.

On topic of deprecation - see https://wiki.openstreetmap.org/wiki/Proposed_features/landcover with

In response see #2548 (comment) bullet point 4. The proposal page has been edited a lot by a lot of different people since it was created. So who knows when the part you cited was added to it or if it was there originally. It doesn't seem to be current opinion of the person who created the proposal at least. Ultimately, anyone can edit a wiki page and put whatever they want on it (that sentence could just as easily be removed). The original intent of the tag should be the important thing.

See also https://wiki.openstreetmap.org/wiki/Proposed_features/landcover#New_tags_and_deprecated_tags - section titled "New tags and deprecated tags" that proposes to deprecate multiple tags.

See the first paragraph on the top. "The 'landuse=grass' tag should be deprecated with landcover=grass taking its place." Notice it says it "should" be. Not "will be" or "is being." Its just a recommendation. Again, did @dieterdreist put it there? And if so when? If it was before his comment here in 2017 he's clearly changed his mind. Maybe he just never got around to updating the page to reflect it. It shouldn't matter though. Since its just a recommendation. Personally, I don't see anything wrong with landuse=grass eventually being phased out some day if that's the tagging usage goes, but know one is suggesting it.

BTW, note that comments like "a bunch of people, mostly you, have been lying this whole time" is against basic and obvious rules of not being rude.

Yeah, I know. Your always willing to take an opportunity to chide me about the rules but you never do when its someone violating them to me. If your going to keep making exceptions, keep it to yourself. I'm sick of hearing it.

Even if such comments would be correctly describing situation it still would be preferable to mention it in a less aggressive way.

I can agree with that. I'll try to find a less aggressive way to accuse you of lying next time ;)

Btw, thanks for providing sources this time to back up what your saying and refute points. It helps a lot and gives more room for the problems you have with the tag to be addressed.

@matkoniecz

This comment has been minimized.

Copy link
Collaborator

commented Mar 6, 2019

So who knows when the part you cited was added to it or if it was there originally

Everybody able to check page history - see https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/landcover&action=history

See also latest version edited solely by the author - https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/landcover&oldid=590578#This_proposal_deprecates

And, yes, landcover proposal wanted to deprecate multiple tags from the very beginning.

@Adamant36

This comment has been minimized.

Copy link
Contributor

commented Mar 6, 2019

And, yes, landcover proposal wanted to deprecate multiple tags from the very beginning.

Hhhmmm, well maybe @dieterdreist can comment on the incongruity then. I still haven't seen anyone advocate for it and it sounds more like a recommendation where it is mentioned then a mandate. Tags do replace other outdated tags though and sometimes both are rendered in the meantime.

There has been rendering of both power=substation and power=station for a while. There's also a PR currently in the works to rendering competing healthcare tags, amenity=hospital and healthcare=hospital etc if I remember correctly, which seems to have support. So its not un heard of to render two similar, competing or not competing, tags at the same time.

@bhousel

This comment has been minimized.

Copy link

commented Mar 6, 2019

Can you link me to such requests in JOSM, Vespucci and iD? As far as I know JOSM, Vespucci and iD are happy to add support for features not rendered anywhere, barrier is typically much lower than for rendering in this style (for multiple reasons). And from just found iD ticket - rendering is not even mentioned.

I'm happy to chime in from the iD perspective.. landcover=trees was proposed here: openstreetmap/iD#4272

We decided not to support it because it really doesn't offer anything over the existing tags that are in widespread use. I offered to dual-tag landcover tags with other existing established natural and landuse tags, but people didn't want that.

I wrote:

natural=wood is used, in practice, for all kinds of tree cover, (not just "primeval woodland" - why do people think this?). I see it used pretty frequently for small groups of trees even in urban areas.
landuse=forest is also used, in practice, for all kinds of tree cover, but preferring towards places where the trees are managed by forestry. I just don't see how the new landcover tags solve any problem not already handled by the natural tags.

So it's 2019 and the landcover tagspace is pretty much a failed experiment. I'd love for people to stop pretending otherwise. Also it would be great if maintainers of the wiki would make this clear, so people don't think that the tags have any chance of being supported anywhere.

This is ok! Sometimes tags fail because they don't fulfill an actual need, or because the cost of switching tags doesn't offer enough benefit over the existing tags. The important thing is to not read to literally into the words that we use for the tags. (lots of building are not buildings, lots of highway are not highways, and yes, lots of landuse are not landuse. deal with it!)

@pelderson

This comment has been minimized.

Copy link

commented Mar 6, 2019

@pnorman pnorman removed this from the Database layout change milestone Mar 6, 2019

@pnorman

This comment has been minimized.

Copy link
Collaborator

commented Mar 6, 2019

I'm temporarily locking this because of the unproductive heated discussion and code of conduct violations.

Repository owner locked as too heated and limited conversation to collaborators Mar 6, 2019

Repository owner unlocked this conversation Mar 10, 2019

@pnorman

This comment has been minimized.

Copy link
Collaborator

commented Mar 10, 2019

I've unlocked this. Please remember the code of conduct, in particular,

  • Be respectful
    • In particular, respect differences of opinion.
  • Avoid destructive behavior:
    • Derailing: stay on topic; if you want to talk about something else, start a new conversation.
    • Unconstructive criticism: don't merely decry the current state of affairs; offer—or at least solicit—suggestions as to how things may be improved.
    • Snarking (pithy, unproductive, sniping comments)
    • Microaggressions: brief and commonplace verbal, behavioral and environmental indignities that communicate hostile, derogatory or negative slights and insults to a person or group.
@imagico

This comment has been minimized.

Copy link
Collaborator

commented Mar 10, 2019

For a more fact based look at things here a few numbers from running through a recent history planet file.

There are 48061 version 1 way/relation features with landcover=trees in the planet history. That is the number of features that were created with a landcover=trees tag, i.e. cases where a mapper mapping a feature originally decided to tag it this way. This includes features deleted later or where the landcover tag has been removed later and does not include features where the landcover tag has been added later. Therefore it is a fairly good measure of active use of a tag by mappers newly mapping things.

Here is the list of user names with more than 100 features created including the number of features created:

    115 Arq%20%Alejandro%20%Hoyos
    118 SandraI
    120 MaiaQ
    121 sapitopintor
    122 altairb
    128 n76
    130 Lorena%20%F
    133 MarcoR
    133 NatBC
    136 Hora
    137 nimapper
    151 Gustavo%20%León%20%Servin
    154 DarkSwan_Import
    167 soledadjv
    173 Dahianna%20%Anonis
    175 MapPYOSMMirtha%20%Burgos
    177 tamaratorres09
    178 eugedelgado
    186 imagic
    197 SergioMartínez
    200 Warin61
    215 Majo%20%Cabral
    236 XGiret
    259 Mónica%20%Godoy
    264 María%20%Malvetti
    274 Guido%20%villalba
    275 María%20%José%20%González%20%Ayala
    297 Emistrac
    307 wvsch
    326 monicakrause
    343 MariaSanabria
    365 _al
    379 VioletaKrissRoa
    388 GiuseppeAmici_IT
    411 etrumap
    423 Pieter%20%-%20%Ede
    424 RodrigoOrjuela
    428 MapPyMara%20%Maravilla
    513 Perry-juancamilo
    570 RAMONML
    584 Christian%20%Ricardo
    743 MapPyOSM%20%-%20%Diego%20%Bernal
    786 SaraMZ
    823 Sara%20%Gonzalez
    830 MapPYOSM%20%Manuela%20%Stanley
    900 MapPy-GabrielaCristaldo
   1068 analiaMO
   1213 verstones
   1249 MapPYOSM%20%Jazmín%20%Sanabria
   1257 katrina%20%lisnichuk
   1410 Cindy%20%Franco
   1428 MapPyOSMDaniel%20%Diaz
   1598 Guillermo%20%Torres
   2871 torpemanzano
   3496 jacqueinsfran
   3672 Stella%20%GBO
   4771 dieterdreist
   5672 dieggovera

I did not check the whole list but all of those with more than 500 features except dieterdreist are part of an organized effort in Paraguay. Most of them have from a few dozen up to a few hundred changesets and stopped mapping about three months ago.

So overall conclusion for me is that there is much less active organic use of the tag by individual mappers using the tag out of their own free choice than the raw numbers from taginfo indicate. I don't know the details of how this project in Paraguay came to choose using landcover=trees but likely this results from misinterpreting the meaning of existing tags. If you remove the numbers resulting from the organized effort in Paraguay adoption of landcover=trees by mappers is hardly higher than of landcover=grass.

So far for the analysis. I hope this provides a better understanding on use of the landcover=trees tag and helps understanding why it is so important to look closely how tags are used, by whom and what guides their decision to do so. I also hope this shows why taginfo numbers and taghistory plots do not typically show the whole story and are rarely a good basis for making rendering decisions here.

@CarlosBrys

This comment has been minimized.

Copy link

commented Mar 10, 2019

The data was loaded for a long time by students of a research project of the Faculty of Architecture and Design of the National University of Asuncion, Paraguay. "MapPy OSM - CIDI FADA UNA. Systematic mapping of Paraguay-Buildings-Vegetation-Water". See: https://www.facebook.com/mappyosm/

The names of the editors correspond to the students of the university of Asunción, Paraguay, who participated in the research project.

See: https://cidifadauna.com/2018/10/23/presentacion-de-map-py-osm-en-state-of-the-map-latam-2018-buenos-aires/

The use of the label landcover=trees was discussed at length with the OSM community of Paraguay and Argentina because the research project maps urban trees, and that they are not woods or forest. As a result of the discussion many areas were changed, that had been erroneously mapped as forest plantations in cities.

See the OSM forum: https://forum.openstreetmap.org/viewtopic.php?id=61256

There is no soil management in the squares or the houses of the cities, they are only lands covered with trees, that is why the natural wood or managed forest labels are not applicable in that context.

@Adamant36

This comment has been minimized.

Copy link
Contributor

commented Mar 10, 2019

So, I counted 57 users there. The thing I'm not clear on is what that means exactly? So 57 people in Paraguay mapped a feature. It doesn't mean their edits weren't legitimate because they were all from the same country or say anything about the merits of rendering the tag or not (most countries/areas outside of three main places in Europe only have a small number of users that tend to congregant toward mapping only a few things. In California its a few kinds of landuse and buildings if your lucky). That doesn't really mean anything to rendering those things though. So while its interesting information, I'm still not sure what to take away from it, except its at least not bot edits as prematurely claimed.

Also I don't think why they did or didn't decide to use the landcover tag over something else is relevant, because A. its not something you can know B. It isn't brought up in any other rendering decision.

Another way to look at it would be to exclude those edits from the decision (although I think they matter to make the argument that it should be rendered, but the repeated false of claim of them being nefarious edits was what caused a lot of the problems). Doing that it has essentially same usage of landcover=grass, high enough numbers to render, and globally spread out organic usage by multiple editors.

Its also lame (I'm not sure what the word is) to say landcover=grass shouldn't be rendered because of bad landcover=tree usage (which there wasn't). A lot of my irritation was that when I brought up landcover=grass it was repeatedly deflected by the, now proven false arguments, against rendering landcover=trees. Which seems purposely obtuse. If you can't considering rendering one key without automatically attaching the conversation to another key that you think is badly mapped, there's zero point in discussing or rendering anything. Almost every tag has usage that is bad, be that from bot edits or none approved keys. You couldn't render anything if that was your metrics. Plus, its just dismissive to repeatedly drone on repeatedly about landcover=trees and bot edits when some one asks repeatedly about a different tag. Last I check this issue is about both. So say landcover=trees turns out to be trash and not rendered, it doesn't mean the issue is done and that we can call it a day. Anymore then because one barrier or shop or whatever icon isn't worth rendering we didn't say to hell with rendering the rest of them. Or because power=plant didn't get rendered we then don't render power=substation. Personally, I could care less about landcover=trees, but I think landcover=grass is extremely needed. I don't see why it can't be rendered even if landcover=trees isn't. They ultimately have nothing to do with each other.

@imagico

This comment has been minimized.

Copy link
Collaborator

commented Mar 10, 2019

@CarlosBrys - As said previously what is the proper tagging of things is off-topic here but since your project seems to be by far the largest user of the tag discussed here i will try to quickly comment on your specific situation. But i don't want this to be used to start a more elaborate discussion on woodland tagging or organized mapping, such would need to be done elsewhere.

I don't speak Spanish so i can't follow in detail the discussion you linked to but you seem to have gotten the wrong impression, possibly due to the wiki not properly documenting the actual meaning of tags (which unfortunately is very common, in particular for the tags this is about - you can blame the key systematics fanatics about it), that neither landuse=forest nor natural=wood can be used for urban tree areas. As you can see in other parts of the world (including South America) this is not a widely accepted interpretation of these tags - urban tree areas are tagged with those in many parts of the world in far larger numbers than what you mapped in Paraguay.

Now you are free to tag things the way you do as long as it is fine with the local community but this style has among other things a responsibility to safeguard the privilege of individual mappers to decide on tags they use as a community of individuals independent of organized projects and their collective influence and to do that we do not give a project like yours that tags a hundred thousand features in a uniform way centrally decided on significantly more weight that to a single hobby mapper mapping maybe a few hundred or thousand features.

Now again - this is just an attempt at me explaining how i think this project should and needs to regard organized mapping projects like yours. This is not an invitation to discuss tagging or the rights and responsibilities of organized mapping projects in OSM here - those topics belong into a different venue.

@Adamant36

This comment has been minimized.

Copy link
Contributor

commented Mar 11, 2019

"key systematics fanatics about it.'

If there's going to be a civil discussion about it, it would be helpful not to refer to people who want to see the tags rendered as "fanatics." Even if they are passionate about it. Or the same could said about the people who are against their rendering, but saying as much leads chastisements of not following the rules and the issue being locked. The contributing guidelines about not name calling etc should apply to you as much as they do to people who aren't moderators.

@mkyral

This comment has been minimized.

Copy link

commented Mar 11, 2019

I see, only landcover=trees is discussed. But I'm more interested in landcover=grass. I have one example for it.

A man_made=reservoir_covered + landuse=industrial + landcover=grass It is a industrial land, but the main part in underground and it is covered by grass. I don't think that landuse=grass is correct there.

How this should be rendered? As industrial area or as grass? It is both.

@Adamant36

This comment has been minimized.

Copy link
Contributor

commented Mar 11, 2019

Your example reminds me of the library a few towns over from me that has grass covering the roof for cooling in the summer. Its a pretty big roof. As it is to map the grass it would be landuse=commerical (for the grounds) + building=commercial + landuse=grass (for the grass on the roof). Its pretty convoluted. Using landcover=grass makes a lot more sense.

I'm aware it shouldn't be a conversation about "tagging" but its relevant to counter the people who say they are against rendering because the tags don't have a use.

@pelderson

This comment has been minimized.

Copy link

commented Mar 11, 2019

@Adamant36

This comment has been minimized.

Copy link
Contributor

commented Mar 11, 2019

"Combination of landuse and landcover: Area features can have both landuse
and landcover tags."

One of the issues I run into all the time is people tagging an area with multiple landuse tags, which results in laduse_1, landuse_2 etc. Its done way more often then it should be. So if this helps solve that great.

@pelderson

This comment has been minimized.

Copy link

commented Mar 11, 2019

@SilentSpike

This comment has been minimized.

Copy link

commented Mar 11, 2019

Just want to weigh in (my opinion, no facts presented here):

  • From a tagging perspective, landcover isn't perfect, but it's better than existing landuse, natural, etc. cases as it addresses some of the ambiguity of existing tagging and solves situations such as grass within a different landuse area.
  • From a decision making perspective, comparing usage of existing tagging which is widely supported in commonly used editors to a proposed replacement tagging which isn't present in said editors by default is a bit of a waste of time. If any random tag is added to a forest/grass preset in iD the usage of that tag would skyrocket.
  • There's a bit of an impasse in that existing tagging has some clear issues (otherwise we wouldn't be having this discussion) and yet it is so widely used that it's almost impossible to change.

Conclusion:

The majority of mappers don't feel strongly enough about the issues with these existing tagging schemes to seek new schemes. However, this doesn't necessarily mean they are opposed to change as long as they can still map features with some form of tag (there's probably a fairly large percentage of mappers who are only interacting with editor presets and not tags themselves).

Tags implemented by editors hold a lot of sway here and I imagine have an even greater impact than an import using a specific scheme ever could.

So personally, it seems like landcover probably shouldn't be rendered at the present time. However, there's a bit of a wider issue in that there's no easy system in the OSM space to deal with issues with widely used tagging schemes. I suspect discussion of issues such as this will continue ad infinitum until such a system is established.

@CarlosBrys

This comment has been minimized.

Copy link

commented Mar 11, 2019

Some facts about the use of landcover in Paraguay and Argentina.
The province of Misiones in Argentina is the last reservoir of the paranaense jungle (see the green spot in South America in satellite view here: -26.692, -54.283) bases its economy on afforestation.

The use of the soil with afforestation and natural forest is very important for the provincial economy. If somebody want to calculate the area of forest implanted using the label landuse=forest or natural=wood, the results would be oversized when incorporating the urban tree mass, which is definitely not a forest plantation.

For this reason, the Paraguayan university project was discussed to use the landcover label and not landuse to map urban trees.

@pelderson

This comment has been minimized.

Copy link

commented Mar 11, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.