The BioDT Recreational Potential Model for Scotland

Summary

Authors

Affiliation

Joe Marsh Rossney

UK Centre for Ecology & Hydrology

Maddalena Tigli

Chris Andrews

Jan Dick

Simon Rolph

Abstract

This report introduces the Recreational Potential model and describes key aspects of its functionality.

1 Introduction

The BioDT project (2022-25) brought together a diverse range of European organisations including universities, non-profit research institutes, research infrastructure providers and commercial partners, with the aim of developing prototype ‘Digital Twins’ (pDTs) to help protect and restore biodiversity. As part of this consortium, the UK Centre for Ecology & Hydrology (UKCEH) led the development of a ‘Cultural Ecosystem Services’ (CES) pDT.

The CES pDT was imagined as a platform that brings together near real time data from a wide range of sources in a manner that is somehow tailored to the individual user. The proposed pDT (Rolph et al., 2024) focuses on two components:

1. The Recreational Potential (RP) component aims to estimate the capacity of a given area to sustain the recreational activities valued by an individual user.
2. The Biodiversity component aims to predict spatial distributions of mammals, birds, plant and insects.

The rationale behind bringing these two components together into a unified framework is that encountering interesting flora or fauna can enrich people’s recreational experiences, and help them to discover new ways to value nature-rich landscapes.

The driving motivation for this work is to promote good health and connection to nature through physical activity outdoors. However, there is also a possible synergy with conservation science, which is increasingly using data collected by non-scientists through ‘citizen science’ apps such as iNaturalist and iRecord. Potentially, certain users could be encouraged to visit areas where there is a greater need for sampling.¹

The RP component and the biodiversity component are distinct models that have been developed independently of each other. However, in both cases their outputs can be displayed on an interactive map of Scotland and served to users using an app framework such as R Shiny.

In this short report we will describe basic aspects of the Recreational Potential model. For a detailed account of the inner workings of the model the reader is directed to the accompanying technical supplement.

2 Background

The Recreational Potential model described here has a direct ancestor in ESTIMAP (Ecosystem Service Mapping Tool), which was a collection of models used to produce spatially explicit assessments of ecosystem services, including recreation, at a European scale (Paracchini et al., 2014; Zulian et al., 2013).

Some years later, Zulian et al. (2018) proposed a protocol for adapting ESTIMAP to local conditions, based on an analysis of case studies involving ESTIMAP and incorporating feedback from stakeholders. This work was part of the OpenNESS project (2012-17), focusing on Long Term Socio-Ecological Research Platforms (LTSER) (Dick et al., 2018).

Dick et al. (2022) adapted the ESTIMAP tool to focus specifically on Recreational Potential in the Cairngorms. They adjusted the parameters of the tool to match two archetypes with different preferences for recreational activities (these are the ‘hard’ and ‘soft’ recreationalist personas described later), and conducted interviews with stakeholders to assess how useful the tool was.

Earlier on in the BioDT project (2022-25), the RP and biodiversity models were combined as part of the ‘beta’ version of the BioDT app.² However, at that time the models was limited to pre-calculated ‘static’ raster layers covering a small region (the Cairngorms National Park) rather than all of Scotland (Rolph et al., 2024). Dick, Carbone, et al. (2025) gathered feedback on this tool via a survey and interviews at the British Ecological Society annual meeting in December 2024.

In the months since, development work has focused on improving the speed and scalability of these components, to enable the interactive and personalisable experience that was envisaged. The model was rewritten from scratch and a new Shiny app developed that was able to leverage these efficiencies. It was released as ‘version 1.0’ upon the close of the BioDT project (Marsh Rossney et al., 2025), and is available on GitHub under an open-source license.

The SPEAK project followed in the same spirit as (Dick et al., 2022), but using the updated Recreational Potential model, which allows for greater individual customisation by users. Some preliminary findings from this study are available as a conference presentation (Dick, Carbone, et al., 2025) and workshop report (Dick, Andrews, et al., 2025).

A retrospective look at the CES part of the BioDT project will be published shortly under Rolph et al. (2025).

3 Model description

3.1 Overview

To describe the Recreational Potential model we will start from its outputs and work backwards.

The main model output is an two-dimensional array of numbers (a raster) representing an Recreational Potential value (RP value) between \(0\) and \(1\) for each 20x20 metre square area of land (pixel) within a given area, with higher values indicating greater Recreational Potential for that specific persona. These RP values can then be mapped to colours and displayed as a heat map over a map of Scotland, as illustrated in Figure 1.

