Planning conditions & constraints

[colmjude]

Planning conditions & constraints

Some planning applications are "granted with conditions" - these conditions become restrictions on what development can be done to a property/site.

What

We are running a mini data discovery to find out more about planning conditions and what people need from the data.

Why

When someone wants to develop a property or site, it is important to know if any existing planning conditions need to be considered. Having planning conditions as data would allow software providers to build this check into their offering.

What we're looking for

We want to know more about:

• the planning conditions process - how are conditions created and what is the decision-making process that is used to add them to a planning application?
• what do planning conditions look like? Are they consistent across the country or do there differ from local authority to local authority?
• what are the characteristics of planning conditions? Are they timebound?
• what do people want to do with the data?
• what should be part of the data?
• does any data exist at the moment?
• anything else we need to know

[debsboyd]

What are we learning about conditions?
We have spoken to three local authorities to date to explore their experiences and processes with planning conditions. An emerging theme is that planning conditions are complex and there is no standardised practice across local authorities currently. Some of the main user needs for standardisations include:

• Help to streamline back end administration
• Making data more readily available
• Readable and accessible

Each local authority we have spoken to so far has presented their own challenges with the organisation of conditions. The main concerns I’ve noted have been:

1. Exploring the possibility of categorising conditions so that they can be coded as they are not currently standardised across LPA’s
2. How ready would other LPAs be to adopt a standard?
3. Variations - in essence, amendments can be made to the original planning application. This creates a need for additional resources and processing stages which can cause difficulties in tracking conditions if not effectively monitored. This is a big aspect to conditions and my thoughts are that it will be the most complex problem to solve.
4. What would be an agreed start date for collating historic data on conditions?
5. How can we incorporate conditions that have been set through the appeals process, would this create further challenges in the standardisation conversation?

[RichLimbrick]

@debsboyd - A useful starting point could be the government model planning conditions in Circular 11/95 (the rest of the circular has been cancelled but Appendix A remains). They haven't been updated for ages though so keep that in mind.

On point 5, PINS also used to have an extensive list of model conditions and this Planning Inspectorate suite of suggested conditions from 2016 was released under a PINS FOI request in 2017 - there may be more up to date versions now.

[Swati-Dash]

From Graham Stephenson (Gateshead)

Article 4 Directions:
Article 4 Directions are a way for local planning authorities to remove specific permitted development rights within a designated area. They are a legal notice served on the property, independent of any planning permission being granted.
Article 4 Directions are typically used to protect the character and appearance of a conservation area, historic district, or specific locality where there is a desire to exert more control over development.
As a result of the Article 4 Direction - Property owners within the designated area may need to apply for planning permission for certain alterations or developments that would otherwise be allowed without it due to the removal of these permitted development rights.
Permitted Development Rights Removed via Planning Condition:
Planning conditions are typically attached to planning permissions granted by the local authority. These conditions can be used to modify or remove certain rights that would normally be allowed under permitted development rules.
In this context, planning conditions are applied to specific planning applications, allowing local authorities to tailor the permissions granted to address concerns or specific issues related to a particular development proposal.
The removal of permitted development rights via planning conditions is often more project-specific and can vary from one development to another, depending on the conditions set by the planning authority.
As a result you can have properties that have had their permitted development rights removed either through an article 4 direction (a property that already exists) or if when their property was granted planning permission, the decision notice included a condition that removed certain permitted development rights (these tend to be new build housing estates)
In summary, the key difference is that Article 4 Directions are broader and apply to designated areas, restricting permitted development rights across the board, while permitted development rights removed via planning conditions are project-specific and are imposed on a case-by-case basis to address specific concerns or requirements related to a particular development proposal.
As such our view and one that is shared by a number of other authorities is that this should form two different data sets. Particularly for the Plan X tool.
Creating a file to identify which properties are subject to a planning condition should be relatively straightforward. The complexity will be identifying which part of the General Permitted Development Order have been removed by the conditions. Certainly putting that into a geospatial format.
Hope this helps. Can chat at the data drop in later if needs be.

[colmjude]

We have done some initial modelling for a planning conditions specification.

