City tree registers
A tree register (de Baumkataster) is a database of trees owned or managed by a specific organisation (typically a local government, university, large gardens and parks). The information is held to enable management of the entire tree stock for reasons of heritage, aesthetics, planning and safety.
Good practice is to create a tree register and then survey the entire stock of trees on a regular basis (often a 3-5 year cycle) to identify dead trees, diseased trees or any general arboricultural maintenance work (crown reduction, pollarding, limb removal etc). Increasingly local government bodies are making their tree registers available as Open Data and thus suitable candidates for import into OpenStreetMap.
This page summarises information about tree registers which have been imported into OSM, and others which have either been considered or have been looked at. It also offers tentative suggestions about best practice for such imports (tagging, verification, etc.)
Tree registers which have been imported
- Belfast. Originally examined by Stereo who noted that some trees had infeasibly large values for the height attribute. The largest value is in excess of 200 metres. Importing was therefore shelved.
- Birmingham: webbrowser. Street trees only. Decently attributed, no survey date, no circumference data. Heights are in 1 m class intervals. Some stumps and vacant sites (accession and deaccession).
- Buenos Aires. BA tree data are available as two data sets: parks & gardens & street trees. Data quality is good in terms of a limited comparison of surveyed trees around Retiro and Costanera Sud.
- London (GLA Datastore)
- Luxembourg: BD-L-TC trees from ARB_ISOLE and RANG_ARBRE, ANF Arbres Remarquables
- New York: Volunteer surveys co-ordinated by Parks Dept
- Nottingham [https://www.owenboswarva.com/blog/note-bio4.htm via Owen Boswarva's opendata site). Reasonable quality data, but some misidentifications and felled trees still included. Most likely will be used in conjunction with survey, as points will be better located. Nottingham University have published lists of trees from 2013 on their University Park Campus, but these are now quite old and not published with an open licence (or in a suitable form for any reuse: pdf files).
- Pittsburgh: Pittsburgh City Trees. The user access conditions for the webste make it questionable as to whether this is true open data, although the actual licence for this dataset looks accceptable. About 10% of trees in the dataset are not trees, being either Stumps or Vacant Sites. Has a "number of trunks attribute" suitable for populating Template:Key:multistemmed. Dataset refers largely to street trees, and certainly does not contain any trees from the larger parks such as Highland, Schenley & Frick.
- Seattle: https://data.seattle.gov/Transportation/Trees/e4p8-hm3u ; license is the vague: "This item is meant for public access and use."
- Australia: see Steve Bennett's blog for local authorities.
- Columbus, Ohio  (CC0)
See also opentrees.org, which contains data from over 130 sources, including their original download URL. Almost all are "open data", but the licences haven't been checked for compatibility with OSM.
- Berlin – "Baumbestand" FIS Broker, more information, a code-for-germany-project makes the city data more accessible (more Info)
What to look for in a tree register
The following table lists common attributes found in tree registers (see also Kit Wallace's notes about building a multi-source tree register for Bristol, much is directly applicable to OSM:
|Scientific Name||species=*, taxon=*, genus=*||Often this attribute will hold values other than valid scientific names|
|Vernacular Name||Use tags as for Scientific Name, but postfixed with ISO language code: e.g., taxon:en=Beech, taxon:de=Buche, taxon:fr=Hêtre||Avoid using longer names which are not in common usage (e.g., Common Beech, European Beech, Hêtre commun etc.) as this tag is principally there to allow mappers familiar with common trees to map detail without needing to add scientific names. A useful convention in English is to use lower case for the vernacular name if the exact species is not knowm.|
|Ref||ref=^||This will always be the reference of an organisation's tree register, and thus usually local to a specific area. The ref should be visible on the tree. Other references might be used on computer systems: in general these should be tagged admin_ref=* to show they are not verifiable by ground survey.|
|Circumference or Girth||In the UK girth is usually measured at breast height (BHG is the common abbreviation) which is assumed to be around 1.4 or 1.5 m. The height used for the measurement is also often of value, although using a height between 1 and 1.5 m is unlikely to result in major discrepancies. Similarly a last survey date for this value is useful to interpret the value: less so for mature trees but certainly highly relevant for new plantings.|
|Height||height=*||A last survey date for this value is necessary to interpret the value.|
|Planted Data||start_date=*||Planted date is not directly equivalent to age. Some relatively mature trees are planted as part of landscaping which may be upto 20 years old.|
|Age||Most likely added as age classes. Requires survey date for interpretation.|
|Crown diameter or Spread||Not generally regarded as useful as height or BHG as spread will tend to depend on situation, management etc|
|Form||Appears in the Birmingham data set. Values include "natural", "pollard", "espalier".|
Tagging best practice for tree registers
Import best practice