Proposal talk:Tree rows

How about...

Just using natural=tree? Used on a node, it's clearly one tree, used on a way, it's unambiguously a line of trees, isn't it? Also, since someone is bound to ask, how do you specify the spacing of trees? Stevage 05:21, 23 February 2010 (UTC)

How would you interpret closed ways tagged with natural=tree then? Outline of a single tree? Circular line of trees? Area covered with trees? All three would be possible interpretations.

How would you interpret closed ways or single nodes tagged with natural=tree_row then? This is exactly the same situation, you just can't because someone used the tag in a forbidden style. Moreover, as natural=tree is defined for a node and natural=tree_row for a way, but none of them are defined for closed ways, you don't gain anything in splitting them in two separate parts instead of using just a single one. --Scai 15:38, 26 February 2011 (UTC)

The second part of my original answer (the one below that you decided to cut off) explains why: Because people will accidentally add the "tree row" tag to nodes. This happens all the time with highway=* or building=yes tags. If the "tree row" tag was the same thing as the "tree" tag, then that situation could be intentional and would not be clearly identifiable as an error. Oh, and by the way, I would consider it perfectly reasonable to interpret natural=tree_row on a closed way as a circular line of trees. --Tordanik 19:58, 26 February 2011 (UTC)

I did not want to cut your answer off, there were two separate paragraphs both without a signature. Of course people might add "tree row" to nodes and they might add "tree" to ways. But I guess it is most likely that a node tagged as "tree row" is a single tree and a way tagged as "tree" is a tree row. Hence, both cases could just easily be tagged as "tree" without actually introducing an error, opposed to the way this proposal suggests. By the way, highway can also be used on nodes for some specific values and even building=yes on a node is quite unambiguous to me, it is almost the same as shop=yes as shops are almost always buildings except for a few special cases. Also, when introducing a new tag you always introduce new ambiguities if the tag is limited to a certain element type. But actually I just wanted to point out that I don't like this proposal very much in its current state. I perfectly understand different opinions here, and that's precisely the problem of this proposal :). --Scai 23:50, 26 February 2011 (UTC)

Outline of a single tree? -- No, because a single tree is too small object to be represented by anything larger than a node. -- Circular line of trees? -- Yes, because it is the only relevant case. -- Area covered with trees? -- No, because areas are tagged with "landuse=forest" or "natural=wood". --Surly 11:22, 28 February 2011 (UTC)

The outline of a single tree at ground level can be 15-20 meters wide, when it has massive branches leaning down. That's surely big enough to be a way. Alv 11:46, 28 February 2011 (UTC)

It's less ambiguous to use different tags and, generally, I don't mind a bit of redundancy: It's easier to spot errors that way. For example, it's still not uncommon to encounter mistakes where someone accidentally tags nodes from a way (or a neighbouring way) with way tags when trying to select a way by drawing a box with the mouse.

About spacing: I don't have a final solution for that. Maybe a generic spacing=Measure would be useful? I'd imagine it could be used on other features, such as bollards, too. --Tordanik 20:02, 23 February 2010 (UTC)

barrier=tree

There's some use of barrier=tree, admittedly only as nodes and not as ways. I thought tree rows were man_made/managed, I never would've guessed that a row of trees could be "natural", but maybe it happens. --goldfndr 09:50, 23 February 2010 (UTC)

About natural=*: I don't read "natural" as "untouched nature", and I don't think that uses of natural=* are generally based on that reading. For example, I expect that many natural=trees have been planted or managed by humans.

I think that natural=* should be read as "geographic feature", not as physical entity. Most natural values are indeed geographical features (e.g. bay, beach, cliff, peak, cave_entrance) and the rest would be fine to be placed in landcover=* and landuse=*. --Dieterdreist 16:04, 25 February 2011 (UTC)

I don't usually think of tree rows as a "barrier", and most of them probably aren't intended to be one. It would be an acceptable solution, though.

Basically, I suggest that tree rows should use the same key as individual trees, and currently that's commonly "natural". --Tordanik 19:33, 23 February 2010 (UTC)

There are real life examples of every item in natural=* that were created without human intervention. I request an example of a tree row that occurred without human intervention. Alternatively, if I'm mistaken about an item in natural=* that does not occur naturally (e.g. all screes are man-made), please point it out. --goldfndr 12:49, 4 March 2010 (UTC)

No, tree rows normally don't occur without human intervention. They are still living organisms, though, which is why I would consider them "natural" rather than "man made". It certainly would be weird if a different key was used depending on whether a tree row was tagged as a whole or as individual trees. --Tordanik 20:47, 11 March 2010 (UTC)

I'm confused. Why do you say they "normally" don't occur without human intervention. I still await an example, whether normal, abnormal, or otherwise. If you are unable to provide an example of a tree row that was created without human intervention then I will accept your retraction. Also, why would it be weird if a man-made change to items was tagged with a different key than something that occurs naturally? man_made=cutline and leisure=garden seem reasonable. BTW, thanks for accepting that everything currently in "natural" has precedent as "untouched nature". --goldfndr 16:05, 14 March 2010 (UTC)

There is natural tree rows along rivers and streams. "living organism" is not a criterion for natural=*, most of the features there are indeed to be considered "dead materia" (IMHO natural is about geographical features, see above). --Dieterdreist 16:08, 25 February 2011 (UTC)