The information you have shared with us so far has been really helpful but we still have more to learn about planning conditions. We wanted to share our thinking early and get feedback - we thought the best way to do that was to prepare a data model based on what we know so far and see what people think.

Here is a sketch of the data model and some of our questions. (Please, explore the miro board and add any comments you have).

Dataset of planning conditions

Essentially we'll start out by creating a dataset of all planning conditions. This would include the more standard conditions that most planning authorities use in some form.

For example, "The development hereby permitted shall be begun before the expiration of 3 years from the date of this permission."

As well as any bespoke conditions a planning authority creates for a given development.

We expect this dataset to be large, but over time, we should be able to standardise the common conditions so each planning authority will no longer duplicate these.

Categorising planning conditions

To help with this dataset's utility, we propose including a few attributes a user could filter on. We are not sure what these should be yet, but our early thinking includes:

• a field for the purpose, for example, is this condition mandating something or restricting something
• a field for the target of the condition, for example, does this condition target planning applications such as setting the time limit for commencement, or does it target properties or sites, such as restricting what the property can be used for.
• a field for the type of condition, for example, is this a condition that affects permitted development rights or is it a condition that affects use classes.

We want your feedback on these proposed category fields because we want the planning conditions dataset to be as valuable as possible.

Linking planning applications and conditions

Once we have the planning conditions dataset and a dataset of planning applications (there is work going on to draft a specification, but for planning conditions, we can start small and expand that dataset as the work continues) we can then create a dataset that links planning applications and conditions together.

Each condition set for a planning application will be a single record. It will include the condition reference, the planning application reference, the date the condition was set and the date it was discharged (if it has been).

Hopefully that makes sense, and you think we are on the right track but please let us know what you think and what you think we’ve not got quite right yet.

[mattlucht]

Last week we met with a handful of LPAs to talk through some of the questions and the draft data model that @colmjude has written about in the thread above.

A couple of points that we took away:

The needs of PlanX

• planning conditions (also known as Article 3 Directions) cover a broad range of purposes, however in the context of supporting PlanX the key thing to look at are planning conditions that remove permitted development rights. We'll focus our thinking around this, but also check that when we're design a data model we're not prohibiting other types of planning conditions in the future (such as conditions around commencement of works) as these have potential value in other services beyond PlanX
• from a PlanX perspective a suitable first-step would be to know whether any planning conditions apply within a defined geography, if yes then this would flag at that a check needs to be made. Further down the line knowing the type of condition(s) and the details of the condition(s) would add further value

Current state of planning condition data

• across the LPAs that we spoke with data is currently held at varying levels of fidelity, some have spatial layers with a reference to a planning application, others have spreadsheet-based lists of conditions that apply to a property or an area
• there isn't a standardised list of conditions across all LPAs, but we've heard that typically within an LPA they maintain their own lists but maintain the ability to create ad-hoc conditions. Potentially in the future a standardised list of conditions could be worth exploring
• the volume of conditions and frequency of updates (i.e. new planning application decisions with conditions attached) varies from LPA to LPA, but it's likely that this dataset will change on a much more frequent basis than anything we currently have on planning.data.gov.uk and that will introduce some technical considerations for the platform

Other points to note

• one LPA has referred to a specific document that outlines the details of any planning conditions attached to a planning application decision. It'll be interesting to know whether this is the case across all LPAs as this would seem like an important thing to be able to point to
• conditions can relate to an individual property of a larger area. There are scenarios where conditions are applied to a large development area, but certain properties have those conditions removed via subsequent planning applications

[mattlucht]

Today we met with several LPAs from the planning conditions working group to discuss how we can start piloting the collection of planning conditions data on planning.data.gov.uk.

The immediate needs from a software perspective are to know whether there is a condition related to a given location – the exact nature of the condition would be incredibly useful but is something that we can build up to.

We reviewed the MVP model from the Miro board and agreed that this was a good starting point to start piloting. Some LPAs may not have all the data available initially, but one of our key principles is that some data is better than no data at all and a good starting point would be to test whether the proposed standard works with data that LPA already hold (or could be made available).

Next steps

