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 · 113 comments
Closed

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

polarbearing opened this issue Jan 13, 2017 · 113 comments
Labels
declined landcover new features Requests to render new features

Comments

@polarbearing
Copy link
Contributor

polarbearing 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.

@kocio-pl kocio-pl added new features Requests to render new features landcover labels Jan 13, 2017
@kocio-pl kocio-pl added this to the Database layout change milestone Jan 13, 2017
@imagico
Copy link
Collaborator

imagico 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
Copy link

dieterdreist commented Jan 13, 2017 via email

@polarbearing
Copy link
Contributor Author

polarbearing commented Jan 13, 2017

Objects with this key were last edited by 1 080 different users. = 216 full hands.

@imagico
Copy link
Collaborator

imagico 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
Copy link

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
Copy link
Collaborator

imagico 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
Copy link

jojo4u commented Jan 13, 2017

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

@aceman444
Copy link

@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
Copy link
Collaborator

imagico commented Jan 13, 2017

Please leave the tagging discussion out of this.

@pnorman
Copy link
Collaborator

pnorman 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
Copy link

dieterdreist commented Jan 14, 2017 via email

@kocio-pl
Copy link
Collaborator

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
Copy link
Collaborator

imagico 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
Copy link
Collaborator

Do you consider any fragmentation favorable at all?

@imagico
Copy link
Collaborator

imagico 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
Copy link
Collaborator

kocio-pl 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
Copy link
Collaborator

imagico 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
Copy link

mboeringa 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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link

Tomasz-W 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
Copy link

@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
Copy link
Collaborator

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
Copy link

mboeringa 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
Copy link
Collaborator

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

@matkoniecz
Copy link
Contributor

matkoniecz 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
Copy link
Contributor

matkoniecz 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
Copy link
Contributor

Adamant36 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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link

bhousel 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
Copy link

pelderson commented Mar 6, 2019 via email

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

pnorman 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
Copy link
Collaborator

pnorman 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
Copy link
Collaborator

imagico 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
Copy link

CarlosBrys 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
Copy link
Contributor

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
Copy link
Collaborator

imagico 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
Copy link
Contributor

"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
Copy link

mkyral 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
Copy link
Contributor

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
Copy link

pelderson commented Mar 11, 2019 via email

@Adamant36
Copy link
Contributor

"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
Copy link

pelderson commented Mar 11, 2019 via email

@kymckay
Copy link

kymckay 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
Copy link

CarlosBrys 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
Copy link

pelderson commented Mar 11, 2019 via email

@zorae
Copy link

zorae commented Nov 22, 2019

There's a worldwide effort on MapRoulette to clean up duplicate landuse tags such as landuse_1 and landuse_2. In solving some of these tasks, I've noticed that much of the landuse misuse in question is a legitimate need that could be solved by landcover tagging.

For example, cemetery forests are pretty common in Asia. Currently, there is no good way to tag them, but landuse=cemetery + landcover=trees would solve the issue.

There is a proposal for landuse=cemetery + cemetery=wood, but I think that solutions like this

  • are too inflexible
  • have an even lower chance of being rendered than landcover=trees
  • are semantically hard to understand, because wood is now a value of cemetery, even though it would be the primary landuse value in any other case.

Just imagining how I'd use landcover if it were supported, I see a lot of opportunity for clearer mapping that would also be more representative of real-world features. I would strongly prefer that scheme, even in areas where no serious issues like cemetery forests occur.

@matkoniecz
Copy link
Contributor

cemetery forests are pretty common in Asia. Currently, there is no good way to tag them

I would be happy to discuss it on tagging mailing list or some other medium like a telegram / slack / OSM Wiki, but I will not do it here as tagging discussions are offtopic here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
declined landcover new features Requests to render new features
Projects
None yet
Development

No branches or pull requests