Proposal talk:Tree row

From OpenStreetMap Wiki
Jump to navigation Jump to search

Comments

  • Looks reasonable on the first glance. Thinking about the proposal, I'd rather introduce an alley=yes tag for highways and in addition extend natural=wood to ways. --ThomasKlosa 00:29, 6 January 2008 (UTC)
natural=wood is ONLY for primeval forest (Urwald). -Markus 06:56, 30 July 2008 (UTC)
  • I don't think we should use landuse=... tags for any linear features. If the marking of tree rows is wanted, then I think the proposed feature borders=... is a better way, but that proposal needs some cleanup. There are also some proposals under natural=... that are like this where it would fit better. --Cartinus 11:39, 9 January 2008 (UTC)
  • And what about that single, 700 years old oak in my backyard? I like to map this one as well. Should also apply to nodes i think. Greetz, GercoKees 12:27, 9 January 2008 (UTC)
    • if it's a significant tree in professional maps this tree would be marked. --Cbm 20:43, 11 January 2008 (UTC)
      • natural=tree in osm. Ben 20:06, 19 January 2009 (UTC)
  • The landuse would depend on what type of land there is below the trees, is it grass, is it concrete with just gaps for the trees? Also it might be worth considering mapping trees individually in some cases. If there are only 20 trees, but big, old, massive once, they could be mapped individually. --Ckruetze 12:49, 9 January 2008 (UTC)
  • Alley - for each road-segment we use alley=left/right/both and tree=numbers?
    Tree - for a single tree we use tree=yes?
    Group of trees - tree=numbers?
    Fence - an array will get tree=yes?
    Or with displacement: one tree is a node, trees on one side of the road is a way, alley is two ways tree=yes/numbers?
    --Markus 06:33, 30 July 2008 (UTC)
    • tree_lined - for roads marked by trees also for other lines of trees, such as near railways, rivers...
      The tag "alley" is a mistranslation from the german "Allee". ---Robert 13 November 2009
  • A typical example street in Germany with cycle lanes and footway: The tree rows could be between the lanes for cars and bicycles, or between the bicycle lanes and footway, or at the border of the street beside the footways, or a combination of this. An additional key may take sense.
    Tree Row Position - for showing the position of the tree rows at the road - tree_row_pos=car-bicycle/bicycle-foot/border?
    For a tree row between car lane and a combined foot-&cycleway like in Germany we use to - tree_row_pos=car-bicycle?
    If there are reasons to differ between the both sides of the street we use:
    Following the direction of the street - tree_row_pos_straight=car-bicycle/bicycle-foot/border?
    For the opposite direction of the street - tree_row_pos_opposite=car-bicycle/bicycle-foot/border?
    --René Falk 10:38, 28 August 2008 (UTC)
  • I say this is best integrated in the barrier=* proposal. Circeus 20:41, 28 September 2008 (UTC)
  • I agree. The only time I would tag a group of trees (excluding natural-wood), would be when they are all that forms the barrier. I would still stick natural tree on the nodes for the trees along that barrier (if I have the data), unless it is a solid wall of pines. If that's not so then there individual and are just natural=tree. A tree on the side of the road, does in some way need to be attached to the roads way. left:natural=tree right:natural=tree seems obvious, since it's still just a tree. Can we just try and keep it as simple as possible...it's fine for adding 1 or 2 which seems to be most users use of this tag, but in there hundreds it needs to take minimal time possible, cause there's a lot of trees out there. Also, consider other barrier= tags which are on the side of roads. Gates/footgates etc. should really be attached to the road if they are along side it, and not on a way, and consistency in the way tags would be super (and noval!).Ben 20:06, 19 January 2009 (UTC)
  • I'm opposed to integrating this with barrier=*. Frequently lines of trees (avenues) do not affect routes, one can pass through the trees in any direction. Therefore they are not barriers, although barriers can be made of a line of trees in which case they are a special case of barrier=hedge). Such features are extremely common in parks and countryside in Britain, but also elsewhere in Europe (Poplar lined roads in France for instance). Equally, I recognise groups of trees which are not a wood or forest (usually in a parkland context) but which it would be nice to map. My feeling is that the tag should be natural=tree and allow nodes (single tree or defined number of trees, default single tree), ways (for lines of trees) and areas (for discrete groups of trees). Areas could be used to cover concepts like Orchards (see landuse=orchard discussion), and Dehesa or other wood pasture). For trees lining a road or other highway then something like René Falk's proposal is sensible. Use of a tag alley=yes is going to cause confusion, alley to english users does not mean "die Allee" as in Unter den Linden. I would suggest avenue=yes or the even clearer line_of_trees=yes. Last comment is, that, whilst the ability to more precisely define a tree is a nice to have: species=oak is not a good illustration as that gives me a choice of several hundred. I'd suggest something a bit more general in naming the tag to allow for a degree of biological naivety by mappers. SK53 21:02, 25 January 2009 (UTC)
  • The permeability of something doesn't make it a barrier or not. Hedgerows are commonly permeable. By default barrier=trees could be, where as by default barrier:hedge would not. The word "barrier" shouldn't be used literally..the need to have perfect word choice in OSM is just such a minor issue, which consumes every debate. "Barrier" in this case is just anything marking a perimeter. Also "=yes" tags are terrible when there isn't variations of the key...please...no more! Lets use the 'Key' for what it's there for. Ben 12:16, 26 January 2009 (UTC)
  • I'm quite happy with the notion that the OSM usage might not accord with a dictionary definition nor follow excessively pedantic rules. However, before writing my earlier comment I did read around the wiki, and rather assumed the following on barrier=* was a consensus: "Physical barriers to all types of "beings" such as vehicles, humans or animals. Not only impediments to a given "way", but also to free movements such as a walk (not following a path) in the countryside.". Either way my need is to identify features which are not perimeters or barriers, so your interpretation of barrier still does not fit. Interestingly the British Forestry Commission have similar definitions to mine regarding groups of trees: to qualify as a wood, a group of trees must be greater than 50 m in all dimensions. They also recognise (and define) linear features etc. Take the point about yes. In fact if my suggestion is followed is entirely redundant: a way tagged {{Tag|natural|tree} is obviously an 'alley' or avenue. Appreciate this does not remove an issue of how to tag tree-lined roads or barriers consisting of trees. Although in the latter case tagging the way with natural=tree as well as barrier=hedge might be acceptable. SK53 20:45, 26 January 2009 (UTC)
  • I see your point, and assuming that the rules were fixed solid, then that would prevent anything permeable being added. Although hedgerows frequently can be past through on foot (squeezed through anyway), the barrier tags for features such as gates and stiles are also possible to pass over. So assuming that we take barrier to mean anything that is impassable, then that leaves us with the concern that you have, and where do the passable barriers go. There were other Key suggestions to tag the same things, which weren't specific to permeability. The voting, as per usual, comes down to word choice though so this was missed. I see no reason why not to change something within a wiki. I have been adding permeable=yes to the (now changed to) barrier= tags for a while, and I treat =no as default so don't state it then. This allows all boundary/borders/barriers to be under 1 key, regardless of passability. A line of trees still in my mind is one of the above, although the word choice 'barrier' is then the issue. A line of trees may of course be impassable and therefore suddenly agree to the prerequisites and barrier=trees would be OK. Changing the key and value when trees become spaced though sounds like over complication, for a slight variation. For your point on woods: Are 'woods' that are less than 50m in diameter in 1 direction a cops, or are you saying this class's as a line of trees? If the latter then that is very strange. OSM's use of the word 'wood' seems to be used regardless of size, but just where a group of trees is anything but literally a line. I have pondered many times though when mapping village boundary 'hedges/woods' which seem to be commonly 10-20m thick, if they should be woods or not. The random shapes usually leads to making it an area though and therefore a wood. Ben 18:31, 27 January 2009 (UTC)
  • I'm trying to play with some examples (I may render them as ski chairlifts in the first instance!), but appreciate the comments. I'm also troubled over having different tags for effectively the same thing (trees by roads, trees as hedges/barriers, and free standing rows of trees). However, this I think is a price paid for overloading concepts (and its cheap compared with trying to get a normalised data model for the same thing). I thought I'd summarise the Forestry Commission's tree/woods scheme as they have a huge amount of data recorded under it: Small Woods are between 0.1 and 2 ha; Group of trees is 2 or more trees in an area under 0.1 ha, Individual Tree is a tree at least 2 m tall, with its crown NOT in contact with another tree (Boundary Trees are on boundaries, Middle Trees are elsewhere, e.g., in middle of field), Linear Feature is at least 25 m long and 4 times longer than broad, up to 50 m wide or as narrow as a single tree (two types, Broad >16m wide and Narrow <16 m wide). HTH. SK53 20:24, 29 January 2009 (UTC)
  • I agree with SK53. Tree lines do exist and are notable enough to be mapped, but it would make it simpler to use natural=tree as a way, which would have the desired result. The use of the world alley is utterly confusing and shows why there is a convention for using British English for tagging, so we all know which dictionary to refer to?. I also agree this should not be integrated with barrier, which is currently for linear features that "stop movement".(Its interesting to see a definition of of when a group of trees become woodland. I've previously have had a look a this to try and find a definition that has some global meaning. Nations with smaller area of woodland tend be more inclusive when defining woodland, but even in individual countries there are different definitions. From the research I've done the reasonable definition for OSM (which shouldnt clash with various countries definitions) would be, Minimum Area = 0.1 ha, Minimum Crown Cover = 10%, Minimum Average Width = 10m. Sadly mapping of woodland is a bit of a farce in OSM due to the current definitions of Forest & Wood)--Jamicu 19:25, 1 March 2009 (UTC)
  • Somewhat later, an example. This is a barely modified osmarender rule for chairlift with a crude tree replacing the chair symbol. This shows park land with a number of avenues of trees. Ideally the lines should be replaced by smaller symbols spaced at a conventional interval (say 50 px), but this is beyond by current understanding of rendering rules. The golf course area has many small stands of trees which would fit with allowing natural=tree for areas. All this in an area of around 1-2 km2.