• we're going to publish the data model sketch as a draft specification
• we'll write some high-level guidance to support the specification
• LPAs from the working group will test the draft specification, with gaps where data isn't available, either initially sending us the data or making it available on their website
• we'll use the discussion thread and the Slack working group channel to share what we're learning before reconvening as a group in a few weeks time

[colmjude]

We have simplified the planning condition model to what we consider to be the minimum viable data model—small enough to be achievable but with enough data points to still be valuable.

We had drafted a much more complete data model, but we still had too many unresolved questions, so rather than let that cause confusion and block things, we stripped it back to the essentials.

We have run through this model with ~15 LPAs and we broadly agree that it is a good place to start.

We still have some questions about what we’ve included, particularly about the field names, but we can work through those as we start to see some sample data. Any comments and thoughts on field names are welcome. We want to use names that resonate with data providers and consumers.

2 fields that come to mind are:

• activation-date - this is the date the condition becomes active. It could be immediate or some point in the future.
• discharge-date - this is the date the condition is ‘discharged’ - we understand not all conditions are discharged and often there is a process to discharge a condition. We want to understand this process better before expanding the model to include evidence of this process. However, it is important to know now if a condition is discharged so that it can be discounted during the planning process.

Here is the revised specification.

As always, any comments are welcome. You can add comments here or on the digital whiteboard we have been using for some of the discussions around planning conditions.

We are looking forward to seeing what data is produced and how it can be used.

[colmjude]

Updates to the planning conditions specification (Oct 2024)

We have made some changes to the planning conditions specification based on the feedback we have been receiving, which has helped us understand conditions better.

We have drafted some guidance to go along with the planning conditions specification, this can be used to guide you through how to create your own planning conditions data.

What we have removed

We have removed applied-date and discharged-date from the planning-application-condition dataset.

We realised we had not quite understood the process, in particular, around discharging a condition. Therefore, we’ve stripped this back for now. We understand there is a need to track which conditions have been discharged, so we will revisit when we know more.

Having some condition data to work with would help us with this.

What we have added

We have added document-url to the planning-application-condition dataset. This field should be used to include a link to the decision notice for the application that sets out the conditions.

For example, document-url = https://camdocs.camden.gov.uk/CMWebDrawer/Record/10131815/file/document?inline

As we continue working on the associated planning application decision specification there may be a better home for this field but for now it makes sense to provide a link to the official document where the conditions are laid out alongside the conditions data.

We have also added a reason field to plannig-condition dataset.

Again, this is to reflect what we are seeing - that, planning authorities include both the condition itself and then subsequent text that explains the reason or rationale behind the condition.

We believe it will be useful to separate out the 2 components (condition and reason). This will make analysis and working with conditions data easier.

And it could end up making it easier to link to local development plan policies - which we also plan to have mapped spatially on the platform. So for now the field is free text but we may need to update it in the future.

Please note, the name of this field may change.

---

Any thoughts on these changes would be appreciated.

[colmjude]

Please send us your planning condition data

We need more planning condition data to work with. So, please, share any you have with us.

The more data we get the more we will be able to understand the planning conditions space. We'll have a better understanding of the breadth and distribution of conditions used.

This will help us (data design) continue to evolve the data specification so that it is more useful for more people and help the community baseline the use of conditions to see how/if things can be improved.

This is why we have focused on a simple specification to start with so that we can build up a body of conditions data, use that for further analysis work and iterate the specification as needed.

[colmjude]

Example/Sample data

Now that we have more confidence in the data model we have drafted we now need to start testing it.
We'll do this by creating some sample data (we'll share the examples here so that people have them to refer to) to stress test the data model and it would be great to get data from local planning authorities too.

Template

We have created this template spreadsheet that can be used to help create planning conditions data.

It also includes a single example to help demonstrate how this data fits together. The example is a single householder application that has 13 conditions.

If you have a look at it you’ll see that the majority of the interesting data is in the planning-condition dataset (see example-planning-condition worksheet).

And the planning-application-condition dataset (see example-planning-application-condition worksheet) is where the links between the application and conditions are recorded.

[colmjude]

MHCLG examples

A list of example planning conditions data:

Camden householder applications

This is a more complete example of planning conditions data. It has over 1500 conditions from 416 planning applications.
What's interesting is one condition, the condition about starting work within 3 years is repeated 416.

