Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
OS Open Greenspace depicts the location and extent of spaces, such as parks and sports facilities, which are likely to be accessible to the public. Where appropriate, it also includes access points to show how to get into these sites. Its primary purpose is to enable members of the public to find and access greenspaces near them for exercise and recreation.
This product is updated every six months
Finding greenspaces has never been easier. Britain’s most comprehensive Open dataset of greenspace provides the foundation for you to help create greener and healthier communities.
Understand the location of public parks, playing fields, sports facilities, play areas and allotments, along with access points for entering and exiting urban and rural greenspaces.
Britain’s most comprehensive Open dataset of greenspaces underpins a range of apps, products and innovations – providing the foundation to help create greener and healthier communities.
Incorporated as a layer into SHAPE, the dataset has been used alongside asset location data (GPs, pharmacies, schools) and indicator data (population and deprivation), to help inform and support the strategic planning of services and physical assets across the health economy.
A vital tool in helping our emergency services, OS Open Greenspace includes site use and access points, making it quicker to get to emergency situations.
Access: Download
Data theme: Land, Land Use
Data structure: Vector
Coverage: Great Britain
Scale: 1:1 250 to 1:10 000
Format: ESRI Shapefile, GML 3.2.1, Vector Tiles (MBTiles), GeoPackage
Ordering area: All of Great Britain or customisable area (100km2 tiles)
Publication months: April, October
OS Data Hub plan: Energy & Infrastructure Plan, OS OpenData Plan (FREE), Premium Plan, Public Sector Plan
Guidance on how to use this product in GeoPackage and vector tiles formats can be found in the following documents:
Access to OS OpenData is free through the OS Data Hub.
OS Open Greenspace depicts the location and extent of spaces, such as parks and sports facilities, which are likely to be accessible to the public. Where appropriate, it also includes access points to show how to get into these sites. Its primary purpose is to enable members of the public to find and access greenspaces near them for exercise and recreation.
There are no significant issues that would impair the use of this product in the October 2024 release. However, there are three error types that have been identified with this release that users should be aware of:
The product contains 16 757 sites that do not have any Access Points. This is due to the constraints of capturing the sites via aerial imagery (for example, some Access Points may be obscured by tree canopy) and / or because a site may lack definitive Access Points (for example, a playing field with no bounding fence or hedgerow). Ordnance Survey aims to reduce the number of sites with missing Access Points as part of ongoing continuous improvement processes.
The product contains 78 instances of duplicate sites (geometry) in the same tile. These errors appear to be caused by the automated production process. Ordnance Survey aims to reduce the number of duplicate sites as part of ongoing continuous improvement processes.
The product contains 81 sites which have one or more holes less than 1msq.
We've updated some of our products available in GeoPackage format to align with Open Geospatial Consortium (OGC) standards and we've also fixed various formatting inconsistencies. For OS Open Greenspace, the updates are as follows:
GeoPackage attribution: The following attribute names have been changed from Title case to snake case:
Layer Names: The following layer names have been changed from Title case to snake case:
AccessPoint to access_point
GreenspaceSite to greenspace_site
Constraints: The following constraints have been changed from Title case to snake case:
AccessPoint_pkey to access_point_pkey
GreenspaceSite_pkey to greenspace_site_pkey
The next release of OS Open Greenspace is scheduled for April 2025.
OS Open Greenspace has two feature types:
Greenspace Site – A polygon defining the extent of greenspaces, such as parks and sports facilities, that are likely to be open for use by members of the public. These extents are generalised.
Access Point – A point feature denoting where access to a site is located and the kind of access permitted at that location.
Each feature type has associated attribution described in .
Greenspace Site features are in the form of a geolocated polygon layer that carries the following attributes:
ID – The unique identifier of the Greenspace Site. The ID is generated for each release and will change between versions of the product.
Distinctive Name – The name of the Greenspace Site. Up to four distinctive name attributes can be populated if a site is known locally by more than one name. Distinctive name attributes are populated in numerical order and only where relevant.
For many greenspaces, this relies on information from local experts who have been encouraged to share relevant information with Ordnance Survey. These names are expected to be useful in gathering more information about a site, such as its opening times or ownership information.
Distinctive names are populated where they can be sourced from relevant existing data holdings during product creation. As a result, only a limited number of records will contain Distinctive Name attribution; the population of this attribute will improve over time.
Function – The purpose of the Greenspace Site, that is, what the site is used for. Functions are determined from a specific greenspace list and only sites that fall within the list are included. OS Open Greenspace includes the following functions:
Allotments Or Community Growing Space
Bowling Green
Cemetery
Religious Grounds (Populated where there is a significant amount of accessible greenspace; this is defined as more than 500m2 of natural surface within the site.)
Golf Course
Other Sports Facility
Play Space
Playing Field (Only playing fields that are used by the public at least some of the time are included in the product. School fields, for example, which are entirely enclosed and used only by the school are not included.)
Public Park Or Garden
Tennis Court
Sports stadiums and grounds which are used primarily for spectating rather than participating in sports are not included in OS Open Greenspace.
Access Point features come in the form of a geolocated point layer that carries the following attributes:
ID – The unique identifier of the Access Point.
Reference to Greenspace Site – The unique identifier of the Greenspace Site to which the Access Point relates.
Access Type – The type of access permitted at the Access Point. Access Types are determined from a specific list and only Access Points which fall within the list are included. The following Access Types are permitted:
Motor Vehicle
Motor Vehicle and Pedestrian
Pedestrian
Where more than one Function is identified within a greenspace, nesting is used. This means that where sites overlap, or where a whole site is contained within a larger site, they are published as separate polygons that overlap one another. For example, in the image below, the whole park including the play areas (green polygon) is captured as one site. The play areas (yellow polygons) are captured separately, and these sites overlap with the park.
Where a nested site has the same Function attribute as the main site, it is merged into the main site, and not shown as separate; this avoids duplicating the greenspace function of sites.
The detail within OS Open Greenspace is automatically generalised using Ordnance Survey large-scale data. Generalisation is the process of reducing the complexity of the data whilst maintaining the key elements and characteristics of the features. OS Open Greenspace generalisation applies in two ways:
Greenspace Site – All Greenspace Sites are generalised to achieve consistency throughout the product. No sites have been removed during this process.
Access Point – Access Points are not moved by the generalisation process and remain in their actual location, allowing them to be used appropriately with large-scale data when required.
OS Open Greenspace depicts the location and extent of spaces, such as parks and sports facilities, which are likely to be accessible to the public. Where appropriate, it also includes access points to show how to get into these sites. Its primary purpose is to enable members of the public to find and access greenspaces near them for exercise and recreation.
Product issues and enhancements
There are no significant issues that would impair the use of this product in the April 2024 release. However, there are two error types that have been identified with this release that users should be aware of:
The product contains 19 841 sites that do not have any Access Points. This is due to the constraints of capturing the sites via aerial imagery (for example, some Access Points may be obscured by tree canopy) and / or because a site may lack definitive Access Points (for example, a playing field with no bounding fence or hedgerow). Ordnance Survey aims to reduce the number of sites with missing Access Points as part of ongoing continuous improvement processes.
The product contains 73 instances of duplicate sites (geometry) in the same tile. These errors appear to be caused by the automated production process. Ordnance Survey aims to reduce the number of duplicate sites as part of ongoing continuous improvement processes.
We've updated some of our products available in GeoPackage format to align with Open Geospatial Consortium (OGC) standards and we've also fixed various formatting inconsistencies. For OS Open Greenspace, the updates are as follows:
The following attribute names have been changed from Title case to snake case:
The following layer names have been changed from Title case to snake case:
AccessPoint to access_point
GreenspaceSite to greenspace_site
The following constraints have been changed from Title case to snake case:
AccessPoint_pkey to access_point_pkey
GreenspaceSite_pkey to greenspace_site_pkey
The next release of OS Open Greenspace is scheduled for October 2024.
This overview introduces OS Open Greenspace and gives context for all users – highlighting key features, providing examples of uses, and listing details such as file sizes, supply formats, etc.
This guide contains an overview of the OS Open Greenspace product and basic information needed to understand, use, and manage the product. For more detailed technical information and the data format specification, please see the .
OS Open Greenspace depicts the location and extent of spaces, such as parks and sports facilities, which are likely to be accessible to the public. Where appropriate, it also includes access points to show how to get into these sites. Its primary purpose is to enable members of the public to find and access greenspaces near them for exercise and recreation.
OS Open Greenspace is a generalised product which has been automatically generated and generalised from Ordnance Survey large-scale data.
The key highlights of OS Open Greenspace are as follows:
Comprehensive coverage of publicly accessible greenspaces.
Polygons of greenspace extents.
Access points to depict the place and type of access to each site.
Up to four distinctive name attributes per site allow multiple official and local names to be available in the product for a single site.
OS Open Greenspace supports a wide range of customer applications that use geographical information. The product can be used alone or combined with other Ordnance Survey products, such as OS Open Roads, OS OpenMap – Local or other OS OpenData products.
Applications of the OS Open Greenspace product include, but are by no means limited to:
Encouraging activity for all.
Allowing local residents to find new greenspaces local to them.
Encouraging discovery and use of new greenspaces.
Promoting health and wellbeing.
Analysing use of amenities.
Mapping routes to access the nearest greenspaces.
Managing and planning greenspaces effectively.
Over the last few years, greenspace as a topic has seen a rise in interest and opinion. As a result, many other datasets on the topic have become available. These datasets can be used in conjunction with
OS Open Greenspace to increase the range of potential applications, answer a wider spectrum of questions, and further promote activity and wellbeing. There are numerous sources of these datasets, and we have included the following links to get you started:
GeoPackage attribute name prior to April 2023 | GeoPackage attribute name after April 2023 |
---|
More detail and descriptions of these Functions can be found in the .
More detail on Access Types can be found in the .
GeoPackage attribute name prior to April 2023 | GeoPackage attribute name after April 2023 |
---|
The product is freely available online as an OS OpenData download and is part of the .
– Authoritative geographic information about the natural environment from across government.
– Open data published by central government, local authorities, and public bodies.
Feature type | Previous release count (April 2024) | New release count (October 2024) |
Greenspace Site | 153 231 | 157 274 |
Access Point | 307 380 | 326 313 |
fid | Fid |
id | Id |
function | Function |
distinctiveName1 | distinctive_name_1 |
distinctiveName2 | distinctive_name_2 |
distinctiveName3 | distinctive_name_3 |
distinctiveName4 | distinctive_name_4 |
geom | Geometry |
accessType | access_type |
refToGreenspaceSite | ref_to_greenspace_site |
Feature type | Previous release count (October 2023) | New release count (April 2024) |
Greenspace Site | 150 415 | 153 231 |
Access Point | 296 639 | 307 380 |
fid | Fid |
id | Id |
function | Function |
distinctiveName1 | distinctive_name_1 |
distinctiveName2 | distinctive_name_2 |
distinctiveName3 | distinctive_name_3 |
distinctiveName4 | distinctive_name_4 |
geom | Geometry |
accessType | access_type |
refToGreenspaceSite | ref_to_greenspace_site |
This getting started guide provides instructions for using OS Open Greenspace in different software applications. Users with limited technical knowledge will be able to follow this guide.
OS Open Greenspace contains information on greenspace sites and their access points and is an OpenData product. This getting started guide illustrates how to load and style OS Open Greenspace data into several commonly used GIS applications.
OS Open Greenspace can be downloaded from the OS Data Hub. It will be available as either ESRI shapefile or Geography Markup Language (GML) format.
The data will be available in 100 km x 100 km tiles, but features will not be clipped at tile edges, resulting in what is called ‘hairy’ tiles.
In the ESRI shapefile release, the product will comprise two elements: the greenspace site and the access points.
The GML release will simply contain both elements in one file.
The following pages cover how to open and use OS Open Greenspace data across five software solutions:
Greenspace Sites – These polygons are identified using topographic and textual information contained within Ordnance Survey large-scale databases. Identified Greenspace Sites are then generated using the visible physical boundaries surrounding individual sites, for example, where a fence or wall clearly surrounds a park.
Access Points – Most Greenspace Sites include Access Points, but a limited number do not. Certain situations make it impossible to capture access into a site:
In open areas, such as a play area in a park, there is often no physical boundary limiting access to specific places, and we therefore do not capture a specific Access Point.
It may not be possible to identify an Access Point due to the limits of data capture, such as an entrance obscured by trees.
Where this is the case, if we are informed about and can verify additional Access Points, we endeavour to include them.
It is also possible for Access Points to occur within larger polygons where they indicate access to a nested polygon within.
Inclusion of an Access Point in this product does not guarantee public access, and users need to be aware of this when using Access Point data.
In the extraction and creation of the OS Open Greenspace features, attribution is generated from the detailed source data and existing site data.
Ordnance Survey is committed to maintaining its products to the highest levels of accuracy and currency. The initial capture of data for OS Open Greenspace is completed using our existing topographic databases and aerial imagery. As such, the quality of the data is constrained to what can be achieved with this approach. For example, where access into a site is obscured (for example, it is situated under dense tree canopy) it will not be captured. In addition, the use of our existing databases to identify the location of sites of interest means that we cannot guarantee that all relevant sites will be included in the data. However, where we are informed and can verify that a feature is missing or inaccurately depicted in the dataset, we will make the necessary amendments to the dataset within 12 months of such verification.
We have processes in place to allow expert users to feed back on the product and allow us to act on potential omissions and improvements to content, subject to accuracy checks. Over time, it is anticipated that this community will assist us in further improving the content in the two OS Greenspace products.
The Greenspace Sites included in this product are the sites that the public can use for recreational activities and outside leisure. Activities include but are not limited to sports, walking, exercise, commuting, and exploration.
Inclusion of a Greenspace Site in this product does not guarantee public access to it, and users should be aware of this when using the data. Sites may have restricted opening times or charges which OS is unable to publish information about. Some sites may charge for use of the facility, area, or parking.
Some criteria have been applied in the creation of this product to ensure that the most appropriate sites are included. Sites are only included where a definable boundary for an individual site can be depicted and where the entirety of the defined site is a greenspace. Large rural areas such as National Parks do not fall within this definition.
Access Point features are point geometries that depict either vehicular or pedestrian access into a Greenspace Site.
The spatial object type defining a point feature which would normally lie on the boundary of a site extent where there is access into or out of the site.
The unique identifier of the Access Point.
Attribute name: id
Type: CharacterString
Length: 38
Multiplicity: [1]
Describes the nature of the access permitted at the Access Point.
Attribute name: accessType
Type: AccessTypeValue
Length: 40
Multiplicity: [1]
The unique identifier of the Greenspace Site to which the Access Point relates.
Attribute name: refToGreenspaceSite
Type: CharacterString
Length: 38
Multiplicity: [1]
Location of the point.
Attribute name: geometry
Type: GM_Point
Length: 50
Multiplicity: [1]
A code list is a controlled set of allowable labels or codes represented as an alphanumeric attribute. This sub-section identifies the code lists used within OS Open Greenspace and describes their values.
A spatial area object describing the geometry, extent, and function of a real-world feature. This does not imply a physical boundary.
Unique identifier of the site.
Attribute name: id
Type: CharacterString
Length: 38
Multiplicity: [1]
Description of the function of the site.
Attribute name: function
Type: FunctionValue
Length: 40
Multiplicity: [1]
The name of the site.
Attribute name: distinctiveName1
Type: CharacterString
Length: 254
Multiplicity: [0..1]
The name of the site.
Attribute name: distinctiveName2
Type: CharacterString
Length: 254
Multiplicity: [0..1]
The name of the site.
Attribute name: distinctiveName3
Type: CharacterString
Length: 254
Multiplicity: [0..1]
The name of the site.
Attribute name: distinctiveName4
Type: CharacterString
Length: 254
Multiplicity: [0..1]
The geometry of the greenspace area.
Attribute name: geometry
Type: GM_MultiSurface
Length: 20 000
Multiplicity: [1]
OS Open Greenspace is available in the following formats:
Geography Markup Language (GML) 3.2.1
Esri shapefile
GeoPackage
Vector tiles (MBTiles)
Coverage is all of Great Britain (GB).
For the GML and Esri shapefile formats, you can optionally set a custom area corresponding to one or more 100 km² tiles of the OS grid reference.
If you select adjacent 100 km² tiles that include features that cross the tile edge, the whole feature is included in both tiles. You may therefore need to deduplicate your data, depending on its application.
A zipped file comprising a national set.
The size of the zipped file is approximately 34.15 MB.
The zipped file contains one GML file.
The data is not encrypted.
A zipped file comprising a national set.
The size of the zipped file is approximately 33.87 MB.
The zipped file contains up to eight shapefiles.
The data is not encrypted.
A zipped file comprising a single national GeoPackage file.
The size of the zipped file is approximately 57.65 MB.
The data is not encrypted.
A zipped file comprising a single national MBTiles file.
The size of the zipped file is approximately 76.4 MB.
The MBTiles file contains a full set of national vector tiles.
The data is not encrypted.
OS Open Greenspace is updated bi-annually in April and October.
The data is available as a Full Supply only, that is, Change-Only Updates (COUs) are not available.
There are two possible ways of loading and displaying the shapefile data in ESRI ArcGIS. The shapefile data can be loaded straight into ArcGIS. However, if more than one 100 x 100 km tile is being loaded, the rendering performance can become an issue. The recommended way of loading the data is to use a file geodatabase to house the data. This is the method which will be described in this guide.
Open ArcCatalog. Choose a folder where the file geodatabase is to be created.
Right click on the folder and in the context menu select ‘new’ and then ‘File Geodatabase’. Give the new file geodatabase a suitable name for ease of reference by highlighting the geodatabase and typing a new name.
Once created, right click on the file geodatabase, and select ‘import’ and then ‘feature class (multiple)’.
In the next window, browse to the location where the data sits which is to be imported. Because the individual shape files begin with the 100 km prefix letters, it is possible to import more than one OS Open Greenspace tile into the geodatabase as per user requirements.
Click on the button to the right of the blank window under ‘input features’ and navigate to the folder(s) where the OS Open Greenspace shapefile data resides.
Select all the shapefiles that are required in the window and click ‘add’.
The shapefiles selected will now appear as a list in the import feature class window. The output file geodatabase should default to the one which has been previously selected. Click ‘OK’. The window will close and now ArcCatalog will import the features classes into the file geodatabase. A dialog box will appear when the process is complete.
If the file geodatabase is now highlighted, a list of the imported features classes should be visible. In this example, two shapefiles covering the 100 km areas TR and TG have been imported. This has created four new feature classes in the file geodatabase - two for access points and two for greenspace sites.
A useful point to note is that loading the shapefiles into a file geodatabase will automatically add spatial indexes to the data in the import process. There is therefore no need to manually add one once the data has been loaded, which would be the case if shapefiles had been loaded into ArcGIS without using the file geodatabase option. As has been previously mentioned, the addition of a spatial index greatly improves rendering performance.
Start ArcMap. Click on the ‘import data’ button in the top toolbar.
In the window that appears, navigate to the location of the file geodatabase just created. Select the feature classes that are required and click ‘add’.
The data will load into ArcMap. Although ArcMap does put the shapefiles into a more logical sequence, the user can move the layers according to the desired preferences. The data will, of course, load in as un-styled data. ArcMap will assign a random style to the data.
The user can manually style each of the layer files by right-clicking on each of the loaded layers, selecting ‘properties’ and then ‘symbology’. ArcMap contains an extensive range of tools to allow the user to apply various styles to each layer of the data and then save the work as an ArcGIS layer file. This procedure is not covered in this guide.
A set of ESRI layer files for OS Open Greenspace will be available for download from the GitHub website at product launch. Follow the instructions in the Quick Start Guide which accompanies these files to apply the styling to the data. These style files will work with either a direct shapefile load in ArcMap or using the file geodatabase methodology described here.
The user should see something like the screenshot above when the process is complete.
If using a different set of layer files, the procedure for adding a style in ArcMap is as follows – this method can be used for many other data types. To add a style to a layer, simply right-click on a layer, select properties and then ‘symbology’.
In the layer properties window, select ‘import’ (the button below the tabs at the top). A list of available styles, drawn from the imported layer file will appear. Simply select the required style and click ‘OK’. The symbol in the box will now change to the predefined style.
Click ‘OK’ again and the style will then be applied in ArcMap. Repeat this procedure for all the layers until the OS Open Greenspace data is styled to requirements. Labels for certain features can also be applied as needed.
If the user wants to load a larger area of interest, it is recommended that they merge the shapefiles together before loading them into the file geodatabase. This procedure is described later in this guide. Doing this will also mean that the supplied layer files for styling will only need to be applied once to the data and all the styles will work properly.
If, however, the user simply wants to load multiple areas using the file geodatabase option, there is no mandatory requirement to merge shapefiles together.
As has already been stated, OS Open Greenspace is supplied as ‘hairy tiles’ with features which cross a tile edge being supplied in both tiles in which the feature appears. These duplicate features will occur if more than one 100 x 100 km tile is loaded into a file geodatabase. In many instances, the user will not need to remove duplicate features along the tile edges as the features will display perfectly clearly with one duplicate feature overlying the other.
There may, however, be instances where the user wishes to carry out some form of analysis using feature counts contained within the data. In this case, the data will need to have the duplicate features removed.
To remove duplicate features in ArcMap, the user needs to merge the tiles together before removing the duplicate features. This procedure can take some time, so the user should consider if this is really needed.
The tiles need to be merged together to create new features classes within the file geodatabase containing the original data (or to a completely new file geodatabase or shapefile if required).
Using either ArcMap or ArcCatalog, from the main menu, select ‘Geoprocessing’ followed by ‘merge’. In the next window, select the layers to be merged. In this example two feature classes, the Greenspace Sites layers for TF and TG, are being merged together. All the attribution is being copied into the new features class though the user can specify what attributes need to be copied. The user can also specify the output required. This can be a new feature class within a file geodatabase or a shapefile. In this example, a new feature class containing the merged data will be created.
Click ‘OK’ when all the feature classes (or shapefiles) to be merged have been selected. Using this method, a number of OS Open Greenspace tiles can be merged together, although only two are shown in this example. ArcGIS will then merge the files and load the newly created feature class (or a shapefile if that was being used), into the map window. Depending on the sizes and number of tiles being merged, this could take some time. A dialog box will appear when the process is finished.
In the example shown below, a new feature class within the original file geodatabase used to hold the data has been created. This new feature class is called ‘Open_Greenspace_Sites_Merged’ and covers the entire area of the two separate feature classes previously loaded into the geodatabase. This new feature class has been styled using the ESRI style file for OS Open Greenspace data which will be available from GitHub. It’s important to follow the instructions in the Quick Start guide, provided with these files, to get the right result.
The ‘Dissolve’ function in ArcGIS will remove the duplicated features along the tile boundaries. This procedure can be carried out in either ArcCatalog or ArcMap. Firstly select ‘Geoprocessing’ and then ‘Dissolve’ from the main menu.
The user will then need to specify which merged file from which duplicate features are to be removed. In this example, we are looking at the Open_Greenspace_Sites_Merged feature class.
We are going to save the de-duplicated data as a feature class within the original file geodatabase called ‘OpenGreenspace_Sites_Dissolved’. All the dissolve fields in the box need to be ticked except the ObjectID field as otherwise the attribution will not be carried over to the new dissolved file. Once complete, the new dissolved feature class will be loaded into ArcMap. This new dissolved feature class will contain no duplicate features. This procedure could also be performed using shapefiles simply loaded into ArcMap without using a file geodatabase.
The new feature class can now be styled as previously described. A count using the attribute table on both the original merged file and the dissolved file will confirm that the dissolved shapefile contains fewer features. The count below shows the merged feature class with duplicates containing 4,473 features.
The count below shows that the dissolved feature class contains 4,468 features.
The GML data can be imported into ArcGIS using the Quick Import function in Arc Toolbox. The data will be imported un-styled. Users should also note that due to the large file sizes of some of the 100 x 100km grid tiles especially within larger cities, this import may take time to process.
The user will need to specify the type of data being imported (in this case, GML data) and browse to the files where the .GML data is stored.
The quick import will create a new file geodatabase into which to import the data. Once the database location and name has been selected click ‘OK’ in the dialog box as shown below to start the quick import. It is important to note that all the .GML files which are required for import should be in the same folder as each other and not in separate folders as they are downloaded, e.g. one file in a folder called ‘TG’ and one in a different folder called ‘TF’. If this is the case, the quick import process would have to be repeated for each folder. Placing all the .GML files in one folder will allow multiple imports at once as shown in the example below.
Once the quick import function has been completed, the data can be added using the usual ‘add data’ button in ArcMap and selecting all the layers from the newly created file geodatabase. The data will be loaded un-styled as shown in the example below.
The resulting imported data will then appear in the ArcMap window and can then be styled to suit requirements. In the case of other .GML datasets, the user may have to manually select the column header of the appropriate table within the data on which to base the styling. This is because in the GML imported data, the column header information is not shortened, as with the shapefile data. Shapefile data is limited to eight characters within the column header. GML imported data is not limited in this fashion. In the case of OS Open Greenspace data, this manual selection of column header is not required.
In the example below, we are matching the column ‘function’ in the ESRI .lyr file with the function column header in the imported GML data.
In this example, the supplied ESRI .lyr file has successfully styled the information from the imported .GML data according to information in the function column within the data. When ‘OK’ is clicked, the data appears as shown below:
CadCorp Map Modeller is a commercial GI application which can load a wide variety of data formats. It also comes with a free software viewer application called CadCorp Map Express.
To load the ESRI shapefile data, open a file explorer window in Windows and simply drag and drop the .shp files into the Map Modeller window.
CadCorp applies a random style to the data as it is loaded. The styles are applied to the borders and fills of the points and polygons within OS Open Greenspace data. Currently, there are no named object library (.NOL) files for OS Open Greenspace to style the data in CadCorp Map modeller appropriately. However, once the SLD files become available from Ordnance Survey on Github, CadCorp will be able to produce these which will allow the data to be dragged and dropped into Map Modeller and styled immediately.
Although CadCorp Map Modeller will load GML files natively without translation, currently, Map Modeller does not contain the GML schema file within it to be able to interpret the OS Open Greenspace data correctly. It is, however, anticipated that this support will follow from CadCorp soon after the OS Open Greenspace data is released.
It is assumed that the user will have already set the default coordinate reference system in QGIS to British National Grid (EPSG 27700). Instructions on how to do this can be found in the QGIS Getting Started Guide:
Click on the ‘browse’ button in the next window.
In the next window, navigate to the folder in which the data has been stored following download.
Select the files which need to be loaded and then click ‘open’.
Click ‘open’ again in the following window:
The data will now load into QGIS and will look something like the following:
The data will be loaded un-styled. It will be noted that the data will be loaded by tile reference as shown in the layers panel window of QGIS on the left-hand side of the screen. For small amounts of data, loading in this way will be perfectly acceptable. However, for larger areas, it will be more manageable to merge the data together to load larger areas as one file.
The user may need to load more than one 10000 km² grid square to cover the required area. The user will need to extract the relevant shapefiles from each tile into a folder. In the final release of data, the individual shapefiles will be prefixed with their National Grid 100 km grid square reference letters as shown below:
In OS Open Greenspace, there are two elements of the shapefile data, one for the Greenspace sites and one for the access points. These two elements will need to be merged separately from each other, so that the user will obtain a larger shapefile for the sites and one for the access points.
It is recommended that the user copies each of these elements into a new empty folder before merging is carried out. In the example below, the Access Points for two tiles of OS Open Greenspace have been copied into a ‘Merged_Data’ folder. This will need to be repeated for the Greenspace sites
To merge the shapefiles together in QGIS, from the main menu, select ‘vector’ then ‘data management tools’. The ‘merge shapefiles to one’ option is towards the bottom of the list of options.
In the next window, the user will need to define if the shapefiles to be merged are either points, lines or polygons. OS Open Greenspace contains two layers, the Access Points are point data and the Greenspace Sites layer is a polygon layer. Additionally, the folder where the files to be merged will sit needs to specified. In this example, all the files in the folder specified will be merged, which is easier than defining individual files. Finally, an output folder and file name for the merged shapefile needs to be selected.
The user can specify if they want the newly-merged file to be automatically added to the map canvass. Click ‘OK’ when satisfied with the files to be merged and the name and location of the output file has been decided.
Click ‘Close’ on this window when the process is completed. If the user selected the ‘add result to map canvass’ box, the data will appear. In the example below, two tiles of OS Open Greenspace, containing Access Points and Greenspace sites in separate layers, have been merged and loaded.
When working with merged shapefiles of any kind, it is highly recommended that a spatial index be applied to each element of the data, particularly if the user is loading national sets of data. The performance improvement in rendering the data will be very noticeable. To do this, carry out the following procedure:
Right-click on the table in the layers pane on the left-hand side of the screen. In the context menu which appears click ‘Properties’.
In the next window, select the ‘General’ tab on the left and then click on the ‘Create Spatial Index’ button.
Click ‘OK’ when this is done. If working with larger shapefiles, the user will notice a distinct improvement in performance in rendering and panning the data.
At the time of writing this Getting Started Guide, the plan is to make available pre-defined style files for Open Greenspace in both ESRI shapefile and GML output. The style files for QGIS are files which have the .qml extension. These are available to download from the Ordnance Survey Github pages.
It is also possible to style the Greenspace data manually using the tools available within QGIS to produce an output which suits the data user’s needs.
To style an element of the data, right-click on the table in the layers pane and in the context menu, select ‘Properties’.
In the next window, select the ‘Style’ tab on the left-hand side of the window. The user will see something like the following:
It’s now up to the user as to how to style the data. However, for the OS Open Greenspace data, a categorized approach, based upon the attributes within the data, is the logical approach.
Using the drop-down box in the style window, select ‘Categorized’ from the list of options.
In the next window, select the column within the data which is to be used for defining the categories. For the Greenspace Sites layer it will be ‘function’.
The user will now need to add all the categories which make up the different elements of the data. Click the ‘classify’ button towards the bottom of the window.
Once this has been done, a list of categories will now appear in the main window.
Each of the categories will have been assigned a random style by QGIS. To change these, the user should select each category in turn, and using the tools within QGIS, assign their preferred style.
In this example, we are going to style the Allotments or Growing Spaces areas. Double-click on the feature in the list.
The style assigned by QGIs is a simple fill. We are going to keep this but change the colour to something more appropriate. Click on the ‘Simple fill’ box beneath the ‘Fill’ entry.
Another set of tools will now open. Select the drop-down next to ‘Fill’ in Colours.
The user has the option to select from a choice of recent colours or copy, pick or choose a colour using the appropriate menu option. In this example, we will choose a recently used colour. We have also selected a transparent border for the feature.
Click ‘OK’ when finished.
The new colour has been applied to Allotments and Growing Spaces. This will need to be repeated for all the remaining categories, using an appropriate colour for each. When finished, click ‘OK’ at the bottom of the window.
In the example above, we see that QGIS has applied the style to the Allotments features.
To load a predefined style file for OS Open Greenspace, click on the ‘Style’ button at the bottom of the window. Then click on ‘Load Style’.
Another window will open to allow the user to browse to the location of the style file (ending in .qml).
In this example, we will select the Greenspace_Site.qml. Click ‘Open’.
The window will now change to a view of the categories in the predefined style as determined by the style file.
The styling will now be applied to the data. In this case, the Greenspace Sites will be styled.
The data will now look something like the above. Styling can also be applied to the Access Points by either styling manually or by adding a predefined style something like the below.
When using the predefined style files available from Github, it is important to consult the quick-start guide with those files for their correct use.
If the user wants to save a style file they have created, they should follow the procedure below:
Click on the layer for which the styling is to be saved. Right-click and select ‘Properties’ to bring up the properties window. Select the styling tab on the left-hand side of the window as previously.
At the bottom, click on ‘Style’.
There is now a context menu which allows the user to save the style as a QGIS Layer style file. Select that option.
In the next window, provide a style name and save it to a location. It is suggested that the user saves the style in a new empty folder to make managing style files easier.
In the example, we are saving the style file as Greenspace Site.QML.
Click ‘Save’. The file of type should be a QGIS Layer Style file, as we are not saving the style into a database or as a Styled Layer Descriptor in this instance. The style file is now saved and can be loaded into QGIS in future to style updated OS Open Greenspace data or data from a different location. It should be noted that this process needs to be repeated for the Access Points file in the OS Open Greenspace data as separate style files for the access point and greenspace sites shapefiles will need to be produced.
OS Open Greenspace data is supplied as ‘hairy tiles’ with features which cross a 100km tile edge being supplied in both tiles in which the feature appears. In many instances, the user will simply wish to use the Greenspace data as merged. In this case, there will be no need to remove duplicate features along the tile edges as the features will display perfectly clearly with one duplicate feature overlying the other.
There may, however, be instances where the user wishes to carry out some form of analysis using feature counts contained within the data. In this case, the data will need to have the duplicate features removed. There are several ways within QGIS to achieve this. There are also several plugins for QGIS which can be installed to carry out this function, in particular, one called ‘MMQGIS’. However, methods using these options are not described here.
The ‘Dissolve’ function in QGIS which is part of standard functionality will effectively carry out this procedure. In the example described below, we are going to de-duplicate the merged OS Open Greenspace file that we created in the section on merging shapefiles in this guide. In this example described, we have the file loaded into the map window.
From the main menu, select ‘vector’ then ‘geoprocessing tools’ followed by ‘dissolve’. Another window will then appear.
The user will need to select the input vector layer to be de-duplicated; in this case, the Merged_Greenspace_Sites file is already selected. The dissolve field is set to ‘id’ which will be the field in the data which will be searched for duplicate features. Finally, the user will need to specify an output folder and file name for the de-duplicated data. Once this is done, the user can specify whether the newly created file can be added to the current map canvass.
Click ‘OK’ to start the process.
A message appears once the process is complete. In this example, we have asked QGIS to automatically load the dissolved file. Once again, it is highly recommended that the dissolved file be given a spatial index using the method previously described to improve rendering performance.
Compared with the data which contains duplicates, the de-duplicated data should contain fewer features.
This can be confirmed by either running a COUNT query in an expression window or by simply opening the attribute table of the data and comparing the number of features.
In the example above, which is the original merged file, there are a total of 4473 features as seen in the attribute table.
In this example, which is the dissolved file, there are now only 4468 features in the layer, so the duplicate features have been removed.
Styling can now be applied to the dissolved file if required. The same style files created earlier or downloaded from Github should work with the dissolved file because no column headers or other changes have been made to attribution.
Open QGIS. Select ‘open vector layer’ from the left-hand toolbar.
In the resulting window, click ‘browse’ to open the window, which will allow the user to select the .GML files to be loaded. The user will need to specify that a .GML (geography mark-up language) file needs to be opened from the drop-down menu at the bottom of the window.
Select the file and then click ‘open’ twice. The .GML data for the OS Open Greenspace contains two elements which make up the data, namely access points and greenspace sites. After selecting the .GML files to load and clicking ‘open’, an additional window will appear:
The user should select the elements from the data which are needed and then click ‘OK’. If both are selected, the user will see something like the example below (the polygons being the greenspace sites and the points being the access points):
The data can now be styled using a predefined style file (.QML file) as described previously or using the tools within QGIS. Please note that style files created for the shapefile supply of the data may not work with GML supply without modifications. It is highly recommended that style files created specifically for the GML supply be used.
The styled data will appear in similar fashion to that shown below. In this instance the style files created for the ESRI shapefile supply do work for the .GML data without modifications.
It should be noted that rendering performance of the data within QGIS will be much poorer than in the case of the shapefile format, as GML data cannot be spatially indexed. It should also be noted that multiple 100 x 100 km tiles of OS Open Greenspace .GML data cannot easily be merged together, as with the shapefile option. Consequently, rendering performance will also be much slower. In addition, it is not easy to de- duplicate features along tile edges using common spatial geoprocessing tools within QGIS. As a result, the GML data itself will have to be queried using code scripts to highlight and remove duplicate features within a text editor. The other option would be to use the QGIS facility of saving out the .GML data as shapefiles and then carrying out additional data processing on the shapefiles instead. However, there would be little point in this as one of the OS Open Greenspace supply options is ESRI Shapefile.
All current commonly used versions of MapInfo Professional can open ESRI shapefiles without direct translation. However, for ease of use within MapInfo, it is recommended that users use the universal translator within MapInfo to convert the shapefile supply to MapInfo .TAB files prior to loading the data. This will be described in the procedures for loading the data.
In MapInfo Professional, start universal translator from the ‘Tools’ menu.
Select the translate button at the top left hand side of the dialog box.
In the next box, the user will need to select the translation parameters required. These will include the format of the files being translated, the format to which the data is being translated and the location of the data.
In the example below, the greenspace sites and access points shapefiles from OS Open Greenspace data, in 100 x 100kms TF and TG have been selected and the MapInfo .TAB data will be stored in a separate folder from the source data to allow easier data management.
Once selected, click ‘OK’. The translation will then run.
A message box will appear when the process is complete. The user will now have MapInfo .TAB files for the greenspace sites and access points within OS Open Greenspace data. This procedure should be repeated for any extra 100 x 100km tiles of OS Open Greenspace which are needed.
To load the created MapInfo .TAB files into MapInfo Professional simply click ‘File – Open’ and navigate to where the files sit. Select the file to be opened. Select ‘new mapper’ from the drop-down menu and click ‘OK’. The data will contain two sets of tables, one for Greenspace Sites and one for access points. It should be noted that MapInfo will open the data un-styled as shown in the screenshot below:
Data loaded into MapInfo Professional, unlike many other GI applications, is better styled at translation stage because the .TAB format used by MapInfo can retain all the styling information applied in the translation process – it does not use separate styling files to apply a style to the data. OS Open Greenspace data currently is not supplied in MapInfo .TAB format. Therefore, there is no Ordnance Survey published styling information for use in MapInfo Professional. It is, however, possible to style the data manually in MapInfo and achieve a good result.
OS Open Greenspace data tables contain all the elements of the data within two MapInfo tables, as can be seen from the layers listing.
Therefore, to style an element of the OS Open Greenspace data, SQL commands will need to be used to query the original .TAB data, pick out the specific element to style and create a new .TAB file for that element. This procedure will take some time to carry out for the whole dataset. An example is provided here for guidance, but a better option would be to use a more specialised translation software application to convert and style the data in one procedure.
From the toolbar menu, click ‘Query – Select’
In the next window, the user will need to type in the parameters to query the data. In this example, we are going to set up a query to select all the playing fields from the TF Greenspace Sites table that we have loaded. Click on the ‘Assist’ button and another window appears.
The expression above is one which will extract the playing fields from the original .TAB file. Click on ‘Verify’ to check if the expression is correct. MapInfo will allow us to save the results in a new table which we can give a name, we will call this Plyaing_Fields. Note also the Browse results box is ticked, so that once the query has been performed, we can browse the results in a table view.
Once satisfied, click ‘OK’. Then click ‘OK’ in the next window and the query will run. The user should see something like the following:
This query will now need to be saved into a new table. Select ‘File – Save Query’
In the next window give the query a name.
We are going to call this TF_Playing_Fields.
Click ‘Save’ and then close the query browser window. The user may need to close the query and any other playing field table open firstly by clicking ‘File – Close’ and selecting the open query table. Then, click on ‘File-Open’ and select the new TF_Playing_Fields .TAB file just created. The user can open the table in a new mapper or add it to the one that is already open. For this example, it will be added to the one already open in MapInfo.
The data will now be loaded. To check to see if the table has been loaded, click on the layers button in MapInfo to display the loaded layers.
The new table has been loaded. It will now be possible to add a style override to the playing fields table by clicking on the style override button and bringing up the following window:
Several style options can now be applied to the playing fields. Click ‘OK’ when finished. The style will now be applied to the data.
In this screenshot, the playing fields in grid square TF are now coloured with a green fill. As stated previously, this method is quite laborious and is not recommended for anything other than styling small areas of data. The best alternative would be to use a specialised software package to translate the data and style it during translation.
In MapInfo, it is possible to merge the elements of two .TAB files together into one new table using the ‘append’ function. This only works for data tables of the same type and will only work for two .TAB files at a time. Please note that the file into which the new data is appended will need to be saved as a new table at the end of the process. This append process should be repeated if more than two .TAB files need to be merged. This will be the case with the OS Open Greenspace product as there are two tables for each 100 x 100km grid square.
It is HIGHLY RECOMMENDED to back up the original OS Open Greenspace data tables before performing any append function, as the options for carrying out this procedure in MapInfo are limited. If multiple areas are required, it would be better to merge the original shapefiles together before translating the data into .TAB format for use in MapInfo Professional.
To carry out the append function, select ‘Table - Append Rows to table’ from the main menu.
Select the two tables to append together. Click ‘OK’. The data from TF Greenspace Site will now be inserted into the table TG Greenspace Site. The user will need to save the table at the end if the appended data is to be retained. Click ‘File – Save table’ once the append process has completed. Once the table is saved, TG_GreenspaceSite will now contain the data for the whole area. This is verified if the new table is opened in MapInfo.
MapInfo Professional will convert OS Open Greenspace data .GML supply into un-styled MapInfo .TAB format, using the Universal Translator tool built into MapInfo Professional version 12.5 onwards.
Select ‘Tools – Universal Translator’ from the main menu.
In the next window, click on the ‘translate data’ button.
In the next window, select ‘Geography Mark-up Language’ from the list of options. Then, select the tiles which need to be translated and a destination folder for the data to be stored. Click ‘OK’ and the translation will begin. A message will appear at the end stating that the translation was successful if all the input parameters have been set correctly.
Once the translation has completed, the user should see something like the following:
The data can now be loaded into MapInfo Professional as .TAB format in the normal way. A point to note is that the translation from .GML to .TAB can produce a single set of OS Open Greenspace tables covering the whole area, avoiding the need for appending files.
The data is loaded un-styled. Styling would have to be applied manually as previously described, or another specialist translation application used to apply the styling during translation of the data.
The data structure of OS Open Greenspace in Geography Markup Language (GML) format is described by a Unified Modelling Language (UML) class diagram and accompanying tables containing text.
OS Open Greenspace geometry is published with a precision of two decimal places.
OS Open Greenspace consists of the following classifications:
Public parks or gardens
Play spaces
Golf courses
Sports areas or playing fields
Churchyards or burial grounds
Allotments or community growing spaces
A full table of these classifications and associated Ordnance Survey real-world terms and their definitions is included in the .
PostGIS is the geospatial extension to the free open source database application PostgreSQL. The PostGIS extension needs to be installed as part of the PostgreSQL install. Instructions of how to do this can be found on the OS Web Site:
Open ‘PG Admin’ from the Windows desktop and, using the menu options available, create a new database and a new schema within the database to hold the OS Open Greenspace data. It is recommended that the user not use the ‘public’ schema to hold the data itself.
In the example above, a database called ‘osopendata’ has been created along with a schema called ‘open_greenspace’ into which the data will be loaded.
As the data to be loaded comes in shapefile format, there is an easy to use PostGIS plugin available within PostgreSQL to load shapefile data.
Select ‘plugins’ from the main menu followed by ‘PostGIS Shapefile and DBF Loader’
The next window allows the user firstly to view connection details and then to add files to the database. The first thing to do will be to test connection details. Click on the ‘view connection details’ button.
The resulting box should contain the username and password already entered along with the host name. The database being used to contain the data should already be selected. Click ‘OK’
If everything is working OK, ‘connection succeeded’ should appear in the Log Window. Click the ‘Add File’ button.
In the next window, which appears, use the file tree in the ‘Places’ box on the left-hand side to navigate to the folder in which the OS Open Greenspace shapefiles data sit. A list of the files will appear in the main window. The user can load one or all the files into the database. In the example above, all the shapefiles have been selected. Then, click ‘Open’. If opening files from multiple 100 x 100km grid tiles, it is better to place the original shapefiles into a single folder.
Another window will open listing the selected shapefiles. The Schema and SRID will need to be changed. The schema will need to be changed to the schema in the database into which the data is being loaded (in this case ‘open_greenspace’). The SRID (or co-ordinate reference system) will need to be changed to 27700, which is the code for British National Grid. This will need to be done for all the shapefiles being loaded. No other element will need to be changed. Once this has been done click ‘Import’.
At the end of the procedure, the log window at the bottom of the PostGIS import/export manager box should indicate that all the shapefiles have loaded successfully. However, one or two of the shapefiles (depending on the area of the country being loaded) may fail to load because the text encoding needs to be changed from UTF-8 to LATIN1. If this is the case, the user will need to close the plugin and start again selecting just the shapefiles which failed to load previously. The schema and SRID must be changed again and this time, the character encoding will need to be changed. This can be done by clicking the ‘options’ button;
Change the DBF character encoding to LATIN1 and click ‘OK’.
Changing this should allow the import to complete successfully. For information, the shapefiles which are most likely to need this change to be made are either in Wales or Scotland. This is because files in these areas may contain text which may have accents within them which are not part of the UTF-8 character set.
Once the import has been completed, the user can check if the data is loaded properly by refreshing the schema in PGAdmin and opening the ‘table’ tree. If the data has loaded correctly, there should be the same number of OS Open Greenspace data tables in the schema as the number of shapefiles opened.
The data is now loaded into the PostGIS database and is now ready to be viewed in a GIS application. As QGIS, the open-source GIS, has been developed to work seamlessly with PostGIS, we will open and view the data using that application. However, any GI application which includes support for PostGIS can be used.
In QGIS, click on the ‘open PostGIS layer’ button on the left-hand side of the window.
If the OS Open Greenspace data has been placed into an existing database, as in the example below, the user will simply need to open the connection to that database within QGIS. The open_greenspace schema should appear in the list of available schemas within that database.
If the database in which the OS Open Greenspace data sits is new, create a new database connection to the database by clicking the ‘new’ button. The following window appears and the information relating to the new database will need to be entered within the appropriate boxes:
One the connection has been made, click on the + sign next to the schema to expand the list of tables. Select all the tables within OS Open Greenspace that need to be loaded to QGIS.
Once all have been selected, click ‘Add’.
The OS Open Greenspace data will load into QGIS. The data will need to be ordered and then styled appropriately using personalised style files or the style files available from GitHub published by Ordnance Survey. If using these published files, please consult the accompanying ‘Quick Start Guide’. It should be noted that there is no need to add a spatial index to the data from PostGIS as those indexes were added automatically during the loading of the data into PostgreSQL.
It is possible to load multiple 100 x 100km grid tiles of data into the same schema in PostgreSQL. As the shapefiles have the 100km grid letters as a prefix in the filename, these files will go into separate tables in the schema. It will then be possible to view data across tile edges using QGIS or other GI applications which support PostGIS.
The screenshot above shows the access points and greenspace sites for two tiles, TG and TF loaded into QGIS from the greenspace schema. It should be noted that duplicate features will exist across the tile edges as the data is supplied as ‘hairy tiles’ as previously indicated.
As stated in the point above, if using multiple tiles of data in PostGIS, loading them as described, some features will be replicated across tile edges loaded in different tables of the same features, e.g. in the case of TF and TG. If the data is being used for contextual purposes only, this should not be an issue for the user.
However, if the data is being used for any kind of analysis involving counts of features, these duplicates will need to be removed to avoid providing skewed results.
It is possible to remove these features using SQL commands in PostgreSQL itself.
Firstly, create a merged file containing the area required, using the merge shapefile feature in QGIS documented earlier. In this example, we are going to use the merged shapefile for TF and TG that was made previously and then load it into PostgreSQL using the shapefile loader plugin.
In the example above, two additional tables, merged_greenspace_sites and merged_access_points, have been added to the open_greenspace schema in PostgreSQL. Open the SQL window in PostgreSQL and type in the following command:
The command returns the following result:
This shows that the number of features detected is 4,473, in this example. The following command should now be typed into the SQL window;
The above command creates a new table called greenspacesites_dissolved in the schema with all the duplicate features removed. This can be verified by typing in the following command;
An alternative way to do what has been described above would be to merge the required shapefiles together and de-duplicate using QGIS as described earlier in this document. The user will then have a set of de- duplicated shapefiles which can then be loaded into PostgreSQL/PostGIS and displayed in QGIS using the methods described previously.
It is possible to load the GML supply data into PostgreSQL using sets of SQL commands, as there is no GUI PostGIS loader for GML data. These SQL commands would create the tables, indexes and load the data. As this data is supplied in shapefile format which can be loaded using the PostGIS shapefile loader plugin, the SQL method of loading the GML data will not be described in this guide.
This sub-section describes the two feature types (Greenspace Site and Access Point) available in the OS Open Greenspace product, giving detailed information about each attribute.
This technical specification provides detailed technical information about OS Open Greenspace. It is targeted at technical users and software developers.
OS Open Greenspace depicts the location and extent of greenspaces, such as parks and sports facilities, which are likely to be accessible to the public. Where appropriate, it also includes access points to show how to get into these sites. Its primary purpose is to enable members of the public to find and access greenspaces near them for exercise and recreation.
OS Open Greenspace is an OpenData product. It is part of the OS OpenData portfolio, which currently consists of a range of datasets, such as , , , and . For more information on the OpenData portfolio, see the .
OS Open Greenspace is available in the following formats:
Geography Markup Language (GML) 3.2.1
Esri shapefile
GeoPackage
Vector tiles (MBTiles)
OS Open Greenspace is supplied as an online download and is available without registration from the .
Open QGIS. Select ‘Add Vector Layer’ from the left-hand toolbar.
Then, click ‘Apply’ followed by ‘Open’.
The name of the attribute and what it is describing.
The nature of the attribute, for example a numeric value or a code list value.
The length of the attribute provided (optional).
Describes how many times this element is expected to be populated in the data. An attribute may be optional or mandatory within the product. These are denoted by:
‘1’ – there must be a value.
‘0..1’ – population is optional but a maximum of one attribute will be returned These values may be used in combination.
The product is supplied in GML version 3.2.1. This sub-section describes how OS Open Greenspace is defined in GML. An understanding of XML (eXtensible Mark-up Language) and XML schemas is required.
GML is an XML grammar for expressing geographic features. GML serves as a modelling language for geographic systems, as well as an open interchange format for geographic transactions on the Internet. More information can be found on the 'Geography Markup Language' page of the Open Geospatial Consortium (OGC) website.
The XML specifications that GML is based on are available from the World Wide Web Consortium (W3C) website.
Information about Unicode and UTF-8 (the character encoding we use) is available on the Unicode Consortium website.
The examples in this section that mention specific data content are for demonstration purposes only and not intended for use.
XML schemas are used to define and validate the format and content of the GML. The GML version 3.2.1 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 to define the data content.
The Ordnance Survey application schema, OSOpenGreenspace.xsd, which is referenced by the data, is available on the 'OS Open' page of the 'XML file resources' section of our website.
The product's two code lists are available at the following links:
Function Value Code List: http://www.os.uk/xml/codelists/OpenFunctionValue.xml
Access Type Value Code List: http://www.os.uk/xml/codelists/AccessTypeValue.xml
OS Open Greenspace is supplied as an Esri shapefile. Shapefile is an open specification file format to store geometry and attribute information about spatial features. It is developed and regulated by Esri for data interoperability among Esri and other geographic information systems (GIS) software products.
OS Open Greenspace is provided in MBTiles, which is an open specification tileset format used for vector tiles. The format is designed to be simple, high resolution, customisable and efficient to load as a single file. The data is supplied in Web Mercator projection (ESPG:3857).
The vector tiles schema, as well as the zoom level for each attribute, is detailed in the following table:
In the Zoom levels columns, 'N' (no) indicates that the specified layer and attribute does not display within that zoom level, whereas 'Y' (yes) indicates that the specified layer and attribute does display within that zoom level.
id
function
distinctive_name_1
distinctive_name_2
distinctive_name_3
distinctive_name_4
Feature types | Zoom levels: 0 to 8 | 9 | 10 | 11 | 12 | 13 | 14 |
---|---|---|---|---|---|---|---|
id
access_type
The Open Geospatial Consortium (OGC) defines GeoPackage (*.gpkg) as an open, non-proprietary, platform-independent, standards-based data format for geographic information systems (GIS). It is designed to be a lightweight format that can contain large amounts of varied and complex data in a single, easy-to- distribute and ready-to-use file. GeoPackage is natively supported by numerous software applications.
GeoPackage offer users the following benefits:
The single file is easy to transfer and offers a rich end-user experience.
Attribute names are not limited in length, making the format user friendly.
The file size limit is large at 140 TB.
A file size limit could be imposed by the file system to which the file is written.
It supports raster, vector, and database formats, making it a highly versatile solution.
It is an OGC standard.
In most cases, it is a plug-and-play format.
For information on how to open, use and understand a GeoPackage dataset, please refer to our Getting Started with GeoPackage guide. For further information on GeoPackage, please see the GeoPackage website.
We've recently updated some of our products available in GeoPackage format to align with OGC standards and we've also fixed various formatting inconsistencies. For OS Open Greenspace, the updates are as follows:
GeoPackage attribution: The following attribute names have been changed from title case to snake case:
GeoPackage attribute name prior to April 2023 | GeoPackage attribute name after April 2023 |
---|---|
Layer names: The following layer names have been changed from title case to snake case:
AccessPoint to access_point
GreenspaceSite to greenspace_site
Constraints: The following constraints have been changed from title case to snake case:
AccessPoint_pkey to access_point_pkey
GreenspaceSite_pkey to greenspace_site_pkey
The UML class diagram and accompanying feature type attribute tables on the data structure page are provided in GML format.
The naming of attributes between the formats varies due to the differing naming conventions associated with each format (for example, presence of underscores, character limitations and capitalisation). For example, Esri shapefile attribute names are limited to 10 characters, whereas GML has no character limit. The following tables map the attribute names for each feature type across the formats.
A couple of attributes are not mapped to all formats; the absence of an attribute field is represented by ‘N/A’ in the table. The fid attribute is only available in GeoPackage format (this is a procedurally generated, non-persistent number required for some GIS applications to be able to read the data). GML and GeoPackage contain the geometry attribute which describes the geometry of the feature; this attribute is not applicable for the Esri shapefile or vector tiles formats as they apply their geometry visually.
OS Open Greenspace attribute naming differences between GML, Esri Shapefile, GeoPackage and vector tiles for the Greenspace Site Feature Type.
GML | Esri shapefile | GeoPackage | Vector tiles |
---|---|---|---|
OS Open Greenspace attribute naming differences between GML, Esri Shapefile, GeoPackage and vector tiles for the Access Point Feature Type.
GML | Esri shapefile | GeoPackage | Vector tiles |
---|---|---|---|
The Access Point feature is attributed with an accessType with a data type of AccessTypeValue. The following table lists the codes which are used to populate this field and gives a description for each code:
Value describing the type of access indicated by the Access Point
Value | Description |
---|---|
The Geography Markup Language (GML) and GeoPackage formats use the British National Grid (BNG) spatial reference system. BNG uses the OSGB36 geodetic datum and a single Transverse Mercator projection for the whole of Great Britain. Positions on this projection are described using easting and northing coordinates in units of metres.
Vector tile format is supplied in Web Mercator projection (EPSG:3857). Web Mercator projection uses WGS84 geodetic datum to render the vector tiles.
A general guide to cartography is available on our .
A general introductory guide to BNG is provided at:
This product is available to try out online using one of our three sets of sample data (Exeter, Newport and Inverness) through the OS MasterMap product viewer:
Feature types | Zoom levels: 0 to 8 | 9 | 10 | 11 | 12 | 13 | 14 |
---|---|---|---|---|---|---|---|
Allotments Or Community Growing Spaces
N
Y
Y
Y
Y
Y
Y
Bowling Green
N
Y
Y
Y
Y
Y
Y
Cemetery
N
Y
Y
Y
Y
Y
Y
Golf Course
N
Y
Y
Y
Y
Y
Y
Other Sports Facility
N
Y
Y
Y
Y
Y
Y
Play Space
N
Y
Y
Y
Y
Y
Y
Playing Field
N
Y
Y
Y
Y
Y
Y
Public Park Or Garden
N
Y
Y
Y
Y
Y
Y
Religious Grounds
N
Y
Y
Y
Y
Y
Y
Tennis Court
N
Y
Y
Y
Y
Y
Y
Motor Vehicle
N
Y
Y
Y
Y
Y
Y
Motor Vehicle and Pedestrian
N
Y
Y
Y
Y
Y
Y
Pedestrian
N
Y
Y
Y
Y
Y
Y
fid
fid
id
id
function
function
distinctiveName1
distinctive_name_1
distinctiveName2
distinctive_name_2
distinctiveName3
distinctive_name_3
distinctiveName4
distinctive_name_4
geom
geometry
accessType
access_type
refToGreenspaceSite
ref_to_greenspace_site
N/A
N/A
fid
N/A
id
id
id
id
function
function
function
function
distinctiveName1
distinctiveName1
distinctive_name_1
distinctive_name_1
distinctiveName2
distinctiveName2
distinctive_name_2
distinctive_name_2
distinctiveName3
distinctiveName3
distinctive_name_3
distinctive_name_3
distinctiveName4
distinctiveName4
distinctive_name_4
distinctive_name_4
geometry
N/A
geometry
N/A
N/A
N/A
fid
N/A
id
id
id
id
accessType
accessType
access_type
access_type
refToGreenspaceSite
refToGSite
ref_to_greenspace_site
N/A
geometry
N/A
geometry
N/A
Allotments or Community Growing Spaces
Areas of land for growing fruit, vegetables and other plants, either in individual allotments or as a community activity. Produce is for the grower's own consumption and not primarily for commercial activity.
Bowling Green
A specially prepared area intended for playing bowls.
Cemetery
Areas of land associated with burial areas.
Religious Grounds
Areas of land associated with churches and other places of worship. Only included where there are significant areas of greenspace (over 500m2 of natural space – identified as surfaces that are not manmade, such as grass, woodland and bare earth).
Golf Course
A specially prepared area intended for playing golf.
Other Sports Facility
Land used for sports not specifically described by other categories. Includes those facilities where participation in sport is the primary use of the area.
Play Space
A specially prepared area intended for children’s play, usually linked to housing areas or parks, and containing purpose-built equipment. Not captured if within schools or paid-for tourist attractions.
Playing Field
Large, flat areas of grass or specially designed surfaces, generally with marked pitches, used primarily for outdoor sports, i.e. football, rugby, or cricket.
Public Park or Garden
Areas of land designed, constructed, managed, and maintained as a public park or garden. These normally have a defined perimeter and free public access, and generally sit within or close to urban areas.
Access is granted for a wide range of uses and not usually restricted to paths or tracks within the area. May include areas with managed facilities, such as benches and flowerbeds, and more natural areas.
Tennis Court
A specially prepared area intended for playing tennis.
Motor Vehicle
Access Point permits access to motor vehicles.
Motor Vehicle and Pedestrian
Access Point permits access to motor vehicles and pedestrians.
Pedestrian
Access Point permits access to pedestrians.