Planning application submissions #98
Replies: 7 comments 24 replies
-
Explaining our work on planning application submissionsIdentifying and analysing template componentsCurrently, the standards for planning applications consist of various templates and national information requirements, each with different components such as ‘applicant name and address’, ‘waste storage and collection’ and ‘parking’. To build a foundation for standardisation, the data design team are cataloguing these components across all templates, noting how often each one appears. For instance, ‘applicant name and address’ appears on all 24 templates, while ‘parking’ is only included in a few. This analysis aims to identify the core elements needed across templates. Developing data specificationsThe primary goal is to establish detailed specifications for each component, defining exactly what type of data should be captured under categories like ‘address’ or ‘parking’. These standardised specifications will ensure that any instance of a component, such as ‘address’ follows the same format. This consistency will then be integrated into new template designs to form a cohesive, unified data structure. Creating interoperable software schemasOnce standardised components are defined, they should be used to inform software schemas. This maintains data consistency across various systems, allowing for seamless interoperability. Databases on different platforms can then exchange data effortlessly because of the shared structure. Maintaining consistency across systemsThere is a need for local authorities to move data between systems and suppliers without risking reformatting issues or data loss. Standardising data components makes these transitions straightforward, ensuring minimal disruption for planners who will continue seeing familiar input fields on their screens, only now they’re underpinned by a consistent data structure. National picture of planning activityImproving the consistency and flow of data at the planning application stage will lead to greater transparency across the planning landscape and make it possible to create a single source of the truth. This makes it possible to take a more data-led approach where it’ll be possible to track housing delivery, identify stalled sites, support building safety initiatives and see how our cities and rural areas are changing. Our next stepsForming a working groupTo make sure these goals are met, we are setting up a collaborative working group involving suppliers, users, local government and other stakeholders. Working in the openWe only have 20 places on the working group so we need to ensure that we have the right blend of stakeholders. We’re setting up and running an open community too to make sure those who can not attend the working group meetings can still see what we are doing and can contribute to the discussions we are having. This will run alongside the working group. This community-based approach would bring together commercial stakeholders and end users to refine and shape the specifications effectively. Short-term focus on specification agreementThe immediate priority is to finalise and agree upon the core data specifications, creating consensus within the working group. This initial step is critical before moving on to discussions on integrating specifications into software and establishing full interoperability. Laying the groundwork for interoperabilityAfter defining these core components, further work will focus on creating new templates and ensuring compatibility across software systems. The working group will lead these efforts, collaborating with both internal and external stakeholders to implement this standardised approach. |
Beta Was this translation helpful? Give feedback.
-
|
Great stuff Colm, Camden would like to be involved please :) |
Beta Was this translation helpful? Give feedback.
-
|
Hi @NoraAC - thanks for the message! We'll reach out when plans for the working group have been finalised. |
Beta Was this translation helpful? Give feedback.
-
Application typesOur first step has been to define a list of the main planning application types to start with. We’ll use this list of planning application types as the basis of the data specifications for planning application submissions. We’ll work through the list to understand what information and information components are required for each. Then we’ll use the list of components to understand the specific data requirements. We understand some planning authorities and people use and refer to more specific application types or sub-types (e.g. full planning major waste or prior approval - development of toll facilities). We will look at them, in particular, to understand the key differences between the main application type (parent) and any sub-types (children), in a future stage. The first set of application types we’ll look at are all:
They are:
Your inputWe have three asks:
|
Beta Was this translation helpful? Give feedback.
-
|
Good spot @James-Planningportal - you are right “Consent under TPO” doesn’t quite cut it if the existing form covers 2 application types. Thanks for also providing that background. That has helped provide a bit of the missing context! The fact its called a section 211 suggests to me it is its own type and looking at the form it does seem there are some “components” that are only applicable for the “consent under a tpo” application, which would also suggest it warrants being its own application type. Its probably one to open as an issue to resolve and take to the group. We’ll add the Hedgerow Removal Notice to the list. Thanks for your pointers @HBray-SCC Thats really interesting, I’d not heard of "Details pursuant" before (I have limited planning knowledge) so, yes, it would be good to find out how common that is or if other names are used so we can a) capture the variations and b) use one that works for everyone. The Public Service Infrastructure application is an interesting one. Do we know how common they are? It’d be good to unpack how they are handled differently and if that means certain data points/information become more important. @James-Planningportal do you know if the Planning Portal handle "Public Service Infrastructure applications" and "Mineral development applications"? We are not excluding county matter applications but starting out with a subset of all application types. We’ll probably look at county matter application types in a second round so very helpful to know about them thank you. Thanks @RichLimbrick - noted. I’m going to open an issue re the name of this application type so we can capture the variants people use and any information like avoiding “reserved”. |
Beta Was this translation helpful? Give feedback.
-
|
@colmjude @James-Planningportal - just to clarify on PSI applications. They are not very common. Very basically it's major applications relating to schools, prisons and other 'public' buildings... I think we (as a CPA) probably get a disproportionate number as all the school rebuilds, etc. and are Reg 3 applications for us, but I don't think they would be for Districts - not sure about Unitary PAs. We do get them through the Planning Portal, but not marked as such; it is up to the LPA to identify which applications meet the criteria, process accordingly and determine on the shorter timescales - although being Major applications they often get Extensions of Time anyway. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @HBray-SCC, is the applicant aware they are preparing and submitting a PSI application? |
Beta Was this translation helpful? Give feedback.
-
|
Good question @colmjude. Personally, I doubt they would be aware - I don't think it's something we mention in pre-app or anything and they are just submitting a full application. How it's processed is up to the planning authority. |
Beta Was this translation helpful? Give feedback.
-
We handle PSI applications via the full planning permission type as requirements are the same. We do flag in the 'Description' question that such applications may be eligible for faster determination timeframes
We do not currently handle Minerals applications, but have a draft specification for them that we are planning to implement once we've carried out some testing with local authorities (and I've previously spoken to @HBray-SCC about them helping here). So if this type is in contention, we've already done a fair bit of work to analyse a range of different LPA application forms to draw out common questions and fields (including where we can reuse common components from other application types). |
Beta Was this translation helpful? Give feedback.
-
Information requirementsHaving decided on the applications to look at, next, we want to understand what the information components for each application type are. To do this we decided to look at the existing forms. Why?The information requirements and conventions have already been built into the forms over the years they have been developed and used. So, as a first step, we will work backwards from the existing forms, using them as input to analyse. This analysis will inform the as-is set of components for each application type. Once we have this list of components, we can work through the underlying data requirements (or specifications) for each.
OutcomeOnce we have the list of components it should be possible to use it to determine what is the minimum information (and data) required for each application type, whether a single type (for example, Householder) or a combined one (Household with listed building consent). It would then be possible to dynamically generate a form for any combination of applications an applicant wants to submit. |
Beta Was this translation helpful? Give feedback.
-
|
Agree on the existing/proposed split. Can be covered in same component, but each specifically called out (much as it is in materials, residential units, and others). Regarding some of the others that are not a 'one size fits all'... 'Checklist' is broadly replaced by 'supporting documents' functions in PP (and the PlanX equivalent), but the specific requirements vary by application type nationally and via any local information requirements. 'Eligibility' is also varied as it covers the specific requirements of the permitted development right that each specific prior approval relates to, plus a separate set of fields for non-material amendment eligibility (again to determine if proposal is in scope for that type). 'Description...' is much more common across types, apart from a couple of examples, such as advertisements, which captures much more granular detail about each proposed advert (e.g. size, illumination, etc...) Finally, whilst the component 'titles' may be common, that is not to say there is variation within them based on the requirements for each type. These could be additional fields (an extreme example being biodiversity net gain for householders vs full), or that different logic is required (e.g. more mandatory information about materials for listed buildings than non-listed). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for calling that out @jessicamcinchak, we’ll make sure we’ll keep these things apart - or at the very most only join the sets of fields under a single component whilst being mindful to make sure not to lose the distinction in the data provided. A good one to walk through and discuss! Thanks @James-Planningportal , thats very helpful. And the ‘checklist’ part was something I was going to ask about. With the checklist replaced by supporting documents does PP still include the checklist section if an applicant chooses to download the completed application form as a pdf? Or has it become completely redundant at this point? We hope to be able to include the requirements (required docs) in the appropriate specifications - starting with the nations ones and then, in the future, looking at whether it’s possible to do the same with local area requirements. At the moment does PP have a set list of required docs for each application type? Do you venture into local requirements or is that currently down to the applicant to look at the local area requirements (or do a pre app)? Agreed, how we model that variation is something that we’ll need to work through but is hopefully where the MUST, SHOULD, MAY groupings will help. We noticed the additional material information required for listed building apps but one thing I had a question about was why for a Householder + Listed Building Consent application it seems to ask for just the material information asked for in a Householder app (and not the extended one found in the LBD form). Have I interpreted that correctly? Anyone know why that might be the case? |
Beta Was this translation helpful? Give feedback.
-
|
@colmjude regarding the 'Checklist', it is not included in our online question set, as it is covered by the supporting documents section and other functions such as fee calculator. The forms generated from applications in our online system also do not contain the 'checklist' component. However, the 'blank' PDF forms we provide (which are only intended for printing and completion by hand if 'online/electronic' completion/submission is not possible) do contain it as per the government templates. I guess that as an overall 'requirement' the checklist serves an important purpose to call out all the elements necessary to make up a valid submission (obviously subject to the content of those elements being sufficient!), but it still has to do so with enough grey area to cover the entire potential scope of the application type. This currently means, for example, that its hard to pin down EXACTLY what plans/drawings a user may require, as this will depend on the subject of the application. Generally, this comes down to: "any other plans, drawings and information necessary to describe the development which is the subject of the application" as per DMPO legislation (though some application types do more specifically require 'floor plans', etc...) Planning Portal maintains a list of nationally required documents, which are taken from a wider overall standard list of document types (which also includes many specific types of plan/drawing). It also allows LPAs to configure additional mandatory document types from that wider list based on their local requirements via their individual PP admin accounts. The full list of our current standard supporting document types is online here: https://ecab.planningportal.co.uk/uploads/planning-portal_supporting-document-types.xlsx More than happy to run you though this with a screen share if that's useful. |
Beta Was this translation helpful? Give feedback.
-
|
This work (and the PP doc list James posted above) is really useful for trying to align a Local Application Requirements standard too. This would then allow the "checklist" or local requirements to be incorporated into forms as long as LPAs publish their requirements in line with any standard (many are based on app type). |
Beta Was this translation helpful? Give feedback.
-
|
@RichLimbrick we've started pulling together a list of the planning requirements (document types) based on the list James shared and looking at LPA local area requirements. A good first step would be to collaborate on a definitive list of requirements with descriptions so everyone works from a shared footing. From a quick look at various local area requirements it does look like people use different (often only slightly) names for the same thing. Aligning these would then help with the next step which would be building out a local area requirement specification. We've added an issue for discussing this |
Beta Was this translation helpful? Give feedback.
-
Components and fieldsWe have listed out all the components and fields of the planning application forms we’ve reviewed. Evaluating the elementsNext we want to evaluate each element. This is where we could do with the help from people in the community. Your expertise is needed to help us to capture, for each element:
The spreadsheetIn the recent Advisory and community sessions we trialled sharing an open spreadsheet to handle all contributions. We are going to use Googlesheets for now. As we receive your feedback we can iterate it as needs change. There is a worksheet called “Instructions” which explains how you can contribute. Essentially, in any way you want. Option 1Feel free to work directly on that spreadsheet, its open to everyone so all your contributions will be visible to anyone who access it. We just ask that if someone else has already entered something into a cell then you don’t remove it. If the cell contains text then you can add your text to the same cell. Or you can add comments. Option 2An alternative approach would be to duplicate the worksheet to make your own tab (tabs at the bottom) and work on your own tab. If you do this note that the spreadsheet is completely open and “live” so everyone will be able to see your working and be able to comment if they wish. Option 3Another alternative is to take a copy of the whole spreadsheet and work on this “offline”. If you do this then you can send your spreadsheet to the data design team or reply to this post and share it here. We (data design team) will then collate your contributions and add them into the mix. Option 4You may wish to just send us a few notes - that’s great and helpful too. Reply to this post if that’s how you’d like to do it. SPREADSHEET: planning-application-components-and-fields Managing contributionsTo help us manage this process, we have created a couple of versions of this spreadsheet and made them open for people to contribute. Plus people can duplicate and share if they wish. This might mean you come across a version that doesn’t have your contributions in it. If that happens this is probably why. Yours will still be in the version you worked on and we will ensure all contributions are incorporated into a single version. We’ll share separately, as the output of this activity. Any questions, do ask. We look forward to seeing what we get! |
Beta Was this translation helpful? Give feedback.
-
|
My main piece of feedback will be that many of the fields you have collected have GUIDS, and fairly robust definitions, and defined datatypes with the [IFC schema], which I mentioned on the call. This schema provides some efficiencies I think you may be able to apply here. For example IFC uses groups of properties (it call PSets) which it assigns to entities. For example Address information (Pset_Address) that can be applied against 3 different entity types: Actors, Buildings, Sites (it calls ifcActor, ifcBuilding, ifcSite) Considering that you reuse address fields across: Applicant (actor), Agent (actor), Site (site), Adjoining premises (building), Tree ownership (actor). It may be possible to rationalise these by allowing the same fields to be assignable to different actor types. In addition, the main advantage of alignment to IFC will be the ability for designer and engineering software to export information in IFC. i.e. having design works in Revit, Archicad etc, a specific subset (called MVD in their language) could be exported which provided the information needed to populate (or event pre-populate) planning forms. I’m pretty knowledgeable in IFC but by no means an expert. I do know some people far more knowledgeable than I am on it I can connect your team with if you are interested? They work within specific voluntary groups looking at IFC and its relationship with regulations, so they may have further ideas or case studies from other countries you could also benefit from. Just let me know! |
Beta Was this translation helpful? Give feedback.
-
|
Hi all. Mike Rose has introduced me to this work. My interest at GeoPlace is around definitive addressing and Unique Property Reference Numbers. We maintain the national index of addresses which is published by Ordnance Survey as AddressBase. The address data is updated by every local authority and contains a unique ID (the UPRN), geolocation and other important attributes like usage classification and parent/child relationships. The Open Standards Board have mandated the use of the definitive address and UPRN across all government systems that use property information. The address data is available via an OS API and is being used by the VOA, EPC surveyors, Electoral Registration, DVLA and many other services to unambiguously identify properties and their address. Local authorities will, in the main, use UPRNs in their planning and BC systems and we are leading the sector towards recording development site and plot information in the address data from planning applications (approvals is our focus). We are also talking with NHBC and LABC about how we can work with BC notices tied to UPRNs to enable tracking of properties through the development process. We are also very involved in the Home Buying and Selling Group. I would be really keen to discuss how our data could be a component of digital planning standards. Mike and I have discussed a show and tell, and I'm keen to get involved in this work if anyone would like more info. You can find more about what we do at www.geoplace.co.uk. Thanks |
Beta Was this translation helpful? Give feedback.
-
|
? comment may be in wrong place.
|
Beta Was this translation helpful? Give feedback.
-
|
Having now looked at this housing section of the spreadsheet I am impressed: it looks pretty good on the proposals, though it is not clear (to me) where the pre-existingdata are entered to enable NET CHANGE to be computed. Overall/global comment on the entire project: have you thought of using a model in which the entire form is made up of blocks such that an applicant only getts to see the blocks which apply to their case? The brilliant example is the HMRC self-asessment form which is very soimple for most people to use because there are filters everywhere like I DO NOT HAVE SELF-EMPLOYMENT INCOME or I DID NOT DISPOSE OF CHARGEABLE ASSETS THIS YEAR. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Micahel, thanks for contacting us here.
|
Beta Was this translation helpful? Give feedback.
-
Update - Jan 29th 2025Hi all, Here is a quick update. Over the last week, we’ve held both an advisory group and a community group drop-in session. Details of the sessions can be found on the Advisory Group page. We’ll add links to minutes, slides and videos in the coming days. I just wanted to share the planning application data specification repository link that we have recently set up. From this point, we’ll use that repository to share draft specifications and supporting datasets (enums) and track issues and discussions. We’ll still use this discussion thread to provide overall updates and will use the issues section of the new repository to focus on specific issues related to the specifications. |
Beta Was this translation helpful? Give feedback.
-
Update - Feb 14th 2025Summary of work on the planning application data specification work:
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Planning application submissions
This discussion is specifically for discussing work on technical specifications that relate to the data needed to submit a planning application.
It is the first part of a wider initiative MHCLG have started to look at data specifications for planning applications.
These specifications are how we plan to promote greater interoperability between systems handling planning applications, whether that is systems helping applicants prepare and submit a planning application or back office systems (BOPs) used by planning officers to review and assess planning applications.
Beta Was this translation helpful? Give feedback.
All reactions