Figure 1: An example of a heat map displaying Recreational Potential.

An RP value is constructed from a combination of 87 items representing distinct attributes of the land. The 87 items are grouped into four components, which are outlined in Table 1. RP values are calculated by weighting each item by a score between \(0\) and \(10\) that reflects the importance of that item to the user. A full set of 87 scores is referred to as a persona.

Component	Short code	# items
Landscape - the suitability of land to support recreational activity	SLSRA	40
Natural Features influencing the potential	FIPS_N	24
Infrastructure features influencing the potential	FIPS_I	10
Water - rivers and lakes	Water	13

Table 1: The four components contributing to Recreational Potential values.

The RP model thus requires two inputs from users:

1. A persona, i.e. the 87 scores for each item/feature, contained in a .csv file.
2. A region of interest, i.e. an area within Scotland in which to calculate RP values, given by either a shapefile or the four coordinates of a bounding box.

We will often refer to the computations that produce an RP raster from the two user inputs as the ‘dynamic’ part of the RP model, since these computations must be performed each time the user makes a change to their persona or region of interest.

3.2 Persona

As previously stated, a persona is nothing more than a set of 87 numbers between \(0\) and \(10\) corresponding to each of the 87 items.

Personas are stored in .csv files. However, the interactive R Shiny app provided with the model (Section 4.7) contains a convenient interface for loading, saving and editing personas. Figure 2 is a screenshot from this app, showing some example persona scores for the Water component.

Figure 2: An example set of persona scores for the ‘Water’ component.

3.3 Input data

There is another essential set of inputs to the model which are not specified by the user. These are a set of 87 feature layers — one for each of the 87 items — covering Scotland at a resolution of 20x20m.

Items and feature layers

We use the term items in the context of a persona (i.e. a single persona score is an item), and feature layers in the context of raster data (a single layer of a raster is a feature).

There is a one-to-one relationship between the 87 items and the 87 feature layers.

Thus, they are described by the same set of labels. For example, the user must provide a score for the Water_Lakes_1 (Pond) item, and the input dataset also contains a feature layer called Water_Lakes_1.

For features belonging to the Landscape (SLSRA) component or the Natural Features component (FIPS_N), these rasters contain just ones and zeros, with \(1\) indicating presence of the feature in that pixel and \(0\) indicating absence.

\[ \mathrm{SLSRA}_j = \begin{cases} 1 & \text{if feature} \; j \; \text{present in pixel} \\ 0 & \text{if feature} \; j \; \text{absent in pixel} \end{cases} \]

For features belonging to the Infrastructure (FIPS_I) component or the Water (Water) component, the input rasters contain values between zero and one.

\[ \mathrm{Water}_j = \begin{cases} 1 & \text{if feature} \; j \; \text{present in pixel} \\ 0 & \text{if feature} \; j \;\gtrapprox 500\text{m away} \\ u(\mathrm{distance}_j) & \text{otherwise} \end{cases} \]

where \(\mathrm{distance}_j\) is the distance to the nearest pixel in which the feature \(j\) is present, and \(u(\mathrm{distance})\) is a function that maps distances to values between \(0\) and \(1\), decreasing as the distance increases and falling to zero at approximately 500m (see Section 1, Technical Supplement for details).

Thus, \(1\) still indicates presence of the feature in that pixel, but \(0\) instead indicates that the feature is not only absent in that pixel, but all surrounding pixels within 500m. The range of values between zero and one are used to signify that the feature is nearby (within 500m), but not present in this pixel itself.

This continuous scale allows the RP model to incorporate how areas near e.g., a loch, can still contribute to the recreational potential, even if they do not directly contain the feature.

Figure 3 contrasts a presence/absence raster (lowlands) with a proximity raster (minor rivers).

Figure 3: An example of a presence/absence raster (left) and a proximity raster (right) covering the same region just south of Edinburgh.

3.4 Recreational Potential calculation

Each of the four components is calculated by multiplying the item/features by the corresponding persona score, summing, and normalising the result,

\[ \mathrm{SLSRA} = \mathrm{normalise}\left( \sum_j \mathrm{Score}^{(\text{SLSRA})}_j \times \mathrm{SLSRA}_j \right) \, . \]

In this context, ‘normalisation’ means transforming the values so that they lie between \(0\) and \(1\), through the following transformation:

\[ \mathrm{normalise}(x) = \frac{x - x_\text{min}}{x_\text{max} - x_\text{min}} \, . \]

The final RP value is calculated by summing these four components and normalising once more,

\[ \mathrm{RP} = \mathrm{normalise} \left( \mathrm{SLSRA} + \mathrm{FIPS\_N} + \mathrm{FIPS\_I} + \mathrm{Water} \right) \, . \]

The effect of changing the region of interest

An important detail is that the normalisation step depends on the minimum and maximum values within the chosen region of interest. This means that running the model with a different region of interest (e.g. over a larger area) will generally yield different values for the same locations, even if both the persona and the underlying data are unchanged.

The dynamic part of the model is depicted in Figure 4.

flowchart LR
 subgraph s1["'Dynamic' computation of Recreational Potential"]
        D["Crop the 4<br>component rasters to the<br>region of interest"]
        E["Calculate each<br>component"]
        F["Normalise each<br>component"]
        G["Sum<br>components"]
        H["Normalise"]
  end
    A(["<i>User input:</i><br>Persona scores"]) ---> E
    B(["<i>User input:</i><br>Region of interest"]) --> D
    C[("<i>Fixed input:</i><br>Raster data")] --> D
    D --> E
    E --> F
    F --> G
    G --> H
    H --> I(("RP value"))
    style s1 fill:#FFF9C4
    style A color:#000000
    style B color:#000000
    style C color:#000000
    style D color:#000000
    style E color:#000000
    style F color:#000000
    style G color:#000000
    style H color:#000000

Figure 4: A breakdown of the ‘dynamic’ part of the Recreational Potential model, that responds to changes in user input.

4 Model code

4.1 Brief history of development work

The RP model has been gradually developed within UKCEH over a number of years. There have been three (known) major iterations.

Some effort has been taken to make previous versions findable. All individuals known to have contributed to development are credited in the version 1.0 release (Marsh Rossney et al., 2025).

Iteration	Version	Source
1 (2023)	-	https://github.com/BioDT/uc-ces/tree/main/recreation_model
2 (2024)	-	https://github.com/BioDT/uc-ces-recreation/tree/2024-model
3 (2025)	SPEAK pre-release	https://github.com/BioDT/uc-ces-recreation/tree/SPEAK-prerelease
3 (2025)	1.0	https://github.com/BioDT/uc-ces-recreation/releases/tag/v1.0

Table 2: Versions of the Recreational Potential model.

Source code for the most recent version of the code can be found on GitHub at https://github.com/BioDT/uc-ces-recreation. This may be more up-to-date than version 1.0 (June 2025), which is the subject of this report.

4.2 Overview of the repository

The repository is organised in the following way:

├── CONTRIBUTING.md
├── DESCRIPTION
├── inst
│   ├── examples
│   │   ├── capture_messages.R
│   │   ├── compute_component.R
|   |   ...
│   │   └── save_persona.R
│   ├── extdata
│   │   ├── config
│   │   │   └── config.csv
│   │   ├── personas
│   │   │   └── presets.csv
│   │   ├── rasters
│   │   │   ├── Bush
│   │   │   │   ├── FIPS_I.tif
│   │   │   │   ├── FIPS_N.tif
│   │   │   │   ├── SLSRA.tif
│   │   │   │   └── Water.tif
│   │   │   └── Scotland
│   │   │       ├── FIPS_I.tif
│   │   │       ├── FIPS_N.tif
│   │   │       ├── SLSRA.tif
│   │   │       └── Water.tif
│   │   └── shapefiles
│   │       ├── Bush
│   │       │   ├── Bush.cpg
│   │       │   ├── Bush.dbf
│   │       │   ├── Bush.prj
│   │       │   ├── Bush.shp
│   │       │   └── Bush.shx
│   │       └── Scotland
│   │           ├── Scotland.cpg
│   │           ├── Scotland.dbf
│   │           ├── Scotland.prj
│   │           ├── Scotland.shp
│   │           └── Scotland.shx
│   └── scripts
│       ├── cli
│       │   ├── app.sif
│       │   ├── main.R
│       │   └── README.md
│       └── data_production
│           ├── app.sif
│           ├── main.R
│           └── README.md
├── LICENSE
├── LICENSE.md
├── man
│   ├── assert_to_bool.Rd
│   ├── assert_valid_bbox.Rd
│   ...
│   └── timed.Rd
├── NAMESPACE
├── R
│   ├── app_run.R
│   ├── app_server.R
│   ├── app_text.R
│   ├── app_theme.R
│   ├── app_ui.R
│   ├── bbox.R
│   ├── config.R
│   ├── data_download.R
│   ├── data_input.R
│   ├── data_production.R
│   ├── example.R
│   ├── legacy.R
│   ├── persona.R
│   ├── recreation.R
│   └── utils.R
├── README.md
├── renv.lock
├── dev
│   ├── cli_test.sh
│   ├── dev.sh
│   ├── pre-commit.R
│   ├── README.md
│   └── run_app.sh
├── tests
│   └── testthat
│       └── test_io.R
└── vignettes
    ├── compute_potential.qmd
    ├── personas.qmd
    └── run_app.qmd

1

Instructions for potential contributors.

2

The standard DESCRIPTION file for R packages, containing metadata about the package.

3

Simple examples using the package functions, which get included in the generated documentation.

4

Configuration file, mapping layer names to raster values (for the pre-processing step) and descriptions (used in the Shiny app).

5

File containing two ‘preset’ personas: the ‘hard’ and ‘soft’ recreationalists described in Rolph et al. (2024).

6

Dataset covering a small area, for use in examples and vignettes.

7

Dataset for all of Scotland. This is not included in the package and is instead downloaded separately.

8

Shapefile and auxiliary data for the example dataset.

9

Shapefile and auxiliary data for the full Scotland-wide dataset.

10

Container definition file used to build a Singularity container for cli/main.R.

11

Command-line script for the model taking a persona and bounding box as input. This is expected to be called from the main BioDT app.

12

Container definition file used to build a Singularity container for data_production/main.R.

13

Script that executes all steps of the data pre-processing pipeline.

14

MIT licenses (.md for the repository, no extension for the package).

15

Compiled documentation for the package, generated using roxygen2.

16

The standard NAMESPACE file for R packages, containing a list of functions provided by the package.

17

Source code for the package.

18

renv lockfile used (in theory) to install packages deterministically. Used when deploying app to Posit Connect.

19

Bash script that runs Rscript inst/scripts/cli/main.R with example data.

20

Bash script that runs pre-commit if available, or else Rscript scripts/pre-commit.R, as well as the tests.

21

R script that emulates the behaviour of pre-commit when run, in case the latter is not installed.

22

Bash script that loads the local version of the package and runs the Shiny app, for convenience during development.

23

A file containing unit tests. Essentially tokenistic, but provides a template for more unit tests to be added in future.

24

Some vignettes demonstrating simple use of the package.

4.3 Package structure

The code is bundled as an R package. This has a number of advantages compared with a stand-alone script, since the standardised setup allows us to leverage tools for installing, documenting and testing the code, and managing its dependencies on other packages.

In particular, the package may be installed by passing the GitHub repository to remotes::install_github (or the devtools function with the same name).

remotes::install_github("BioDT/uc-ces-recreation")

This will install the package, which is named biodt.recreation. It will also install the packages upon which biodt.recreation depends, which are listed under Imports in the DESCRIPTION file.

Functionality is provided through a collection of functions in the R/ directory that, after installing the package, are accessible to the user in the biodt.recreation namespace. That is, functions such as compute_potential are accessed using the syntax biodt.function::compute_potential, or by name alone after exposing the whole namespacing using library(biodt.recreation).

Documentation for these functions is contained in the .Rd files within the man/ directory. This documentation can be brought up in RStudio by typing in ? followed by the function name. For example, typing in ?compute_potential opens the page shown in Figure 5.

Figure 5: An example of rendered documentation in RStudio.

4.4 Downloading the input data

Input data for the RP model is not available in precisely the form required by the model, as described in Section 3.3. Rather, these input rasters are obtained through a series of processing steps which combine and transform ‘raw’ data downloaded from various open-access datasets.

Currently, this ‘data production’ process is split into a manual stage and an automated stage. The automated stage is carried out by a script in the inst/scripts/data_production/ directory.

However, users need not run this script; the data which it produces is stored on Dropbox³ and can be downloaded by calling a function provided by the package.

# Allow 10 minutes for the download before timing out!
options(timeout=600)  

biodt.recreation::download_data()

4.5 Calculation of RP values

As stated earlier, the RP model requires two user inputs to run: a persona and a region of interest.

For this demonstration, we will use one of the ‘preset’ personas, which is loaded using the function get_example_persona(). We will also load an example bounding box which covers an area just south of Edinburgh.

The following snippet of code demonstrates how to compute Recreational Potential. The function also returns each component individually.

library(biodt.recreation)

persona <- get_example_persona()
bbox <- get_example_bbox()

layers <- compute_potential(persona, bbox)

The output of this function, layers, is a five-layered raster, whose layers are the four component layers plus the RP layer, as described in Section 3.4.

4.6 ‘Preset’ personas

The code snippet above made use of two convenience functions for constructing a persona and a bounding box.

A persona is represented by a very specific type of object in R (a named vector with 87 elements and specific names). It is therefore unlikely that users will want to create one from scratch without using the Shiny app interface.

We provide two ‘preset’ personas along with the package. These are

1. Hard Recreationalist: this persona values remote, challenging environments and avoids built-up or highly managed areas.
2. Soft Recreationalist: this persona values tranquil, accessible landscapes and natural water features, and avoids steep or harsh terrain.

Origins of the Hard/Soft Recreationalist personas

These personas can be traced back to the study by Dick et al. (2022, p. 5), from which we quote:

Two individuals were selected and invited to parameterise the model because they were both users of the [Cairngorms National Park] for recreation and considered by park officials as typical of the spectrum of recreational users of the area (local and visitors)… The self-reported soft recreationalist was a staff member of CNPA who had never climbed a ‘Munro’ (a hill over 3000 ft – a common measurement of hiking capability and achievement in the area) and the hard recreationalist regularly hill walked and had completed over 200 Munros.

Preset personas can be loaded into an R session as follows:

# Get the path to the preset persona file
persona_file <- get_preset_persona_file()

# Load the Hard Recreationalist persona
hard_recreationalist <- load_persona(persona_file, "Hard_Recreationalist")

# Load the Soft Recreationalist persona
soft_recreationalist <- load_persona(persona_file, "Soft_Recreationalist")

In fact the function get_example_persona() loads the Hard Recreationalist persona.

The strongest preferences of the Hard Recreationalist persona are highlighted in Table 3.

score_group	features
highest scores (scored 10 or 9)	Rock Walls (FIPS_N), Mountains (FIPS_N), Inland cliffs, rock pavements and outcrops (SLSRA), Rock cliffs, ledges and shores (SLSRA), National Park (SLSRA)
lowest scores (scored 0 or 1)	Built-up areas (FIPS_N), Flood plain (FIPS_N), Depressions (FIPS_N), No slope (FIPS_N), Gentle slope (FIPS_N), Country Park (SLSRA), Raised and blanket bog (SLSRA), Valley mires, poor fens and transition mires (SLSRA), Windthrown woodland (SLSRA), Woodland fringes and clearings and tall forb stands (SLSRA), Bare field or exposed soil (SLSRA), Built-up area (SLSRA), Royal Society for the Protection of Birds (RSPB) Reserve (SLSRA), Pond (Water), Motorway (FIPS_I), A Road (FIPS_I), B Road (FIPS_I), Minor or local road (FIPS_I), Access roads or Track (FIPS_I), Saltings (FIPS_N)

Table 3: Highest and lowest scores in the Hard Recreationalist persona.

The strongest preferences of the Soft Recreationalist persona are highlighted in Table 4.

score_group	features
highest scores (scored 10 or 9)	Traffic Free: Paved Surface (FIPS_I), Coastal dunes and sandy shore (SLSRA), National Park (SLSRA), Major Lochs (Water), Beaches or Dunes (FIPS_N), No slope (FIPS_N), Freshwater (SLSRA), Mixed deciduous and coniferous woodland (SLSRA), Scots pine woodland (SLSRA), Broadleaved deciduous woodland (SLSRA)
lowest scores (scored 0 or 1)	Rock Walls (FIPS_N), Built-up areas (FIPS_N), Rocks or Scree (FIPS_N), Depressions (FIPS_N), Extremely steep slope (FIPS_N), Screes (SLSRA), Windthrown woodland (SLSRA), Bare field or exposed soil (SLSRA), Unnamed minor stream or tributary (Water), Motorway (FIPS_I), A Road (FIPS_I), Saltings (FIPS_N)

Table 4: Highest and lowest scores in the Soft Recreationalist persona.

4.7 Shiny app

As part of the SPEAK study an R Shiny app was developed that focused exclusively on the Recreational Potential model. This is provided alongside the main package, since it provides a convenient, dynamic interface for testing and visualising outputs.

The source code for the app is split across several files, each containing the app_ prefix:

• app_ui.R contains a function make_ui that returns the user interface (UI), i.e. the layout of the Shiny app, sliders, map, buttons etc.
• app_server.R contains a function make_server that returns the server function, which defines the dynamic parts of the app, such as loading/saving/editing personas and drawing a rectangle on the map.
• app_theme.R contains some custom UI elements such as the colour scheme and logo.
• app_text.R contains the extended text elements of the app, such as the user guide.
• app_run.R contains a convenience function run_app for running the app.

