GeoPackage file naming

If GeoPackage format is selected, the filename will be constructed as: OSMasterMapTopography_gpkg_<order number>.zip

Where:

• order number is your customer order number.

Within the zip file, there will be a Data folder (containing six GeoPackage files – one file per feature type)

and a Doc folder (containing licence and readme files):

• Data folder

  • OSMasterMapTopography_<order number>_boundary_line.gpkg

  • OSMasterMapTopography_<order number>_cartographic_symbol.gpkg

  • OSMasterMapTopography_<order number>_cartographic_text.gpkg

  • OSMasterMapTopography_<order number>_topographic_area.gpkg

  • OSMasterMapTopography_<order number>_topographic_line.gpkg

  • OSMasterMapTopography_<order number>_topographic_point.gpkg

• Doc folder: <licence and readme files>

Vector tiles file naming

If vector tiles format is selected, the file name will be constructed as: OSMasterMapTopography_mbtiles_gb.zip

Within the zip file, there will be a Data folder (containing six MBTiles files – one file per feature type) and a Doc folder (containing licence and readme files):

• Data folder

  • OSMasterMapTopography_gb_BoundaryLine.mbtiles

  • OSMasterMapTopography_gb_CartographicSymbol.mbtiles

  • OSMasterMapTopography_gb_CartographicText.mbtiles

  • OSMasterMapTopography_gb_TopographicArea.mbtiles

  • OSMasterMapTopography_gb_TopographicLine.mbtiles

  • OSMasterMapTopography_gb_TopographicPoint.mbtiles

• Doc folder: <licence and readme files>

GML file naming

Geographic chunks (zipped)

If geographic chunk data supply is used, the file name will be constructed as: orderNumber-ngxxyy.gz Where:

• orderNumber is your customer order number.

• ngxxyy is the chunk name plus the four-digit grid reference belonging to the 1km south-west corner of the 2km / 5km / 10km chunk being supplied.

For example: 1234567-SU4020.gz

Non-geographic chunks (zipped)

If non-geographic chunk data supply is selected, the file name will be constructed as: orderNumber- vvvvvv.gz

Where:

• orderNumber is your customer order number.

• vvvvvv is the volume number of the file.

For example: 1234567-000001.gz

Buildings are defined as permanent roofed constructions, usually with walls. This includes permanent roofed constructions that exceed 8.0m² in area (12.0m² in private gardens). Exceptions are made to this area rule for smaller buildings that, due to their detached position, form relatively important topographic features; these are shown at minimum size, as stated above. With a few exceptions (for example, by describing government offices or hypermarkets), no distinction is currently made between residential, private, public, commercial, or industrial buildings.

Physical features shown in the Buildings theme include:

• Roofed Buildings (identified as being of sufficient size or importance to be shown)

• Mobile or Park Homes that are permanent, residential and have a postal address

• Archways and Covered Passageways, where the alignment can be determined from outside the building

• Horticultural Glasshouses over 50m²

• Covered Tanks

Features such as cooling towers, uncovered tanks, bridges, and monuments are shown within the Structures theme.

Only glasshouses over 50m² that serve a horticultural purpose will continue to be captured as glass structures. Other glass structures, such as office buildings and conservatories, exist within OS MasterMap and will be recorded as buildings. There are some non-physical features shown in the Buildings theme, represented as the following text features:

• House Numbers

• Descriptive Building Names

• Distinctive Building Names

Detail in private gardens attached to residential buildings, such as sheds, pathways and ornamental ponds, is not captured as part of the specification. Where possible, all gardens of this type are generalised and represented by a single garden polygon.

OS MasterMap Topography Layer orders are fulfilled via the OS Data Hub’s download service. However, in exceptional circumstances, OS will supply the product via CD, DVD, an SFTP server or a download service, on a minimum six-week cycle.

Full Great Britain coverage is available by ordering a National Set (GB) in GML or vector tiles formats only. Smaller areas can be ordered by selecting an AOI through the online ordering system in GML or GeoPackage formats only.

More information about supply options can be found in the product's Overview, which is available from the OS MasterMap Topography Layer Product Support page of the OS website.

Chunking for GML files

In GML format, OS MasterMap Topography Layer is split into chunks to allow file sizes to be kept at a manageable level. Two types of chunks are available: geographic and non-geographic. A more detailed description of these options can be found in the product's Overview, which is available from the

OS MasterMap Topography Layer Product Support page of the OS website.

Geographic chunking

Geographic chunking divides supply areas into manageable sizes in a geographically meaningful way. Chunks are created to a user-specified size, either 2km by 2km, 5km by 5km, or 10km by 10km. Features that fall within two or more chunks are supplied in both chunks, meaning that some features around the chunk edges will be duplicated.

Non-geographic chunking

Non-geographic chunking divides supply areas into files that have a fixed nominal size, regardless of geographic area. There are three compressed file size options available: 10MB, 30MB or 50MB. Each feature will only appear in one chunk file. It is possible for features from various geographic locations to appear in one file, and for adjacent features to be supplied in different files.

Administrative boundaries are defined as showing the limits of responsibility and representation for electoral and administrative purposes. Boundary alignments are shown within the Administrative Boundaries theme. As well as the boundary’s relationship to real-world objects, its mereing and boundary descriptions, where needed for clarification, are also supplied.

The following types of boundary are shown within the Administrative Boundaries theme:

Parliamentary boundaries

In Great Britain:

• County Constituency

• Borough Constituency (England and Wales)

• Burgh Constituency (Scotland)

• Assembly Electoral Region and Assembly Constituency (Wales)

• Parliamentary Electoral Region and Parliamentary Constituency (Scotland)

Local Government boundaries

In England:

• County

• City and County of London, District, London borough, Unitary Authority, and Metropolitan District

• Civil Parish and the Inner and Middle Temples

• Electoral Division

• Ward

In Wales:

• Unitary Authority

• Community

• Electoral Division

In Scotland:

• Unitary Authority

• Ward

Physical features shown in the Administrative Boundaries theme include:

• Boundary Posts

• Boundary Stones

• Boundary Markers

Non-physical features shown in the Administrative Boundaries theme include:

• Alignments of Boundaries

• Textual Descriptions of Boundaries, Mereings and Posts and Stones

Application of precedence

Where two or more boundaries are coincidental, a single alignment is shown by the most important boundary in the following order:

In England and Wales:

• County, City and County of London, Unitary Authority, District, London Borough and Metropolitan District, Civil Parish, Community, Inner and Middle Temples

• European Electoral Regions, County / Borough Constituencies

• Welsh Assembly Electoral Region

• Electoral Division and / or Ward

In Scotland:

• Unitary Authority

• European Electoral Regions, County / Burgh Constituencies

• Scottish Parliamentary Electoral Region

• Ward

A textual description often accompanies this occurrence and is used for clarification. If the alignment of an administrative boundary coincides with any other feature (other than another boundary), then both will be shown in their respective themes.

More information on administrative boundary alignments can be found here.

Roads

For Ordnance Survey purposes, a road is defined as a metalled way for vehicles. Roads that form part of the public network and driveways to private properties that are over 100m in length are normally included within OS MasterMap Topography Layer.

Tracks

A track, for Ordnance Survey purposes, is defined as an unmetalled way that is clearly marked, permanent and used by vehicles. Tracks are only normally recorded in private gardens if they are 100m or more in length. They need not be ‘all weather’. All tracks are described as ‘Track’, or ‘Tk’ if required to be abbreviated. Distinctively named tracks have their name recorded, for example, HICKS LANE (Track).

Paths

For Ordnance Survey purposes, a path is defined as any established way other than a road or track. They can be considered as either ‘made’ or ‘unmade’.

Made paths

Made paths are those whose surface is paved or metalled. Only major paths are shown in parks, public gardens, cemeteries and so on. Made paths are described by the annotation ‘Path’, except in built-up areas, where the description will not normally be recorded. Distinctive names, such as ‘Simmons Walk’, are also included as part of OS MasterMap Topography Layer.

Unmade paths

Unmade paths are those that are neither paved nor metalled. An unmade path is included in OS MasterMap Topography Layer when its entire length is evident on the ground and it starts at a road, track or path and finishes at a similar feature or a specific place of interest. Unmade paths are described by the annotation 'Path (um)' in urban and rural areas.

Physical features shown in the Roads, Tracks and Paths theme are listed below:

Kerb lines or the limits of metalling:

• Carriageway Limits, including any hard shoulder or shallow drainage gullies forming the side of the road on dual carriageways or motorways

• Kerbed Roundabouts

• Traffic Islands in roads (usually 8m² or more)

• Traffic-calming measures forming a physical obstruction, including pinch points

• Dedicated Cycle Lanes

• Fords

• Car Parks

• Edges or centre alignments of tracks and paths

• Step treads

Road furniture:

• Mile Posts

• Guideposts (traditional fingerposts only)

• Kerb Barriers

• Gates across roads

• Posts preventing vehicular access

• Weighbridges

• Cattle Grids

Road-bounding features:

• Hedges, Walls, Fences, and Banks

• Crash Barriers (where they form the sole bounding feature of a carriageway)

Non-physical features shown in this theme are represented as distinctive and descriptive text and inferred links.

There are two situations where constraints on how the features are depicted are normally imposed by survey tolerances:

• Where the central alignment of an unmade path is less than 1m (urban areas) or 2m (rural and moorland) from an adjacent building, fence, hedge or wall, the central alignment is shown at that minimum distance away from the feature.

• Where one edge of a track is parallel and close to the bank of a water feature, the track edge nearest to the river is omitted.

It is important to note that rights of way are not identified in OS MasterMap Topography Layer. The representation of a road, track or path cannot be used as evidence of a right of way.

For Ordnance Survey purposes, antiquities are defined as existing artificial features of a date not later than AD 1714 (the date of the accession of George I). These antiquities are captured along with very important battlefield sites and natural features connected with important historic events. Features and sites of a date later than AD 1714 may be treated as antiquities as an exception if they are of national importance.

The investigation, recording and surveying of archaeology is the responsibility of English Heritage, Historical Environment Scotland (HES) and Cadw (Wales). Antiquity find sites are not shown in OS MasterMap Topography Layer. Ordnance Survey has no responsibility for defining the authenticity of distinctive or descriptive names of antiquities.

Due to the variety of physical features in the Heritage and Antiquities theme, an exhaustive list is not provided, but the following are included:

• Standing Stones

• Earthworks

• Hill Figures

• Ruined Buildings

• Tombs

• Stone Circles

Some non-physical features are shown in the Heritage and Antiquity theme, including:

• Textual Descriptions for the real-world objects

• Battle Sites, as either text or a symbol

There are some limitations on what can be shown, imposed by survey principles. Many earthworks are of low relief and do not meet Ordnance Survey’s minimum criteria. To depict the feature clearly, it may be necessary to exaggerate antiquity detail. In mountain and moorland areas, some antiquity features may be generalised, without losing the essential characteristics of the depiction.

This defines the height above ground level of a feature (heightAboveGroundLevel attribute) and defines the accuracy of this, where known (accuracyOfHeightAboveGroundLevel attribute). This attribute is only present in the Topographic Line and the Topographic Point Feature Types.

heightAboveGroundLevel

Height of the feature above ground level, in metres. Forms part of the heightAboveGroundLevel complex attribute.

• Attribute Name: heightAboveGroundLevel

• Type: Real

• Multiplicity: [1]

accuracyOfHeightAboveGroundLevel

The accuracy of the vertical position in metres at the 95% confidence level. Forms part of the heightAboveGroundLevel complex attribute.

