This service pack is specific to Hackney Council.
Hackney Council has a RESTful API that is open and combines LLPG/NLPG data to facilitate an address look up. We have modified our eDesigner solution to facilitate the use of this API.
Functionality
To add the address look up to a form navigate to design mode and click 'Add Item':
Add a section as shown here:
Select Address Fields from the list of section types:
Give it a field id, click 'Use address lookup' and select Hackney address lookup as the provider:
Follow these three simple steps and you'll have added an address look up to your form:
Notes
1) The Hackney Address API takes ~5 seconds to respond the first time it's used. All subsequent calls are virtually instant. This is important for the first time you use it as it seems it is not working the first time it is clicked.
2) If an invalid/nonsensical postcode is provided you will be presented with this:
3) When building a new eDesigner form you should you the option of blank if you want to use 'Who Are You' page. This will allow you to add the Address Fields with the Hackney Look up within them.
4) if you've already built an online form with address fields then this will not use the address look up. You'd need to tweak the form's design / add a new page etc. to then use the new address look up.
5) All product forms have the capability to use this now. IEG4 staff need to set this up on any product forms being used.
6) If no address is returned the user is able to manually type in an address. Where this occurs XML will not be stored in the form's XML. (highly unlikely)
7) A person could technically change address after doing a lookup, so UPRN wouldn't match with address entered manually IF this happens (highly unlikely)
8) The XML containing each UPRN will need to be processed by Hackney IT once back office systems start to become available.
API Foibles
1) For some postcodes more than one property with the exact same information is returned. The API should clearly not do this. Example below where the postcode BS5 8DD was used:
api/v1/addresses/?format=simple&postcode=BS58DD
2) Postcode is shown both the line4 element of the address as well as the postcode element.
3) Addresses are not ordered as a human would expect to interact with the results. For example, when you give the postcode BS5 8DD you get results ordered as follows:
{
"data": {
"address": [
{
"line1": "1 ST GEORGES AVENUE"
},
{
"line1": "10 ST GEORGES AVENUE"
},
{
"line1": "11 ST GEORGES AVENUE"
},
{
"line1": "15 ST GEORGES AVENUE"
},
{
"line1": "16 ST GEORGES AVENUE",
},
{
"line1": "20 ST GEORGES AVENUE"
},
{
"line1": "21 ST GEORGES AVENUE",
},
{
"line1": "22 ST GEORGES AVENUE",
},
{
"line1": "23 ST GEORGES AVENUE",
},
{
"line1": "5 ST GEORGES AVENUE"
},
{
"line1": "6 ST GEORGES AVENUE"
},
{
"line1": "7 ST GEORGES AVENUE"
},
{
"line1": "8 ST GEORGES AVENUE",
},
{
"line1": "9 ST GEORGES AVENUE",
}
],
"page_count": 1,
"total_count": 36
},
"statusCode": 200
}
This means the address results are ordered like this for citizens searching for their address:
1 ST GEORGES AVENUE
10 ST GEORGES AVENUE
11 ST GEORGES AVENUE
15 ST GEORGES AVENUE
20 ST GEORGES AVENUE
21 ST GEORGES AVENUE
22 ST GEORGES AVENUE
23 ST GEORGES AVENUE
5 ST GEORGES AVENUE
6 ST GEORGES AVENUE
7 ST GEORGES AVENUE
8 ST GEORGES AVENUE
9 ST GEORGES AVENUE
Given that many applications would all need to code workarounds to the above foibles it is much more logical for the API to sort the above list as follows:
1 ST GEORGES AVENUE
5 ST GEORGES AVENUE
6 ST GEORGES AVENUE
7 ST GEORGES AVENUE
8 ST GEORGES AVENUE
9 ST GEORGES AVENUE
10 ST GEORGES AVENUE
11 ST GEORGES AVENUE
15 ST GEORGES AVENUE
20 ST GEORGES AVENUE
21 ST GEORGES AVENUE
22 ST GEORGES AVENUE
23 ST GEORGES AVENUE
And to not have duplicates/triplicates.
eDesigner - Release Version Details
The following is the release version info:
| Release Date | Version Number |
| 22/10/2020 |
2.5.5 |