-
Notifications
You must be signed in to change notification settings - Fork 823
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
Comments
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:
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. |
sent from a phone
On 13 Jan 2017, at 20:19, Christoph Hormann ***@***.***> wrote:
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.
IMHO there will indeed be not so much difference because of people abusing landuse=forest or natural=wood for any spot with more than 1-2 trees, because it's the only way to map groups of trees that is supported by this style (needless to point out that this is tagging for the renderer in its purest form), although the word "forest" implies more than just some trees (think soil, microclimate, etc.). Landuse=grass is another glorious fail, whatever definitions are written in the wiki, it just doesn't make sense on a semantic level, grass is not a use, and the originally defined scope (grass as part of highways) would better be expressed by landuse=highway and a landcover tag.
|
Objects with this key were last edited by 1 080 different users. = 216 full hands. |
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.
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.) |
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. |
@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. |
I liked the more comprehensive proposal by Rudolf more. It's also based on scientific classifications categories. |
@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). |
Please leave the tagging discussion out of this. |
👍 |
sent from a phone
On 14 Jan 2017, at 14:47, Paul Norman ***@***.***> wrote:
Especially for trees the different opinions on the meaning of common tags seem to already cover what landcover=trees is meant to indicate.
I think we can say that we don't have any clear idea how to tag the difference of a forest and a group of trees. We also can't tell whether there are actually trees currently or if the whole forest has been cut down recently and is currently being reforested. At most our "forests" can be either some trees or an area with forest landuse. Personally I would be interested to change this and get to clearer definitions when to apply which tags, and I feel that I'm not alone here, but as long as being more accurate (by omitting the landuse=forest tag) will lead to vanishing the objects from the main map it is unlikely that more than a handful of hardcore mappers will do it
|
I feel this is result of taking this purpose to the extreme:
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. |
So far i don't think anyone has suggested anything extreme in this thread. |
Do you consider any fragmentation favorable at all? |
I think i made my view quite clear:
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. |
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)? |
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. |
A couple of considerations here:
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. |
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? |
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. |
@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 |
@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. |
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? |
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. |
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: |
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
|
First of all, thanks for confirming my suspicion that On topic of deprecation - see https://wiki.openstreetmap.org/wiki/Proposed_features/landcover with
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 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. |
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.
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 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.
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.
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. |
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. |
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. |
I'm happy to chime in from the iD perspective.. 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 I wrote:
So it's 2019 and the 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 |
Again, landcover tagging is growing despite not being rendered by OSM Carto
and not being supported bij Id.
Also, I don't think your adding your own negative arguments to text of the
original proposal helps. Should we all edit our arguments into that?
I would rather create a new proposal documenting the current use of the
landcover tag without argumentation, just basic info how it's used. No big
schemes or plans.
Fr gr Peter Elderson
Op wo 6 mrt. 2019 om 17:17 schreef Bryan Housel <[email protected]>:
… Can you link me to such requests in JOSM, Vespucci and iD
<openstreetmap/iD#4272>? 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
<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!)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2548 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AkrTynyvUR1CSUnGOqqW_rFGcSrRoRPCks5vT-oagaJpZM4LjKpS>
.
|
I'm temporarily locking this because of the unproductive heated discussion and code of conduct violations. |
I've unlocked this. Please remember the code of conduct, in particular,
|
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:
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. |
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. 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. |
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. |
@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. |
"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. |
I see, only A How this should be rendered? As industrial area or as grass? It is both. |
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. |
I have written a description of current usage of landcover tags. I think it
covers all the usage so far, including the Paraguay mapping project.
It is not meant to be prescriptive, only descriptive. If this description
was broadly accepted, would that help to decide about rendering? Of course
the same question would be put to mappers and editors.
…---
Key:landcoverTags: landcover=trees & landcover=grassUsage: The landcover
key is used to describe what covers the land. Currently, the most used
values are trees and grass. What is tagged: A landcover tag is used to map
a physical area of (currently) grass or trees in two cases:
1. when the human use of the land is not known, e.g. an area of grass
not visibly dedicated to any purpose, or
2. when landcover differs from the implied landcover of the underlying
landuse, eg a grass clearing within a forest, or patches of trees within an
industrial, residential or military area.
In this context, “underlying landuse” includes other tags which represent
types of landuse such as leisure=park.
Combination of landuse and landcover: Area features can have both landuse
and landcover tags. The landuse indicates what the land is used for; the
landcover indicates what it is covered with.
Where landuse implies a landcover and the above two use cases are not
applicable or foreseen, adding landcover is redundant.
----
Fr gr Peter Elderson
Op ma 11 mrt. 2019 om 09:02 schreef Marián Kyral <[email protected]>:
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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2548 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AkrTyoc6Rcbs7LcOgPLbg124HsLsZccbks5vVg2egaJpZM4LjKpS>
.
|
"Combination of landuse and landcover: Area features can have both landuse 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. |
Apart from the possibilites for the future? Do you agree with this
description of current usage?
Fr gr Peter Elderson
Op ma 11 mrt. 2019 om 10:40 schreef Adamant36 <[email protected]>:
… "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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2548 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AkrTygi33ZGJacK9wpFFYfkROTp89Lcjks5vViSTgaJpZM4LjKpS>
.
|
Just want to weigh in (my opinion, no facts presented here):
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 |
Some facts about the use of landcover in Paraguay and Argentina. 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. |
I think the Paraguay and Argentina project fits nicely to the description I
gave.
Fr gr Peter Elderson
Op ma 11 mrt. 2019 om 13:20 schreef Carlos Brys <[email protected]>:
… 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 logging. 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 project was discussed to use the landcover
label and not launduse to map urban trees.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2548 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AkrTyglxtQ3vapk9vAPQwPZ5FpwNrP99ks5vVkoEgaJpZM4LjKpS>
.
|
There's a worldwide effort on MapRoulette to clean up duplicate For example, cemetery forests are pretty common in Asia. Currently, there is no good way to tag them, but There is a proposal for
Just imagining how I'd use |
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. |
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.
The text was updated successfully, but these errors were encountered: