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)

Overview

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

Brian Prangle's mappa-mercia.org blog : Massive Release of Highways Asset Data in Birmingham 13-March-2017

License

Open Government License

Accuracy

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."

Data fields

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)

Changes

Example changeset: [1]

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

http://www.openstreetmap.org/node/4721553869

natural=tree

source=bcc_dec_2016

form=Natural

age=New Planting

height:range=2 to 2.99m

species=Liquidambar styraciflua 'Worpl

ref:usrn=2701986

plot_number=110007

site_name=LUDGATE HILL

ward=Ladywood

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? Yes, it's an issue because it often describe shortname that need to be expanded. 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)
• noise describing that some data doesn't exist for some key -> fixed in osm, maybe not in the import tool
• tree_stump tagged as tree -> fixed in osm, maybe not in the import tool
• unicode in some value -> fixed in osm, maybe not in the import tool
• several species=* aren't a species but a taxon -> partial fix in osm, maybe not in the import tool
• the age tag makes no sense in osm as it changes over time -> need to be converted to an approximate start_date
• plot_number -> ref_plot (or delete, no addedvalue to tag every objet on a plot with the number of the plot)

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