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 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.
When a new linear real-world object comes into being, a new line feature is created to represent it.
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.
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.
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.
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?').
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
A line feature representing an old fence is found to have an error in its position and is corrected. The line feature and the polygon features bounded by it are retained. The version numbers of the features are incremented.
The feature representing an area of road has been assigned an incorrect descriptive group. The feature is reclassified and retained. The feature version number is incremented.
An area of non-coniferous trees has been incorrectly assigned the descriptive term 'coniferous trees' by photogrammetric revision techniques. The feature is reclassified and retained. The feature version number is incremented.
A building foundation captured as a feature with a descriptive group of ‘unclassified’ is completed, and the feature is reclassified to a descriptive group of ‘building’. The feature is retained. The feature version number is incremented.
A feature is no longer included within Ordnance Survey’s capture specification. The feature is not retained.
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.
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'>
The TOID is provided in the GeoPackage and vector tile attribute 'toid'.
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.
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.
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.
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.
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.
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.
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.
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.
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.
