PMLH

Postcode 
Management 
Licence Holder

National  Postcode System 

Design Report

V. 4.0

May 2014

Peat COO ) 

,

Management 

Licence Holder  ■

Revision  History

Revision  Date

Summary  of Changes

Changes  Marked

21  Feb 2014

Draft Report (Formatting  required)

No

23 Feb 2014

Final draft

No

14 March  2014 Revised final draft

Yes

8 April 2014

Final  amendments

Yes

28  May 2014

Final formatting  amendments

Yes

Version

4 0 issued 28 May 2014

Contact 

Liam  Duggan, Account Director

Capita  Ireland,  2 Grand Canal Square,  Dublin 2.

M n h ilo   +  

* °   '

_L

7 ELI

Postcode 

MirJ^urjnl 

Licence Holder

Table of Contents

E xecutive  S u m m a ry

................................................................................................................................................

.............. 1

Design  Principles..............................................................................................

.....................

1

W hat  gets  a  Postcode?................................................................................... .............. 2

Po^tc Dd E  D^SI^ 0 

l j

+

l j

+

l j

+

l

. ^ .

j + l j

 

l

 ■ 

j

 

lij

 

l

3

Postcode  Validation.........................................................................................

PAD  Design........................................................................................................ .............. 4

PAD  V alid atio n ..................................................................................................

.....................

5

PAD  Pricing

............................................................................................................................................................... .....................

5

Conclusions........................................................................................................

.....................

6

1

,

In tr o d u c tio n

........................................................................................................................................................

.............. 7

1.1 

Pu rpose  of  th is  Docum ent

........................................................................................................ .....................

7

1.2  Background  to  this  Docum ent

............................................................................................

.............. 7

1,3  Contents  of this  Docum ent..................................................................

.....................

S

1 .4   Desig n  Pri nci p ies ....................................................................................

.....................

8

2

Postcode  D esign.......................................................................................

..................

10

2.1  Why  a  unique  postcode  rather  than  an  area-based  postcode?

. ..................

10

2.2  W hat  gets  a  postcod e ?

................................................................................................................ ..................

11

2,3  What  gets  a  unique  postcode?

.......................................................................................... ..................

12

2.4  Routing  Key  (1st  three  characters  of th e  postcode)

.............................. ..................

13

2.5  U niq u e  I d enti n er  ( Last  fou r ch ara cters  of th e  pos tcod e )

.................

............14

2 .6   Character  set  used................................................................................. ............16

2 .7   Avoiding  undesirable  combinations................................................... ............10

3

Postcode V a lid a tio n ................................................................................

............19

4

PAD  D e s ig n .................................................................................................

............ 20

4.1  PAD  c o n te n t............................................................................................. ............20

4.2  Address  Elements................................................................................... ............20

5

PAD  V a lid a tio n ..........................................................................................

............ 23

5.1  Validation  of  GeoDirectory  source  d a ta ........................................... ............23

S.2  Validation  of PAD  versus  G eoD irectory........................................... ............23

5.3  PAD  Postcode  VaSidation...................................................................... ............23

5 ,4   Feedback  to  G eoD irectory................................................................... ............25

6

PAD  P ric in g ............................................................................................................ 26

6.1  D esignPrincipies

................................................................................................................................ ..................

26

6 .2   Pricing  models  in  other countries

..................................................................................

............26

6.3  Pricing  Model

............................................................................... .

....................................

..................

26

6 .4   Public  sector  use  of  the  PAD  d a ta ..................................................... ............29

Postcode 

MuUgimtr.t 

licence Holder  <

Conclusions............................................................................................................ 30

7.1  Achievement  of Project  G oals......................................................................  30

7 .2   Next  Steps.............................................................................................................3D

Appendix

A p p en d ix A:  Design A ssum ptio ns  &  D ecisions................................................. 31

1  P U rp OSe 

I  ■■  I  I  ■ I  I  ■ I  ■ .  ,  ,  ,  r m   n T n T n T n T i T n  + n + + i + + r H  + i ++rH + H  + i ++rH + rH + r++-++H++-++- + h'  + h ' + + ‘ + + '  + h ' + + "  + h"H + "H + " ' * ‘ 