Lines of Trees Example
  • A line of trees is almost always represented as a dotted line in most maps and I think OSM renderings can best follow that. A line of tree icons will clutter it too much. --Eimai 15:46, 15 May 2009 (UTC)

This is a lane

Like a footway, a cycleway or a driving lane a "line of trees" is a lane. It's width and if it can be passed (bushes or grass between trees) is a valuable information for blind persons. Landuse is not sufficiant for that usecase. --Lulu-Ann 07:03, 16 May 2009 (UTC)

I think the trees in this case are to bee seen as a feature of the road; that's why there are special words for this ensemble. For dams and fences for example I would also prefer separate lines - not so for the trees of an alley. I think that's also the way this feature is "implemented" with the official maps I'm used to. (see below) This way it's also clear that with this road there may be some special dangers to think of - like the height of a lorry conflicting with the tree's branches above the road, lighting issues, slippy surface from wet or rotting leaves, ...--Ido 00:18, 31 October 2009 (UTC)

Contra

  • I oppose this. Imo it's better to use in continuation with natural=tree on at a node the same tag at a way for a line (or row) of trees. Voila - there we are. No need of a new tag. Beside, we need something to stick that value to a highway so one hasn't to draw an extra line for the trees. I think about natural:tree=left/right/both -- Malenki 13:42, 19 August 2009

