As the product is created from existing OS data, the quality of the OS Detailed Path Network data depends on the quality of the compilation data.
Our focus has been to provide a connected network with the attribution required to facilitate routing.
The positional accuracy of OS Detailed Path Network has been designed to be usable with readily available GPS-enabled hardware that does not make use of real-time correction, such as mobile phones and personal navigation devices.
The typical device that the data will be used upon is positionally accurate to approximately 10m in plan.
The alignment of roads, tracks and paths has been sourced from Ordnance Survey large-scale data whose positional accuracy is typically between 2.4 and 8.9m (99% confidence level).
Sample data tracked using an ordinary mobile phone showed a correlation of 95% of GPS positions being within 10m of the RouteLink feature contained within the product.
Data only sourced from the 1:25 000 Scale Colour Raster will have a lower planimetric accuracy. This is because the processes of generalisation, exaggeration, selection and offsetting reduce the positional accuracy.
This applies to RouteLink features for rights of way and the extent of danger areas where there is not an Ordnance Survey large-scale data representation.
GPS devices may only provide coordinates using the WGS84 coordinate reference system (EPSG code 4979, although 4326 is often used also). The OS Detailed Path Network data is supplied using a combination of coordinates in the OSGB36 British National Grid system and heights relative to Ordnance Datum Newlyn (EPSG code 7405) for both the Geography Markup Language (GML) and GeoPackage formats. Note that the vector tiles format is supplied in Web Mercator (EPSG code 3857).
To allow the data to be used with positions from GPS devices, a transformation is required. The transformation can be applied to the OS Detailed Path Network data (to move it on to WGS84) or to the GPS coordinates (to provide positions in OSGB36 British National Grid). The choice may depend on the coordinate systems of any other datasets in use.
Given the difference that can ensue from using the incorrect coordinate reference system, care must be taken to use the appropriate transformation. A recommended transformation is the seven parameter one published in A Guide to Coordinate Systems in Great Britain, which is available on the OS website. This transformation is EPSG code 1314.
Further information on coordinate systems and transformations is available on our website.
The positional accuracy of OS Detailed Path Network data has been designed to be usable with readily available GPS enabled hardware that does not make use of real-time correction, such as mobile phones and personal navigation devices. Typically, these devices are accurate to approximately 10 to 20m in height.
OS Detailed Path Network data has been heighted using the source data that was in turn used to create the OS Terrain 5 and OS Terrain 50 products – the accuracy of this data is expected to be +/- 6m.
The height data used to height the OS Detailed Path Network data was captured in a separate process to the network data. On occasion, there may be discrepancies where the height data has not captured the intricacies of the terrain. For example, along an embankment or locating the precise start and end of a tunnel. The result can be discrepancies in the height value of individual vertices.
These limitations should be considered when using the height values and related calculated attributes to create estimates of journey times and draw profiles.
The data includes all roads, tracks and paths contained within Ordnance Survey data and rights of way information contained on 1:25 000 Scale Colour Raster.
Changes to Roads are generally captured within six months of the change occurring.
Changes to Paths and Tracks are captured as part of a cyclic revision programme that completes every three to five years, using aerial photography as the main tool to identify change.
Changes to rights of way are updated when received from Local Highway Authorities or National Park Authorities, where they are responsible as legal custodians of the Definitive Map and Statement for Public Rights of Way.
Feature classifications are based upon Ordnance Survey datasets, including interpretation of aerial photography. This presents the following data capture limitations:
Surface descriptions may be limited to made and unmade surfaces.
Unmade paths in upland areas can be ambiguous and, consequently, are sometimes not captured.
Changes that have occurred in obscured areas, for example, under trees, can go unrecorded.
Values for proper names have been extracted from existing Ordnance Survey data. The coverage of language alternatives may not be as complete as it is in other datasets.
Length of lines is calculated and is not based on real-world measurement.
Three-dimensional capture is based on a terrain model that may not be entirely sympathetic with
OS Detailed Path Network data. For example, in the terrain model, disused railway cuttings will not have been explicitly modelled, and bridges and tunnels may not be entirely coincident with OS Detailed Path Network data; see Height and Planimetric Correlation.
The featureID, versionID and versionDate attributes have been included to support future developments of the product that would support change-only update (COU) and maintained identifiers. At present, the data is supplied as a complete replacement, and identifiers are not maintained between epochs of data supply.
featureID: This will be unique within each supply. The same feature in a future release will have a different value.
versionDate: This will be set to the date the product data was created.
Customer input on the desirability of COU and maintained identifiers in future releases is welcome.
Content
Attribute values are imposed by edit systems and tested using validation to comply with those in the schema.
Logical combinations of attributes are imposed by edit systems and tested using validation.
Basic topology is tested in the edit software and additional validation is applied to ensure the topology is correct.
The connectivity between features at the same and different levels is tested through validation and visual inspection.