One of the key problems to solve if the Carbon Co-op application is to work is the Locality problem. That is: who is near who? For the SiCamp weekend my approach was going to be simply to hack it by saying that everyone who shared the first same segment of postcode were in the same Locality.

This is blatently not true though. In London Boroughs matter more and can consist of different Postcode stems due to the alphabetic numbering system. In small cities like Swansea, Bath and Bristol you can effectively consider most of the city codes to be in the same Locality. Swansea postcodes also cover Carmarthen which is clearly not in the same locality as Swansea.

I have seen this handled in a variety of ways before, usually by creating a hierarchy where a Postcode stem is mapped to a leaf node in a tree which is normally the county, city or metropolitan area the area belongs to. The counties then belong to regions, regions to countries and countries to the UK, then Europe.

However for the Carbon Co-op I didn’t want to have the hassle of having to create and maintain a hierarchy. You also need to deal with the fact that people who share the same Postcode actually may have special meaning in terms of the projects they can partake in.

So I thought about create a Locality model that is simply named and arbitrary and which has many (and at least one) Locality Filters that are actually Regular Expressions. You then run someone’s postcode through the Filters to see which Localities they belong to. This deals with the situation where someone may be able to take part in Locality linked Actions for both Scotland and Fife.

Design-wise I’m quite taken with this and would like to implement it to see if it works in practice. However it is a techie solution as only programmers really love Regular Expressions and even then… not so much. To simplify the interface you would probably just have the user type the extent of the postcode they wanted to group. There is also a question of whether this filtering would actually scale. You might have to associate the Devotee with their Localities, which then raises the issue of when it should be regenerated, which makes you wonder whether you can back a Django model with a view, which makes a good case for doing it!