We need to decide where to record UPRNs affected by a planning application or proposal.
UPRNs are useful because they identify properties and can support matching, search and analysis.
Current situation
The submission specification currently has uprns in the site-location component, used by the site-details module on application forms. That made it tempting to also include uprns in the decision-stage site dataset.
But that may not be the right place. The site dataset describes the land or buildings the application relates to. If we have a site boundary, UPRNs within or intersecting that boundary can often be derived from a property gazetteer. Storing that derived list on site could become stale or conflict with the boundary. As a general rule we try to avoid recording inferrable data.
There is a separate use case: applicants may need to identify which properties or UPRNs are affected by the proposal. That is not necessarily the same as every UPRN inside the site boundary.
What we need
We need a pattern that lets us:
- record applicant-supplied affected UPRNs where they are known
- distinguish submitted affected-property information from UPRNs derived from a boundary
- avoid making
site carry derived data that could go stale
- support search, matching and analysis by affected property
Where should affected UPRNs be recorded?
Questions for feedback
- Currently, do applicants often provide UPRNs during the application process?
- When applicants provide UPRNs today, are they identifying the site, affected properties, or both?
- Are affected UPRNs needed in the decision-stage specification, the submission specification, or both? What will they be used for?
- If UPRNs are derived from a boundary, should that derived list be part of the specification or left to consuming services? There is a difference between what gets stored and what can be provided to consuming services.
- Should we create a separate affected-property or affected-premises pattern linked to the planning application?
- Do we need provenance, for example applicant-supplied, authority-supplied or system-derived?
We need to decide where to record UPRNs affected by a planning application or proposal.
UPRNs are useful because they identify properties and can support matching, search and analysis.
Current situation
The submission specification currently has
uprnsin thesite-locationcomponent, used by thesite-detailsmodule on application forms. That made it tempting to also includeuprnsin the decision-stagesitedataset.But that may not be the right place. The
sitedataset describes the land or buildings the application relates to. If we have a site boundary, UPRNs within or intersecting that boundary can often be derived from a property gazetteer. Storing that derived list onsitecould become stale or conflict with the boundary. As a general rule we try to avoid recording inferrable data.There is a separate use case: applicants may need to identify which properties or UPRNs are affected by the proposal. That is not necessarily the same as every UPRN inside the site boundary.
What we need
We need a pattern that lets us:
sitecarry derived data that could go staleWhere should affected UPRNs be recorded?
Questions for feedback