The app can be run from an R session by calling the run_app() function:

biodt.recreation::run_app()

The result should look like Figure 6.

If you are in RStudio this should launch the app in a separate pane. To launch the app in your default browser, you can pass the option launch.browser = TRUE to the function.

Figure 6: A screenshot of the R Shiny App developed specifically for the RP model for use in the SPEAK study.

Detailed instructions for using the app are contained within the app itself, in the ‘User Guide’ tab. However, the essential steps are:

1. Create a persona using the ‘Persona’ tab.
2. Draw a box on the map by clicking the square orange button and dragging your mouse over the map.
3. Click the ‘Update Map’ button to compute the Recreational Potential value.

5 Interactive demo

This interactive demo showcases the model running with the Hard Recreationalist persona for the Bush Estate area near Edinburgh.

The model outputs for this example case are displayed in the map below. It is possible to explore the contribution of each component using the controls in the top-right corner of the map.

We now take a step back, splitting each component into its constituent layers. You can switch between different components by clicking on the tabs, and toggle different feature layers using the layer selector in the top-right corner of the map. Please note that not all layers contain data specific to the Bush Estate area, so some may not be visible.

The base map has been rendered in black and white to enhance the visibility of layers with sparse data. As shown, the Landscape (SLSRA) and Natural Features (FIPS_N) components display binary data, indicating either the presence or absence of features; whereas the Infrastructure (FIPS_I) and Water (Water) components present a distance gradient.

Tip

As you explore the maps, it is helpful to have the list of features and their descriptions open in another browser window.

Water

Discarded layers (no valid data):
[1] "Water_Lakes_5"  "Water_Lakes_6"  "Water_Rivers_1" "Water_Rivers_6"
[5] "Water_Rivers_7"

Landscape

Discarded layers (no valid data):
 [1] "SLSRA_LCM_1"  "SLSRA_LCM_3"  "SLSRA_LCM_5"  "SLSRA_LCM_8"  "SLSRA_LCM_9" 
 [6] "SLSRA_LCM_14" "SLSRA_LCM_20" "SLSRA_LCM_21" "SLSRA_NNR_2"  "SLSRA_NP_2"  
[11] "SLSRA_NR_2"   "SLSRA_RSPB_2" "SLSRA_SAC_2"  "SLSRA_SPA_2"  "SLSRA_WLA_2" 

Natural Features

Discarded layers (no valid data):
 [1] "FIPS_N_Landform_1"  "FIPS_N_Landform_2"  "FIPS_N_Landform_3" 
 [4] "FIPS_N_Landform_4"  "FIPS_N_Landform_5"  "FIPS_N_Landform_6" 
 [7] "FIPS_N_Landform_7"  "FIPS_N_Landform_10" "FIPS_N_Landform_11"
[10] "FIPS_N_Landform_13" "FIPS_N_Landform_15"

Infrastructure

Discarded layers (no valid data):
[1] "FIPS_I_NationalCycleNetwork_1" "FIPS_I_NationalCycleNetwork_4"
[3] "FIPS_I_RoadsTracks_1"         

6 Scotland wide datasets

The outputs of the RP model for the Hard Recreationalist and Soft Recreationalist personas for the whole of Scotland will soon be available for download as a data product (Tigli et al., 2025). The results are previewed in Figure 7.

Figure 7: Recreational Potential values for the whole of Scotland using the two persona presets.

Producing these large raster datasets is not straightforward unless one has access to high-memory computing facilities. We describe the steps we took to reduce peak memory requirements in the Developers’ Report.

7 Known limitations

Here we outline some known issues and limitations that a user is likely to encounter when using the model. Issues and suggestions of a more technical nature are discussed in the Developers’ Report.

• The RP maps can be insufficiently detailed and sometimes important features such as footpaths are missing. This is due to the underlying data being either inaccurate, out of date, or of insufficient resolution to resolve these features.

• The model outputs lack important information relevant to recreational activities, such as information about toilets, parking etc.

• Linear features such as paths and rivers are hard to discern. This is due to the fact that proximity to rather than presence of these features contributes to the RP value, so a road appears on the map as a thick band.

• The current set of 87 items that users must score includes many feature types that many lay users will not be familiar with — what is a “moraine” anyway?

• The RP values depend on the region of interest specified. Hence, if the region of interest is changed (e.g. by drawing a smaller box on the map) the RP values will likely change, even if the persona scores are unchanged. This is due to the ‘normalisation’ step.