3 1

A.2  Design  Principles............................................................................................ 31

A.3  Issues  Addressed  a nd  Reco m m e r* d a tion s.................................................

31

A ppendix  B:  S ta k e h o ld e r  E n g a g e m e n t............................................................... 68

8,1:  An  P o s t............................................................................................................ 88

A ppendix  C:  List o f R outing  K eys...........................................................................73

A ppendix  D:  Map o f Routing  K e y s .........................................................................74

Postcode 

Management 

Licence Holder

Executive Summary

This  report  describes  the  design  principles  and  methods  of  validation  for  two  key 

components  of  the  National  Postcode  System  (NPS):  the  postcode  itself  and  the  main 

vehicle  for  its  usage,  the  Postcode  Address  Database  (PAD)  which  cross-references 

postcodes  and  addresses  including  non-unique  addresses.  It  builds  on  the  earlier work  of 

the  National  Postcodes  Project  Board  around  2006  and  subsequent  studies  and 

consultations  conducted  by  the  Department  of  Communications,  Energy  and  Natural 

Resources  (DCENR).  The  legal framework for the  NPS  is  set down  in the Communications 

Regulation (Postal Services) Act 2011.

Design  Principles

The  consultations  referred  to,  informed  also  by  the  Postcode  Management  Licence  Holder 

(PMLH)  procurement process,  set out a number of design  principles,  inter alia:

■ 

The postcode should be unique for each address point -  referred as “Unique Delivery 

Point"  (UDP)  - and initially at least,  be used solely for identifying  postal addresses,

■ 

It should  consist of a three-character Routing  Key identifying the  principal  post towns 

assigned  by  the  Universal  Service  Provider  (USP),  followed  by  a  four-character 

Unique  Identifier for each  UDP within that area.

■ 

Dublin  postal  districts  should  be  retained  but  all  other  Routing  Keys  should  avoid 

association with geographic features such as town or county names.

■ 

The form  of address  used  (in the  PAD) should  be the  postal  address - as determined 

by the  USP -  in  Irish  and English.

■ 

The  detailed  design  of the  postcode  should  facilitate  automated  and  manual  sorting 

of post (through consultation with the USP).

A  special  licenced  service  should  manage  and  operate  the  NPS:  the  Postcode 

Management Licence Holder (PMLH).

The  above principles were  based  on  experience  in  implementing  new or changed  postcodes 

in  other  countries  and  on  the  high  proportion  (35%)  of  non-unique  addresses  (NUA)  in 

Ireland.  In  most countries,  a  postcode is assigned to clusters of properties ranging  in size  of 

10-50 properties (e.g.  UK) to tens of thousands (e.g.  most EU  countries).

The  'non-unique  address'  issue arises elsewhere  (albeit to  a far lower extent)  and was  dealt 

with  by  enforcing  rigid  addressing  standards;  for  example,  the  UK  insisted  that  instead  of 

using  townland  names,  all  rural  roads  were  named  and  each  house  assigned  a  number 

This  process  added  greatly  to  timescales  for  adoption  due  to  the  workload  involved  and  to 

cultural  resistance.  Trying  to  do  so  in  Ireland  would  risk  considerable  delay  and  possible 

failure  of  postcode  adoption.  That  idea  was  therefore  dropped  in  favour  of  assigning  a 

unique identifier to each property that did not necessitate changing addresses.

The  PMLH  team  conducted  further  research  and  consulted  with  the  USP  to  arrive  at  the 

detailed  specification  for the  proposed  postcode  and  PAD.  The  team  then  prepared  plans 

for how the postcode and the PAD can  be validated so as to protect its integrity and  promote 

confidence amongst public,  commercial and  personal  users.

National  Postcode System
Design  Report 

Poatcodo

I S

l T

i U

l l   Managenumt 

L. _ 

Licence Holder 

*

W hat gets a  Postcode?

All  addresses  in  permanent  structures that receive  mail will  be  assigned  a  postcode  and will 

be  included  in  the  Postcode  Address  Database  (PAD)  -  these  are  known  as  a  Unique 

Delivery  Point  (UDP).  All  UDPs  and  their  addresses  are  recorded  in  the  GeoDiredory 