• Attribute Name: accuracyOfHeightAboveGroundLevel

• Type: String

• Multiplicity: [1]

Rail features are defined as features related to travel by railway or tramway. The exception to this is railway tunnels, which are currently in the Structures theme. OS MasterMap Topography Layer contains information relating to permanent railways that form the network between two points, for example, from railway station to railway station, or from an industrial building to a private quarry.

Standard-gauge railways are shown to scale by a pair of rails and represent tracks 1.435m apart. Railways narrower than 1.435m are deemed to be narrow gauge and are shown by a single line representing the central alignment. Tramways, metros, and light-rapid-transit systems are treated as railways.

Underground portions of the Metropolitan and District lines in London that are close to surface level are shown; where a deep-level tube railway comes to the surface and continues as a normal railway, it is shown as a standard-gauge railway. In other cities, only the sections of underground railways that are open to the sky are currently shown.

Physical features shown in the Rail theme include:

• Level Crossings

• Lighting Towers

• Loading Gauges

• Turntables

• Mile or Kilometre Posts and Stones

• Sand Drags

• Signal Posts, Bridges, and Gantries

• Switches and Slips

• Retarders

• Bridges and Viaducts

• Mail Pick-ups

• Rails

• Permanent Ways

• Station Buildings and Platforms

Some physical features are not shown in the Rail theme:

• Telephones associated with Level Crossings

• Conductor Rails and Overhead wires for electrified trains

• Detail beneath the roofs of Railway Stations

• Water Troughs

• Repetitive Features, such as signal lights within marshalling yards

Some non-physical features are shown in the Rail theme: these are text descriptions of railway and associated railway features.

Information about the change history of a feature that comprises the reason for the change (reasonForChange attribute) and the date for this change (changeDate attribute). Each feature may have numerous change history records and these are ordered chronologically in the attribute. This attribute is present in all six feature types.

reasonForChange

The reason for a change made to a feature. Forms part of the feature’s complex attribute, changeHistory.

• Attribute Name: reasonForChange

• Type: String

• Multiplicity: [1]

changeDate

The date a change was made to the feature by an editor. Forms part of the feature’s complex attribute, changeHistory.

• Attribute Name: changeDate

• Type: String

• Multiplicity: [1]

This contains information about the height above Ordnance Datum Newlyn (ODN; heightAboveDatum attribute) and, where known, the accuracy of this value (accuracyOfHeightAboveDatum attribute). This attribute is only present in the Topographic Line and the Topographic Point Feature Types.

heightAboveDatum

The height of the feature above the ODN vertical datum, in metres. Forms part of the heightAboveDatum complex attribute.

• Attribute Name: heightAboveDatum

• Type: Real

• Multiplicity: [1]

accuracyOfHeightAboveDatum

The accuracy of the vertical position in metres at the 95% confidence level. Forms part of the heightAboveDatum complex attribute.

• Attribute Name: accuracyOfHeightAboveDatum

• Type: String

• Multiplicity: [1]

OS MasterMap Topography Layer provides the most detailed and accurate large-scale representation of Great Britain available from Ordnance Survey. It contains features that represent objects in the physical environment, such as buildings, fields, fences, and letter boxes. It also includes intangible objects, such as county boundaries and the lines of mean high or low waters. There are over 500 million features in the product. Coverage includes the whole of Great Britain (i.e. England, Scotland, and Wales).

Key concepts

The three key concepts underlying OS MasterMap Topography Layer are:

• A feature model with identifiable and persistent features.

• Feature lifecycles defined to match actual change.

• Integration of the OS MasterMap suite of products.

Feature model

OS MasterMap Topography Layer is created on the premise of a feature-based model. This models the real world at the level of the feature, which represents an object in the real world. Each feature has an identity, location and other additional attribution.

Feature lifecycle

The features that comprise OS MasterMap Topography Layer are managed by feature lifecycle rules. These rules manage how changes in real-world objects are represented by the features in OS MasterMap Topography Layer. The rules define what real-world change constitutes a modification to an existing feature, and what change is represented by a new feature. This management allows a consistent representation of changes in the real world, based upon the capture specification.

Integration of the OS MasterMap layers

The suite of layers that make up OS MasterMap have been modelled to allow simple integration with each other. All the layers are managed in a single capture and maintenance environment, meaning the geometries of the different layers are in sympathy with each other, allowing easy integration. Additionally, they all invoke the principle of the Topographic Object Identifier (TOID) and use this as their unique IDs.

Available formats

OS MasterMap Topography Layer is available the following formats:

• GeoPackage (area of interest – AOI – only)

• Vector tiles (MBTiles)

• Geography Markup Language (GML) 2.1.2

Adherence to standards

UML diagram and table conventions

The data structure in this document is described by means of Unified Modeling Language (UML) class diagrams and accompanying tables containing text.

The following colour conventions have been used in the UML diagrams and tables: feature types from the Ordnance Survey product specification are orange, data types are in purple, and enumerations are green.

Metadata

ISO 19115 compliant UK GEMINI discovery level metadata is provided for the data and can be found in the OS Data Catalogue.

Index

• File naming

• Supply mechanisms

• Product themes

• Feature types

• Complex attributes

• Enumerations

• Geometric data types

• Topology

• Seamless data supply

• Feature lifecycles and tracking changes

• GML overview

• GeoPackage overview

• Vector Tiles overview

• Attribute mapping

• Geometry mapping

• COU overview

• Feature code lookup table

• Change value descriptions

• Administrative boundary alignments

Water features are defined as features that contain, delimit, or relate to real-world objects containing water.

Physical water features shown in OS MasterMap Topography Layer include:

• Mean High Water (springs) and Mean Low Water (springs)

• Swimming Pools, Ponds, Lakes, and Lochs

• Moats, Bridges, and Footbridges

• Reservoirs, Rivers, Canals, and Streams

• Drains and Ditches

• Foreshore Features

• Floating Objects (they are only shown when they are fixed and attached to permanent detail)

• Shake Holes and Swallow Holes (in mountain and moorland areas; limits of numerous shake holes are shown, and the area described as ‘area of shake holes’)

• Sluices (except those found in sewage works) and Culverts

• Stepping Stones

• Taps (which take the form of drinking fountains or that form the communal water supply), Drinking Fountains and Water Troughs (public)

• Tidal Gauges

• Waterfalls (only if formed by natural features) and Weirs

• Bollards, Capstans, and Mooring Posts

• Breakwaters and Groynes

• Perches, Pilot Beacons, and Navigational Beacons

• Pumps, Wells, Spouts, Springs, and Fountains

Taps, water troughs and drinking fountains are no longer captured under the current specification.

The image below shows a sample of real-world objects in the Water theme, including a pond, a river, flow arrows, sluices, and drains:

Non-physical features shown in the Water theme are:

• The highest point in a river to which normal tides flow; this is described as the Normal Tidal Limit (NTL). The point is shown and annotated with text.

• Low Water Level (LWL); this is the point to which mean tides (or mean spring tides in Scotland) flow at low water. The point is shown and annotated with text.

• Textual descriptions of all water features.

• Flow arrows, which are symbols used to indicate the direction of flow of non-tidal moving water.

As water is a dynamic element within the landscape, certain survey principles and constraints are imposed on the representation of water within OS MasterMap Topography Layer.

Rivers, streams, and drains are shown at their true scale width. A single line is normally used where their width is less than:

• 1.0m in urban areas

• 2.0m in rural, mountain and moorland areas

OS MasterMap Topography Layer does not contain polygons of the open sea. Where inland water bodies meet the sea, the following principles are applied:

• Ordnance Survey shows high and low water marks of a mean average tide, that is, an average tide halfway between spring and neap tides in England and Wales, and of average spring tides in Scotland.

• In tidal rivers, the point to which mean tides (or spring tides in Scotland) flow at high or low water is included.

Lakes and ponds are surveyed at normal winter level; reservoirs are shown at top water level, that is, spill over level. All water features are described. Continuous topographical water features that extend into private gardens are shown. Where a river flows under another object, typically a bridge, the part of the river beneath the object is not supplied. This is why there are gaps in rivers when the theme is viewed on its own. An example of such a gap in a river is shown below:

Features representing topographic objects that have a polygon-based geometry (for example, Building).

• Spatial attribute: polygon

• Data type attribute: GM_Surface

TopographicArea attributes

TOID or gml:id

The unique topographic reference number. It consists of the letters ‘osgb’ followed by thirteen or sixteen digits. The TOID must always be retained/stored in its entirety and any leading zeros on the TOID are retained to permit linking of the feature to other OS MasterMap products.

• Attribute Name: TOID or gml:id

• Type: String

• Multiplicity: [1]

featureCode

Topographic features have a numerical feature code (a five-digit integer) assigned to each feature. This feature code is wholly determined by the feature type, the descriptive group(s) and the descriptive term(s). The feature code does not add any information to that contained in these attributes. The physicalLevel, physicalPresence and make attributes do not affect the feature code.

The feature code itself is arbitrarily assigned and is therefore not informative without the look-up table that gives the feature type and attribute values corresponding to each feature code.

• Attribute Name: featureCode (GML), feature_code (GeoPackage), N/A (Vector Tiles)

• Type: Integer

• Multiplicity: [1]

version

The version number of the feature (in the range of 1 to 4294967295). This uniquely identifies a specific version of a feature with a given TOID.

• Attribute Name: version (GML), Version (GeoPackage), N/A (Vector Tiles)

• Type: Integer

• Multiplicity: [0..1]

versionDate

The date on which this version of the feature became the current version. This is the date on which the feature was changed in the database and is not the date of any associated real-world change.

• Attribute Name: versionDate (GML), version_date (GeoPackage), N/A (Vector Tiles)

• Type: Date

• Multiplicity: [1]

theme

A theme that the feature belongs to.

• Attribute Name: theme (GML), Theme (GeoPackage), theme (Vector Tiles)

• Multiplicity: [1..*]

calculatedAreaValue

This is the calculated area of a polygon feature in square metres.

• Attribute Name: calculatedAreaValue (GML), calculated_area_value (GeoPackage), N/A (Vector Tiles)

• Type: Measure

• Multiplicity: [1]

changeHistory

Information about the change history of a feature that comprises the reason for the change and the date for this change. Each feature may have numerous change history records, and these are ordered chronologically. A complex attribute.

• Attribute Name: changeHistory

• Multiplicity: [1..*]

descriptiveGroup

This is the primary classification attribute of a feature.

It assigns a feature to one or more of 21 groups, most of which are categories of real-world topographic objects, such as path, building or natural environment; others are categories of supportive or administrative features, such as network or polygon closing geometry and political or administrative. In general, values of this attribute are not specific to particular feature types.

Due to limitations in the source data from which OS MasterMap was created, there are some exceptions to this principle. For instance, the descriptiveGroup buildings or structure contains text describing or naming buildings and structures, while the topographic features have the descriptiveGroup values of building, glasshouse or structures.