• The influence of the persona scores on the output RP values is not transparent and sometimes counter-intuitive. Scoring an entire component with high (low) values does not necessarily mean the component will contribute more (less) to the RP. In fact, only differences in scores within a component translate into differences in RP values. This is again due to the ‘normalisation’ step.

8 Future directions

We see several potential avenues for further research and development work. Again, more technical detail on these suggestions is provided in the Developers’ Report.

1. Simplifying feature scoring:

   While the current set of 87 items allows for a detailed definition of a persona, this can be very time-consuming for users, especially if they are unfamiliar with many of the feature types. Further work could look at grouping similar features into broader thematic categories (e.g. ‘mountain terrain’, ‘urban infrastructure’, ‘wetlands’) to make the scoring process more intuitive and efficient. The option of scoring items at a finer level of detail could be retained for the benefit of expert users.

   An expanded set of ‘preset’ personas could be an additional convenience. These could include personas calibrated for cyclists, families, hikers, birdwatchers etc.

2. Make the effect of user inputs on RP values more intuitive:

   As discussed above, the effect of adjusting personas scores or the region of interest on the RP values is likely to be a source of confusion. Future updates to the model should prioritise intuitive behaviour and transparency. Removing the normalisation of components would go a long way to meet these objectives.

3. Periodically update the underlying datasets:

   Some of the datasets used in the current version of the model will become outdated as landscapes change or improved data becomes available. Periodically updating the datasets is therefore important to maintain relevance of the model. This could be achieved by replacing the manual ‘offline’ data production process with an automated ‘online’ process that is triggered periodically, e.g. when a dataset is updated. Doing this would also allow the model to be updated based on the weather or season, and in doing so account for flood risk, trail closures etc.

   However, the frequency with which to update these datasets should be determined by balancing the needs of users with the monetary and environmental cost of the data acquisition and processing pipeline.

4. Integrate with third-party apps or services:

   It may be worth considering whether integrating the BioDT app with third party data services may be more efficient than regularly re-creating the input data for the RP model. Third-party services could provide information as to the availability of parking, toilets, places to eat, weather forecast, and other things that people may need to plan their activity.

5. Scenario analysis:

   The RP model could become a tool for scenario planning, if users were able to add or remove features from the landscape to simulate possible developments (e.g. a new cycle route), land use changes (e.g. a housing development), or land cover changes (e.g. from climate change forecasts).

Access to code & data

Code for the Recreational Potential model is available as an R Package hosted on GitHub at https://github.com/BioDT/uc-ces-recreation. These reports relate specifically to the version 1.0 release, which is also available on Zenodo at https://doi.org/10.5281/zenodo.15705544.

The model requires some input data that is too large to be bundled in with the package, but which can be downloaded from Dropbox after package installation using biodt.recreation::download_data(). This data is also included in the Zenodo listing.

The source for these documents and this website can be found at https://github.com/BioDT/ces-recreation-reports.

Funding

Funding for OpenNESS came from the European Community’s Seventh Framework Programme (FP7/2007-2013) under grant agreement no 308428, OpenNESS Project (Operationalisation of Natural Capital and Ecosystem Services: From Concepts to Real-world Applications.)