database;  they will be passed to the PMLH for inclusion  in the PAD.

An  important  point  to  bear  in  mind  in  assigning  postcodes  for  commercial  premises  is  that 

postcodes  relate  to  the  property  or  building,  not  to  the  business  itself.  Within  multi-unit 

complexes,  postcodes will  be  assigned  to each  unit  if they  are  addressed  as  such  (e.g  Unit 

20  in  a  shopping  centre)  but  not  to  each  tenant  in  a  multi-tenancy  building  (e.g.  an  office 

shared by a number of businesses)  but rather one postcode will be given to the building.

The  GeoDirectory  does  sometimes  record  the  businesses  within  a  property  as  a  value- 

added feature  of its  database  but these  are  not  relevant to  addressing;  such  instances  can 

be identified and dealt with in creating and maintaining the PAD (i.e. they will share the same 

postcode  assigned  to  the  building).  The following  are  some  examples  of what  will  and  will 

not be allocated a postcode

What gets a  Postcode

What does  NOT get a  Postcode

Each  residential property, e.g.

• 

Each house on a street

• 

Each flat in an apartment block

• 

Both  units in a duplex unit

• 

Halting site

Other types of residence, e.g.

• 

Mobile homes

1

!  • 

Canal barges or houseboats

• 

Jeanie Johnson

• 

Caravan

Mon-residential addresses, 

e.g.

 

Office building

• 

Factory

■ 

Units in a  Shopping Centre

• 

Units  in  a  Business  Park  or  Industrial 

Estate

• 

College Campus

Ancillary buildings/locations 

e.g.,

• 

Milking  parlour

• 

Sports fields

• 

Public parks

• 

Points of interest (e.g  Dublin Spire)

In the case of multi-unit buildings (e.g.  apartments  in an  apartment block,  units  in  a shopping 

centre),  a  postcode will  be assigned to each  UDP which  is  a  unit which  is  uniquely identified 

within  the  address  information  (i.e.  an  apartment has  a  unique  number;  the  shop  has  a  unit 

number)  by  the  USP.  In  these  cases,  business  name  alone  is  not  considered  a  separate 

UDP,  as  postcodes  are  not  assigned  to  individuals  or  businesses,  but  rather  they  are 

assigned to addresses.

In  the  case  of  mixed  use  buildings  (i.e.  residential  and  non-residential  UDPs),  unique 

postcodes  will  be  assigned  for  each  uniquely-addressed  residential  UDP  and  each  non- 

residential  UDP (i.e. there will be a minimum of two unique postcodes in such buildings).

Postcode  Design

The detailed design of the postcode firstly considered how the two segments of the postcode 

should  be  allocated. 

