Talk:Tag:natural=tree
Species
JOSM uses name:biological=quercus robur. I haven't found any endorsement yet though. Ipofanes 13:29, 27 October 2008 (UTC)
Tree Images
Definatly way way too large!. Something this size would require nothing to be within half a mile of it, to work on a map. Also, I think it should be from a birds eye perspective. Having them on there sides like this makes looking at a map a rather a wierd experience. Much like the gates in mapnik currently.
I use the image below in kosmos, as in example. It's 50% this size at z17, 25% z16, 10% z15, and 5% z14. A pine alternative would be easily created. Ben 20:17, 19 January 2009 (UTC)
Rendering of alley=left/right/both
The actual way that mapnik renders alley=left/right/both is, it simply ignores it. Is that wanted?--Shmias 16:27, 6 May 2009 (UTC)
- Afaik alley isn't an approved tag at all. Discussions around the wiki still try to get a consensus how to map trees beside streets -- Malenki 19:17, 19 August 2009 (UTC)
Size
Would it be useful to give the approximate distance across the whole of a tree? That is, the width as viewed from above. This could be used to plot circles rather than dots on maps, and give some indication of the amount of tree cover. Daveemtb 15:06, 6 October 2009 (UTC)
- Gardeners call it the spread, but it its usage is abhorred by biologists, because it is more or less biologically meaningless. If you want to use suggest tree:spread=*or tree_spread=*. SK53 19:07, 2 July 2010 (UTC)
- Arborists call what you are talking about Crown Width
- Um; it is usually called the spread or less commonly, crown spread, in the UK. The word 'width' generally refers to the lower of two measures of an object - i.e., it should only be used when there is an implied or explicit length to go with it. Indigomc 22:33, 5 March 2011 (UTC)
Is it worth revisiting trees as areas again now that we are modeling towns in much more detail and often have access to very detailed aerial photography? I have plotted a load of large single oak trees in a park and they show as weedy little dots even though I can see from the imagery that they are substantial things in places nearly touch each other. The trunk would be assumed to be at the centre of gravity - for a very lopsided tree we could devise some other modeling system. Whatever biologists do we are about mapping what we see and what I see is a large volume or area not a tree trunk. PeterIto 07:22, 5 January 2012 (UTC)
Species
species=oak is incorrect. There are over 400 species under the genus oak !! [1] --Skyper 14:29, 9 November 2009 (UTC)
- It is not incorrect, it is inaccurate! --Skippern 14:11, 16 March 2010 (UTC)
- It is plain incorrect. Oak is a genus, not a species. Indigomc
- please introduces genus=* and seperate it from species=*. There is a huge difference !!--Skyper 10:55, 20 April 2010 (UTC)
- +1 --westfa 18:59, 30 June 2010 (UTC)
- +1, for this reason I use taxon=* which should allow Oak, Quercus etc., without providing precise details which may well be outside the interest/competence of many mappers. I think name, whether namespaced or not wrong. If I tag the Major Oak, I want to do something like name=Major Oak taxon=Quercus robur taxon:en=Pedunculate Oak. SK53 19:33, 30 June 2010 (UTC)
- I don't think it is a problem to have just species for tagging, as genus can be derived from this e.g. by using the wikipedia database. Who knows the exact species can put it and it will be sufficient, genus and the rest can be concluded. If someone adds a genus description into the species tag whilst beeing biologically inaccurate, it will still be useful, and someone else can complete it or not. If someones reads species from the db and gets a genus he will discover this himself without any need to specify that he actually got just a genus and therefore incomplete species. --Dieterdreist 10:51, 5 July 2010 (UTC)
- Then we should use genus=* and not species=*. If someone knows the species he/she can still use species=* in a correct way. Anyway we should think about using a db to get local names, genues and species. Otherwise we need to add 100 of tags to each tree.--Skyper 10:57, 8 July 2010 (UTC)
- This can be acomplished by using the wikipedia interlanguage links. therefore it is strongly recommended to simply use latin names. All local names can be derived from that. -- Dieterdreist 10:26, 5 September 2010 (BST)
- sorry, i didn't see this before my edits ... it's a wiki ;-) and it's really no problem having a genus tag (we use it on the german page too) -- Schusch 08:21, 11 September 2010 (BST)
- This can be acomplished by using the wikipedia interlanguage links. therefore it is strongly recommended to simply use latin names. All local names can be derived from that. -- Dieterdreist 10:26, 5 September 2010 (BST)
- Then we should use genus=* and not species=*. If someone knows the species he/she can still use species=* in a correct way. Anyway we should think about using a db to get local names, genues and species. Otherwise we need to add 100 of tags to each tree.--Skyper 10:57, 8 July 2010 (UTC)
- I don't think it is a problem to have just species for tagging, as genus can be derived from this e.g. by using the wikipedia database. Who knows the exact species can put it and it will be sufficient, genus and the rest can be concluded. If someone adds a genus description into the species tag whilst beeing biologically inaccurate, it will still be useful, and someone else can complete it or not. If someones reads species from the db and gets a genus he will discover this himself without any need to specify that he actually got just a genus and therefore incomplete species. --Dieterdreist 10:51, 5 July 2010 (UTC)
- It is plain incorrect. Oak is a genus, not a species. Indigomc
- Added in taxon= tag, I think any tag: species, genus or taxon would do, with enough tidying up of the data, it should be possible to get a sensible idea of what people are mapping either way. Personally, taxon makes sense to me. Taxonomists have been arguing for hundreds of years about the best way to define this so I doubt we will reach a consensus. There are some well established rules for dealing with taxonomic metadata called the Darwin Core http://rs.tdwg.org/dwc/terms/simple/index.htm These may help when thinking about the type of information to collect/tag Hawkeyes 19:27, 15 May 2010
× Hello, do we have rule about hybrids (https://en.wikipedia.org/wiki/Hybrid_name), Platanus × hispanica for exemple ? The hybrid name have this × (not an x, but x is way more convenient). What should we use ? --Defuneste (talk) 17:33, 24 February 2019 (UTC)
The name 'alley'
It seems to me that this is an inappropriate term here. In English, an alley is a type of road, has nothing to do with trees and will cause confusion. If the intention is to use the French or German terms (e.g. allee), then it would be better to use that spelling. If an English word is to be used, then the nearest equivalent is avenue, (though the word is now often used for roads without trees). Indigomc 08:20, 19 March 2010 (UTC)
Benefit for the blind
In city centers with few trees blind users with guidedogs need to know where the trees are, not only to avoid running into them (that works fine with the white cane), but also as a poi, because the dog needs a place to drop excrements. Read more on OSM for the blind. Lulu-Ann
Subtags to indicate the significance
These subtags were introduced to the main page, but are still in discussion:
| Tagging | Symbol | Description | Picture | Comments | Hints / Links |
|---|---|---|---|---|---|
| name=* |
The usual rules for names apply. This tag should not be used for a description of the species. |
why don't we simply use the definition from name=*: use it for named trees, not as a description. I don't see why we should limit this to historical and memorial names.Dieterdreist 20:50, 11 September 2010 (BST)
I have used it for tree tagging, useful for tree survey e.g. 0061, 0062, 0063, 0064,... So not event no historical but yes scientific and managerial interests. Until there is a tag that will adjust to this description and shows on the map best done this way. --Amunizp (talk) 11:57, 15 January 2018 (UTC) Amunizp, this is incorrect tagging for renderer and must not be used - https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer Mateusz Konieczny (talk) 04:05, 17 January 2018 (UTC) I have read the article, I think I did not explain correctly. The tag is an actual physical thing: a metal label put on the tree that actually give this tree a proper name. That metal Tag as a number and thus is labelled on the name. I will attempt to link to a picture to describe it. There is no other tree with that name in the woodland I am labelling. Please let me know if I understood this wrong. In this situation I would tag it as ref=*, but I would not consider tagging it as name as really wrong Mateusz Konieczny (talk) 09:46, 23 January 2018 (UTC)
|
|||
| ref:tree_tag=* | Shows the number label put physically on the tree. see link to a picture | ||||
| denotation=* | defines the context of the tree | ||||
| denotation=landmark |
|
why not landmark=*? | wikipedia:Landmark | ||
| denotation=natural_monument |
|
why not monument=*? | wikipedia:Natural monument | ||
| denotation=avenue |
Usually it is sufficient to mark the way with tree_lined=yes instead of mapping individual trees. |
in case of urban avenues: I'd suggest to use avenue and prioritize it over urban | wikipedia:Avenue | ||
| denotation=urban |
Trees found within settlements, e.g. in parks or spread through residential areas. For large or dense groups of trees it may be better to just map the surrounding polygon with landuse=forest |
||||
| denotation=cluster |
Generically marks trees that are not standing alone. This tag is a rough estimate placed by bot to distinguish unmarked trees which are close together and therefore are more likely to be urban trees or forests rather than landmarks. If known, this value should be replaced by one of the more precise descriptions above. |
automated edits are not necessary. I think this tag is useless because you can see this from the data and define your own limits. Not combineable with urban and avenue Dieterdreist 20:50, 11 September 2010 (BST) |
This list is incomplete. What about a few trees on a meadow? They might not be landmarks, are no clusters as they rather stand alone, ... --Scai 17:44, 21 September 2010 (BST)
- Map the meadow as a meadow, each tree as natural=tree. What other data do you want to enter about those trees? --Tordanik 19:06, 21 September 2010 (BST)
- Of course, that’s what I did and what others did, too. But "some" people want to have the denotation tag on every tree. Just take a look at any natural=tree and you'll see a denotation=cluster and a fixme on them that states to correct the denotation tag to any of the above. --Scai 21:12, 21 September 2010 (BST)
- So for example: I have collected a spreadsheet with name, coordinates, (maybe even level), and maybe even genus or the risk of it being fallen (yes/no) of all the trees in a small wood. Would it be possible to import that into OSM some how? Would it be permitted--Amunizp (talk) 12:54, 31 January 2017 (UTC)?
- Of course, that’s what I did and what others did, too. But "some" people want to have the denotation tag on every tree. Just take a look at any natural=tree and you'll see a denotation=cluster and a fixme on them that states to correct the denotation tag to any of the above. --Scai 21:12, 21 September 2010 (BST)
A missing denotation=* value would be one for trees that are not worthy of being called denotation=natural_monument, but are added just because they are rarely occuring trees. For example here in Finland most consider Larches notable trees just because of the species (usually even if planted by man). They're not inherently endangered, nor protected as such. The same goes for some other so called "noble" broad-leaved tree trees, i.e. trees that are common for example in central Europe, but flourish here only in small, especially suitable environments (most common ones being Maple, Oak, Elm, Hazel). These might well occur in a cluster, but with other trees mixed in between, or next to them, so denotation=cluster would be misleading. Alv 09:28, 15 July 2011 (BST)
Typo "broad_leafed"?
I would assume that the value should be broad_leaved, see e.g. wikipedia:Broad-leaved_tree, but I'm not a native speaker. Is this a typo or intentional? --Tordanik 03:34, 31 January 2011 (UTC)
- Broad-leafed is sometimes seen, but it is not correct, it should be broad-leaved. It is probably misapplied from the word 'leafed', which is correctly found with a different meaning, as in I leafed through the book. Indigomc 22:52, 19 February 2011 (UTC)
- Thanks. This leaves us with the question what we should do about it. Unfortunately, that value has been added to the data a few ten thousand times, for example by the tree import in Girona. Simply fix the wiki page and add a note about the fact that there are lots of misspelled tags in the database? Ask the tagging mailing list? --Tordanik 23:25, 19 February 2011 (UTC)
- Yes, I'd say to fix the wiki page. I did think about doing this last night, but thought I'd wait to see what other opinions were. Actually I would also look to change it wholesale in the data if such a thing is possible.
- However, having done some google searches, it seems that there is a still a lot of use of 'broad-leafed'; about 100000 returns, compared with about 500000 for 'broad-leaved'. It might therefore be said that it is an accepted alternative form. I would still say it is incorrect.
- Indigomc 11:50, 20 February 2011 (UTC)
- I've changed to broad_leaved - going to create a page for this soon as well as coniferus and palm and mixed etc and try to get a bit more guidance together. I'll add information about this discussion and change so any using the data will know to look for broad_leafed as well. Hawkeyes 13:12, 17 October 2011
- I perhaps shouldn't have changed this to broad_leaved or should it be broad-leaved(?) so quickly. There is wood=coniferous/deciduous/mixed/palm that is synonymous (partially) with type=conifer/broad_leafed/leaved. Also foliage= has been suggested. See wood= discussion page.
The usage of type=* for non-relation elements should be avoided. There is a proposal for new keys leaf_type and leaf_cycle. See Proposed features/leaftype. --Rudolf (talk) 16:05, 8 May 2014 (UTC)
Circumference and girth
The text recommends using the term 'circumference=?' to record the trunk diameter in meters. I see some problems with this.
- One, the term generally used in my experience is 'girth'. The word circumference would more likely be thought to be the measure of the tree's crown outline.
- Two, it recommendeds measure is the girth at 1 meter above the ground. Is this the standard height for measurements anywhere? In the UK it is more likely to be 1.5m, though 1.3 and 1.4 are also used by some people. I believe that this girth value would need two values, both the circular measure and the height of measurement.
Indigomc 22:41, 5 March 2011 (UTC)
- OSM has some guidance as 1.3m Key:circumference, I have been using 1.3 for our local project. --Amunizp (talk) 11:22, 15 January 2018 (UTC)
Maybe we can use:
- circumference:h=d
where h is the height of the measurement above ground and d is the diameter as currectly used
--Computerfreaked (talk) 14:32, 14 March 2014 (UTC)
- Wikipedia has a note about this but only described as "some authors" DBH I guess it will not hurt.--Amunizp (talk) 11:22, 15 January 2018 (UTC)
I really like this discussion. I really would like to measure a lot of trees in my vincinity. However it would be useful to track this data with the actual date of the measuring. This data would be useful for calculation like e.g. growth per year etc. Any suggestion how to track data with a datestamp? -braegel (talk) 15:37, 9 January 2018 (UTC)
- By making edit you save timestamp (in changeset itself). One may keep data updated and as long as one is not waiting years before measurement and editing OSM it should be enough Mateusz Konieczny (talk) 21:34, 9 January 2018 (UTC)
- I agree with this assessment. Never the less, I have been setting a log of the DBH for extra information. --Amunizp (talk) 11:22, 15 January 2018 (UTC)
Indigomc: Circumference in math is defined as π × diameter (see https://en.wikipedia.org/wiki/Circumference). Why not just use the standard Key:diameter for this? That page also states it can be used on trees, and is actually what the iD editor shows. JOSM shows circumference and not diameter... -- Kars (talk) 12:12, 7 July 2020 (UTC)
Also see
I have added in 'habitat' and 'plant community' links. I thought this would be relevant here. If anyone would like to help create more guidance or has any experience or examples of habitat/species mapping please get in touch Hawkeyes
Commemorative trees
Some trees are planted to commemorate individuals, or to mark visits by notable people, or other occasions. For example, http://www.openstreetmap.org/browse/node/1509618150
We may need some extra tags:
(all of which I've used on the above example)
and perhaps to make use of historic=memorial
Thoughts? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:26, 20 November 2011 (UTC)
- How about dedication=* rather than or as well as commemorates=*? I got a certificate through the door for a tree some company had planted on my behalf, which I'm guessing bears my name, but I'd rather not think of it as commemorating me ;) Craigloftus 12:17, 20 November 2011 (UTC)
- Good point, but what about "opening of school gym" or "visit by the queen"? Here's another example: http://www.openstreetmap.org/browse/node/1510174916 Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:32, 20 November 2011 (UTC)
- (I think you meant historic not historical? I think we should use this because it will make a commemorative tree a special type of memorial, rather than a separate type of entity Grahamjones 13:33, 20 November 2011 (UTC))
- Yes; thank you. But not all such trees are memorials (assuming memorials means "to dead person" rather than just an event or visit). And we already have "trees" as entities, this just adds details. perhaps we should tag Tree=commemorative? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:32, 20 November 2011 (UTC)
- Make it a general thing, and just write it up with no proposal as a tag in its own right, to be used with anything, not just trees. Do some taginfo searches first to make sure you aren't overloading an existing tag. I'd prefer dedication=<entity-or-event>, with the caveats that a) an object probably shouldn't be dedicated to the default deity of an existing religion=* tag (though their saints, or gods-with-special-attributes would be fine) and b) it probably shouldn't retread the same ground as the any of the name=* attributes. We have several amenity=benches round here dedicated to dead members of the local community, or indeed fictional characters (413626566
413626566) with the name of the dedicatee engraved on a tasteful little plaque. name=* isn't really the right tag to use, but right now you sort of have to use it. Other possibilities for the name exist if those are taken: dedicatee/dedicated_to, dedicator/dedicated_by. --achadwick 17:54, 28 November 2011 (UTC)
- Would it be useful to use start_date= and end_date=. Nice information to have if you are planting commemorative trees or community orchards etc. I suppose end_date could be used for significant tree stumps? For instance, there are many Sequoia tree stumps which would have end_dates? Hawkeyes 21:28 11 Jan 2012
- I think that natural=tree combines well with historic=memorial, in case its memorial characteristic is obvious to visitors. --Fkv (talk) 10:05, 12 January 2015 (UTC)
Carved trees
Here's another type; a carved tree, as an artwork, such as the Elfin Oak (OSM; Wikipedia). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:40, 4 December 2011 (UTC)
- Meanwhile, the new tourism=artwork tag has been applied to it, but I would say that it is still a tree, even though it's dead. I suggest natural=tree + ruins=yes in addition to tourism=artwork. --Fkv (talk) 09:57, 12 January 2015 (UTC)
small-leaved
At this page we have "type=broad_leaved/conifer/palm", but at Tag:natural=tree we have "wood=coniferous/deciduous/mixed". Deciduous tree can be broad-leaved tree and can be small-leaved tree. It is easily to distinguish deciduous tree from coniferous and from palm, but it can be hard to non-specialist to distinguish broad-leaved tree from small-leaved tree. If I understand correctly, one type of trees can contain both broad-leaved subtype and small-leaved subtype. So I propose to add 2 new values: type=small_leaved (for small-leaved tree) and type=deciduous (for broad-leaved or small-leaved tree, if editor can't realize specific type of tree). Dinamik (talk) 16:01, 26 September 2013 (UTC)
- What is a "small-leaved" tree? Perhaps my English just isn't good enough, but after reading the Wikipedia article for "Broad-leaved tree", I was under the impression that the term covers all trees that have actual wide leaves rather than "needles". --Tordanik 14:43, 27 September 2013 (UTC)
- Broad-leaved trees are Laubbaum (de) Frondosas (es), Conifers are Nadelbaum (de), Coniferas (es) a term which is presumably even applicable to the Gingko which has broad leaves but is a conifer. The real problem is the horrendous use of deciduous as some kind of apparent synonymy for broad-leaved. Currently I am retagging woods/forests which I have mapped with deciduous=yes. Unfortunately my talk on this subject at SotM-13 was not recorded. I will add the slides on Slideshare soon. I particuarly focused on Larch (Larix) woodland and evergreen oaks (Holm Oak, Quercus ilex; Cork Oak, Quercus suber) as these groups of species highlight the absurdity of the wood=deciduous tag. It might be fun to have a concerted effort to map larch woods this autumn as they are particularly obvious as Goldener Laerchen. SK53 (talk) 15:01, 27 September 2013 (UTC)
- While wood=* or leave_type=* and leave_cycle=* may be useful on areas (landuse=forest, natural=wood), I think that we better omit that kind of tags for single trees, because they are subjective to some extent (is a cypress needle-leaved?). We better use species=* or genus=* tags from which foliage can be derived. I created a dumb conversion table in the rendering section. Note that Ginkgo is NOT a conifer according to current classification, where Ginkgophyta and Pinophyta are different plant divisions. --Fkv (talk) 09:50, 12 January 2015 (UTC)
- Of course species=* is the most precise, but also the most challenging. People rarely know the latin names, and often don't even know the local names except for the most common species. Tags like leaf_type=* may not work in every single case, but they are still applicable often enough to be very useful. --Tordanik 18:11, 12 March 2015 (UTC)
The usage of key:type for non-relation elements should be avoided.
The usage of key:type for non-relation elements conflicts with the use of the key for a relation's type and should be avoided. It may also create conflicts on multiple tags for the same element. To find a distinct tagging scheme there is a new proposal Proposed features/leaftype for new keys leaf_type and leaf_cycle. --Rudolf (talk) 07:20, 13 May 2014 (UTC)
- Please consider to use the approved key leaf_type=broadleaved/needleleaved instead of type=broad_leaved/conifer. Please consider also updating the tagging of existing elements that you have mapped yourself. --Rudolf (talk) 22:17, 6 June 2014 (UTC)
- As I just wrote below (see "Possible Rendering" section), type=palm cannot be replaced. Remember that type=* on trees is approved too. With currectly 375 671 occurences on natural=tree, it cannot become disapproved, even though some radical extremists have been removing it from the wiki and doing illegal mass edits in OSM data. --Fkv (talk) 09:17, 12 January 2015 (UTC)
- type=* on elements does not conflict with a relation's type as long as the element is not a relation itself. If you would use type=conifer on natural=wood areas, a conflict may arise, because you may need a multipolygon relation for the area, and the relation cannot be tagged both type=multipolygon and type=conifer. But for natural=tree, type=* is ok, because you never need a multipolygon or any other relation to map a single tree.
- What do you mean by "conflicts on multiple tags"? I can hardly imagine a combination of natural=tree with any other of the keys which have a type=* attribute defined, e.g. aeroway=aerodrome. I agree that we should avoid additional use cases for type=* tags, but it's ok to keep the established ones, because applications need to be aware of them anyway.
- --Fkv (talk) 09:17, 12 January 2015 (UTC)
Cleanup suggestions
I think the page would benefit from some cleanup. I suggest the following measures:
- remove mentions of the very rare tree=* key, including the "Other tags without documentation" section
- remove one of the duplicate mentions of natural=tree_row (either from "Tree rows" section or "See also")
- remove leaftype proposal link (the approved keys are now documented in the "Additional tags" section
- merge "Related Projects" into "See also"
Any objections? --Tordanik 00:30, 27 June 2014 (UTC)
- Done. --Tordanik 14:51, 28 June 2014 (UTC)
Is key:tree_lined still in use?
The tag tree_lined=* is not documented. This page mentioned tree_lined=yes. The page DE:How_to_map_a mentioned tree_lined=left/right/both. Is this key still recommended or deprecated? --Rudolf (talk) 06:34, 27 June 2014 (UTC)
- Well, it is used some >1000 times. That seems enough to justify proper documentation. Of course, the documented values should not differ between translations. --Fkv (talk) 09:29, 12 January 2015 (UTC)
“Possible Rendering” section
What is this intended for? It could encourage people to use the tags wood=* (confused use of values) and type=* (confused use of values and can’t be used with woodland multipolygons) when in fact they are being steadily replaced across the database with leaf_type=* and leaf_cycle=*. --Andrew (talk) 07:37, 12 January 2015 (UTC)
- It is intended for rendering. (Does that come as a surprise?) Literate people will certainly find out that tagging is not rendering, and that the "How to map" section describes how to map.
- Replacing type=* on trees is evil, because leaf_type=* and leaf_cycle=* do not retain the information if it's a palm. Consider that some renderers may use a distinctive symbol for palms. You need at least a genus=* tag AND the conversion table to get along without the type=* tag.
- --Fkv (talk) 08:38, 12 January 2015 (UTC)
Taxon vs Species/ Genus
taxon=* and species=*/genus=* (see discussion from 2010, above) are not both needed; the latter pair is a subset of the former. How should this be resolved? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:38, 27 April 2015 (UTC)
- Use species=* if you know it, otherwise genus=* if you know it. taxon=* is fine if you don't even know the genus (e.g. taxon=Pinaceae), or (in addition to species=*, which is easier to process) if you know a subspecies, variety or forma (e.g. taxon=Pinus nigra ssp. nigra). It's neither necessary nor wrong to set all 3 tags redundantly, as long as they are consistent. --Fkv (talk) 21:28, 27 April 2015 (UTC)
Migrating species table to new tags
The table listing the different species of trees unfortunately still contains the old wood and type tags. It would be a lot better if it used leaf_type and leaf_cycle instead. --Tordanik 18:10, 19 September 2016 (UTC)
- The type=* column is necessary for the palm symbol, and there are 170 K instances of natural=tree + type=*. Feel free to add a column for leaf_cycle, but please keep the existing columns. When the table gets too big, we can move it to a separate page and link it. --Fkv (talk) 18:54, 19 September 2016 (UTC)
Practicalities about labelling trees in a wood.
I have started a project and SK53 in #OSM-GB had some information to help. Estracted from this wiki:
- OSMTracker for android which lets you lay various features into a .gpx we can then upload it.
- GPS works best on cloud free days in the open air
- GPS works best with no leave or dry leaves
- if you want to survey trees in woodland what you need is a good compass & a 30m tape. Make all measurements from points which have been accurately recorded using GPS or better & probably you need 2 good points as a baseline you can triangulate from other trees. how do you pick the middle of the tree for triangulation ? accurately recording every tree in a wood is largely regarded as difficult. if girth is less than 2m errors will not be too serious & a lot less than using GPS
- you probably need at a minimum some suitable labels to attach to trees before the survey starts; I think proper ones can be quite expensive, but it's worth doing if you want the information kept
Using this information to populate this article. Help/comments appreciated.Richmond_Upon_Thames,_UK/Petersham_Common_Woods --Amunizp (talk) 13:12, 23 January 2018 (UTC)
Trees named with their common name
In some places we have some specific trees with a plaque containing their common name (and sometimes also their species).
For example, http://i.imgur.com/5xRrJfv.jpg
This is a Cariniana legalis https://en.wikipedia.org/wiki/Cariniana_legalis tree, locally known as "jequitibá-rosa", "jequitibá-branco", etc.
How wrong would it be to use name with the tree common name? (name=Jequitibá-rosa in this example)
Note that this isn't exactly the same thing as including the common name in every tree; this case is specific for trees with plaques; ie, while the wiki says that "This tag should not be used for a description of the species", is naming a tree with the common name from its plaque still considered to be a "description of the species"? --naoliv (talk) 04:41, 21 February 2017 (UTC)
- I'd avoid doing this, the plaques merely help correctly assign species or taxon. Think of it as analogous to a ref on street furniture, it helps accurately identify the thing. Name on trees should be reserved for trees which are genuinely known to the general public by that name: usually historical or with social interest. There are a couple of ways which this information could be represented: use source:species or source:taxon and a value that shows it comes from a label, or invent a specific tag for the same purpose. Such plaques or tags are very common in botanical gardens, not only on trees but on many other plants so adding name would make a real rendering mess. SK53 (talk) 09:54, 21 February 2017 (UTC)
- There is also the issue that, as the chief maintainer of Nominatim pointed out, any key beginning with name needs to be kept for individual names. You could use species:pt though.--Andrew (talk) 20:17, 21 February 2017 (UTC)
- I would usually agree here, to not name the species. But this still seems to be a different case for me. The furniture ref is used for some kind of internal control, but the plaque usually is used to highlight/feature that specific tree exemplar for the public. For example, people in a botanic garden will be able to see the plaque with the name (and possibly the species). There will be only one named tree from that species (or very few of them). For example, https://www.openstreetmap.org/#map=19/-21.96418/-47.89610 Only some trees are marked and local people know them by their names (the names available in the plaques); they can be used for situations like "I will be waiting for you at the Cambuí". One of them is even used for geocaching (having instructions like "it's near the Peroba-rosa tree"). People using our data will want to locate that specific Peroba-rosa tree, with the plaque, and not any other Peroba-rosa. I also don't think that it could cause a rendering problem (at least for this example); we don't have all the trees in this forest named, but only the featured ones. By using species:pt or other kind of tag we won't be able to differentiate featured trees from unfeatured ones; we would need to invent another tag for this? Trying to reinforce the idea, name would be used only for the featured trees (with a plaque, tag, etc), visible in public areas, and not for every tree in the forest/park. Naming every Peroba-rosa in a forest, just because you know that they have this common name, would still be wrong. But naming a specific exemplar, which can be part of a botanic garden map, touristic route, etc, still makes sense for me. --naoliv (talk) 20:55, 22 February 2017 (UTC)
- There's still a difference between a name and the kind of situation you describe, though. When I tell another local to meet at the bus stop, they are probably aware which location I have in mind. There might even be a sign labeled "bus stop" there, but that doesn't mean that the station should be tagged as name=Bus stop. So the information that a there is a sign near that tree, unlike most other trees, might be worth mapping, but I feel your use case doesn't fit any existing tag such as name. --Tordanik 12:37, 25 February 2017 (UTC)
- "How wrong would it be to use name with the tree common name?" - 100% wrong. Mateusz Konieczny (talk) 07:22, 9 January 2018 (UTC)
Dead tree
Any suggestion how to tag a dead tree - e.g. abandoned:natural=tree?
I am open to suggestions as well. --Amunizp (talk) 13:09, 23 January 2018 (UTC)
- Found that denotation=* dead might be the best solution. Mentioned on the main article.
Preservation
Some trees in the UK are under TPO (Tree Preservation Orders) more information can be found in Wikipedia TPO and the Government TPO information. I am going to set up a new key with a YES/NO on label.
Would making them protected area be a better description? They also have a legal basis. --Amunizp (talk) 13:09, 23 January 2018 (UTC)
- TPO is too opaque, too UK-centric. Calling a tree with a TPO a protected area is a stretch, but the tag is used for all sorts of things (far too many, I think it's a bit of a dumping ground). You would need a protect_class too. Just protected=yes would seem simpler in the first instance. SK53 (talk) 15:05, 23 January 2018 (UTC)
vernacular / common names in lower case
Hi all. I would recommend we use the Wikipedia convention of spelling the English common / vernacular names of plants (i.e. the `species:en=` tag) in lower case, except when there is a proper name included. Quoted from the Wikipedia page:
The manual of Style says that English vernacular ("common") names are given in lower case, except where proper names appear. Examples are "mountain maple", "common sundew", but "English sundew", "Low's pitcher-plant". Personal names should be capitalized only when they refer to specific individuals; thus for Arum maculatum, English names include "Adam and Eve" and "jack in the pulpit" – "jack" here does not refer to a particular individual.
Could we agree on this? For the first letter of the name too? Would that contradict any general OSM naming convention I am not aware of? Chtfn (talk) 02:30, 9 January 2018 (UTC)
Outsourced table "List of Genus, Leaf cycle, Leaf type" ?
@Gnrc69 - Having the genus table collapsible was a good idea. But how does it help to have it outsourced into a separate page? --Polarbear w (talk) 18:03, 13 February 2019 (UTC)
- Hello, if you think it is better to leave the table collapsable in the main page, and in the chapter where is the link to the table, it suits me too. The idea was to attach to the table a bibliography justifying the "Latin names" imposed for the genus, but it would be possible to put it at the end of the table. --Gnrc69 (talk) 18:45, 13 February 2019 (UTC)
- I don't know yet what is better, thus I was asking what the plan is and if the extra click has a value. If it helps e.g. to translate the pages, it might be good. --Polarbear w (talk) 19:04, 13 February 2019 (UTC)
- I also had this idea still confused that one could increase the number of columns of the table according to the Latin names and main local names, or other complements. But wait for other opinions! --Gnrc69 (talk) 19:51, 13 February 2019 (UTC)
- Hello, I would like to first ask what is the goal of this table ? Is it go give some exemple, trying to be exhaustive, be a ressource for mappers or for 3D engine, maybe a bit of both ? When I checked it to see if it can help me to add leaf_cycle and leaf_type it lacked a bunch of common genus from Europe (Acer, Fagus, etc...). We can add them but the table will grow quickly so that lead us to the idea of separate it of the page.--Defuneste (talk) 09:36, 15 February 2019 (UTC)
- I also had this idea still confused that one could increase the number of columns of the table according to the Latin names and main local names, or other complements. But wait for other opinions! --Gnrc69 (talk) 19:51, 13 February 2019 (UTC)
- I don't know yet what is better, thus I was asking what the plan is and if the extra click has a value. If it helps e.g. to translate the pages, it might be good. --Polarbear w (talk) 19:04, 13 February 2019 (UTC)
Age of tree
I recently created the age=* wiki page to document the significant usage of this key. It has been used (almost exclusively) in a single data import project to document the age/lifecycle stage of a tree. Personally, I think this isn't good usage and would be better described by a more specific key. Any thoughts/edits would be appreciated. Casey boy (talk) 09:09, 19 April 2022 (UTC)
Tags for Palm trees
Palm trees are trees of the family 
Arecaceae. As of 2021-09-06 there is no community consensus on how to tag these trees, although several different tags are in use. Most of these tags are technically incorrect, because palm is not the scientific name of these trees and palm trees are a family rather than a genus or species.
Examples of existing tags for palm trees are:
The following tag from this proposal and RU:Tag:natural=tree technically indicates the shape of a tree rather than its biology but nonetheless results in a palm tree in some 3D renderers:
- @Gnrc69: Why did you move it here? Wiki is for documentation. Many other feature pages show various usages and stats. You can use Template:Collapse/top and Template:Collapse if you find it too long. https://wiki.openstreetmap.org/w/index.php?title=Tag:natural=tree&type=revision&diff=2592272&oldid=2592159
—— Kovposch (talk) 14:36, 4 October 2023 (UTC)- @Kovposch:Hello, yes the wiki is for validated documentation, not for discussion. And since there is no consensus on this tag, it seems better to me to put its unapproved uses in the discussion page, hoping that this will start a debate which will provide a less scattered solution. Sincerely. Gnrc69 (talk) 16:26, 4 October 2023 (UTC)
- Wiki can list out debates and different viewpoints. Forest#Which_tag_should_be_used? already does so. People can look at them, and decide for themselves. This encourages converging to a popular choice.
It has already been discussed before. This section was the result of the research and exchange on different solutions. Palm trees are widespread, and not sufficiently expressed by other tags. It's more beneficial than clutter to show there exist solutions users can pick from directly. Nearly half of them are thousands, with two in the tens of thousands range. They would be considered "in use" , but the wiki don't necessarily need a page for each notable group of plant.
And clearly crown_type=I is rendered by some application. It should definitely be recorded in the main article. In fact, F4Map render many of them here.
—— Kovposch (talk) 17:46, 4 October 2023 (UTC) - @Gnrc69: It's good to have a discussion, but moving the documentation here will only exacerbate the proliferation of inconsistent tags. Talk page discussions aren't searchable by default, so in the absence of even a list of common tags, mappers may resort to coining their own tags, complicating a future cleanup. – Minh Nguyễn 💬 23:11, 21 October 2023 (UTC)
- Wiki can list out debates and different viewpoints. Forest#Which_tag_should_be_used? already does so. People can look at them, and decide for themselves. This encourages converging to a popular choice.
- @Kovposch:Hello, yes the wiki is for validated documentation, not for discussion. And since there is no consensus on this tag, it seems better to me to put its unapproved uses in the discussion page, hoping that this will start a debate which will provide a less scattered solution. Sincerely. Gnrc69 (talk) 16:26, 4 October 2023 (UTC)
- It would be interesting if other contributors gave their opinion in this discussion to know where to put these usage tables which do not reach consensus. --Gnrc69 (talk) 06:55, 10 October 2023 (UTC)
- I wanted to see if anyone documented anything on those tags in the wiki, so here is the list. Turns out, no wiki pages where created, yet --Tordans (talk) 04:00, 21 October 2023 (UTC)
- I think using taxon:family=Arecaceae for palm trees makes sense, in large part because the taxon:family=* tag in combination with natural=tree likely distinguishes several types of trees well enough to suggest both identification and generic rendering even in the absence of additional information. For example, natural=tree + taxon:family=Fagaceae indicates something like a broad leaved tree, natural=tree + taxon:family=Pinaceae indicates a pine or conifer tree, and natural=tree + taxon:family=Cactaceae indicates a large tree-like cactus (something like a Saguaro). And natural=tree + taxon:family=Asparagaceae would indicate a Joshua Tree while natural=plant + taxon:family=Asparagaceae would indicate a yucca or agave. --B1tw153 (talk) 17:58, 19 January 2024 (UTC)
In 2024 we had another round in https://community.openstreetmap.org/t/leaf-type-palm-is-anything-wrong-with-it/109646 Mateusz Konieczny (talk) 18:22, 23 February 2024 (UTC)