Converting to UKHab

From swathes of grassland and woodland in parks and nature reserves to tiny mosaics of vegetation on derelict land, London is a complex patchwork of different habitats. At GiGL we are working hard to prepare our habitat data for mandatory Biodiversity net gain (BNG) this winter. BNG is a planning approach which aims to leave the natural environment in a measurably better state than beforehand.

A significant part of this preparation is the conversion of our Habitat and Land Use (HLU) dataset into the UKHab classification system, as this is one of the primary underpinning systems of BNG metric 4.0 (which is used to determine the biodiversity value of a site). Converting our data into UKHab will enable us to better assist our partners in their BNG endeavours, and make it easy for us to process incoming UKHab survey data into our HLU dataset.

Habitat classification systems are a way to define and group all the different habitat types together. Each type is defined by specific codes, names and descriptions, to enable a simple and robust approach to survey and monitoring.

The HLU dataset is currently in Integrated Habitat System (IHS) classification format, and has not yet been published as we are still refining it. Much of the data in the HLU dataset have been translated from our current (soon to be legacy) habitats dataset which is primarily in London Phase 1 (LonP1) classification format. Another portion of the HLU data are based on Ordnance Survey MasterMap (OSMM), which has a classification system of its own and was translated into IHS for our dataset. Beyond the key driver of requiring UKHab for BNG, this project provides us with an opportunity to look in depth at the habitat classification translations that make up the HLU dataset during the first two phases of the project. We will also be assessing the overall quality of our HLU data in phase three, before moving on to engaging with London Planning Authorities (LPAs) in phase four.

Running alongside this project, we will also be updating the HLU tool which we use to manage the habitat data. The HLU Tool is currently appropriate to be used for IHS habitat types, but will soon be equipped to handle UKHab data. Once all of this is complete and the appropriate guidance has been written, we will be ready to convert our HLU dataset to UKHab.

Phase 1

Phase one, the assessment of the translation of OSMM data into IHS, began in January 2023. Prior to this project, a member of the team had already gone through and identified codes that had potential errors in their translation. This project then picked up that work and assessed every code translation that had been flagged as potentially not correct or in need of attention.

In phase one, each error was systematically checked and categorised according to the next steps required. Several hundred polygons had their translations corrected within this phase, strengthening the validity of our habitat data. Some errors were no longer present as the polygons had since been resolved or changed through the course of other processes and projects, and some required no change. Several of the errors will be resolved with the integration of OSMM 2022, which is an upcoming task for GiGL, and some have been flagged as needing further investigation in a project outside of this one.

Phase 2

Having completed phase one, we moved on to the review of the habitat classification system translations. Phase two is split into two stages, first the LonP1 to IHS translation will be assessed for accuracy, consistency and sense. The second stage will be to extend these translations out to UKHab.

There are 11,000 unique LonP1 codes across London, and each of these are being individually checked and their IHS translation amended accordingly. Due to our legacy habitat datasets use of multi-habitat parcels, and our HLU dataset using single-habitat polygons (often smaller than the legacy parcels), there are inevitably some habitats that make up a small percentage of a legacy habitat parcel that will not be represented in the HLU dataset polygon.

Some habitat types such as rivers, bare artificial ground and woodland are sourced from OSMM. When translating a parcel with one or more of these habitats in it, we know that it has already been mapped by OSMM and cut out of the polygon, so we only need to pay attention to the remaining habitats in the legacy parcel.

Rules for translations of different habitats and code combinations are being made to ensure that all the translations are justified and consistent across the HLU dataset. To make these rules we have to make assumptions about which habitats are likely to be present, primarily based on the percentage coverage. There is a chance of both over and underrepresentation of habitats in the HLU polygons, but the alternative would be to lose those data entirely. These assumptions will provide data which can then be improved by ground truthing and surveying.  

Below is an example translation. The original legacy code contains three different grassland codes (lowland dry acid grassland BASG, amenity grassland AMNG and neutral grassland NSIG), posing the question of which one to represent in the IHS translation. Due to there being such a low proportion of lowland dry acid grassland, we ignore this code. We also ignore the bare artificial code (BATH), as we know that this has been taken care of by OSMM. Roughland (RGHL) and scattered trees (SCTR) are all secondary (or ‘matrix’) codes, and so are easy to include, leaving us with similar percentages of the amenity grassland and the neutral grassland. Amenity grassland is usually translated as GI0.GL1, meaning it is improved grassland (GI0) which has been managed for amenity (GL1). Therefore we can translate the neutral grassland code, while still representing amenity grassland with the GL1 matrix code.

This translation follows the rule we established for instances like this: “where amenity grassland is the majority code, but there is a second grassland code with ≥15% coverage, the second grassland takes precedence as the primary code in IHS, with amenity being represented in the management code (GL1).” It also follows the rule for translating roughland (RGHL), which was previously undefined and inconsistent, where it is translated as GNZ.OT3.SC2.GM4 expect in cases where it is not the majority habitat type, so is represented just by OT3.SC2.

Particular care has to be taken when there is a priority habitat involved in the translation, as over- or underrepresentation could have ramifications for local policy and planning. To ensure our data are  as robust as possible, in instances where there is a priority habitat that is the majority habitat type (and so is translated into the HLU dataset) but may not make up 100% of the polygon, we give it the attribute of being “not accurately mappable”. This ensures that the data are not misleading. Similarly, where there is a priority habitat that only makes up a small percentage, and is then not translated into the HLU dataset, we give it the attribute of having a “potential priority habitat” present. This would be the case with the lowland dry acid grassland in the example above.

In some instances, there are so many habitats in the legacy parcel that it is impossible to determine which one should be carried over into the HLU polygon, in cases like this we give the polygon our own code of UH3, meaning it is an untranslatable polygon. These untranslatable polygons can be useful for our partners in flagging areas where more recent data are needed to determine the habitat type.

Next steps

Phase two is due to be completed imminently by the extension of the translations into UKHab. This will be based on our existing translation tables as well as the most up to date UKHab category definitions. Following this, we will soon be heading into phase 3 of the project, in which we will be assessing the quality of both our legacy and HLU datasets, so keep an eye out for future updates.