(UTC)

  • I like this suggestion: it accords with my earlier comment above, but shows how natural=tree can be used in association with highways to represent tree lined roads or tracks. I would suggest furthermore that this could be extended to other ways as appropriate: streams and rivers are the most obvious (perhaps because I've seen them on French IGN map legends). -- SK53 15:35, 19 August 2009 (UTC)
  • A bit unclear: Do you like the suggestion of the OP (the proposal itself) or my suggestion of enhancing natural=tree?
To this suggestion of mine I'd like to use barrier:*(hedge/wall/guardrail/hwatever):right/left/both at highway tags to describe the barriers accompagnying them. I guess I'll have to propose a little bit on my own. -- Malenki 19:13, 19 August 2009 (UTC)
I prefer your suggestion over the OP (long discussion above). I prefer solutions which use natural=tree. I like your suggestion for using pre-existing tags to describe aspects of the highway corridor (although these could be separately micro-mapped). It retains consistency, reduces tag proliferation and seems to meet the range of requirements described on this page. SK53 19:29, 19 August 2009 (UTC)
  • Thanks for making that clear. for micro-mapping separate tree-lines I partially agree. at some places this will be necessary (p.e. tree rows between fields) but in general it would be a waste of time to draw extra ways for street accompagnying rows of trees. In grmany alone there are several thousand kilometres of them. Besides, would you also like to draw another line for barrier:guardrail between street and trees ? ;)
PS: after adding all that stuff (p.e.: natural:tree=left, barrier:railguard=left, footway=both, cycleway=both) a scheme to put these tags into the right order (after the highway the cycleway, then the footway, then the barrier:guardrail, then the trees) is needed. Somewhere at the wiki I found a suggestion how to handle that, but atm I don't find it anymore :( Proposed_features/lane_and_lane_group (tx to Lulu-Ann :) ) -- Malenki 19:48, 19 August 2009 (UTC)
A line of trees is a kind of lane. It is a valuable information for blind persons. See OSM for the blind. Left/Right is not enough, we need to be able to stack different kinds of lanes next to each other, like fence, footway, grass, cycleway, tree line, bus lane, 2 car lanes and mirrored or not on the other side of the road... --Lulu-Ann 21:50, 19 August 2009 (UTC)

rendering of streets with tree rows

sample from an official german topographical map showing roads with tree rows

Official german topographical maps show streets with tree rows - also which sides of the road are tree-lined. They usually render small (brown) circles beside the road. Here's a small sample of what that looks like.--Ido 23:56, 30 October 2009 (UTC)

Specific examples

Hi,

With this shot

residential highway with one tree row in right sidewalk and no tree row in the left sidewalk.

I should make a line for marking the sidewalk and then put tree row. But does this "overwrite" the sidewalk tag? Proposed_features/Sidewalk So how can I combine this two tags?