Wychavon major application

This example spreadsheet
is for a single application which has 26 conditions attached.

It contains a single condition removing a permitted development right (see condition PC-01718-22)

[colmjude]

Exploring "standard conditions"

Looking at the sample of householder data from Camden we can see that every application has a condition about commencement with the exact same text.

We would suggest this could be a “standard” condition. Which would mean it only needs to appear in the planning-conditions dataset once.

For example, they might work something like this

This would reduce the scale of the datasets and allow the planning community to devise the standard conditions gradually as it becomes clearer which are the common ones LPAs regularly use without tweaking.

Also, if and when Standard conditions are updated or replaced the model could handle that. For example, see diagram with a hypothetical change to the standard commencement condition - instead of 3 years, its now 2 years. This is how it could be handled, keeping all existing and future data valid.

This is something we will explore further - so great to have more data from more planning authorities to work with.

[colmjude]

Things we are still exploring (Oct 2024)

We have updated the specification (see above) and started testing it with sample data (see examples) but there is still more to do.

Below is a summary of the things we are still looking into.

Categories

We are still trying to work out if and how conditions should be categorised. We are leaning towards an initial categorisation of:

• compliance
• pre-commencement
• pre-occupation
• pre-above ground works

We are aware some planning authorities use more fine-grained categorises, but we wanted to start with a small set that makes sense to everyone and then expand from there.

For example, we have seen a decision notice where the conditions are grouped by:

• Standard conditions
• Pre-start conditions (any works)
• Pre-start conditions (other than demolition or site clearance)
• Prior to above ground works
• Prior to occupation or use
• Compliance conditions
• Building regulations (imposed optional requirements)

If planning authorities can share how they categorise or group their conditions (if they do) that would be very helpful.

Why we want to categorise conditions

Categories can provide an initial clue about what the condition covers and makes them easier to work with.

For example, we have seen examples where conditions are laid out in decision notices this way. Therefore, adding this type of categorisation would help applicants/developers use the data to manage their conditions (or companies creating software for these developers) and could potentially make it easier for planning authorities to produce their decision notices due to the standardised nature of the proposed data.

This data should also make it easier to track which conditions have been submitted/discharged.

Conditions from 3rd Parties

We still need to work out how best to capture conditions from third parties.

For example, we know utilities may ask for conditions to be added. From a data specification perspective, we are trying to work out whether we should use the organisation field to capture who provided the condition or a different mechanism. Knowing who the condition is from can improve the monitoring and tracking of conditions.

One aim of this is that officers and applicants would be able to predict if specific conditions have been added to neighbouring sites, e.g. in terms of specific highway improvements/requirements for that area.

Understanding the process for discharging conditions

We understand there is often a requirement for developers to “discharge” conditions.

We understand this to mean developers have to do the thing set out in the condition. For example, they will create the Piling Method Statement needed for the condition

No piling shall commence until a Piling Method Statement has been submitted to and approved in writing by the local planning authority in consultation with Thames Water.

Then they would create an “Approval (discharge) of conditions” application to submit to the planning authority.

Hopefully we've understood that correctly.

We are trying to work out how we might model this in the data. Should it be part of the datasets already outlined in the planning conditions specification or should it be handled via recording the application?

Essentially, we still need to know more about the discharging of conditions to make this decision.

[colmjude]

Tweaking the specification based on feedback

Doncaster have been pulling together their planning condition data.

Whilst doing this they encountered an issue. The planning-application-condition dataset asks for a document-url. This field is for linking to the decision notice document that lists out the conditions for the given application.

However, they were not able to link directly to the decision notice. They can link to the page on their site where it is possible to find the decision notice. This makes complete sense. And it made us realise that we are not following our own rule where any document-url field should be paired with a documentation-url field.

Therefore, we have added a documentation-url field to the planning-application-condition dataset. This should be used to link to the page where one can expect to find the relevant decision notice.

To summarise:

• If a link to the decision notice is available, include that in document-url.
• If it is not possible to link directly to it then link to a page where a user can find it, add this link to the documentation-url.

---

Planning condition spec - v1.5.0