Funding for BioDT came from the European Union’s Horizon Europe Research and Innovation Programme under grant agreement No 101057437 (BioDT project, https://doi.org/10.3030/101057437). Views and opinions expressed are those of the author(s) only and do not necessarily reflect those of the European Union or the European Commission. Neither the European Union nor the European Commission can be held responsible for them.

Funding for SPEAK came from the Natural Environment Research Council – Growing Shoots Partnership and application co-creation bursary. NE/Y005805/1 _Growing Shoots.

CRediT statement

JMR: software; visualisation; writing. MT: software; visualisation; writing. CA: conceptualisation; data curation; funding acquisition; software. JD: conceptualisation; funding acquisition; project administration. SR: funding acquisition; software.

Acknowledgements

We wish to acknowledge significant contributions to a previous version of the Recreational Potential model by Will Bolton. JMR would also like to thank Tomáš Martinovič for assisting with understanding the requirements of BioDT.

We are very grateful to all the participants of the SPEAK project which this output is based on including: Alastair Leaver, Alice MacSporran, Brian Cassidy, Chris Pollock, David Giles, Jean Cowie, Joanna Gilliatt, Justyna Olszewska, Laura Taylor, Maddi Bunker, Rebecca MacLennan, S Mayes, Shaila Rao, Steve MacKinnon and Tom Gebbie, Active Stirling. We are equally grateful to an additional 18 participants who preferred to remain anonymous.

Correspondence

• {jand,chan}@ceh.ac.uk for enquiries relating to the BioDT or SPEAK projects, or ongoing and future work.

• chan@ceh.ac.uk for enquiries relating to the data sources and QGIS processing.

• {joemar,madtig}@ceh.ac.uk for enquiries relating to the code and anything else appearing in the technical supplement and/or developer’s report.

• simrol@ceh.ac.uk for enquiries relating to the biodiversity component of the BioDT project.

References

Dick, J., Andrews, C., Orenstein, D. E., Teff-Seker, Y., & Zulian, G. (2022). A mixed-methods approach to analyse recreational values and implications for management of protected areas: A case study of cairngorms national park, UK. Ecosystem Services, 56, 101460. https://doi.org/10.1016/j.ecoser.2022.101460

Dick, J., Andrews, C., & Powell, D. (2025). Governance and ethics of wearable technologies [Workshop report].

Dick, J., Carbone, D., Sara-aho, K., Andrews, C., & Martinovič, T. (2025). Consultation on BioDT draft cultural ecosystem service digital twin: Responses to structured interviews BES 2024 [Project Report]. UK Centre for Ecology & Hydrology. https://nora.nerc.ac.uk/id/eprint/538779/

Dick, J., Orenstein, D. E., Holzer, J. M., Wohner, C., Achard, A.-L., Andrews, C., Avriel-Avni, N., Beja, P., Blond, N., Cabello, J., Chen, C., Díaz-Delgado, R., Giannakis, G. V., Gingrich, S., Izakovicova, Z., Krauze, K., Lamouroux, N., Leca, S., Melecis, V., … Van Ryckegem, G. (2018). What is socio-ecological research delivering? A literature survey across 25 international LTSER platforms. Science of The Total Environment, 622–623, 1225–1240. https://doi.org/10.1016/j.scitotenv.2017.11.324

Marsh Rossney, J., Tigli, M., Andrews, C., Rolph, S., & Bolton, W. (2025). The BioDT Recreational Potential Model for Scotland (Version 1.0) [Computer software]. Zenodo. https://doi.org/10.5281/zenodo.15705544

Paracchini, M. L., Zulian, G., Kopperoinen, L., Maes, J., Schägner, J. P., Termansen, M., Zandersen, M., Perez-Soba, M., Scholefield, P. A., & Bidoglio, G. (2014). Mapping cultural ecosystem services: A framework to assess the potential for outdoor recreation across the EU. Ecological Indicators, 45, 371–385. https://doi.org/10.1016/j.ecolind.2014.04.018

Rolph, S., Andrews, C., Carbone, D., Lopez Gordillo, J., Martinovič, T., Oostervink, N., Pleiter, D., Sara-aho, K., Watkins, J., Wohner, C., Bolton, W., & Dick, J. (2024). Prototype digital twin: Recreation and biodiversity cultural ecosystem services. Research Ideas and Outcomes, 10. https://doi.org/10.3897/rio.10.e125450

Rolph, S., Carbone, D., Williams, M., Andrews, C., Martinovič, T., Sara-aho, K., Tigli, M., Marsh Rossney, J., & Dick, J. (2025). Double trouble? Lessons from developing a prototype digital twin for cultural ecosystem services.

Tigli, M., Marsh Rossney, J., Andrews, C., Dick, J., & Rolph, S. (2025). Computed ouputs from the BioDT Recreational Potential Model for Scotland for two types of recreationalist [Dataset].

Zulian, G., Paracchini, M.-L., Maes, J., & Liquete Garcia, M. D. C. (2013). ESTIMAP: Ecosystem services mapping at european scale. Publications Office of the European Union. https://doi.org/10.2788/64369

Zulian, G., Stange, E., Woods, H., Carvalho, L., Dick, J., Andrews, C., Baró, F., Vizcaino, P., Barton, D. N., Nowel, M., Rusch, G. M., Autunes, P., Fernandes, J., Ferraz, D., Ferreira dos Santos, R., Aszalós, R., Arany, I., Czúcz, B., Priess, J. A., … Viinikka, A. (2018). Practical application of spatial ecosystem service models to aid decision support. Ecosystem Services, 29, 465–480. https://doi.org/10.1016/j.ecoser.2017.11.005

Footnotes

1. This was the objective of the DECIDE project.

2. The beta version of the BioDT app is no longer available online.

3. In case the Dropbox data becomes unavailable, the data is also bundled with the version 1.0 release on Zenodo.

Copyright

BioDT and the UK Centre for Ecology & Hydrology, 2025