• Attribute Name: descriptiveGroup (GML), descriptive_group (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [1..*]

descriptiveTerm

This attribute, if present, gives further classification information about the feature.

A feature may have multiple descriptiveTerm attributes, but this is little used at present. Most features have zero or one descriptiveTerm attributes. A situation where multiple descriptiveTerm attributes are used is where area features have a descriptiveGroup with the value of ‘Natural Environment’. These features can have one or more descriptiveTerm attributes specifying the natural land cover types present in the area.

• Attribute Name: descriptiveTerm (GML), descriptive_term (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [0..*]

make

Where known, indicates whether the real-world nature of the feature is man-made or natural.

• Attribute Name: make (GML), Make (GeoPackage), N/A (Vector Tiles)

• Type: MakeValue

• Multiplicity: [0..1]

physicalLevel

This attribute states whether the feature is underground, obscured below normal cartographic level, at normal cartographic level, or overhead.

Normal cartographic level perceived to be the normal surface level. Where an area feature overlies another (for example, bridges), they are at normal cartographic level and the features below them are recorded as obscured.

Indicates the physical level of a feature with reference to the normal cartographic surface level. Only four values are used: -1 = Underground detail 49 = Obscured detail below the normal cartographic level 50 = Detail at the normal cartographic level 51 = Overhead detail above normal cartographic level

• Attribute Name: physicalLevel (GML), physical_level (GeoPackage), N/A (Vector Tiles)

• Type: Integer

• Multiplicity: [1]

physicalPresence

This attribute indicates the nature of the object represented by the feature. This is normally used for TopographicLine, for example, a value of ‘obstructing’ indicates that the feature prevents pedestrian access, whereas a value of ‘edge/limit’ means that the feature represents a change of surface type and does not generally impede access. This attribute is also used to identify administrative boundary and inferred line features, and moveable area features (for example, moveable cranes).

• Attribute Name: physicalPresence (GML), physical_presence (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [0..1]

polygon

A polygon is a single closed region defined by a set of lines that represent the boundaries.

• Attribute Name: polygon

• Type: GM_Surface

• Multiplicity: [1]

Features providing information on symbols used when rendering OS MasterMap Topography Layer graphically (for example, Culvert).

• Spatial attribute: point

• Data type attribute: GM_Point

CatographicSymbol

TOID or gml:id

The unique topographic reference number. It consists of the letters ‘osgb’ followed by thirteen or sixteen digits. The TOID must always be retained / stored in its entirety and any leading zeros on the TOID are retained to permit linking of the feature to other OS MasterMap products.

• Attribute Name: TOID or gml:id

• Type: String

• Multiplicity: [1]

featureCode

Topographic features have a numerical feature code (a five-digit integer) assigned to each feature. This feature code is wholly determined by the feature type, the descriptive group(s) and the descriptive term(s). The feature code does not add any information to that contained in these attributes. The physicalLevel, physicalPresence and Make attributes do not affect the feature code.

The feature code itself is arbitrarily assigned and is therefore not informative without the look-up table that gives the feature type and attribute values corresponding to each feature code.

• Attribute Name: featureCode (GML), feature_code (GeoPackage), N/A (Vector Tiles)

• Type: Integer

• Multiplicity: [0..1]

version

The version number of the feature (in the range of 1 to 4294967295). This uniquely identifies a specific version of a feature with a given TOID.

• Attribute Name: version (GML), Version (GeoPackage), N/A (Vector Tiles)

• Type: Integer

• Multiplicity: [0..1]

versionDate

The date on which this version of the feature became the current version. This is the date on which the feature was changed in the database and is not the date of any associated real-world change.

• Attribute Name: versionDate (GML), version_date (GeoPackage), N/A (Vector Tiles)

• Type: Date

• Multiplicity: [1]

theme

A theme that the feature belongs to.

• Attribute Name: theme (GML), Theme (GeoPackage), theme (Vector Tiles)

• Multiplicity: [1..*]

changeHistory

Information about the change history of a feature that comprises the reason for the change and the date for this change. Each feature may have numerous change history records, and these are ordered chronologically. A complex attribute.

• Attribute Name: changeHistory

• Multiplicity: [1..*]

descriptiveGroup

This is the primary classification attribute of a feature.

It assigns a feature to one or more of 21 groups, most of which are categories of real-world topographic objects, such as path, building or natural environment; others are categories of supportive or administrative features, such as network or polygon closing geometry and political or administrative. In general, values of this attribute are not specific to particular feature types.

• Attribute Name: descriptiveGroup (GML), descriptive_group (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [1..*]

descriptiveTerm

This attribute, if present, gives further classification information about the feature. A feature may have multiple descriptiveTerm attributes, but this is little used at present. Most features have zero or one descriptiveTerm attributes.

• Attribute Name: descriptiveTerm (GML), descriptive_term (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [0..*]

orientation

The orientation of symbol features for cartographic placement. Given in tenths of a degree anticlockwise from due east (0–3599).

• Attribute Name: orientation (GML), Orientation (GeoPackage), orientation (Vector Tiles)

• Type: Integer

• Multiplicity: [1]

physicalLevel

This attribute states whether the feature is underground, obscured below normal cartographic level, at normal cartographic level, or overhead.

Normal cartographic level is that perceived to be the normal surface level. Where an area feature overlies others (for example, bridges), they are at normal cartographic level and the features below them are recorded as obscured.

• Attribute Name: physicalLevel (GML), physical_level (GeoPackage), N/A (Vector Tiles)

• Type: Integer

• Multiplicity: [1]

physicalPresence

This attribute indicates the nature of the object represented by the feature. This is normally used for TopographicLine, for example, a value of ‘obstructing’ indicates that the feature prevents pedestrian access, whereas a value of ‘edge/limit’ means that the feature represents a change of surface type and does not generally impede access. This attribute is also used to identify administrative boundary and inferred line features, and moveable area features (for example, moveable cranes).

• Attribute Name: physicalPresence (GML), physical_presence (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [0..1]

point

A pair of easting and northing ordinates in metres, defining a horizontal location in the British National Grid spatial reference system.

• Attribute Name: point

• Type: GM_Point

• Multiplicity: [1]

referenceToFeature

A reference by TOID to a related feature. In cartographic symbol features, it is used to point from the symbol feature to the topographic feature to which it refers.

• Attribute Name: N/A (GML), reference_to_feature (GeoPackage), N/A (Vector Tiles)

• Type: String

• Multiplicity: [1]

Feature representing topographic objects and concepts that have a line-based geometry (for example, Fence).

• Spatial attribute: polyline

• Data type attribute: GM_Curve or GM_MultiCurve

TopographicLine attributes

TOID or gml:id

The unique topographic reference number. It consists of the letters ‘osgb’ followed by thirteen or sixteen digits. The TOID must always be retained/stored in its entirety and any leading zeros on the TOID are retained to permit linking of the feature to other OS MasterMap products.

• Attribute Name: TOID or gml:id

• Type: String

• Multiplicity: [1]

featureCode

Topographic features have a numerical feature code (a five-digit integer) assigned to each feature. This feature code is wholly determined by the feature type, the descriptive group(s) and the descriptive term(s). The feature code does not add any information to that contained in these attributes. The physicalLevel, physicalPresence and make attributes do not affect the feature code.

The feature code itself is arbitrarily assigned and is therefore not informative without the look-up table that gives the feature type and attribute values corresponding to each feature code.

• Attribute Name: featureCode (GML), feature_code (GeoPackage), N/A (Vector Tiles)

• Type: Integer

• Multiplicity: [1]

version

The version number of the feature (in the range 1 to 4294967295). This uniquely identifies a specific version of a feature with a given TOID.

• Attribute Name: version (GML), version (GeoPackage), N/A (Vector Tiles)

• Type: Integer

• Multiplicity: [0..1]

versionDate

The date on which this version of the feature became the current version. This is the date on which the feature was changed in the database and is not the date of any associated real-world change.

• Attribute Name: versionDate (GML), version_date (GeoPackage), N/A (Vector Tiles)

• Type: Date

• Multiplicity: [1]

theme

A theme that the feature belongs to.

• Attribute Name: theme (GML), theme (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [1..*]

accuracyOfPosition

The accuracy of a horizontal position in metres at the 95% confidence level.

• Attribute Name: accuracyOfPosition (GML), accuracy_of_position (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [1]

changeHistory

Information about the change history of a feature that comprises the reason for the change and the date for this change. Each feature may have numerous change history records, and these are ordered chronologically. A complex attribute.

• Attribute Name: changeHistory

• Multiplicity: [1..*]

descriptiveGroup

This is the primary classification attribute of a feature.

It assigns a feature to one or more of 21 groups, most of which are categories of real-world topographic objects, such as path, building or natural environment; others are categories of supportive or administrative features, such as network or polygon closing geometry and political or administrative. In general, values of this attribute are not specific to particular feature types.

Due to limitations in the source data from which OS MasterMap was created, there are some exceptions to this principle. For instance, the descriptiveGroup buildings or structure contains text describing or naming buildings and structures, while the topographic features have the descriptiveGroup values of building, glasshouse or structures.

• Attribute Name: descriptiveGroup (GML), descriptive_group (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [1..*]

descriptiveTerm

This attribute, if present, gives further classification information about the feature.

A feature may have multiple descriptiveTerm attributes. Most features have zero or one descriptiveTerm attributes. A situation where multiple descriptiveTerm attributes are used is where line features have a descriptiveGroup with the value of ‘Tidal Water’. These features may have multiple descriptiveTerm attributes, for example, where Mean High Water (Springs) and Mean Low Water (Springs) are co-incident.

• Attribute Name: descriptiveTerm (GML), descriptive_term (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [0..*]

nonBoundingLine

Indicates that a TopographicLine feature is not on the boundary of a TopographicArea feature.

• Attribute Name: nonBoundingLine (GML), non_bounding_line (GeoPackage), N/A (Vector Tiles)

• Type: Boolean

• Multiplicity: [0..1]

heightAboveDatum

A complex attribute that is comprised of two simple attributes. The height of the feature above the Ordnance Datum Newlyn (ODN) vertical datum (in metres) is defined in the ‘heightAboveDatum’ attribute. The accuracy of the vertical position in metres at the 95% confidence level is defined by the ‘accuracyOfHeightAboveDatum’ attribute.

• Attribute Name: heightAboveDatum (GML), height_above_datum (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [0..1]

heightAboveGroundLevel

A complex attribute that is comprised of two simple attributes. The height of the feature above ground level (in metres) is defined in the ‘heightAboveGroundLevel’ attribute. The accuracy of the vertical position in metres at the 95% confidence level is defined by the ‘accuracyOfHeightAboveGroundLevel’ attribute.

• Attribute Name: heightAboveGroundLevel (GML), height_above_ground_level (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [0..1]

make

Where known, indicates whether the real-world nature of the feature is man-made or natural.

• Attribute Name: make (GML), make (GeoPackage), make (Vector Tiles)

• Multiplicity: [0..1]

physicalLevel

This attribute states whether the feature is underground, obscured below normal cartographic level, at normal cartographic level, or overhead.

Normal cartographic level is that perceived to be the normal surface level. Where an area feature overlies another (for example, bridges), they are at normal cartographic level and the features below them are recorded as obscured.

Indicates the physical level of a feature with reference to the normal cartographic surface level. Only four values are used:

-1 = Underground detail 49 = Obscured detail below the normal cartographic level 50 = Detail at the normal cartographic level 51 = Overhead detail above normal cartographic level

• Attribute Name: physicalLevel (GML), physical_level (GeoPackage), N/A (Vector Tiles)

• Type: Integer

• Multiplicity: [1]

physicalPresence

This attribute indicates the nature of the object represented by the feature. This is normally used for TopographicLine, for example, a value of ‘obstructing’ indicates that the feature prevents pedestrian access, whereas a value of ‘edge/limit’ means that the feature represents a change of surface type and does not generally impede access. This attribute is also used to identify administrative boundary and inferred line features, and moveable area features (for example, moveable cranes).

• Attribute Name: physicalPresence (GML), physical_presence (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [0..1]

polyline

This is either a Polyline or a Multiline geometry. In TopographicLine features, this will only be a Multiline if there is a problem with the geometry that is indicated by the broken metadata flag.

• Attribute Name: polyline

• Type: GM_MultiCurve

• Multiplicity: [1]

Features that define the content and placement of text when rendering OS MasterMap graphically (for example, Road Name or Classification).

• Spatial attribute: point

• Data type attribute: GM_Point

CartographicText attributes

TOID

The unique topographic reference number. It consists of the letters ‘osgb’ followed by thirteen or sixteen digits. The TOID must always be retained/stored in its entirety and any leading zeros on the TOID are retained to permit linking of the feature to other OS MasterMap products.

• Attribute Name: TOID

• Type: String

• Multiplicity: [1]

featureCode

Topographic features have a numerical feature code (a five-digit integer) assigned to each feature. This feature code is wholly determined by the feature type, the descriptive group(s) and the descriptive term(s). The feature code does not add any information to that contained in these attributes. The physicalLevel, physicalPresence and Make attributes do not affect the feature code.

The feature code itself is arbitrarily assigned and is therefore not informative without the look-up table that gives the feature type and attribute values corresponding to each feature code.

• Attribute Name: featureCode (GML), feature_code (GeoPackage), N/A (Vector Tiles)

• Type: Integer

• Multiplicity: [0..1]

version

The version number of the feature (in the range of 1 to 4294967295). This uniquely identifies a specific version of a feature with a given TOID.

• Attribute Name: version (GML), version (GeoPackage), N/A (Vector Tiles)

• Type: Integer

• Multiplicity: [0..1]

versionDate

The date on which this version of the feature became the current version. This is the date on which the feature was changed in the database and is not the date of any associated real-world change.

• Attribute Name: versionDate (GML), version_date (GeoPackage), N/A (Vector Tiles)

• Type: Date

• Multiplicity: [1]

theme

A theme that the feature belongs to.

• Attribute Name: theme (GML), theme (GeoPackage), theme (Vector Tiles)

• Multiplicity: [1..*]

anchorPoint

The coordinate position that a piece of text is positioned relative to. Measured in metres in the British National Grid spatial reference system.

• Attribute Name: anchorPoint

• Type: GM_Point

• Multiplicity: [1]

changeHistory

• Attribute Name: changeHistory

• Multiplicity: [1..*]

descriptiveGroup

This is the primary classification attribute of a feature. It assigns a feature to one or more of 21 groups, most of which are categories of real-world topographic objects, such as path, building or natural environment; others are categories of supportive or administrative features, such as network or polygon closing geometry and political or administrative. In general, values of this attribute are not specific to particular feature types.

• Attribute Name: descriptiveGroup

• Multiplicity: [0..*]

descriptiveTerm

This attribute, if present, gives further classification information about the feature. A feature may have multiple descriptiveTerm attributes, but this is little used at present. Most features have zero or one descriptiveTerm attributes.

• Attribute Name: descriptiveTerm (GML), descriptive_term (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [0..*]

make

Where known, indicates whether the real-world nature of the feature is man-made or natural.

• Attribute Name: make (GML), make (GeoPackage), make (Vector Tiles)

• Multiplicity: [0..1]

physicalLevel

This attribute states whether the feature is underground, obscured below normal cartographic level, at normal cartographic level, or overhead.

Normal cartographic level is that perceived to be the normal surface level. Where an area feature overlies another (for example, bridges), they are at normal cartographic level and the features below them are recorded as obscured.

• Attribute Name: physicalLevel (GML), physical_level (GeoPackage), N/A (Vector Tiles)

• Type: Integer

• Multiplicity: [1]

physicalPresence

This attribute indicates the nature of the object represented by the feature. This is normally used for TopographicLine, for example, a value of ‘obstructing’ indicates that the feature prevents pedestrian access, whereas a value of ‘edge/limit’ means that the feature represents a change of surface type and does not generally impede access. This attribute is also used to identify administrative boundary and inferred line features, and moveable area features (for example, moveable cranes).

• Attribute Name: physicalPresence (GML), physical_presence (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [0..1]

textRendering

Provides the information to graphically display a text string in harmony with the underlying map detail and consists of anchorPosition, font, height and orientation. textRendering is a complex attribute.

• Attribute Name: textRendering

• Multiplicity: [1]

textString

Textual information that can be rendered using the textRendering attribute.

• Attribute Name: textString (GML), text_string (GeoPackage), text_string (Vector Tiles)

• Type: String

• Multiplicity: [1]

Features representing the boundaries of administrative areas that have a line-based geometry (for example, Parish Boundary).

• Spatial attribute: polyline

• Data type attribute: GM_MultiCurve

BoundaryLine attributes

TOID or gml:id

The unique topographic reference number. It consists of the letters ‘osgb’ followed by thirteen or sixteen digits. The TOID must always be retained / stored in its entirety and any leading zeros on the TOID are retained to permit linking of the feature to other OS MasterMap products.

• Attribute Name: TOID or gml:id

• Type: String

• Multiplicity: [1]

featureCode

Topographic features have a numerical feature code (a five-digit integer) assigned to each feature. This feature code is wholly determined by the feature type, the descriptive group(s) and the descriptive term(s). The feature code does not add any information to that contained in these attributes. The physicalLevel, physicalPresence and make attributes do not affect the feature code.

The feature code itself is arbitrarily assigned and is therefore not informative without the look-up table that gives the feature type and attribute values corresponding to each feature code.

• Attribute Name: featureCode (GML), feature_code (GeoPackage), N/A (Vector Tiles)

• Type: Integer

• Multiplicity: [1]

version

The version number of the feature (in the range of 1 to 4294967295). This uniquely identifies a specific version of a feature with a given TOID.

• Attribute Name: version (GML), version (GeoPackage), N/A (Vector Tiles)

• Type: Integer

• Multiplicity: [0..1]

versionDate

The date on which this version of the feature became the current version. This is the date on which the feature was changed in the database and is not the date of any associated real-world change.

• Attribute Name: versionDate (GML), version_date (GeoPackage), N/A (Vector Tiles)

• Type: Date

• Multiplicity: [1]

theme

A theme that the feature belongs to.

• Attribute Name: theme (GML), theme (GeoPackage), theme (Vector Tiles)

• Multiplicity: [1..*]

accuracyOfPosition

The accuracy of a horizontal position in metres at the 95% confidence level.

• Attribute Name: accuracyOfPosition (GML), accuracy_of_position (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [1]

changeHistory

Information about the change history of a feature that comprises the reason for the change and the date for this change. Each feature may have numerous change history records and these are ordered chronologically. A complex attribute.

• Attribute Name: changeHistory

• Multiplicity: [1..*]

descriptiveGroup

This is the primary classification attribute of a feature.

It assigns a feature to one or more of 21 groups, most of which are categories of real-world topographic objects, such as path, building or natural environment; others are categories of supportive or administrative features, such as network or polygon closing geometry and political or administrative. In general, values of this attribute are not specific to particular feature types.

Due to limitations in the source data from which OS MasterMap was created, there are some exceptions to this principle. For instance, the descriptiveGroup buildings or structure contains text describing or naming buildings and structures, while the topographic features have the descriptiveGroup values of building, glasshouse or structures. NOTE: There is only ever one descriptiveGroup with the value of ‘Political Or Administrative’ on a BoundaryLine feature.

• Attribute Name: descriptiveGroup (GML), descriptive_group (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [1]

descriptiveTerm

This attribute, if present, gives further classification information about the feature.

A feature may have multiple descriptiveTerm attributes, but this is little used at present. Most features have zero or one descriptiveTerm attributes. A situation where multiple descriptiveTerm attributes are used is where area features have a descriptiveGroup with the value of ‘Natural Environment’. These features can have one or more descriptiveTerm attributes specifying the natural land cover types present in the area.

• Attribute Name: descriptiveGroup (GML), descriptive_group (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [0..*]

physicalLevel

This attribute states whether the feature is underground, obscured below normal cartographic level, at normal cartographic level, or overhead.

Normal cartographic level is that perceived to be the normal surface level. Where an area feature overlies another (for example, bridges), they are at normal cartographic level and the features below them are recorded as obscured.

Indicates the physical level of a feature with reference to the normal cartographic surface level. Only four values are used: -1 = Underground detail 49 = Obscured detail below the normal cartographic level 50 = Detail at the normal cartographic level 51 = Overhead detail above normal cartographic level

• Attribute Name: physicalLevel (GML), physical_level (GeoPackage), N/A (Vector Tiles)

• Type: Integer

• Multiplicity: [1]

physicalPresence

This attribute is also used to identify an administrative or political boundary.

• Attribute Name: physicalPresence (GML), physical_presence (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [1]

polyline

A polyline is an ordered set of points forming a line feature.

• Attribute Name: polyline

• Type: GM_MultiCurve

• Multiplicity: [1]

A land feature is defined as either a man-made or a natural polygon feature that describes the surface cover and area to which it is applied. This includes both natural and man-made slopes and cliffs. All general features are also placed in the Land theme. There are some exceptions to this, such as routes of communication and buildings.

Landform features, such as slopes and cliffs, behave slightly differently from other features as in the instances that they are represented as line features, they can cross other line features without being broken at the intersection of the line. Additionally, when they are polygon features, they can overlap other polygon features instead of sitting adjacent to them.

The Land theme encompasses those areas that do not form part of another theme. For example, a grass verge next to a road would appear in the Roads, Tracks, and Paths theme, whereas a grass area within a park would be in the Land theme.

The limits of geographic features such as hills and valleys are not recorded, although the distinctive names of these geographic features are shown when applicable.

Physical features shown in the Land theme include:

• Recreation areas such as Parks, Playing Fields, Football Pitches, and Golf Courses

• Slopes and Cliffs

• Car Parks

• Gardens

• Woodlands

• Areas of Vegetation (including scrub, heath, rough grass, and marshland) The Land theme also contains text features that describe the physical features.

In the image below, different types of vegetation cover have been identified on the edges of a settlement. Each type of vegetation has been labelled using the attribution within OS MasterMap Topography Layer:

Structures are defined as features that are man-made constructions but do not qualify as buildings

(for example, Band Stands and Clock Towers). These features may or may not obstruct passage at ground level. OS MasterMap Topography Layer contains information relating to all permanent structures that are considered large enough to be included. The image below gives some examples (highlighted in dark grey) of structures:

Physical features in the Structures theme include:

• Stand-Alone Monuments

• Fountains

• Covered Reservoirs

• Pylons

• Weirs and Sluices

• Gas Holders

• Double Walls

• Pontoons

• Uncovered Tanks

• Conveyors

• Cooling Towers

• Upper Levels of Communication

• Bridges, Viaducts, Aqueducts, and Piers Non-physical features are represented by text.

OS MasterMap Topography Layer is comprised of nine themes:

The following sub-sections describe the main features and content of each theme in detail. This will aid users’ understanding of which features they can find in the data and the most likely theme(s) that the feature will be found in. The rules governing which theme or themes are assigned to a feature are discussed in .

Wherever possible, real-world objects are represented in their true surveyed position. However, for the sake of clarity of display or plotting, real-world objects may be generalised. For example, parallel features and small juts in house fronts may not be shown. The normal methods of generalisation that can be applied to features are:

• Emphasis

• Selection for inclusion

• Simplification

• Omission

Real-world objects may also be simplified in OS MasterMap Topography Layer, for example, a small group of trees may be recorded as a single point or polygon feature. The following sub-sections give a breakdown, by feature type, of the themes in greater detail, including regional and cultural special designations.

Theme rules

There are several rules that govern what theme or themes are assigned to a feature. These rules give the data consistency so that the same kind of real-world objects are assigned to the same themes as far as possible.

There is one attribute – called the descriptive group attribute – that has a major bearing on the theme rules. The value in the descriptive group is the key determinant of which theme(s) is / are assigned to a feature. The table below relates the value of descriptive group (of which there are 21) to the theme. If the feature has the value listed in the first column, it will be assigned into the theme listed in the second column.

There are some additional rules for assigning lines to themes. Lines serve two purposes in OS MasterMap Topography Layer. There are lines that are coincident with the boundaries of polygon features; these are called bounding lines and they are the most common type of line. However, some lines do not form boundaries to features, but are a feature in their own right; these are called non-bounding line features.

In addition to being a member of each theme rule, a line feature that is part of the boundary of one or more polygon features is also considered a member of the theme of those polygon features which it bounds. For example, any line feature that bounds a polygon feature that is a member of the Roads, Tracks and Paths theme is also a member of the Roads, Tracks and Paths theme, in addition to any other themes to which it belongs. The image below gives examples of the application of theme rules:

The product themes pages discuss the themes of OS MasterMap Topography Layer and outline the contents of each theme and explain how Ordnance Survey allocates a feature to one or more themes. This helps users to understand which theme a feature is likely to be found in, and why some features may appear in a theme that may not seem logical on first appearance.

Layer Structure

In OS MasterMap Topography Layer, features are classified using feature type and feature description attributes. This section describes the feature types and shows their permitted attribution. The tables below provide the following information about each feature type attribute:

Attribute name and definition

The name of the attribute and what it is describing.

Attribute type

The nature of the attribute. The following values may occur:

Multiplicity

• [1] indicates that the attribute is mandatory and can only occur once. [1..*] indicates that the attribute is mandatory and can occur many times. [0..1] indicates that the attribute is optional; if present, it only occurs once.

• [0..*] indicates that the attribute is optional; if present, it can occur many times.

Feature type attributes

The product is comprised of six feature types:

Three of these are topographic feature types: TopographicPoint (such as a post), TopographicLine (such as Mean High Water) and TopographicArea (such as coniferous trees)

One is a boundary feature type: BoundaryLine (such as unitary authority boundary)

Two are cartographic feature types: CartographicSymbol and CartographicText

In addition, if a Change-Only Update (COU) Supply has been provided, the data may contain information about the movement and deletion of features (i.e. Inserts, Updates and Deletes). These are represented by the feature type called DepartedFeature. More information about COU is contained in Section 10 – COU overview.

Each of the six feature types is discussed in more detail in their sub-pages.

These are features that denote the ground level at any given point. OS MasterMap Topography Layer does not contain height contours, instead it contains height information point features of known height.

Triangulation stations

These are physical marks that represent points in the national triangulation scheme. The best-known form is the triangulation pillar, often found on hill or mountain tops. Other forms include triangulation points placed on church towers and flagpoles. The coordinates of a triangulation station in the data are not usually the very accurate coordinates for the control point. The accurate coordinates of the control point can be obtained from Ordnance Survey (see sub-section below on spot height). All triangulation stations are shown, except for buried and surface blocks.

Spot height

These are non-physical points, the altitude of which (relative to Ordnance Datum) has been determined by levelling. All current spot heights are shown by a point feature or symbol. The altitude to one decimal place of a metre is shown by a textual description. The latest information on Ordnance Survey’s GPS, triangulation and control points can be found on the .

Bench marks are represented in OS MasterMap Topography Layer as a symbol to mark their position. The values for these bench marks are available from the . It should be noted that the bench mark information is historic, and Ordnance Survey cannot guarantee its accuracy.

Features representing topographic objects and other concepts that have a point-based geometry (for example, Telephone Call Box).

• Spatial attribute: point

• Data type attribute: GM_Point

TopographicPoint attributes

TOID or gml:id

The unique topographic reference number consists of the letters ‘osgb’ followed by either thirteen or sixteen digits. The TOID must always be retained/stored in its entirety, and any leading zeros on the TOID are retained to permit linking of the feature to other OS MasterMap products.

• Attribute Name: TOID or gml:id

• Type: String

• Multiplicity: [1]

featureCode

Topographic features have a numerical feature code (a five-digit integer) assigned to each feature. This feature code is wholly determined by the feature type, the descriptive group(s) and the descriptive term(s). The feature code does not add any information to that contained in these attributes. The 'physicalLevel' attribute, 'physicalPresence' attribute and 'Make' attribute do not affect the feature code.

The feature code itself is arbitrarily assigned and is therefore not informative without the that gives the feature type and attribute values corresponding to each feature code.

• Attribute Name: featureCode (GML), feature_code (GeoPackage), N/A (Vector Tiles)

• Type: Integer

• Multiplicity: [0..1]

version

The version number of the feature (in the range 1 to 4294967295). This uniquely identifies a specific version of a feature with a given TOID.

• Attribute Name: version (GML), Version (GeoPackage), N/A (Vector Tiles)

• Type: Integer

• Multiplicity: [0..1]

versionDate

The date on which this version of the feature became the current version. This is the date on which the feature was changed in the database and is not the date of any associated real-world change.

• Attribute Name: versionDate (GML), version_date (GeoPackage), N/A (Vector Tiles)

• Type: Date

• Multiplicity: [1]

theme

A theme that the feature belongs to.

• Attribute Name: theme (GML), Theme (GeoPackage), theme (Vector Tiles)

• Multiplicity: [1..*]

accuracyOfPosition

The accuracy of a horizontal position in metres at the 95% confidence level.

• Attribute Name: accuracyOfPosition (GML), accuracy_of_position (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [1]

changeHistory

Information about the change history of a feature that comprises the reason for the change and the date for this change. Each feature may have numerous change history records, and these are ordered chronologically. A complex attribute.

• Attribute Name: changeHistory

• Multiplicity: [1..*]

descriptiveGroup

This is the primary classification attribute of a feature.

It assigns a feature to one or more of 21 groups, most of which are categories of real-world topographic objects, such as path, building or natural environment; others are categories of supportive or administrative features, such as network or polygon closing geometry and political or administrative. In general, values of this attribute are not specific to particular feature types.

Due to limitations in the source data from which OS MasterMap Topography Layer was created, there are some exceptions to this principle. For instance, the descriptiveGroup buildings or structure contain text describing or naming buildings and structures, while the topographic features have the descriptiveGroup values of building, glasshouse or structures.

• Attribute Name: descriptiveGroup (GML), descriptive_group (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [1..*]

descriptiveTerm

This attribute, if present, gives further classification information about the feature.

A feature may have multiple descriptiveTerm attributes. Most features have zero or one descriptiveTerm attribute/s. Multiple descriptiveTerm attributes occur in several different scenarios, such as where point features have a descriptiveGroup with the value of ‘Structure’ or ‘Inland Water’. These features can have one or more descriptiveTerm attributes specifying the type of feature shown by the point.

• Attribute Name: descriptiveTerm (GML), descriptive_term (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [0..*]

heightAboveDatum

A complex attribute that is comprised of two simple attributes. The height of the feature above the Ordnance Datum Newlyn (ODN) vertical datum (in metres) is defined in the ‘heightAboveDatum’ attribute The accuracy of the vertical position in metres at the 95% confidence level is defined by the ‘accuracyOfHeightAboveDatum’ attribute.

• Attribute Name: heightAboveDatum (GML), height_above_datum (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [0..1]

heightAboveGroundLevel

A complex attribute that is comprised of two simple attributes. The height of the feature above ground level (in metres) is defined in the ‘heightAboveGroundLevel’ attribute. The accuracy of the vertical position in metres at the 95% confidence level is defined by the ‘accuracyOfHeightAboveGroundLevel’ attribute.

• Attribute Name: heightAboveGroundLevel (GML), height_above_ground_level (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [0..1]

make

Where known, indicates whether the real-world nature of the feature is man-made or natural.

• Attribute Name: make (GML), Make (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [0..1]

physicalLevel

This attribute states whether the feature is underground, obscured below normal cartographic level, at normal cartographic level or overhead.

Normal cartographic level is that perceived to be the normal surface level. Where an area feature overlies another (for example, bridges), they are at normal cartographic level and the features below them are recorded as obscured.

Indicates the physical level of a feature with reference to the normal cartographic surface level. Only four values are used:

• Attribute Name: physicalLevel (GML), physical_level (GeoPackage), N/A (Vector Tiles)

• Type: Integer

• Multiplicity: [1]

physicalPresence

This attribute indicates the nature of the object represented by the feature. This is normally used for TopographicLine, for example, a value of ‘obstructing’ indicates that the feature prevents pedestrian access, whereas a value of ‘edge/limit’ means that the feature represents a change of surface type and does not generally impede access. This attribute is also used to identify administrative boundary and inferred line features, and moveable area features (for example, moveable cranes).

• Attribute Name: physicalPresence (GML), physical_presence (GeoPackage), N/A (Vector Tiles)

• Multiplicity: [0..1]

point

A pair of easting and northing ordinates in metres, defining a horizontal location in the British National Grid spatial reference system.

• Attribute Name: point

• Type: GM_Point

• Multiplicity: [1]

A complex attribute is an attribute that consists of two or more simple attributes that go together to convey some composite information about a feature. They only exist within the GML format.

Further information on complex attributes in OS MasterMap Topography Layer is detailed in the following sub-pages.

ThemeValue attributes

• Administrative Boundaries

• Buildings

• Heritage And Antiquities

• Land

• Rail

• Roads Tracks And Paths

• Structures And Height

• Water

DescriptiveGroupValue attributes

• Building

• Buildings Or Structure

• Built Environment

• General Feature

• General Surface

• Glasshouse

• Height Control

• Historic Interest

• Inland Water

• Landform

• Natural Environment

• Network Or Polygon Closing Geometry

• Path

• Political Or Administrative

• Rail

• Road Or Track

• Roadside

• Structure

• Terrain And Height

• Tidal Water

• Unclassified

AccuracyOfPositionValue attributes

• 1.0m

• 2.0m

• 5.0m

• 6.0m

• 8.0m

• Unknown

Provides the information to graphically display a text string in harmony with the underlying map detail and consists of anchorPosition, font, height and orientation attributes. This attribute is only present in the Cartographic Text Feature Type.

anchorPosition

A number between 0 and 8 that specifies which part of the text is bound to the anchorPoint. Forms part of the feature’s complex attribute, textRendering.

• Attribute Name: anchorPosition

• Type: Integer

• Multiplicity: [1]

font

A value of 0, 1, 2 or 3 that can be used as a basis for determining which font to use when displaying the text. For example, a user application could associate Verdana with 2 to display all text with a font of 2 in Verdana. Forms part of the feature’s complex attribute, textRendering.

• Attribute Name: font

• Type: Integer

• Multiplicity: [1]

height

The height of CartographicText. The height is expressed as the distance on the ground covered by the text, in metres. Forms part of the feature’s complex attribute, textRendering.

• Attribute Name: height

• Type: Measure

• Multiplicity: [1]

orientation

The orientation of text for cartographic placement. Given in tenths of a degree anticlockwise from due east (0–3599). Forms part of the feature’s complex attribute, textRendering.

• Attribute Name: orientation

• Type: Integer

• Multiplicity: [1]

ReasonForChangeValue attributes

• Attributes

• Incomplete

• Modified

• New

• Position

• Reclassified

• Restructured

• SoftwareChange

• TextChange

PhysicalPresenceValue attributes

• Boundary

• Closing

• Edge / Limit

• Extent

• Indicator

• Minor Detail

• Moveable

• Network

• Obstructing

• Overhead

MakeValue attributes

• Manmade

• Multiple

• Natural

• Unclassified

• Unknown

Features within OS MasterMap Topography Layer have a lifecycle which is matched, where possible, to that of the real-world object they represent. For example, a new building becomes a new object in the Ordnance Survey main database and is treated as one feature, even if it undergoes change, until the building is demolished. With this approach, Ordnance Survey is emulating real-world behaviour within a digital model. Not all change to the real-world object will be reflected in a change to the feature. For example, the addition of a new porch to a house would usually be considered too minor a change to capture.

Different applications of the data will require different views of feature lifecycles. For some users, any change to the geometry or classification of a feature means it is no longer the same feature for their application, whilst others need persistence of features – so a feature continues to exist through extensive modification. Understanding change is important to understanding OS MasterMap Topography Layer and deriving the optimum value from it.

Lifecycle rules adopt the approach of allowing features to persist through changes, so far as is reasonable. There is inevitably some subjectivity involved in judging that a real-world object has changed so much it can no longer be considered the same object, so specific rules exist to govern this.

Topographic Object Identifiers

Ordnance Survey provides persistent managed identifiers as Topographic Object Identifiers (TOIDs). A TOID is a unique identifier, consisting of the letters ‘osgb’ followed by either 13 or 16 digits between 0 and 9. The TOID is allocated sequentially when a feature is created by Ordnance Survey and is never reassigned to a different feature. One of the key principles of unique referencing is that the TOID will stay the same throughout the life of a feature. This gives the feature continuity within its lifecycle and makes managing change in a holding of the product easier.

The TOID is provided in the GML attribute ‘fid’ of the osgb:Feature element, as shown below:

<osgb:TopographicArea fid='osgb1000000324268289'>

TOIDs enable explicit, maintained references between features in different layers. Other OS MasterMap products reference Topography Layer polygon features within which they are located, allowing the user to navigate between OS MasterMap products using the TOID.

The allocated TOID should never be shortened or amended as this will result in it not being compatible with other OS MasterMap products.

Feature version numbers

Although the nature of a feature might remain essentially the same throughout its life, it is likely to undergo change to its geometry or attributes. Each feature has a version number which is incremented each time there is change of any kind to the feature via one of its attributes. The change can be due either to real- world change or to processes not connected with a real-world change, such as error correction, geometric cleaning, and structuring of the data.

The previous version is referred to as the superseded version, and the new version as the superseding version. In a small minority of cases, a new version of a feature can be created without any apparent change to the product. This is due to change to internal database attributes used in the maintenance process but not included in product data.

Feature version date

The date on which the new version is created is recorded in the feature version date attribute. The date is important for tracking and identifying when change has taken place. Using the TOID, the version number and the version date, it is possible to track a feature’s changes over time. The date the version changed for Ordnance Survey will be different from the date on which the feature is loaded into the user’s file or database holding. Many translators provide an additional column to record the load date. It is important for the user to identify these dates in their holdings and to understand the difference between them if they want to be able to track changes.

One of the key differences between OS MasterMap features and other products is that, with the correct data storage model, a data holding can be rolled back and forward to a given point in time. It must be emphasised that this is the user’s responsibility, since only the current version is available in the product; none of the previous versions are included.

Lifecycle rules

The following sub-sections set out the rules that define the lifecycles of features in OS MasterMap Topography Layer. By understanding how change is defined and recorded within the product, users can start to identify what kind of change has a bearing on their applications and develop their own management regimes.

• Polygon feature lifecycle rules

• Line feature lifecycle rules

• general point feature lifecycle rules

The lifecycles of point features are simpler than those of lines or polygons since they cannot change in size or be split into multiple features.

Creation of point features

When a new real-world object comes into being, a new point feature is created to represent it. If, however, the object is a replacement for a previous real-world object in the same position, the original feature is retained. An example would be if an existing post box was replaced by another post box in the same location.

Deletion of point features

When a real-world object is no longer present in the real world, the point feature is removed from Ordnance Survey’s holding. Ordnance Survey keeps a record to indicate that the feature with this TOID used to exist and notifies the user at the next date of COU supply.

Modification of point features due to real-world change

By the nature of the real-world objects represented as point features in OS MasterMap Topography Layer data, it is unlikely that one will be modified without changing its identity. Therefore, any modification to a point feature as a result of real-world change will result in the deletion of the original feature and creation of a new feature, unless there is a clear reason to identify the resultant real-world object with the original. This applies to both geometric change and change of descriptive group or descriptive term.

Modification of point features due to error correction

When a point feature is found to be incorrectly attributed due to an error or is moved due to the correction of a positional accuracy error, the original feature is retained and appropriately modified.

This section has explained in some detail the lifecycles of features so that users can understand how the data is managed by Ordnance Survey.

DescriptiveTermValue attributes

• Agricultural Land

• Aqueduct

• Archway

• Bench Mark

• Bottom Of Cliff

• Bottom Of Slope

• Boulders

• Boulders (Scattered)

• Boundary Half Mereing

• Boundary Post Or Stone

• Bridge

• Buffer

• Canal

• Canal Feeder

• Capstan

• Cattle Grid

• Cave

• Chimney

• Collects

• Compound

• Conduit

• Coniferous Trees

• Coniferous Trees (Scattered)

• Conveyor

• Coppice Or Osiers

• County

• Course Of Heritage

• Crane

• Cross

• Culvert

• Direction Of Flow

• Distance Marker

• District

• Disused Feature

• Division

• Drain

• Electoral

• Electricity Sub Station

• Emergency Telephone

• Flagstaff

• Footbridge

• Ford

• Foreshore

• Fountain

• Gantry

• Gas Governor

• Groyne

• Guide Post

• Heath

• Inferred Property Closing Link

• Issues

• Landfill

• Landfill (Inactive)

• Letter Box

• Level Crossing

• Lighting Gantry

• Line Of Mooring Posts

• Line Of Posts

• Lock

• Lock Gate

• Marth

• Marsh Reeds Or Saltmarsh

• Mast

• Mean High Water (Springs)

• Mean Low Water (Springs)

• Mill Leat

• Mine Leat

• Mineral Workings

• Mineral Working (Inactive)

• Mooring Post

• Mud

• Multi Surface

• Narrow Gauge

• Nonconiferous Trees

• Nonconiferous Trees (Scattered)

• Normal Tidal Limit

• Orchard

• Outline

• Overhead Construction

• Parish

• Parliamentary

• Pole

• Polygon Closing Link

• Positioned Boulder

• Positioned Coniferous Tree

• Positioned Nonconiferous Tree

• Post

• Public

• Public Convenience

• Public Telephone

• Pylon

• Rail Signal Gantry

• Reed

• Reservoir

• Ridge Or Rock Line

• Road Name Or Classification

• Road Related Flow

• Rock

• Rock (Scattered)

• Rough Grassland

• Saltmarsh

• Sand

• Scree

• Scrub

• Shingle

• Signal

• Sinks

• Site Of Heritage

• Slag Heap

• Slag Heap (Inactive)

• Slipway

• Slope

• Sloping Masonry

• Sluice

• Spoil Heap

• Spoil Heap (Inactive)

• Spot Height

• Spreads

• Spring

• Standard Gauge Track

• Static Water

• Step

• Structure

• Swimming Pool

• Switch

• Tank

• Telecommunications Mast

• Top Of Cliff

• Top Of Slope

• Track

• Traffic Calming

• Triangulation Point Or Pillar

• Tunnel Edge

• Unmade Path Alignment

• Upper Level Of Communication

• Watercourse

• Waterfall

• Waterfall (Vertical)

• Weir

• Well

• Wind Turbine

The OS MasterMap Topography Layer product is supplied in Geography Markup Language (GML) version 2.1.2. This section describes how OS MasterMap is defined in GML. An understanding of XML

(eXtensible Mark-up Language) and XML schemas is required. The XML specifications that GML is based on are available from the World Wide Web Consortium (W3C) website.

XML schema

Schema overview and Internet location

XML schemas are used to validate the format and content of the GML. The GML 2.1.2 specification provides a set of schemas that define the GML feature constructs and geometric types. These are designed to be used as a basis for building application-specific schemas, which define the data content.

The Ordnance Survey application schemas that are referenced by the data are available from the Ordnance Survey XML schemas page of the OS website.

These schemas make use of XML Schema Definitions (XSDs) and Document Type Definitions (DTDs) produced by the W3C that are available from The XML: Namespace page of the W3C website.

Schema descriptions

The W3C-provided XSDs and DTDs are:

• xml.xsd – To allow the use of the xml:lang attribute for language qualification.

• XMLSchema.dtd – Required by xml.xsd.

• datatypes.dtd – Required by XMLSchema.dtd.

The OGC-provided schemas are:

• feature.xsd – The feature and property constructs.

• geometry.xsd – The geometric constructs, such as polygon and point.

• xlinks.xsd – A schema based on the W3C XLINK recommendation provided by the OGC to make use of the XLINK constructs.

The Ordnance Survey application schemas are:

• OSDNFFeatures.xsd – The definition of the Ordnance Survey features and their properties.

• OSComplexTypes.xsd – The complex property types, including changeHistoryType.

• OSSimpleTypes.xsd – The basic property types, including descriptiveGroupType and accuracyOfPositionType.

• OSMeasures.xsd – The definition of measure-qualified types used in OS MasterMap data.

• OSQueryresult.xsd – The definition of a query result with its properties.

• OSGeometryTopology.xsd – Geometry and topology extensions to the GML 2.1.2 specification required by Ordnance Survey, including rectangles and polygon topology.

XML namespaces

• xlink – http://www.w3.org/1999/xlink

• gml – http://www.opengis.net/gml

• osgb – https://www.ordnancesurvey.co.uk/xml/namespaces/osgb/

• xml – http://www.w3.org/XML/1998/namespace

Use of examples

Any examples in this section that mention specific data content are to be taken as examples only. All data content is defined in OS MasterMap Topography Layer separately, and the examples are not necessarily in harmony with the data specification.

XML declaration

The XML declaration to all query results is: <?xml version=‘1.0’ encoding=‘UTF-8’?>

Document type

All information returned from a query is provided in an osgb:FeatureCollection. If no features lie inside a query, then an empty collection is returned with its required collection properties.

The document defines the XML namespaces:

osgb – https://www.ordnancesurvey.co.uk/xml/schema/v9/index.html The location of the schema is defined as: https://www.ordnancesurvey.co.uk/xml/schema/v9/index.html http://www.ordnancesurvey.co.uk/xml/schema/vX/OSDNFFeatures.xsd The fid is set to the Ordnance Survey identifier given to the query.

For example:

<osgb:FeatureCollection xmlns:osgb=’
http://www.ordnancesurvey.co.uk/xml/namespaces/osgb
’ xmlns:gml=
’http://www.opengis.net/gml’
 xmlns:xlink=’
http://www.w3.org/1999/xlink
’ xmlns:xsi=’
http://www.w3.org/2001/XMLSchema-instance
’ xsi:schemaLocation=
’http://www.ordnancesurvey.co.uk/xml/namespaces/osgb
 
http://www.ordnancesurvey.co.uk/xml/schema/vX/OSDNFFeatures.xsd
’ fid=’queryId’>
...
</osgb:FeatureCollection>

Query result properties

The gml:description element is the first property of the feature collection; this contains a copyright statement and the date of the query.

The gml:boundedBy element is the next property of the feature collection; this contains a gml:null element with the value of ‘unknown’.

The start time of the query is specified at GMT as a feature property. The name of the property is queryTime.

The following optional properties are provided for the osgb:FeatureCollection if they were provided as part of the query. The ordering of these properties is according to the order they appear in the table:

For geographically chunked data, if there are features in the collection, the last element in the feature collection is an osgb:boundedBy element. This is a gml:Box defining the minimum bounding rectangle of all items in the collection, including the query extent. If the collection is empty, no osgb:boundedBy element is provided.

For example:

<osgb:FeatureCollection xmlns:osgb=‘
http://www.ordnancesurvey.co.uk/xml/namespaces/osgb’
 xmlns:gml=
‘http://www.opengis.net/gml’
 xmlns:xsi=
http://www.w3.org/2001/XMLSchema-instance
 xmlns:xlink=
http://www.w3.org/1999/xlink
 xsi:schemaLocation=‘
http://www.ordnancesurvey.co.uk/xml/namespaces/osgb http://www.ordnancesurvey.co.uk/xml/schema/v3/OSDNFFeatures.xsd
’ fid=‘queryId’>
<gml:description>
OrdnanceSurvey, (C) CrownCopyright. All rights reserved, 2002-05-16
</gml:description>
<gml:boundedBy><gml:null>unknown</gml:null></gml:boundedBy>
<osgb:queryTime>2001-03-28T14:31:54</osgb:queryTime>
<osgb:queryExtent’>
<osgb:Rectangle srsName=‘osgb:BNG’>
<gml:coordinates>4000000,3094763 4000010,3094820</gml:coordinates>
</osgb:Rectangle>
</osgb:queryExtent>
<osgb:queryChangeSinceDate>2001-01-31</osgb:queryChangeSinceDate>
<!-features go here-->
<osgb:boundedBy>
<gml:Box srsName=‘osgb:BNG’>
<gml:coordinates>3999350,3089542 4005602,3095673</gml:coordinates>
</gml:Box>
</osgb:boundedBy>
</osgb:FeatureCollection>

Features

Each feature within the osgb:FeatureCollection is encapsulated in one of the following member elements according to its feature type:

Each member element contains a single feature element that has the name of the feature type, for example, TopographicPoint, TopographicLine, and so on.

The TOID of the feature is provided in the XML attribute ‘fid’ of the osgb:Feature element. A TOID has a maximum of 16 digits and is prefixed with ‘osgb’. The ‘osgb’ prefix is required to form a valid XML ID type.

A feature element does not contain a name, description or boundedBy element. For example:

<osgb:topographicMember>
<osgb:TopographicPoint fid=‘osgb15789329786’>
....
</osgb:TopographicPoint>
</osgb:topographicMember>

Properties

Our application schema defines three main types of properties that are present inside a feature element; these are simple, complex and geometric properties.

The ordering of properties within a feature element is important as XML validation is reliant on elements being in a specified order. The order of properties is specified within the XML schema.

Each type of property may additionally have associated metadata encoded using an XML attribute. This metadata provides some qualification of the status or accuracy of the content provided in the attribute.

Simple

A simple property is one that contains a single piece of non-geometric information. These properties correspond to simple feature attributes. The value of each feature attribute is enclosed in an element that takes its name from the feature attribute.

A feature association is a special type of simple property that defines a relationship between one feature and another. The feature association is defined by the XML attribute xlink:href. This shall refer to a feature as if it was locally available, even though this is not guaranteed to be the case; that is, it shall be set to the character ‘#’ followed by ‘osgb’ and then the TOID of the feature being referenced.

For example:

<osgb:descriptiveGroup>Rail</osgb:descriptiveGroup>
<osgb:calculatedAreaValue>13254</osgb:calculatedAreaValue>
<osgb:referenceToFeature xlink:href=‘#osgb5798572675343543’/>

Geometry

A geometric property is one that describes a specific geometry. All geometric properties are encoded according to the GML specification. We have extended the GML v.2.1.2 specification to include a rectangle that is defined by two points. The first point defines the minimum coordinate, whilst the second point defines the maximum coordinate.

All geometric properties are encoded by placing the GML geometry elements inside an element that takes its name from the feature attribute.

The XML attribute srsName shall be set to ‘osgb:BNG’ (BNG stands for British National Grid), which uses eastings and northings specified in metres.

If a line is broken or a polygon has bled into another because of a partial update (see inconsistent features), then the XML attribute broken shall be set to ‘true’. A line that is broken will be encoded as a gml:MultiLineString.

All polygon outer boundaries have an anticlockwise orientation, and all inner boundaries have a clockwise orientation.

For example:

<osgb:anchorPoint>
<gml:Point srsName=‘osgb:BNG’>
<gml:coordinates>12365.563,8975.676</gml:coordinates>
</gml:Point>
</osgb:anchorPoint>
<osgb:queryExtent>
<osgb:Rectangle srsName=‘osgb:BNG’>
<gml:coordinates>0,0 700000,1300000</gml:coordinates>
</osgb:Rectangle>
</osgb:queryExtent>
<osgb:polyline broken=‘true’>
<gml:MultiLineString srsName=‘osgb:BNG’>
<gml:lineStringMember>
<gml:LineString>
<gml:coordinates>
01289.2,970344.5 301300.0,970352.6
</gml:coordinates>
</gml:LineString>
</gml:lineStringMember>
<gml:lineStringMember>
<gml:LineString>
<gml:coordinates>
301300.0,970354.1 301304.6,970369.8
</gml:coordinates>
</gml:LineString>
</gml:lineStringMember>
</gml:MultiLineString>
</osgb:polyline>

Complex

A complex property is one that contains more than one piece of information. These properties correspond to the complex feature attributes.

Class model

The definition of a complex property here is recursive, so complex properties may be nested. Currently, within OS MasterMap, this recursion is not used.

Figure 9: Class model diagram showing a complex property in OS MasterMap Topography Layer.

XML mapping

The complex property element takes its name from the complex feature attribute. Each part of a complex property shall be encoded as a simple, complex, geometry or topology property, as appropriate, inside the complex property element.

For example:

<osgb:textRendering>
<osgb:anchorPosition>4</osgb:anchorPosition>
<osgb:font>2</osgb:font>
<osgb:height>24</osgb:height>
<osgb:orientation>3476</osgb:orientation>
</osgb:textRendering>
<osgb:heightAboveDatum>
<osgb:heightAboveDatum>3456</osgb:heightAboveDatum>
<osgb:accuracyOfPosition>2.0m</osgb:accuracyOfPosition>
</osgb:heightAboveDatum>

Change-Only Update (COU) is only available for GML format orders. COU is unavailable in GeoPackage or vector tile formats.

COU is data that is provided to bring a user’s data holdings up to date with the most recent data available from Ordnance Survey. COU contains, for a user’s defined area, only the features that are new or have changed (known as Inserts and Updates, respectively), as well as departed features (i.e. those features that have moved or have been deleted from the user’s data extent; known as Deletes). Any feature that is new or changed since the COU date the user provides will be supplied in its latest version and departed features will indicate which features have been moved or deleted since that date.

COU will not provide intermediate versions of features that have existed between the previous order and the most recent version. Conversely, COU may supply departed information for features that the user has never had, as they have appeared and subsequently disappeared between order dates.

COU data format

COU data is supplied in GML 2.1.2 format. Inclusion of features in the COU file is triggered by a new version of a feature appearing in the database with a version date between the previous and new order dates. In the data, these new and modified features (i.e. Inserts and Updates) are represented in the same way they would for a Full Supply. Departed Feature (i.e. Deletes) is a specific feature type only present in COU supply; it represents features to be removed from a user’s holding. The departed feature’s records contain the TOID of the deleted feature, its bounding rectangle, its theme or themes, and the date and reason for its departure.

DepartedFeature attributes

Features that indicate that a feature in a previous supply may no longer be relevant, for example, it may have been deleted or moved. This feature type is used in COU data supply only.

TOID or gml:id

The unique topographic reference number. It consists of the letters ‘osgb’ followed by thirteen or sixteen digits. The TOID must always be retained/stored in its entirety as any changes, including removal of digits, will make the TOID unusable with other OS MasterMap products.

• Type: String

• Multiplicity: [1]

boundedBy

The minimum enclosing rectangle that encompasses a geometry. For departedFeatures, this encompasses all geometries that a feature has had in its lifecycle.

• Type: Rectangle

• Multiplicity: [1]

theme

A theme that the feature belongs to.

• Type: String; see ThemeType

• Multiplicity: [1..*]

reasonForDeparture

This is set to ‘Deleted’ or ‘Vacated’ to indicate whether a feature has physically been deleted from the database or is no longer relevant due to change in COU supply.

• Type: String

• Multiplicity: [1]

deletionDate

The date the feature was deleted from the Ordnance Survey maintenance database.

• Type: Date

• Multiplicity: [0..1]

COU requires that information be provided for features that were present in a spatial query but no longer meet the query criteria. Such features may have changed theme so that they:

1. Are no longer in any of the themes being requested.

2. Have had their geometry modified between queries so that they no longer meet the spatial criteria.

3. Have been deleted.

These features are represented using the DepartedFeature Feature Type explained above. These are encoded the same way as other features.

For example:

Rectangle

A rectangle is a pair of points that are used to define a rectangular area that is aligned to the National Grid. One point defines the minimum easting and northing of the rectangle, the other defines the maximum easting and northing.

Example

Example class model:

Applying COU

All the information to update a user’s holding is provided in the COU file. How this is processed by the user’s software is obviously critical to ensuring that these changes are correctly applied. The basic principles that need to be followed to help ensure consistency are:

1. Ensure that the Initial Supply or latest Full Supply or COU has been correctly loaded. This can be checked with the feature validation dataset (FVDS), which gives a full list of the TOIDs that should be in a user’s current holding at time of Full Supply.

2. Ensure that the COU to be applied covers the period from the date of last supply (‘Extraction date’) through to the update date required.

3. Apply the COU to the existing holding. How this is applied will be dependent upon the user’s system.

4. Check the holding using the FVDS at appropriate intervals to ensure currency and consistency of data holdings.

Within OS MasterMap Topography Layer, there are four topological structuring layers that determine how features interact with each other. A structuring layer contains features that do not cut across each other and are permitted to connect to each other spatially, sharing common geometry at their edges.

Most topographic features participate in a single topological structuring layer, but features that are underground or above cartographic level, or that represent pylons, cliffs and slopes are not considered to interact with other features in the topography structuring layer.

During capture and maintenance of the data, processes ensure that vertices of the geometry of features are coincident where they should be, so that the features topologically structure with each other. The full structuring layer definitions are given in the following table:

A principle of OS MasterMap Topography Layer is that data is seamless, which means there are no fixed units of data supply. The nominal boundary of each packet of OS MasterMap Topography Layer data is defined by the user’s data selection polygon and by the data chunking method applied to break the supply into manageable units (if used).

With respect to the nominal boundary, data is supplied unclipped. This means that all features with geometry that overlaps the nominal boundary are supplied in their entirety.

Inconsistent features

There are occasions when a data update will temporarily leave a feature in an inconsistent state. This occurs when neighbouring data is updated, and the edits are applied to the seamless database at different times. According to the type of feature, the following results may be realised:

Polygon boundary duplication

A break in a polygon boundary on the edge of an update area will cause neighbouring features to take on identical geometric properties and the broken line work to be removed from all polygon structuring. Once the update is completed, the polygons will resume their respective boundaries.

Example

Disappearing polygon features

Where a polygon boundary is broken and there is no neighbouring polygon, the feature will be temporarily removed from supply. A query on this area between updates will not return the broken feature. A change- only query will return a departed feature (i.e. a Delete) to indicate that this feature has been removed from the supply. Once the complete edit has been applied to the database, the feature will be supplied with its original identity and history.

Broken lines

A polyline that crosses an updated area boundary may occasionally be broken by a partial update. Where this occurs, the line is flagged as broken and the component parts will be output separately in a multiline geometry.

Intersecting polygon boundaries

Some polygons have inner boundaries that have a common point with each other or with the outer boundary. In this case, each loop formed where the boundary returns to the common point is treated as a separate boundary.

Example

This polygon has an outer boundary (ABCDEA) and two inner boundaries (AHGFA and GKJIG).

Line features in OS MasterMap Topography Layer are not as persistent in the same way as polygon and point features. This is because line features are maintained by what are called topological structuring rules. If a line feature is intersected by another line, it is broken at the intersection. This means that a single linear real-world object is often represented by several line features – no real-world object should ever be made up with a partial line feature. There is no concept in OS MasterMap Topography Layer of a line feature that is made up of multiple line geometry elements.

An illustration of this rule is shown in the diagram below. A fence cuts a field into two real-world objects. A new fence is built at right angles to the original to further divide one half of the field. Although the old fence has not changed at all, it will be split into two separate line features.

As there is no recorded relationship between OS MasterMap Topography Layer line features and discrete real-world objects, a change to a line feature may result in the deletion or significant modification of that feature and the creation of new line features. This change is not necessarily caused by a real-world change to the linear object. In the example above, the original line feature is retained as one of the resultant line features; the other line feature is new. The user cannot predict which of the resultant line features will bear the original TOID. The major exception to this is that when the reason for change is a correction of error rather than real-world change, then features are retained whenever possible.

The more rapidly changing lifecycle means that associating user data with OS MasterMap Topography Layer line features by TOID references needs to be considered very carefully, as there will be greater overheads in terms of managing change. In most cases, it will be more practical to associate with points and polygons, rather than lines.

Inferred links

Inferred links are a particular type of line feature that do not actually exist in the real world. An inferred link is a line that Ordnance Survey has introduced into the data to make some types of polygons into more manageable units. There are two main uses:

• Network closing links are frequently found where road polygons meet at junctions. If the roads were not split in this way, the Road theme would contain numerous very large polygons that would not be particularly useful in terms of being able to derive data or attach meaningful attribution to them. Roads with comparatively few junctions, such as motorways, are also split where another feature crosses them, such as a road bridge or footbridge.

• Polygon closing links are used to make more manageable, or logical, polygons. The types of link are shown in the figure below. One example would be the creation of a link to separate an open-plan garden around a pair of semi-detached houses into two distinct entities, reflecting that there are two properties there in the real world. It must be stressed that these polygon closing links do not constitute the legal boundary of any property any more than a physical line feature does. These links are clearly identified in the ‘descriptive group’ attribution and could be filtered out in most GIS if a user wishes not to display them.

Creation of line features

When a new linear real-world object comes into being, a new line feature is created to represent it.

Deletion of line features

When a real-world object is no longer present in the real world, the corresponding line feature is deleted from the Ordnance Survey main holding. A record is kept in the database to indicate that a feature with this TOID used to exist. Users with local holdings of OS MasterMap Topography Layer data are informed of the deletion in their next COU.

Modification of line features due to real-world change

As noted above, a line feature may be modified due to changes to the real-world object, or due to changes in adjacent real-world objects. The original feature may be retained if a portion of its geometry remains and one or more new features may be created to reflect the change. If the classification attributes of a line change, then it will usually be retained, and the version number incremented. Occasionally, a line feature may be replaced with a seemingly identical line feature that is considered a new feature. For example, where a line is created to represent a newly erected fence placed along the alignment of an existing line boundary between a garden and the pavement.

Modification of line features due to error correction

When a line feature is changed solely to correct a surveying or cartographic error, the feature is retained, unless the resulting topological changes with adjacent features make this inappropriate.

All feature types are presented in British National Grid (BNG) as one of the four data types specified below:

GM_Point (Point)

A point is used to specify a single x,y location by a coordinate pair in a given spatial reference system.

Example

A point defined in the BNG reference system has easting and northing ordinates in units of metres, where the easting is in the range of 0 to 700000 and the northing is in the range of 0 to 1300000. Coordinates are output to millimetre precision and are output in the data as float64 real types.

Example class model

GM_Curve (Polyline)

A polyline is an ordered set of points that are interpolated linearly. A polyline may not intersect itself or contain repeated points.

Example

Example class model

GM_MultiCurve (Multiline)

A multiline is a collection of polyline geometries. There are no specific semantics or rules applied to the collection.

Example

Example class model

GM_Surface (Polygon)

A polygon is a single closed region on the spatial reference system projection plane, defined by a set of geometric rings that represent the boundaries. A polygon has one outer boundary and zero or more inner boundaries (holes in the polygon). The inner boundaries must not cross each other or contain other inner boundaries. Coordinates in outer boundaries are oriented in an anticlockwise direction; coordinates in inner boundaries are oriented in a clockwise direction.

Example

Example class model

The flowchart below shows the process followed whenever a real-world object represented as an OS MasterMap Topography Layer polygon feature appears, changes, or is removed from the physical environment (i.e. referred to as Inserts, Updates and Deletes). The rules are described in more detail in the following sub-sections, particularly the guidelines used to answer the question in the centre of the flowchart (i.e. 'Is it still the same real-world object?').

Creation of polygon features due to real-world change

When a new real-world object with an area (for example, a building or pond) comes into being, a new polygon feature is created in the data, with a new TOID and version number. Users with local holdings of OS MasterMap Topography Layer data will be informed of new features in their holding via Change-Only Update (COU).

Deletion of polygon features due to real-world change

When an object represented as a polygon feature no longer exists in the real world, the polygon feature is deleted from the database. A record is kept in the database to indicate that a feature with this TOID used to exist and when it was deleted. Users with local holdings of OS MasterMap data are informed of the deletion in their next COU.

Modification of polygon features due to real-world change

When an object represented as a polygon feature changes but is considered to be still the same real-world object, the corresponding modified feature is retained in the database. The version number is incremented and the date on which the new version became current is stored.

If, however, the real-world object has undergone change to such a degree that it is not considered to be the same object as before, the polygon feature representing it is deleted and one or more new features created.

Changes to geometry of polygon features

When a real-world polygon object expands or contracts, due to alteration to its bounding lines, it is considered to be the same real-world object, and as such retains its TOID. For example, the polygon feature representing the back garden of a property is retained, even if it is greatly reduced in size due to extension work done to the house. This is because its identity and association to a property remains unchanged despite extensive changes to its geometry.

If it is not clear whether the real-world object after modification is the same object or a new one, the following considerations are used as a guideline:

• Is there topographic information to suggest the function of the resultant real-world object is the same as that of the original?

• Is the resultant real-world object more than half the size and less than twice the size of the original?

• Does the majority of the extent of the resultant real-world object lie within the bounds of the original?

• Is the resultant real-world object the obvious logical successor to the original?

If the continuation of the feature cannot be justified on one or more of these grounds, the feature is deleted and replaced with a new feature.

Examples

• A private house is extended. The building and garden features are retained.

• A field changes shape and reduces in size due to the realignment of one of its boundary fences alongside a road. The field feature and the adjacent road features are retained.

Splitting of polygon features

When a real-world polygon object is split into two or more separate real-world objects, one of the features may be clearly recognisable as the original real-world object. If this is the case, then the feature is retained.

If it is not clear whether one of the resultant features represents the same real-world object as the original feature, then the following considerations are used as a guideline:

• Is the function of one of the resultant real-world objects the same as the original?

• Is one of the resultant real-world objects the obvious logical successor to the original?

• Does one of the resultant real-world objects occupy more than half the area of the original?

If the continuation of the feature cannot be justified on one or more of these grounds, the original feature is deleted and replaced with new features.

Examples

• A new housing development is completed within an agricultural field. Part of the field remains and continues to be used for agriculture. The feature representing the remainder of the field is recognisable as the original with the same function, therefore it is retained. New polygon features are created to represent the new housing development.

• An agricultural field is subdivided into three approximately equal parts that continue to be in similar usage. Using the guidelines above, none of the fields can be considered the obvious successor to the original field: all have an area less than half of the original; therefore, the original feature is deleted and three new features are created.

• A house is divided equally in two by an externally surveyable division. The original feature is deleted and new features are created. This is because neither of the resultant houses is the obvious successor to the original.

• A large agricultural building is split into two by the addition of an externally surveyable division enclosing approximately 25% of the original area. The original feature is retained to represent the larger part, and a new feature is created to represent the smaller part.

• Most of the large garden of a residential property is sold off for development. The garden feature is retained to represent the much-reduced garden.

Joining of polygon features

When two or more real-world polygon objects are merged by the removal of physical boundaries, it may be that one of the original real-world objects is clearly recognisable as subsuming the other. If that is the case, the feature representing the dominant real-world object is retained and the other feature is deleted.

If one of the original real-world objects is not clearly dominant, the following considerations are used as a guideline to determine whether a feature is retained:

• Is the function of the resultant real-world object the same as one of the originals?

• Can one of the original real-world objects be considered the obvious predecessor to the resultant real-world object?

• Is the area of the resultant real-world object less than twice that of one of the original real-world objects?

If the continuation of the feature cannot be justified on one or more of these grounds, all the original features are deleted and replaced with new features.

Examples

• Two fields, one of which is larger than the other, are merged into one, such that the resultant real- world object is recognisable as the larger field subsuming the smaller field. The feature representing the larger field is retained. The smaller field feature is deleted.

• Three fields, which are broadly similar in size, are merged into one, such that none of the original fields are recognisable as the obvious predecessor of the resultant field. The original features are deleted, and a new feature is created to represent the field.

• A pond within a field is filled in. The feature representing the pond is deleted and the field feature is retained.

• Two semi-detached cottages of equal size are combined into one dwelling, with no alteration to the external geometry of the building. Both of the original features are deleted, and a new feature is created.

• A large greenhouse lies within a parcel of land only marginally larger than itself. The greenhouse is demolished. The feature representing the greenhouse is deleted, and the feature representing the land parcel is deleted as it has increased significantly and can no longer be considered as the same object.

Change of polygon feature classification

When a real-world object represented by a polygon feature changes such that the nature of the feature changes, the feature is retained, unless changes to its geometry indicate deletion of the feature under the guidelines above.

Examples

• An area of agricultural land is wholly planted with trees; there are no changes to its bounding features. The descriptive group of the feature changes but its geometry is unchanged. The feature is retained.

• An area of woodland is felled, and the area now consists of rough grass and scrub. The feature is retained.

• A barn is converted into a private dwelling. There is no change to the nature of the building (it is still a building) and the feature is retained.

Modification of polygon features due to error correction

When a polygon feature is changed solely to correct errors either in geometry or other attributes, the feature is retained. If the feature has been moved to correct an error and simultaneously modified for real-world change; for example, when natural movement of a physical feature occurs, such as a riverbank or foreshore, then the feature modification rules above are followed.

Examples