I am a bit confused about what the denotation=street tag is supposed to mean when applied to trees — specifically, how is it different from denotation=avenue? Both values are very popular according to taginfo, but only the latter is properly documented.
I am assuming there must be some subtle difference, and it would be nice to have it documented on the wiki.
Well, “avenue” can describe a kind of road which by design is lined by trees so you may see this as the subtle difference to a normal street, which may be lined by some trees here and there but can also exist without any. I understand avenue as a kind of representative road in most cases, but this is just the theory.
What I am not sure about is if the tags have really been used considerinig this difference or if denotation=street may also have been used in lack of knowing the tag denotation=avenue here and there. Also I am not sure if it really makes sense to have a special tag to assign trees to an avenue exclusively. Traffic ways change fast these days and what is an avenue today maybe a expressway tomorrow.
For reference:
What are those links reference for? In case you’re wondering that I might be planing to change all denotation=street into denotation=avenue (or vice versa) as a result of this discussion, rest assured that I have no such intention. In the edits you linked to I merely fixed obvious typos which I encountered while attempting to figure out the meaning of these tags. (I did check each value manually.)
Thanks — I did wonder if indeed the designation “avenue” was discouraging people to use that tag given the association of the name to major roads, and thus led to the prevalence of the street value as an alternative, despite the fact that the definition (at least according to Wikipedia) appears to be generic enough to encompass any type of street. The wiki page certainly describes the tag as usable in such a broad way.
Do you think it might be worth explicitly documenting the street value and describing it as an alternative for “unassuming”, regular streets as opposed to large, landmark-type roads? Or would that introduce a nuance in definition that would be hard to tease apart, especially as conditions change as you refer?
Yes, that is what I believe. The only real differende may be seen in the fact, that an “avenue” originally meant a road or way definitely lined by trees on both sides, although today lots of roads without a single tree on either side carry “avenue” in their name. As such denotation=street could be used to make clear that the so tagged tree is standing at the side of a road which is not completely “lined” with trees but merely shows some trees or short tree rows here and there.
The reasons why I would not support 2 different tags for roadside trees:
denotation=street by definition) alongside a road bearing “avenue” in its name would result in some kind of paradoxic tagging (and to some endless discussions for sure).I would favour the deprecation of either “avenue” or “street” instead.
It’s a reference to a very large, not discussed mechanical edit. See also: What's the problem with mechanical edits? - OpenStreetMap Wiki
and Automated Edits code of conduct - OpenStreetMap Wiki
How do you know, for example, that the value streetbulletin_board is a roadside tree and not a value in the advertising tag?
I also find parkcarnes_mega questionable, since these trees are on an alley and not in a park. Why did you choose park here instead of avenue?
“Parkcarnés” sounds like a parking entry card in Spanish.
denotation=none may not be a documented value, but it is also not classified as deprecated. What about “Any tags you like” here? So why not use the key?
Fair points; thanks for clarifying. For what it’s worth, it was not a simple find/replace operation; I did my best to not touch any values where I had doubts, and even looked at the history of some nodes I was unsure about, to check whether they might have been mangled in edits after the original (presumably correct) value was added. I merely was trying to help the editors complete the edit that the values appeared to suggest was their initial intent (I didn’t attempt to correct valid values to others I considered more appropriate, e.g. park → avenue as you suggest). Btw, “Carnes Mega” is the name of a butcher on the other side of that road.
As for denotation=none, I definitely agree I was too hasty in removing it. I would totally support reverting that edit. (update: I’ve done it.)
Interesting — so in your opinion we should ideally not use any of the options? I personally prefer the roadside-ness of trees being explicitly indicated (whichever the tag we use to do so), especially because otherwise it’s hard to obtain statistics about which streets are tree-lined without doing a bunch of geographic data processing. I just feel it’s confusing to have two nearly-identical values for what is essentially the same thing. (Though perhaps others might chime in to indicate a nuance that’s escaping us both.)
I do not have any objection against these denotation tags, but I am not using them myself. My personal opinion is they do not add much value but others will surely feel they do so. In view of using 2 different tags for street side trees my vote is a clear “no” but I am sure, others will vote “yes”. This is OSM 
.
Oh dear, here we go again 
My recollection is that the whole idea of denotation arose because the original definition was “Lone or significant trees”. People later started mapping every tree, and some people were upset that they couldn’t tell which ones were significant any more. That property got added about a dozen years ago as denotation (there was a lot of argument and at least one mass edit, if my memory is correct).
There are clearly a bunch of partially overlapping concepts in use in taginfo, but that doesn’t mean that tagfiddling between those values makes sense, because the categories only partially overlap. Having different tags used for similar concepts does not cause problems for data consumers (unlike having the same tag tag used for different concepts, which does).
It’s not quite “write only data”. because a few projects other than editors do use it, but the values are certainly not widely displayed.
Yes, and exactly that is what I use this key for, to mark trees either as “landmark” which can be useful for orientation or as “natural_monument” which has a well defined meaning at least here in Germany.
I don’t mind all the others values but if two values which are difficult to distinguish (leading to a mixup of tags usually) are developing parallel I believe it is better to deprecate one and focus on the other one. Nevertheless this is just my personal opinion, so no need to worry about that …
how does this relate to trees?
There is also denotation=urban for generic urban trees, I have never used “street” as denotation value, but given that it has no documented meaning it is not likely that it is consistently used
I have explained that in post #6 and also made reference to denotation=urban in the same post already.