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 Products, including APIs. These products will continue to be managed through their product lifecycle, including withdrawal, 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.
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. In both instances, these new 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 either because:
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: Boundaries Collection (updated biannually), Transport Network Collection (updated monthly), RAMI Collection (updated monthly), or 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 eight new feature types released in March and September 2023 (River Basin District Catchment, Waterbody Catchment, Average and Indicative Speed, Building, Railway Link, Railway Node, and Railway Link Set Feature Types) or you have selected data schema version 2.0 of Road Link or the addressing feature types. The data for the aforementioned eight new feature types and for data schema version 2.0 of Road Link or the addressing feature types were only made available in the OS NGD after 01 January 2023. The Full Annual Supply order frequency option for data from the eight feature types and data schema version 2.0 of the addressing feature types will become available from 01 January 2024, after which point, data packages containing one of these feature types will no longer contain blank files.
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 Transport Network Collection).
Please see the 'Data schema versioning' page in the Core Principles section for a full explanation of data schema versioning and how it works in the OS NGD.
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 new 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).
For information about data ordering and currency, please see the 'Data ordering and currency' page.
Please see the 'Coordinate reference systems' page in the Core Principles 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 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.
Log into your OS Data Hub account.
Select Download from the main menu.
Choose Data Packages from the secondary navigation menu.
From your list of data packages, click on the name of the data package you wish to delete, then click on the Package options dropdown and select Delete 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.
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).
No, not currently. Height data is only available on the Building Part. Height data will be available on the Building feature type in a future product release.
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.
Yes. Embedded height attribution is available for Building Part features, enabling users to create simple height models.
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.
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.
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.
The pavement data in the OS NGD uses the RoadLink 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 Ordnance Survey 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.
The generalisation of Rail Networks should ensure full connectivity between relevant rail nodes. Rail track generalisation can be typically 3 or 4 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.
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 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.
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.
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.
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).