If tree rows are an important part of landscape they will be protected by law (Nature Conservation Act). I'm also think they are a bit more nature than man made.--Falcius 17:37, 14 March 2010 (UTC)

Species / Type

Weren't there also some proposals about species / type of trees? At least I remember some discussions about this. I would like to see cross-reference or addition to this proposal (subtags), but could not find anything on the natural=tree page either. I found this one on a tree:

1. species: Betula
2. species:de: Birke
3. species:en: Birch
4. type: broad_leafed

The keys type and species are mentioned on Tag:natural=tree, but it haven't found a list or description of the values anywhere. I'm not knowledgeable enough myself when it comes to tree species, but it would be great if someone could come up with a definition. --Tordanik 17:30, 26 February 2010 (UTC)

Wikipedia:Category:Lists of trees would be a good start. Just looking at Oak is a bit overwhelming. --goldfndr 12:49, 4 March 2010 (UTC)

Tree rows in addition to the highway-tag

I think there is a difference between a normal row of trees an row of trees alongside a road. Trees alongside a road are a special kind of lanscape. In this case I would prefer to use tree_row=* as a subtag in addition to the highway=* tag (tree_row=left, tree_row=right, tree_row=both or tree_row=forward, tree_row=backward, tree_row=both). --Falcius 19:28, 11 March 2010 (UTC)

If you consider a row of trees part of a road, then - imo - it should ultimately be expressed using whatever method of describing "lanes" we agree on. left/right/both isn't an ideal solution: For example, there are roads with tree rows between a footway and the car lanes, which cannot be expressed by a simple left/right tag.

Of course ways cannot properly describe this either, but we will still need those even when we have a proper lane model, as not all tree rows are related to roads. tree_row=left/right, on the other hand, would only be a temporary solution. --Tordanik 20:55, 11 March 2010 (UTC)

Why you can't describe a row of trees between road and footway with tree_row=left/right? You have to tag footway or road with it. But I admit that it brings risk of redundancy if someone does not notice that the information is already taged to one of the lanes (road or footway).--Falcius 21:26, 11 March 2010 (UTC)

Windbreaks with several tree rows

See full size

As I understand this proposal only for single tree rows. But very often windbreaks between fields have more then 1 tree row. Also when you're mapping by low-resolution aerial images (see example at right) you don't know how tree rows in some windbreak. Therefore I propose 2 solutions:

• Approve tag which contain information about number of single rows. (In this case 'tree row' is not very good, IMHo. Better 'tree line'. But I'm not sure because my English is not good.)

or

• Propose another tag for windbreaks (not natural=tree_row). (In this case similar objects like tree line between fields and tree line along alley will be tagging with absolutely different tags.)

Lzhl 00:55, 15 January 2011 (UTC).

Couldn't you just add a single row first (possibly with fixme=*) and create multiple natural=tree_row ways later? --Tordanik 19:13, 16 January 2011 (UTC)

When will the vote begin ?

I realize that the RFC started one year ago and there is still no vote for this proposal. I live in a land where tree rows are very common and I really need to map them. --Zewan 13:57, 22 February 2011 (UTC)

You are right, it's time for the vote. I'll wait until Friday in case there are last-minute objections, and will then send out the vote request to the tagging mailing list. --Tordanik 15:16, 22 February 2011 (UTC)

Optional tag for average space between the trees

I think such a tag would be useful. Such a natural=treet_row way can then be rendered as a row of single trees, without the work of mapping every of them, I see this in some kind related to the address interpolation ways. So there should be a tag for the everage distance between the free trunks. --Fabi2 23:43, 24 February 2011 (UTC)

This is a good suggestion and I'll likely include it in a follow-up proposal, if no one beats me to it.

However, I think that, in many situations, it would be easier for a mapper to count the trees than to measure the distance between them, as counting requires no additional tools. If the number of trees is known, then the average distance is known, too. So something like Key:step_count for trees would work. Or would we want to allow both alternatives (count and/or spacings), to allow for mappers' preferences even though they are essentially equivalent? --Tordanik 00:01, 25 February 2011 (UTC)

I think in general it is easier to count the trees, but this may not always possible e.g. when doing drive-by-mapping or on longer alleys (maybe you leave before it's end or must be contentrate on driving). So it would be useful to have both tags, but recommend the use of the tree count if possible. --Fabi2 00:51, 25 February 2011 (UTC)

Tree rows vs. individual trees or polygons

[I'm replying to statements in the voting section that suggest to map trees in tree rows either individually or as narrow polygons.]

• A polygon does not adequately express the linear character of a tree row. There would be no easy method to reconstruct the placement of the individual trees if desired. With a way and a tag for either the number of trees or the distance between them (which are, of course, reasonable additions to tree row mapping), this is easily possible.
• Mapping individual trees, on the other hand, allows easy access to the individual tree positions. However, it's more effort and has no real advantage unless the tree positions are irregular or the trees need individual descriptive tags for some reason. Even then, connecting the trees with a way allows renderers to generalize the tree row into a single entity, rather than showing each tree separately (which wouldn't necessarily be appropriate detail for all maps). --Tordanik 16:33, 25 February 2011 (UTC)

Landuse=forest for tree rows?? Please show me...

how to map ~100-200 "forests" for these tree rows (close to Bischofsheim/ Bayrische Rhön)?? If you have *one* tree row this might be fine, but THIS (Tree Rows Sat Picture) is straight idiotic... ;-) --Taunide 12:04, 1 March 2011 (UTC)