The  first  three-character  segment  (“Routing  Key")  is  designed  to 

support  the  methodology  for  manual  sorting  of  mail  which  will  bring  operational  and  cost 

benefits  to  postal  operators  and  improve  downstream  access  opportunities  to  the  USP 

network  by third  parties.  Consistency  in the  style  of the  Routing  Key  is  also  important,  so  a 

style  similar  to  that  used  for  Dublin  Routing  Keys  (D01,  D14,  etc.)  is  retained,  i.e.  other 

Routing  Keys  are  in  a  letter-number-number  style  (e.g.  A10,  F24,  etc.).  While  not  linked 

directly to geographic features (i.e. towns,  counties,  etc.),  it will provide a sense of location in 

a  similar fashion  to  telephone  prefix  codes  do,  so  providing  a  sense  of geographic  intuition 

aiding  better recall.

The  random/structured  issue  was  also  considered  in  regard  to  the  second  segment  of the 

postcode,  the  “Unique  Identifier”. 

A  structured  form  of  Unique  Identifier  would  involve 

linkage  to  geographic  features  (i.e.  streets,  townlands)  and  assigning  house  numbers. 

Although this  style  is  more  intuitive,  it has  no value  in  sorting  mail  and extensive geographic 

surveys are needed to create it and subsequently,  in maintaining  it.  This type of code is also 

more prone to running  out of capacity (i.e.  resulting from growth in towns,  streets,  etc.) which 

can  lead  to  people  having  to  change  their  postcode  which  is  very  disruptive. 

An 

unstructured  or  random  Unique  Identifier  is  more  ‘future-proofed’  and  its  setup  and 

maintenance  effort  is  minimal;  for  these  reasons,  a  randomised  Unique  Identifier  is 

recommended.

The  length  of the  code  is  an  important factor as  regards  “memorability”  as  this  will  strongly 

influence  adoption  rates.  Internationally,  postcodes  vary  in  size  from  4  to  10  characters; 

most  are  all  numbers  but  some  use  numbers  and  letters  (e.g.  UK,  Canada,  and 

Netherlands).  Shorter codes  are clearly easier to  remember so the  main  issue  is to find the 

minimum  size that can accommodate the  number of Unique  Identifiers within  a  Routing  Key. 

At  present,  the  largest  Routing  Key  area  has  80,000  UDPs  but  the  average  Routing  Key 

area  has  12,000  UDPs.  To  allow  for  growth,  the  Unique  Identifier  needs  to  be  able  to 

accommodate  350,000k Unique  Identifiers  per Routing  Key.  Doing  so using  numbers would 

lead to a  nine-character code  (without counting  spaces).  Adopting an alpha-numeric Unique 

Identifier would  only  require  a  four-character  code,  giving  a  total  length  for the  postcode  of 

seven characters.  The proposed  postcode layout is therefore as follows:

Routing  Key 

Unique Identifier

f

A

6

5

Letter

Number

Number*

L  

J

AJpha-

Numeric*

Alpha

Numerio

Alpha-

Numeric

Alpha-

Numeric'

The letter "W” will only be allowed for postcodes in D6W.

The technical design work concentrated on four key areas affecting the postcode:

• 

Excluding  certain  letters  which  can  cause  problems  for  automated  mail  sorting 

equipment which uses optical character recognition  (OCR) technology.

■ 

Consideration was  also  given to  phonetically similar letters which  can  be confused  in 

verbal  communication,  notably in call centres.

■ 

Choosing  the  letters  used  for  the  Routing  Key  which  avoid  association  with  local 

features  along  with  some  other rules with  regard  to the  construct of the  Routing  Key 

(e.g.  avoiding  leading or trailing zeroes which  might be omitted inadvertently)

■ 

Avoiding  offensive  or  otherwise  sensitive  words  or  terms  (e.g.  proper  names, 

acronyms, words) within the combinations of letters and  numbers.

■ 

Avoiding  possible  miscommunication  of  postcodes  by  avoiding  physically  adjacent 

addresses having similar postcodes.

These are set out in  Section 2 with further detailed  analysis of the rationale in Appendix A. 

Postcode Validation

A series  of measures will  be  built  into the systems  and  processes  used to assign  postcodes 

to  ensure  accuracy,  completeness  and  adherence to the design  principles described  above. 

Further tests will  be conducted  independently of the team  directly engaged  in the  production 

of postcodes.

PAD  Design

The  Postcode Address Database (PAD) will cross-reference postcodes to addresses and will 

contain  one  record  for each  unique  delivery  point.  It will  be  derived  from  the  GeoDirectory 

which contains all postal addresses recognised by the USP.

The  PAD  acts  as the  main  vehicle for deploying  postcodes  into  organisations,  usually  being 

embedded  into  systems  to  assist  with:  postcode  validation,  address  verification  and 

postcoding  databases.  When  additional  data  is  appended  (e.g.  geo-coordinates),  the  PAD 

can  assist  in  areas  such  as:  marketing  analyses,  anti-fraud,  logistics  planning  and  other 

location-based services.

The  PAD will  be the  PMLH’s  primary  revenue  source  and  will  be  distributed  mainly  through 

value-added-resellers  (VARs).  The  PAD  which  will  be  made  available to  all  licence  holders 

will contain  standard  address details and  postcodes.  The  PMLH  will  enable the  provision  of 

enhanced  services  through  its  Value-Added  Resellers  (VARs)  who  will  be  provided  with 

additional  data  which  will  contain  address  “aliases”  and  (subject  to  contractual  agreement 

with  data  suppliers)  geo-coordinates  and  boundary  data  which  will  be  made  available  on  a 

separate commercial basis to that of the PAD.

The technical design  of the  PAD follows  internationally  recognised  standards  adapted to the 

unique  features  of  Irish  addresses  and  the  fact  that  there  is  no  obligation  to  change  or 

standardise  addresses.  The  PAD  design  caters  for supplying  Irish  and  English  versions  of 

postal  addresses and will  be distributed  in a technically standard  and  simple format (i.e.  as a 

‘flat file') which will  make it accessible to all levels of users.

A

After  the  initial  development  exercise  -   using  the  GeoDirectory  and  some  large  public 

service  databases  -  the  PAD  will  be  updated  (e.g.  with  new  addresses)  and  distributed  to 

licenced  users on a regular basis by the PMLH.

PAD Validation

The design objectives for PAD Validation are:

■ 

To ensure that every unique address is assigned its correct postcode

■ 

To ensure completeness and accuracy of the PAD

A series  of measures  have  been  built  into the development process to  achieve these  goals. 

In  addition,  a  number  of  independent  validation  measures  will  be  taken  in  respect  of  the 

PAD.  These will  involve  a  structured  sequence  of validating  the  prime  source  data  (i.e.  the 

GeoDirectory) for completeness and accuracy and then reconciling the GeoDirectory and the 

PAD.

The following diagram illustrates the relationship between the main data sources:

The final  component  of the  Validation  exercise  will  independently  assure  the  completeness 

and accuracy of the PAD itself,  particularly in regard to how postcodes are assigned and that 

the various rules (described  in Section 2:  Postcode Design)  have been fully implemented.

These  validation  processes  may  raise  queries  or issues  that  may  need  review or correction 

in  the  GeoDirectory.  The  operational  procedures  associated  with  handling  queries  -  and 

other aspects of the Validation exercise - are under discussion with GeoDirectory.

PAD  Pricing

Sales  of the  PAD  are the  main  revenue source for the  PMLH,  so the  pricing  model  must  be 

low  to  encourage  use  of  the  PAD  but  it  must  also  generate  sufficient  funds  to  make  the 

PMLH self-funding.

The  Pricing  Model  has  been  kept as simple as possible with  options for larger users to have 

unlimited  usage  for  a  fixed  fee  and  for  smaller  users  (e.g.  small  businesses,  voluntary 

bodies)  paying smaller amounts related to  postcode lookups that they used.

The  Public  will  be  able  to  easily  access  the  PAD  data  for free  from  a  dedicated  web  site. 

The  cost  of  using  the  PAD  data  for  commercial  or  non-commercial  purposes  will  be  the 

same irrespective of how the data is purchased.

The  pricing  is  based on the  indicative  pricing  included  in the tender document and  has been 

designed  to  encourage  use  of  the  data  as  widely  as  possible  and  in  as  many  markets  as 

possible. 

A  number  of  companies  in  different  markets  (e.g. 

Internet  and  customer

*

Postcodft 

MaiiageirumJ 

Licence Holder

management  systems)  have  had  the  opportunity  to  comment  on  the  proposed  pricing. 

Following  these  meetings  with  companies  and  a  study  of  licensing  approaches  in  other 

countries,  slight adjustments have been recommended.

It is  recommended that a  negotiation  is  undertaken through  central  procurement (OGP/CIO) 

to agree a  non-discriminatory,  annual PAD licence fee for unlimited  use across named  public 

bodies.

Conclusions

We  believe  that  the  proposed  design  will  achieve  the  goals  set  for  the  project  and 

accommodates  the  sortation/operational  requirements  of the  USP.  Validation  programmes 

will  provide  assurance  as  to  the  accuracy  and  completeness  of  the  postcodes  and  of the 

PAD.

The  postcode and  PAD designs are on the critical  path for the overall  project as they directly 

affect two  key project milestones:

• 

Passing  the  full  PAD  to  the  USP  so  that they  can  start  on the  nine-month  project to 

postcode-enable their automated sortation systems

• 

Releasing  the  postcode  specifications  and  PAD  specifications  to  VARs  so  that they 

can proceed with developing and refining their products and services.

Both  must occur by the end  June 2014  in  order to  achieve the overall objective of launching 

postcodes in April 2015.

s