FAQs
Frequently asked questions on OS NGD data and access methods (OS Select+Build and OS NGD APIs).
Last updated
Was this helpful?
Frequently asked questions on OS NGD data and access methods (OS Select+Build and OS NGD APIs).
Last updated
Was this helpful?
Was this helpful?
OS NGD data is available in four easy-to-use formats: GeoPackage, CSV (comma-separated values), GeoJSON and vector tiles. The download service of OS Select+Build supports GeoPackage and CSV. OS NGD API – Features supports GeoJSON. OS NGD API – Tiles supports vector tiles.
For more information about the file formats, please see the File formats and naming page.
Features are now available to customers more quickly in the OS NGD than they are in OS Premium or OS OpenData products. OS NGD features that will also ultimately be supplied in existing products with a TOID will now appear in the OS NGD in advance of their publication in OS Premium or OS OpenData Products. At a future refresh of OS Premium or OS OpenData Products, these features will appear with the same TOID.
Monthly and daily COU (Change-Only Update) supplies are available for CSV files; however, they are not available for GeoPackage files. For more information about COUs, please see the COU supplies page and the Data ordering and currency page.
Please be aware that CSV (comma-separated values) files are designed to be opened in a database or GI system, and opening them in other software applications could corrupt the data. In particular, Excel has a row limit which might be exceeded by some of our CSV files containing OS NGD data, depending on the order you placed and its size.
We recommend that you load CSV files containing OS NGD data directly into a database or GI system, rather than trying to open these files in Excel.
For more information about CSV files, please see the File formats and naming page.
No. The launch of the OS NGD does not instigate withdrawal of any of the existing OS Premium or OS OpenData Download products, including APIs. These products will continue to be managed through their product lifecycle, including withdrawal / becoming End of Life, separately to the OS NGD.
The OS NGD gives new and enhanced ways for customers to access the most trusted and up-to-date geographic information from OS.
The OS Product Roadmap is available to view on our website – it has details of upcoming OS NGD releases, new Download product releases (for Premium and OpenData products), and dates for planned product withdrawals as they reach their End of Life stage.
Following the launch of the OS NGD in September 2022, we have and will continue to add new feature types as part of our data enhancements. These could be brand new feature types or enhanced versions of previously existing feature types (with new attribution added for a new version). In both instances, these new / enhanced feature types will have later start dates.
The earliest date on which you can request a one-off snapshot of a date in the past for data in a feature type in most collections is 29 September 2022, but that date can be later for certain feature types (for example, it's 28 March 2023 for the Waterbody Catchment Feature Type). Each feature type page states the earliest start date available for temporal filtering on that feature type.
Please refer to the File formats and naming page for information about the OS NGD file naming convention.
You could have received blanks files for one of the following reasons:
You are collecting data via a COU (Change-Only Update) and there has been no change.
You have selected a feature type from one of the following OS NGD collections which has a different update frequency from your selected COU: OS NGD Boundaries Collection (updated biannually), OS NGD Transport Features Collection (updated daily, with the exception of the Street Light Feature Type which is updated monthly), OS NGD Transport Network Collection (updated monthly), OS NGD RAMI Collection (updated monthly),or the OS NGD Water Network Collection (updated quarterly).
You have requested data via a temporal filter (i.e. a one-off snapshot of a date in the past) that predates the start date for data from one or more of the collections in your order. The earliest date on which you can request a one-off snapshot of a date in the past for data in a feature type in most collections is 29 September 2022, but that date can be later for certain feature types (for example, it's 28 March 2023 for the Waterbody Catchment Feature Type). Each feature type page states the earliest start date available for temporal filtering on that feature type.
You have selected the Annual Full Supply order frequency option for a data package containing one (or more) of the new feature types or new data schema versions of existing feature types released in March and / or September of the current year. If you select an Annual Full Supply frequency for your OS NGD data order in OS Select+Build, we will provide you with the data as it was on 01 January of the current year. This means if a new feature type or a new data schema version of an existing feature type was released after 01 January and you order either of these as part of your Annual Full Supply, you will receive an empty data package for the newly released feature type / new data schema version of an existing feature type. The data for the new feature type / new data schema version of an existing feature type will then be included in your supply on the next 01 January after the release, after which point, data packages containing one of these feature types will no longer contain blank files.
For example, the March 2025 OS NGD data enhancements release contained 3 new feature types (Building Access Location, Crowd Sourced Name Point, and Street Light), and 11 new data schema versions (Building v4.0, Building Part v2.1, Land v3.1, Path Link v2.0, Rail v3.1, Road Link v4.0, Road Track Or Path v3.1, Site v2.2, Site Access Location v2.0, Structure v3.1, and Water v3.1). As per the bullet above, this data will not be part of Annual Full Supply orders until 01 January 2026.
You have an existing OS Select+Build recipe that uses the Site Routing Point Feature Type or transact with that feature type via an OS NGD API. As of 26 April 2023, this feature type no longer contains any features or data. It is in an 'end of life' state where it has stopped receiving updates; therefore, any OS Select+Build recipes that use this feature type or any OS NGD APIs that transact with it will return blank files. You can access historic data for Site Routing Point using the temporal filter option in OS Select+Build by selecting the tick box for a 'one-off snapshot'; historic data is available for this feature type from 03 October 2022 to 25 April 2023. As part of a data enhancement programme in late spring 2023, all Site Routing Points were recreated as Road Nodes and are therefore now accessible via the OS NGD Transport Theme (from the OS NGD Transport Network Collection).
Please see the Data schema versioning page in the OS NGD Fundamentals section for a full explanation of data schema versioning and how it works in the OS NGD.
Yes. The OS NGD documentation can be saved to a PDF using the Export as PDF button on the right-hand side of the page. This tool allows users to download individual pages or groups of pages that make up a complete document. Users should limit their documents to a maximum of 100 pages per PDF to prevent issues when saving or opening the file.
The OS Features API is based on the OGC standard Web Feature Service (WFS) and provides access to OS OpenData and OS Premium Product data. It does not give access to any OS NGD data.
OS NGD API – Features gives you simple access to the OS NGD using the latest in API standards (based on the OGC API – Features specification). As the new API uses the latest standards, it's easier than ever before to quickly discover what OS NGD data is available and create your own bespoke data selections with more understandable filtering options. Ultimately, this will help accelerate your time-to-value by making it easier to build awesome things with our trusted geospatial data.
A key benefit of vector tiles is that they comprise layers of vector features optimised for caching and scaling that can render quickly. As a result, to ensure the vector tiles are lightweight and offer a smooth user experience, we only use the OS NGD feature types required to create a complete contextual base map.
Additionally, vector tile services include minimal attribution data to ensure maps load quickly. Even with minimal attribution, map developers can apply styles and interactivity to vector features that is just not possible with raster maps. The inclusion of unique identifiers (where available) allows you to cross-reference with the full product, for example, with OS NGD API – Features.
The OS NGD API – Tiles basemap is updated weekly. This means that the OS NGD data is updated with the latest available data every week, usually by Monday. The data used to update the API is taken from the previous Wednesday, ensuring that we’ve updated the vector tile cache with the latest OS OpenZoomstack and OS NGD data available at the time.
Additional general FAQs and answers about OS APIs are available on the 'OS Data Hub FAQs: Plans' page and 'OS Data Hub FAQs: Account and API' page, for example, 'What's a Project?', 'What throttling is applied to the APIs?'.
The download service of OS Select+Build supports GeoPackage and CSV file formats (more information on these file formats is available on the File formats and naming page from the OS NGD Fundamentals section).
For information about data ordering and currency, please see the Data ordering and currency page.
Please see the Coordinate reference systems page in the OS NGD Fundamentals section for full details.
It is possible to select what CRS you'd like to receive data in for feature types in your data package. There's more information about selecting a CRS on the Downloading with OS Select+Build page. If you don't choose a particular CRS for your data package, OS Select+Build will automatically select the default CRSs for the feature types in your data package for you.
A recipe is a bespoke selection of OS NGD data which is made by a user within OS Select+Build. Recipes allow you to choose the OS NGD data that best fits your requirements.
Please see the Downloading with OS Select+Build page for more information about recipes and step-by-step instructions for creating them.
Please see the Downloading with OS Select+Build page for step-by-step instructions on how to edit a recipe.
Please see the Downloading with OS Select+Build page for step-by-step instructions on how to delete a recipe.
Please see the Downloading with OS Select+Build page for step-by-step instructions on how to check which recipes are associated with each data package.
Please see the Downloading with OS Select+Build page for step-by-step instructions on creating an OS Select+Build data package.
Please see the Downloading with OS Select+Build page for step-by-step instructions on deleting an OS Select+Build data package.
The OS NGD Address Islands Collection contains data for Northern Ireland, the Isle of Man, and the Channel Islands. When ordering data from this collection, you will be provided with a full supply of the data regardless of whether you select 'All of Britain or Predefined Area', or an 'area of interest' (AOI).
For example, if you order the OS NGD Address Islands Collection and the Building Line Feature Type selected with an AOI, then you will receive the Building Line Feature Type data for your selected AOI and all of the Address Islands Collection data (i.e. data for Northern Ireland, the Isle of Man, and the Channel Islands, and not just data for your AOI).
Please see the Getting started with attribute filtering page for step-by-step instructions on how to filter attributes using OS Select+Build.
The OS NGD collection can be identified within the file name of your .zip file: themeshortcode_collectionshortcode_featuretype.zip.
For example, bld_fts_buildingpart.zip is the file name which would be created for an order of the Building Part Feature Type within the OS NGD Building Features Collection of the OS NGD Buildings Theme.
For more information about the file naming convention for OS NGD data, please see the File formats and naming page in the OS NGD Fundamentals section.
We wouldn't recommend trying to use OS NGD Address Theme data to update existing product supplies of AddressBase products. The different data format and attribution mean that there are no direct mappings available back to AddressBase products, and there is a risk of updating your existing holding incorrectly.
The Alternate Address Related Component provides alternative address labels where they exist for a ‘current’ address, independent of whether these alternate labels are current / live or historic. Where a historic address label is present but there is also a live / approved address label, then the historic version will appear in the Alternate Address data.
As addresses move through different stages of their lifecycle, you will see different update types dependent on your chosen data package. In OS NGD Address Theme data, pre-build, built, and historic addresses are kept in separate feature types. This means that as an address moves from one stage to another (for example, pre-build to built), it will be removed from one feature type and added to the other. This differs to AddressBase Premium, where, when an address changes from one stage to another, the record is updated, i.e. not deleted from one table and inserted into another. This will also mean that, if, for example, a user has a data package that includes pre-build addresses but not built addresses, as an address moves from pre-build to built in its lifecycle, the user will see a deletion to the record that they hold of this address.
Addresses that cannot receive post are classified as such for various reasons. Therefore, there are a number of different ways of extracting addresses that occupy different classes of 'Non-Postal'. The terms 'Non-Postal' and 'Non-Addressable Objects' used in OS NGD Address Theme data represent categories of addresses which are defined by differing logic.
Non-Addressable Objects are features which OS deem to always be non-postal. This is our most certain view of addresses that are non-postal, for example, Bandstands, Telephone Boxes, and Nature Reserves. The vast majority of Non-Addressable Objects will also have an 'N' value in the Postcode Source attribute.
'Non-Postal' in the Description attribute is essentially an amalgamation of all addresses that are defined by Local Authorities to be either 'N: Non-Postal' or 'L: Maybe Postal', and therefore is most relevant for customers who are only interested in using it as a filter to get to the 'Postal' addresses.
The Postcode Source attribute is the best attribute to use if you are interested in a more nuanced representation of Non-Postal addresses. This splits out 'Not-postal' and 'Maybe Postal' into two different code lists. The vast majority of addresses that have Non-postal in the description field but are not in the Non-Addressable Object Feature Type are likely to be 'Maybe Postal' addresses. This is a Local Authority representation of addresses that may be able to receive post, such as Car Parks.
The parent-child relationship is used to relate multiple addresses to each other. These are most commonly used to relate addresses within a building, for example, a block of flats. A parent Unique Property Reference Number (UPRN) is assigned to the building shell to give an indication that the flats within that building are related to the overarching address, for example, Example Court and the flats within.
A good example of this is:
Parent: 1 High Street (UPRN: 1234)
Child: Flat A, 1 High Street (UPRN: 2345)
Child: Flat B, 1 High Street (UPRN: 3456)
However, parent-child relationships also work beyond the level of a single building footprint and can be used to relate addresses in a larger addressable site to each other, for example, University buildings on the same campus site.
An example of this is:
Parent: Exeter University (UPRN 1)
Child of UPRN 1: Block C, Exeter University (UPRN 2)
Child of UPRN 2: Flat 1, Block C, Exeter University (UPRN 3)
Please note: Parent records are only inserted where child addresses share part of an address, for example, '1 High Street' in the above example. If two flats occupy the same building but are addressed 12A and 13A, then no parent record would be created.
These attributes are populated by data captured by local authority address custodians. The data previously had been available within our AddressBase products, but there was a large variation in the textual format. The level information has been standardised into an ordered numeric list (for example, ‘First Floor’ is now ‘1’, and ‘Ground Floor’ is now ‘0’ and remains a string field).
In OS NGD Address, the Full Address attribute is populated entirely from address data sourced from local authorities. This differs from the logic behind the Full Address attribute used in the AddressBase Core product, which is populated with information from Royal Mail and data from local authorities.
Yes. This can be done non-spatially by interrogating the new Boundary Parent Reference attributes.
By using the Building Part feature type and merging connected Building Parts that are within the same Land Use Site and have a contiguous border greater than 0.5m.
If a Building Part feature type does not belong to a Site, then it will retain the same geometry in the Building feature type.
If there are multiple Sites, the smaller Site has hierarchy over the larger site (i.e. Building Parts only merge within the smaller Site, and if they share a border with a Building Part outside of the smallest Site then the Building Parts features will not merge).
Yes. Height data is available on Building features and Building Part features.
The various address count attributes that have been derived from the OS NGD GB Built Address feature type where the ‘buildstatus’ value is classified as ‘Built In Use’. Residential, commercial and other address counts have been derived where the primary code in the address classification is equal to ‘R’, ‘C’, or anything not ‘R’ or ‘C’ respectively.
The main building aims to easily identify the building a casual visitor to a site would identify as the most useful building to represent the entire site. For example, the house on a residential site would be identified as the main building rather than the shed in the garden, or the ticket office of a train station rather than the waiting room on the other side of the platform.
Building use is derived from an in-house algorithm that uses either OS NGD Address data or OS Land Use Sites data to determine what the building is being used for. In most cases, the attribute value has been derived from address data classification.
There are two main differences; a difference in what each attribute is trying to convey and a difference in their derivation.
Building Use attempts to convey what the Building is specifically being used for, whilst OS Land Use Tier A attempts to convey what activity the site that the Building is situated within is being used for. For example, Nurses' accommodation on a hospital site will have the Building Use value of ‘Residential Accommodation’ but the OS Land Use Tier A value of ‘Medical Or Health Care’.
Building Use is mainly derived from address data, whilst OS Land Use Tier A data is derived from Ordnance Survey sites data.
The derivation of Roof Shape involves using automated methods and height models to delineate roof faces, while Roof Material is derived from imagery processed by a supervised ML model and an Automated Feature Extraction algorithm.
Building Access Locations identify specific entry and exit points for individual buildings, while Land Use Site Access Locations represent access points for broader areas (Sites), identified for a specific purpose, connecting them to the Road Network.
The OS NGD Boundaries Collection provides a definitive dataset of administrative and electoral boundaries; whereas, the depiction of settlement boundaries in the Named Area Feature Type of the OS NGD Named Features Collection is an OS geographic depiction of the extent of settlements and should not be mistaken for administrative or electoral uses.
More features and attributes are provided in the OS NGD Geographical Names Theme than in OS Open Names. The theme also includes a new feature type (Named Area) which shows geometry never before published by OS. The rich attribution provided by the theme's data lends itself to helping users perform gazetteer searches as well as high-level visualisation and spatial analysis of named features and places.
Coverage of Crowd Source Name Point features is dependent on submissions from expert third parties via the Vernacular Names Tool.
The Vernacular Names Tool is a resource developed by Ordnance Survey to assist Emergency Services by incorporating user-submitted colloquial names for geographic features across Great Britain.
The names are published as they are submitted by expert third parties. OS doesn't make changes to the names and doesn't enforce standardisation at this time because casing and punctuation can be important elements in some names. Spelling mistakes are also expected as these can be common variants tried in searches.
Crowd sourced names can be submitted via the Vernacular Names Tool on the OS Data Hub. You'll need to be member of an approved organisation to submit a name.
The Vernacular Names Tool is a resource developed by Ordnance Survey to assist Emergency Services by incorporating user-submitted colloquial names for geographic features across Great Britain.
Please report these via the Errors & Omissions Tool on the OS Data Hub.
Names usually appear in the Crowd Sourced Name Point features dataset within two months of being submitted, but they can be viewed in the Vernacular Names Tool on the OS Data Hub before then.
The Vernacular Names Tool is a resource developed by Ordnance Survey to assist Emergency Services by incorporating user-submitted colloquial names for geographic features across Great Britain.
Names will not be published if they have been flagged as containing personally identifiable information or potentially offensive language. They will also not be published if the name is identical to an existing OS feature or is of an unsuitable classification (for example, a defibrillator as their locations are not currently captured).
OS is not looking for duplicates within Crowd Sourced Names Point features, so if the same name is submitted multiple times, all entries will be published.
OS NGD Land Theme data contains land cover attribution that describes the physical and biological surface of the land. OS NGD Land Use Theme data contains land use attribution that describes the human or economic activity taking place on areas of land (i.e. how areas of land are being used / their purpose).
The OS NGD Land Theme contains some land information data which can also be seen in the OS MasterMap Topography Layer, Sites Layer, and Greenspace Layer products. The data in the theme is similar as that provided by the aforementioned OS products, but it has been structured to be more analytical and consistent across the six OS NGD features collections, allowing you to easily select the specific features you require and delivering greater value to users.
(The six OS NGD features collections, which also include data from the three aforementioned OS products, are the OS NGD Building Features, Land Features, Land Use Features, Structure Features, Transport Features, and Water Features Collections.)
Please refer to the OS NGD Land cover enhancements section for further information.
Upon OS NGD launch, it is expected and intentional that the OS Land Use Tier B attribute will be NULL for all records. This attribute has been included in the design as it ensures consistency with other core data themes in the OS NGD, and it could be utilised in the future and therefore it will not always be NULL.
Wind farms are a complex site to model as they are often constructed across large areas of open land with much of the ground around individual turbines being used for other activities, such as animal grazing or a solar farm. Some Wind Farm sites, in contrast, may be wholly contained within another existing site, such as a factory. Additionally, access roads may extend a significant distance from the turbines, or each turbine may have individual access. Consequently, what is recognised as a Wind Farm extent is heavily dependent on the surrounding geography, the nature of the wind farm, and the user’s perspective.
OS has chosen not to include the entire extent of the land parcels below turbines as the definition of a Wind Farm extent because this can sometimes translate to many thousands of hectares in mountain and moorland areas and therefore misrepresent the real-world site. Other sources of land extent data such as land registration and planning area data were considered, but did not provide consistent high-quality coverage across Great Britain.
Instead, a nominal 300m buffer was applied to the individual wind turbines associated with wind farm schemes referenced in the Renewable Energy Planning Database to indicate the general area of land used as a Wind Farm. Land Use Sites extents are not meant to represent specific concepts like land ownership, which is made clearer by this nominal geometry design choice.
In comparison to OS MasterMap Topography Layer data, OS NGD Structure Features Collection data has been enriched with additional attribution, including the following:
Geometry change metadata
A Description attribute to provide a one-word or simple phrase description of a feature
Detailed land use classification
Detailed land cover classification
Capture specification to give details about the geography of the area a feature resides in (that is, urban, rural, or moorland)
Embedded height attribution for chimneys, roofed tanks, and glasshouses, enabling users to create simple height models of these structures. Field Boundary features also have a height value.
In addition, other feature types are available in the OS NGD Structure Features Collection: the Compound Structure Feature Type and the Field Boundary Feature Type.
The new Compound Structure Feature Type is a polygon feature which encompasses one or more components and represents a manmade construction that has been built for a specific purpose. Examples include a bridge, a dam, and an aqueduct. A compound structure essentially combines multiple polygons into a single polygon, making it easier for you to analyse and query data when you want to analyse a structure as a single part rather than its constituent parts.
Name attribution, where known, is provided for structure features to help you identify what a structure is called. This attribute is optional as not all structures have a name and, in some instances, OS may not yet have captured a structure's name in the data.
Embedded height attribution is available for chimneys, roofed tanks, and glasshouses, enabling users to create simple height models of these structures. Field Boundary features also have a height value.
Please refer to the Field Boundary section for further information.
OS's capture focus is on tunnels that reach the surface, meaning that the Metropolitan and District Lines of the London Underground are captured, whereas other London Underground lines are generally not captured.
Yes. Data in the OS NGD Routing and Asset Management Information (RAMI) Collection can be fed into routing software. The routing information provides details about potential routing hazards (for example, dangerous bends and low bridges) and vehicle restrictions (for example, one-way streets and road widths).
The generalisation of Rail Networks should ensure full connectivity between relevant Rail Nodes. Rail track generalisation can be typically three or four Rail Links represented as one link, for example, multiple siding tracks. However, this may not always be the case, for example, tracks that pass either side of a station platform are normally included to ensure connectivity at a station.
Paths and tracks will both be represented in the OS NGD Transport Network Collection. The Description attribute provides a one-word or simple phrase description of a feature, and you'll be able to use this attribute to easily distinguish between paths and tracks.
The OS NGD Routing and Asset Management Information (RAMI) Collection provides in-depth routing and asset management information for roads across Great Britain. Rights and restrictions define properties that restrict, regulate or prohibit the use of the network by traffic which may affect the allowable route for users. Advisory information provides additional information that may either affect a driver’s preferred choice of route or highlight potential hazards, such as the presence of a toll or a level crossing. Asset management information provides additional information describing the network to support its long-term operation and maintenance.
The pavement data in the OS NGD uses the Road Link geometry in order to give the features a geographic location; therefore, pavements will be depicted using the road centre line.
When there is a pavement on both sides of the road, we create two features both with the same geometry; therefore, if viewed in a GIS, these will appear on top of each other, but each individual feature will have specific attribution relative to its own side of the road.
Often, the answer is there is no pavement adjacent to the Road Network. Some gaps appear, typically at junctions, where the end of Road Links have no adjacent pavement.
Currently OS does not capture large-scale depictions of features such as pavements when they are obscured by structures from above.
The left and right side of the road is determined by the direction of digitisation of the Road Link. In Direction of digitisation is from start node to end node, and Against Direction is from end node to start node.
When there is a pavement on both sides of the road, we create two features both with the same geometry; therefore, if viewed in a GIS, these will appear on top of each other, but each individual feature will have specific attribution relative to its own side of the road.
Indicative speed limit data is sourced from road signage and surveying. Average speed data is calculated based on historic speed information, which is based upon in-vehicle telematics devices; in this context, 'historic' means that the average speed data was collected over a six-month period for the selected road link.
Speed data is published monthly into the OS NGD. Indicative Speed data is updated by our 3rd party supplier 4 times a year, and Average speed data is updated 2 times a year. In-between these updates, OS 'infills' speeds with inferred values to account for any changes in the network monthly.
Average speed is provided in kph to support travel time analysis software in the market which predominantly uses kph as the unit of speed.
The main difference is that all speed data in the OS NGD has road link geometry and is published monthly. Additionally, average speed data in the OS NGD has an increased number of daily time periods available for each road link (with eight time periods Monday to Friday and six time periods Saturday to Sunday) in comparison to the OS MasterMap Highways Network with Speeds product (with five time periods Monday to Friday and only one time period Saturday to Sunday).
The speed data is published monthly into the OS NGD and customers can choose whether they want the supply to be either Full Supply or Change-Only Update (COU) depending upon their access requirements.
Street Light data is GB coverage. Features have been captured where they exist alongside publicly accessible Road Links and Path Links. Street Lights will not be included where they exist along restricted access roads. Where features are not visible from aerial imagery (for example, where obscured by tree cover or not visible due to urban shading), these will not be included.
No, the Street Light dataset does not contain information on the times when they are on / off.
An algorithm is used to give an indication of how well-lit a link is; this algorithm is based on an inferred light radius and does not account for information such as the height of a lamp post, the type of bulb, or the presence of any light-blocking obstructions or buildings.
Street Light data is updated into the OS NGD monthly. This includes both the Street Light Feature Type, and Road Link and Path Link attribution.
Yes. There are two known limitations:
Street Light Completeness: Street Lights have been captured from aerial imagery and therefore there are some limitations to completeness. Where features are not visible from aerial imagery (for example, where obscured by tree cover or not visible due to urban shading), these will not be included.
Overlighting and Underlighting: Street Light coverage attribution on Road Links and Path Links is indicative only, and there may be some instances of overlighting and underlighting. An algorithm is used to give an indication of how well-lit a link is; this algorithm is based on an inferred light radius and does not account for information such as the height of a lamp post, the type of bulb, or the presence of any light-blocking obstructions or buildings.
Water link sets are only created where there are a number of water links that share the same name. Within the Water Link Feature Type, there are numerous water links which are unnamed; these unnamed water links therefore will not appear in the Water Link Set Feature Type as they cannot be joined accurately.
Country attribution for catchments that straddle the Wales-England or Scotland-England border is as provided in the third-party data from the authoritative bodies and is aligned with the Geometry Source attribute (i.e. the source organisation that provided the data: Environment Agency for England, Natural Resources Wales for Wales, and Scottish Environment Protection Agency for Scotland).