3. Our approach


The big opportunity present by the web is to shift from a planning system that runs on documents to one that runs on data.

From documents to data
Instead of asking users to provide information by uploading documents (forms, reports, statements and drawings) that can only be read by humans, wherever possible, planning services should ask for information in the form of structured data that can be read by humans or machines.

How will this help reduce invalid planning applications?

This allows us to do a few key things.

GIS data
It allows us to build services that pull-in any available geospatial (GIS) data relating to a property (for example spatial policies such as Conservation Areas) so the user does not have to research them.

Dynamic forms
It allows us to build services that respond immediately to the information already given, so users are only asked for information that is relevant to their project and location.
Web form validations
It allows omissions to be prevented from happening before the user can click submit, in the same way that many online forms do (eg when you buy insurance online).
Rules as code
Knowledge of specific policies and their implications for the user’s application can be coded into the service, so users don’t need to be experts.
Common registers
Pulling data from– and sending data to– common data registers, such as for addresses, property types, or planning registers.

Data interoperability
Creating a service API that makes data available in a structured, machine-readable way, ideally using open, standard schemas.


There are also some important, more general aspects to our approach:

APIs as a service

On the long term, we expect the service to be used not just by human users, but also by third party software applications via a REST API. This will allow others to build complementary software applications that send data to, or fetch data from the service. (Note need for appropriate security measures.)

Modular, extendable and updateable

We are designing all the services to be made using standardised, replicable modules, which can be run on a no-code editor platform, so they can be easily maintained, improved and updated by planning teams across different parts of government (local and national), ideally without knowing how to code. 

Standardise data

Wherever possible, we are using the same data structures as other services and registers, to maximise interoperability.

MVP

We can’t solve everything in one go. Instead we aim to develop a version of the service pattern that works (a ‘minimum viable product’), and then expand it later. You can read more about our scope here.


Mark