Planning Expert System (part 1 of 4)

Long before I joined PAS there was an e-gov project called PARSOL. It created several products that I can remember wrestling with. Some – like the e-planning service standards – I though were very useful. Others less so.

When the time came for PARSOL to disappear, ownership and ongoing responsibility for its products was divided between PAS and the planning portal. One of the products that came to PAS was called the ‘planning expert system’. It might be more accurate to describe it as a set of Q&A scripts that guide a user through the permitted development legislation. Through a combination of the users answers ‘I want to extend my dwelling’ and back-office integration ‘the property is in a conservation area’ answers can be produced. Either you need to apply for planning permission, or you don’t.

The system as it stood suffered from many of the same issues as other PARSOL products. It had low take-up, and there might have been a lingering suspicion that some of the organisations involved might have used the money in a more public-spirited way. We extended it by adding scripts to cover the microgeneration legislation a while ago, but downloads remain low and implementations rare. If you want a peek at one, try South Cambridge.

All of this might have bumbled along for a few more years if there wasn’t a crisis looming. The Householder Development Consent Review (HDCR) promises to deliver a fairly wholesale shake-up of how permitted development is assessed. No longer about volumes, it is instead more about impact and neighbourliness. As an aside, while it can be considered to be a relaxation (i.e. more things are now permitted without a consent) some things that would have been PD will now not be (think smallish things right along a boundary). Ah, the fun there’ll be for our enforcement colleagues.

So, we have a series of ‘expert system’ scripts – 182 of them. The legislative changes are of a scale that we can rip up the old and start anew. This series of posts is a record of my thinking, as I try to put together something to help guide people through the introduction of a new planning system.

Clean sheet of paper

Some of this design process will be tough, but the first few parts seem clear and shiny. Expressing knowledge as a series of pictures is silly. It means that people that have to build web-based systems have to interpret them as a series of pages. This double-handling means there is an immediate issue with accuracy and a potential for updates to become much more of a fuss than they need to be.

What makes this even more of an issue are the further legislative reviews that we can’t yet see. Kilian & Pretty and some of the noises coming out of BURR suggest that the HDCR is only the first in a series of comprehensive rethinks about what planning is and does. This means that the job of mapping the GPDO (The Town and Country Planning (General Permitted Development) Order 1995 as amended several times) onto some kind of process flow will happen not just once, but several times.

The first system decision then is easy – we’ll use XML to represent this structured, changeable and document-centric knowledge.

Having described this decision as easy, I should confess that I spent some time trying to use a published standard form of markup language. I had a look at RuleML, XPDL and Wf-XML to see if I could use their schema. However, it appears that I am not clever enough to understand them, let alone use one. I justify this to myself with the knowledge that XML can be transformed into pretty much any other form of representation fairly easily, so I can revisit this if someone can help me comprehend what I’m missing.

A plan for a system

The pieces of the new ‘expert system’ then are starting to become clearer. Working backwards from the output, then, we have :

A user receives session information. This looks a bit like

<session> stuff about IP, date, time, versions, name of user, maybe a hash to ensure it is a “proper” record </session>

<property> might be worth capturing an address, even if there are no links to constraint data </property>

<Q&A>

<node>answer</node>

<node>answer2</node>

…

</Q&A>

To make this happen, we need some kind of engine that is able to take a node expressed in XML. This has a question, a series of possible answers and a set of directions depending on the answer.

This suggests that the XML knowledge base doesn’t need to be much more complicated than

<ident> unique node key </ident>

<question> Will the development be at the </question>

<responses>

<answer>

<text> Front of dwelling </text>

<next_node> 123 </next_node>

</answer>

<answer>

<text> Side of dwelling </text>

<next_node> 456 </next_node>

</answer>

So, gathering this together I have to make four things:

1. An XML schema to define this simple process flow
2. The XML itself to capture the new Part 1 of the GPDO
3. An engine that can walk a user through a series of questions coded up in XML
4. Some way of capturing these sessions so that they can be reviewed, confirmed etc

There isn’t much time – barely five weeks before this thing needs to be public. The biggest and nastiest issue is number 3 – let’s start with trying to find an engine that will do what we want. This is suitable content for part 2.

Advertisement