Birmingham City Council trees data
Imported trees in Birmingham
Birmingham City Council trees data is a dataset about trees (their locations, species etc) in Birmingham
Import status: A phase one import has been carried out. It potentially requires some fixes (perhaps corrective bulk edits)
This trees data forms part of a large set of Birmingham City Council highways assets data released openly by the council. Their data listing site: https://data.birmingham.gov.uk/dataset/highways-assets "Amey" hold this data in line with their highways maintenance work for the council, and recently made this data release to Birmingham City Council
Open Government License
Brian's comment was "A review of the data showed its positional accuracy to be pretty good: none of us have specialist knowledge about tree species so we are accepting the accuracy of Amey’s data."
Amey’s data contains details of the species, estimated age and shape of the trees as well as other identifiers.
Phase 1 import
An import was undertaken March 2017
Brian's comment was "Currently we’re engaged in importing the tree dataset which we’re doing on an area basis so that we can do a human review and delete existing trees which have been added from various aerial imagery sets. One of the benefits of this method is to eliminate trees in the Amey dataset that are identified as “assets to be de-accrued” – these refer to trees that have been removed either because of highway improvements, storm damage, disease or safety."
So update approach is to be planned. This is not a requirement currently listed in the wiki imports guidelines. However it is good practice and the issue was raised with Amey and Birmingham City Council as soon as the data was released. Don't expect quick results!
TODO: document tag mappings used (and what may need fixing)
Example changeset: 
42,974 trees imported (taginfo UK 24 April)
Dataset contains 73,882 trees
No trees imported north of M6 motorway
Trees have been imported on an area by area basis, area size depending on the tree density, and outide of an overpass query the approximate descriptive extent is the 3 quadrants of the city south of the M6: NW, SW and SE completed. NE quadrant still to do
Example imported tree
- age=New Planting
- height=2 to 2.99m
- species=Liquidambar styraciflua 'Worpl
- site_name=LUDGATE HILL
- constituency=City Centre
Problems with initial import
Process problems : The initial phase 1 import was undertaken with very minimal compliance with Import/Guidelines. Discussion and documentation are clear requirements which were not met at the time. Let's just do better in future.
Import user problems: The import so far has been entirely uploaded by the brianboru user account. The size of the import was such that it should have been carried out by specially created OpenStreetMap user account. This guideline is in order to create another mechanism of separating/disentangling these edits from normal mapping
Solution: dedicated import account created: brianboruimport.
Tag problems :
- Areas: ward, and constituency tags describe the area a tree is in. That is not a normal thing to do with tags on many nodes. A lot of data which ordinarily should be determined by a data user (if they require it) by geo-querying boundaries information. These tags will have a data update problems when the political boundaries change The local community decided some years ago not to add political boundaries, so there is currenty no other way of querying the tree data by this attribute. This will need revisiting once the boundary changes are in effect
- 'site_name' key which contains the street name written in all capitals. Did this need importing, and if so, did it have to be in capitals? Enables the average joe/jane to query data by street name . Is the use of capitals a problem apart from being ugly? Maybe searches are case-sensitive? The downoaded dateset used or import has been edited so that this field is "Properly Cased" so any new imports won't be affected. Can also bulk edit existing imported data
- 'usrn' appears to be an identifier (Unique Street Reference Number). The purpose for this should be documented. Perhaps local_ref or ref:usrn should have been used. usrn is indeed Unique Street Reference No. Its purpose is documented in the link and is a national standard for referencing streets.
- 'height' values are formatted in a non-standard way (See Key:height) Is this a problem? Not everything is recorded to a standard. If there is insistence on a standard then it can be fixed e.g by tagging the existing data as height:rangeand tagging with height =x where x= the nearest whole number at the upper end of the range
- species but no genus ????? See example above which uses normal binomial name of genus and species (an includes in tis case a cultivar)
Updates planning : More planning is needed around how updates can occur when Amey make changes to their tree data. Naturally it's tempting to leave this planning until later. See comment above