Local plans (& timetables)

[colmjude]

Local plans

Previously, we have done some work on what data about development plans would be useful to make available on planning.data.gov.uk. We've also considered Local plans to be one type of development plan document, along with things like waste and mineral plans and neighbourhood plans.

However, because of the importance of Local plans we have split out the work.

This discussion has been set up so that we can update and discuss progress.

[colmjude]

Update Oct 2024

A video explaining why we are starting with baselining Local plan data.

[colmjude]

We have created a tool to help us review and check local plan data we have scraped from planning authority websites.

As we check records in the tool we can mark them "for platform". This means they will be made available for the platform to collect, building up the local plan related datasets on planning.data.gov.uk. These are:

• local plan
• local plan boundary
• local plan document

[colmjude]

We are currently working on extending the tool to include timetable data. Part of this work was adding a local plan timetable dataset to the local plan specification.

[colmjude]

Timetables

Timetables are the series of events that happen during the local plan-making process. The "timetable" dataset will include estimated events and actual events. This will allow users of the data to track when things are expected to happen and when things actually happened.

The list of events can be viewed on this finder page.

We have created a template spreadsheet that you can use to create timetable data. It lists all the events and you can fill in the event-date and link it to a local plan. The spreadsheet contains example data for a few plans. We create this data by look at various LPAs' local development schemes or reading the page on their site that provides information on their local plan. You'll see that for some we have been able to extract a comprehensive set of data, for others it is a bit sparser. But we've collected what we can - some data is always better than no data.

We are going to use this thread to capture examples, if we find any, of timetables that LPAs publish.

[colmjude]

Thurrock have a timetable element on their local plan site

[colmjude]

Camden had this "timetable" in their local development scheme

[colmjude]

Issue - duplicate dates

We capture the adopted-date on the main Local plan record.

This is useful because a user can take the local plan dataset and for any plan they will know if it has been adopted (the adopted-date field will have a date in it) and when it was adopted (again, the adopted-date field provides this information).

However, we also collect the date it was adopted as an event in the local-plan-timetable dataset.

This is a problem because it means we are capturing the same data in 2 places. This is something we try to avoid because if the same data is in 2 places then it opens up the possibility of them being different and therefore confusing the user of the data.

This is the case with adopted-date and may become a issue with other significant, status like events. Another one being when a plan is withdrawn.

[colmjude]

Issue - is found-sound an appropriate event

When the Inspector publishes their report, they are saying that the plan is capable of being found sound, subject to the LPA making the agreed main modification changes.

This report marks the end of examination.

Therefore there is a question about whether we need to record both the date the inspector's report is published and the date the examination period ends.

There is also a big question mark about whether we should capture the plan being found-sound as a specific event because it is more an outcome of the steps in the process instead of a specific event along the way.

[colmjude]

Updating your local plan record overtime

We had a question about how to handle changes to your local plan record over time.

The simplest way is to update the parts of the record as they change, whilst keeping things like the reference the same (so that the platform recognises it as being about the same plan).

For example, lets look at a plan going through the Draft → Submitted → Adopted stages.Only the name and, eventually, the adopted-date change:

1. Draft Local Plan
   The plan is in draft, so the LPA has titled it “Draft Local Plan.”

reference	name	period-start-date	period-end-date	local-plan-boundary	document-url	adopted-date	entry-date	start-date	end-date
LP-CMD-123	Draft Local Plan	2025-01-01	2035-12-31	BND-456	https://camden.gov.uk/plans/LP-123.pdf		2020-06-01	2020-01-01

2. Local Plan (Submitted)
   Once submitted, they update the title so it’s clear people are looking at the submitted version.

reference	name	period-start-date	period-end-date	local-plan-boundary	document-url	adopted-date	entry-date	start-date	end-date
LP-CMD-123	Local Plan (submitted)	2025-01-01	2035-12-31	BND-456	https://camden.gov.uk/plans/LP-123.pdf		2020-06-01	2020-01-01

3. Adopted Local Plan
   After adoption, they change the name again and fill in the adopted-date (this allows users of the data to filter on only adopted plans). Everything else stays exactly the same.

reference	name	period-start-date	period-end-date	local-plan-boundary	document-url	adopted-date	entry-date	start-date	end-date
LP-CMD-123	Adopted Local Plan	2025-01-01	2035-12-31	BND-456	https://camden.gov.uk/plans/LP-123.pdf	2021-11-06	2020-06-01	2020-01-01

[psd]

I've added three numbers to the draft local plan specification and local-plan dataset to capture the high level housing numbers in a local plan:

• required-houses --- the total housing requirement (net additional dwellinghouses) for the plan period
• allocated-houses --- the number of additional dwellinghouses allocated to sites by the local plan
• committed-houses -- the number of dwellinghouses already committed for development within the local plan area

where "dwellinghouse" is a building, not flats (see designing buildings wiki for definitions) and "committed for development" relates to permissioned developments which have commenced.

The windfall houses can therefore be calculated from required-allocated-committed.

[psd]

After some discussion, we're renaming these fields from -houses to -dwellings and are clarifying the precise definition of a dwelling with policy colleagues. There is discussion about certain kinds of development being classed as dwellings differently in different places. For example, some monitoring excludes student and sheltered accommodation. We are working towards the number being comparable with other definitions across the planning and housing system.

[psd]

We are also looking to explicitly record windfall-dwellings rather than treating it as a calculation to enable counts of other classes of allocation to be added to a plan.

[psd]

Reverting this idea: we wanted to move the housing numbers to -dwellings to add precision, but that doesn't capture the numbers in existing local plans and requires a policy change for future plans. So we've moved back -housing described as "the amount of housing" which is similar to the number of homes. We can look at possibly being more precise when it comes to recording each allocated site in the future.

[psd]

We've also created a separate local-plan-housing dataset which enables the breakdown of housing numbers for each LPA area in a joint local plan:

• required-housing
• allocated-housing
• committed-housing
• windfall-housing
• broad-locations-housing

[psd]

Local plans are for a single or multiple LPA areas. We don't need to support "partial" local plans.

To simplify how we ask a LPA to provide the boundary for a local plan, I've added the local-planning-authority field to the local-plan-housing dataset.

I've also added local-planning-authorities field to the local-plan dataset. This may be used to reference the local-planning-authority area for a single plan, and the list of local planning authority areas for a joint local plan.

This is expected to replace the local-plan-boundary dataset.

[psd]

The draft local-plan dataset included an adopted-date field. This is an inconsistent design pattern. I've deprecated this field, replacing it with the start-date which is the date when the plan applies (when it is adopted) and clarified the guidance against the dataset and the specifications.

[psd]

We separated out the local-plan-timetable dataset to match the separation in how the policies have been described. I think this complicates understanding for users, and the importance of the reference linking the datasets together.
https://digital-land.github.io/specification/specification/local-plan/

https://digital-land.github.io/specification/specification/local-plan-timetable/

[psd]

The specifications now contain more content. On the timetable I've clarified the way to predict dates, adding them as fields to every timetable entry, reducing the number of different events: