GeoPlace Data Transfer Format 7.3 for Addresses DTF7.3 Version … · 2020. 10. 9. · 01.02.12 GeoPlace™LLP Revisions to align DFT7.3 v3.1 Third Edition (February 2012 to published

GeoPlace Data Transfer Format 7.3

for Addresses

DTF7.3 Version 3.1

Fourth Edition

Consultation Version

March 2016

A Specification Document

GeoPlace™ LLP

Contents

© GeoPlace™ LLP GeoPlace Data Transfer Format (DTF7.3)

A Specification Document Consultation Version 3.1 Fourth Edition

March 2016

Page 3 of 63

Contents Page Number

Document history ............................................................................................................... 4

Copyright ............................................................................................................................ 5

1. Introduction ................................................................................................................ 14

1.1. Background 14

1.2. Notification of changes to DTF7.3 14

1.3. Definitions used throughout this document and the GeoPlace DEC-

Addresses version 3.4 15

2. GeoPlace implementation of BS7666 ..................................................................... 16

3. Data Format ............................................................................................................... 17

3.1. Formats of data types 17

3.2. Transfer File Format 18

3.3. Record order 18

3.4. Required Records 19

3.5. File Naming 20

3.6. ABICS DTF7.3 transfer files 20

4. Record Types ............................................................................................................. 22

4.1. Header Record 22

4.2. Street Record 23

4.3. Street Descriptor Record 27

4.4. Basic Land and Property Unit Record 29

4.5. Provenance Record 35

4.6. Application Cross Reference Record 38

4.7. Land and Property Identifier Record 41

4.8. BLPU Extent Record 48

4.9. BLPU Extent Polygon Record 49

4.10. BLPU Extent Polygon Vertex Record 51

4.11. LLPG Metadata Record 53

4.12. Key Sequence Record 56

4.13. Trailer record 57

5. Operational Guidelines ............................................................................................ 58

5.1. Order within COU files 58

5.2. Re-use of UPRNs 59

5.3. Re-use of LPI and Xref keys 60

5.4. BLPU Transformations and UPRN data integrity 61

5.5. Monthly Health Check 61

6. Relationship Diagram ................................................................................................ 62

Index ................................................................................................................................. 63

Document history



March 2016

Page 4 of 63

Document history

Version Publication

Date

Author Comments

1.0 28.06.06 Intelligent Addressing

Ltd

Initial drafting in conjunction with LLPG

software vendors


Ltd

Revision to initial draft following discussion

with software vendors


Ltd

Comments incorporated from CAPS, GDC,

GGP and MapInfo


Ltd

Incorporation of comments from formal

consultation during September 2006


Ltd

Release of Final Version


Ltd

Version to hold work on revisions (internal to

IA)


Ltd

Released version of update


Ltd

Revisions as set out on page vi of version 1.3


Ltd

Revisions as set out on page v of version 2.0


Ltd

Minor revisions as set out on page iv of version

2.1


Ltd

Revisions as set out on page 17 produced for

discussion with software vendors, unpublished


Ltd

Revisions as set out on page 17


Ltd / LGIH

Revisions for DTF 7.3 v3.0 consultation

documentation


Ltd / LGIH

Revisions from DEC-NLPG v3.0 consultation

documentation resulting in DTF7.3 v3.1

published January 2011

3.1 Second

Edition

(Withdrawn

January 2012)

30.11.11 GeoPlace™LLP Revisions from DEC-NLPG v3.2 documentation

resulting in DTF7.3 v3.1 Second Edition

(December 2011)

3.1 Third

Edition

01.02.12 GeoPlace™LLP Revisions to align DFT7.3 v3.1 Third Edition

(February 2012 to published DTF7.3 v3.1

(January 2011) and DEC-NLPG v3.2.

3.1 Fourth

Edition

(Consultation

Version)

23.03.16 GeoPlace™LLP Revisions and document name change to

align Consultation Version DFT7.3 v3.1 Fourth

Edition May 2015 to consultation version DEC-

Addresses v3.4 and DTF8.1.

Copyright



March 2016

Page 5 of 63

Copyright

All Intellectual Property Rights in this document, except those acknowledged to

belong to third parties, are held by GeoPlace™ LLP. It is a public domain

document and may be copied, quoted, published and distributed with

attribution freely but not re-sold.

If you wish to make any comments on this document, please contact:

GeoPlace™LLP

157-197 Buckingham Palace Road

LONDON

SW1W 9SP

Tel: 020 7630 4600

Email: [email protected]

Web: www.geoplace.co.uk

mailto:[email protected]

http://www.geoplace/

Revisions



March 2016

Page 6 of 63

Revisions

The revisions have been classified as “F” changes to export content or format,

“X” explanatory notes, “E” format errors and “T” for typographical errors found in

and editorial changes made to previous version.

Revisions from version 3.1 Third Edition (February 2012) to version 3.1 Fourth Edition

Consultation Version (March 2016)

Page / Section

Number

Revision

Type

1. Various Name change and alignment of GeoPlace DTF7.3 v3.1

Fourth Edition (March 2016 to consultation version of

GeoPlace DEC-Addresses v3.4 (March 2016).

T

2. 20 / Section 3.5.4 Section 3.5.4 removed. T

3. 24 / Section 4.2 Field STREET_TOLERANCE type changed from I 3 to I 2. F

4. 26 / Section 4.2,

Table S3

Street state code = 5 and maximum permitted tolerance

values added.

F

5. 30 / Section 4.4,

Note 1.

BLPU LOGICAL_STATUS = 5 changed to must only be used

when BLPUs are transferred as Candidate Records from

GeoPlace to the Authority Address Custodian for review.

X

6. 30 / Section 4.4,

Note 2.

BLPU LOGICAL_STATUS = 7 changed to must only be used

when the Authority Address Custodian rejects a

Candidate Record supplied by GeoPlace.

X

7. 34 / Section 4.4,

Table B4

BLPU LOGICAL_STATUS = 5 and note b inserted. STATE = 5,

7 and note c inserted. Any changed to Null, 1, 2, 3, 4, 6.

Note b changed to must not be submitted to GeoPlace.

X

8. 38 / Section 4.6,

CROSS_REFERENCE

Value column – See Note 16, Section 5.7 removed. X

9. 40 / Section 4.6,

Table A1

Dataset ID OS and PA added to table. F

10. 44 / Section 4.7 Reference to Table L4 in POSTAL_ADDRESS Field and Note

4 removed.

E

11. 44 / Section 4.7,

Note 6

LPI LOGICAL_STATUS = 5 changed to must only be used if

BLPUs or LPIs are transferred as Candidate Records from

GeoPlace to the Authority Address Custodian for review,

see Table L1.

X

12. 44 / Section 4.7,

Note 7

LPI LOGICAL_STATUS = 7 changed to must only be used

when the Authority Address Custodian rejects a

Candidate Record supplied by GeoPlace, see Table L1.

X

13. 44 / Section 4.7,

Note 9

Reference to Appendix 4 removed. X

14. 47 / Section 4.7,

Table L4

Table L4 removed. E

15. Section 7, 8 and 9 Section 7, 8 and 9 removed. F

Revisions



March 2016

Page 7 of 63

Revisions from version 3.1 Second Edition (December 2011) to version 3.1 Third Edition

(February 2012)

Page / Section

Number

Revision

Type

1 Various Alignment of DTF7.3 v3.1 Third Edition (February 2012 to

published DTF7.3 v3.1 (January 2011).

T

2 41 / Table A1 Insertion of missing Candidate source suffix “IA”. T

3 63 / 7.3.1 Alignment to DEC-NLPG v3.2, text and table removed. T

Revisions from version 3.1 (January 2011) to version 3.1 Second Edition (December 2011)

Page / Section

Number

Revision

Type

1 Various Reference to DEC-NLPG v3.1 amended to DEC-NLPG

v3.2.

T

2 Various Reference to Creating Authority amended to

Contributing Authority.

T

3 Various Reference to Receiving Authority amended to NLPG

Users.

T

4 Various Reference to Intelligent Addressing amended to

GeoPlace™LLP.

T

5 27 / 5.2 STREET CLASSIFICATION type amended to I 2. E

6 48 / Note 2 Secondary Addressable Object attributes text changed

from must to should and each to one.

T

7 66 / 7.5.1 Local Custodian Code and Authority Code amended to

Local Custodian Code or Authority Code.

T

8 73 / 8.3 AUTHORITY_CODE value amended to issued by NLPG

Custodian.

T

Revisions from version 3.0 (draft for consultation) to version 3.1 (specification document)

Page / Section

Number

Revision

Type

1 Various RECORD_IDENTIFIER redefined as integer. F

2 Various PRO_ORDER redefined as integer. F

3 Various UPRN redefined as integer. F

4 Various USRN redefined as integer F

5 Various PARENT_UPRN redefined as integer. F

6 Various LOGICAL_STATUS redefined as integer F

7 Various SAO_START_NUMBER, SAO_END_NUMBER,

PAO_START_NUMBER AND PAO_END_NUMBER redefined

as integer

F

8 Various POLYGON_NUMBER redefined as integer F

Revisions



March 2016

Page 8 of 63


Page / Section

Number

Revision

Type

9 Various VOLUME_NUMBER and TIME_STAMP redefined. F

10 15 / 1.1.3 Section moved from 19 / 4.4.3. T

11 15 / 1.1.5 Section added explaining purpose of the document. X

12 15 / 1.1.6 Section added explaining audience of the document. X

13 15 / 1.2.1 Mechanism for informing users of changes to the

document amended.

X

14 19 / 4.1.2 Definition of integer added and number redefined. X

15 20 / 4.3 Clarification that Record Order unimportant for other

Records in LLPG to NLPG full supply files.

X

16 20 / 4.3.1 Clarification that records processed in order of volume

number in Header Record and file name

X

17 21 / 4.4.3 Section moved to 13 / 1.1.3. T

18 21 / 4.4.1 Column added to table describing required Records in

export from NLPG Custodian.

X

19 22 / 4.5.1 File naming rules for COUs from LLPG to NLPG clarified to

include Fully Supply files

X

20 22 / 4.6.1 Order of Records in Full Supply files from NLPG specified. X

21 21 / 4.7.1 Section moved to Section 1.2.1 T

22 24 / 5.1 FILE_TYPE values amended to F, C or X. F

23 25 / 5.1 File Type for Candidate Records amended to X F

24 25 / 5.2 RECORD_TYPE, STREET_SURFACE, STREET CLASSIFICATION,

VERSION, STREET_TOLERANCE redefined as integer.

F

25 27 / 5.2 Note 3 removed, Notes 4 and 5 renumbered. F

26 29 / 5.3 Note 1 sentence removed stating NLPG Custodian must

record the date the Street Descriptor sent to the NLPG.

X

27 30 / 5.3 New notes 4 to 10 moved from Appendix 3. T

28 31 / 5.4 RPC, LOCAL_CUSTODIAN CODE, CUSTODIAN_ONE,

CUSTODIAN_TWO redefined as integer

F

29 31 / 5.4 BLPU End Date requirement changed to conditional F

30 32 / 5.4 WARD_CODE and PARISH_CODE redefined as T10 F

31 32 / 5.4 Note 2 sentence removed stating Rejected Candidate

Records should be kept in the LLPG.

X

32 33 / 5.4 New note 10 describing rules for location of Street BLPUs. T

33 34 / 5.4 New note 11. X

34 34 / 5.4 New note 12 moved from Appendix 1. T



37 36 / 5.4 Table B4 reference to note B removed from 4th column. F

38 39 / 5.6 CROSS_REFERENCE Field content change to T50 to

accommodate new bilingual cross references.

F

Revisions



March 2016

Page 9 of 63


Page / Section

Number

Revision

Type

39 41 / 5.6 Table A1 new source code added BG for bilingual

gazetteers.

F

40 44 / 5.7 Note 2 expanded to explain conditional relationship

between SAO fields and PAO fields

X

41 45 / 5.7 Note 4 changed to include rules for POSTAL_ADDRESS

value A.

T

42 45 / 5.7 New note 3 describing rules for use of two characters

permitted in SAO_SUFFIX and PAO_SUFFIX Fields

F

43 46 / 5.7 New notes 16 to 23 moved from Appendix 1. T

44 46 / 5.7 New note 20 describing addition of Cross Reference

rules for LPIs in bilingual gazetteers.

F

45 49 / 5.8.1 Reference to Appendix 5 removed F

46 49 / 5.8 Confidence level removed from Attribute table F

47 49 / 5.8 Table BE1 removed F

48 50 / 5.9 EXTERNAL_POLYGON_IDENTIFIER redefined as integer F

49 52 / 5.10 VERTEX_ORDER redefined as integer. F

50 53 / 5.10 New note describing when a new polygon should be

created.

X

51 62 / 6.4 New Section added describing rule that UPRNs must

endure throughout the life of a BLPU

X

52 62 / 6.5 Section moved from Section 6.4 X

53 69 / 8.2 FILE_TYPE for Candidate Records set to X F

54 72 / 8.3 WARD_CODE and PARISH_CODE redefined as T10 F

55 72 / 8.3 CAN_KEY shown as mandatory in BLPU table and

highlighted as a difference from main table

F

56 75 and 76 / 8.4 CAN_KEY and CUSTODIAN_TWO shown as mandatory

and highlighted as a difference from main table

F

57 Appendix 1 Appendix removed and contents moved to Section 5.4 X

58 Appendix 2 Appendix removed and contents moved to Sections 7, 8

and 9

X



61 Appendix 5 Appendix removed F

Revisions from version 2.2 (unpublished) to version 3.0 (draft for consultation)

Page / Section

Number

Revision

Type

1 11/ Section 1.1.3 Additions to paragraph to explain consultation X

2 11 / Section 1.2 Additional section concerning definitions used

throughout document and DEC-NLPG v3.0

X

Revisions



March 2016

Page 10 of 63


Page / Section

Number

Revision

Type

3 12 / Section 1.3 Insertion of consultation questions X

4 15 / Section 1.4 Insertion of how to respond to consultation section X

5 16 / Section 2 Insertion of POSTAL_ADDRESS X

6 16 / Section 2 Insertion of POST_TOWN X

7 16 / Section 2 Insertion of LPI_KEY X

8 17 / Section 3 Additional paragraph to re-iterate link between DTF and

DEC-NLPG and DEC-NSG documents

X

9 17 / Section 3 Confirmation of differing data formats between NSG

and NLPG and reference to monthly checks between

the NLPG and the NSG

X

10 18 / Section 4.3 Clarification of Record order rules X

11 18 / Section 4.4 Addition of column on explanatory table for Candidate

Records and removal of notes on NSG and NSG related

Records.

Change of Record type 23 to Conditional

Additional paragraph dealing with Application Cross

References

X

F

X

12 20 / Section 4.6 New section detailing variations to DTF7.3 for exports

from the NLPG Custodian

X

13 20 / Section 4.7 New section committing to supplying six monthly

notification of DTF changes

X

14 20 / Section 4.7 Clarification on DTF7.3 updates and registration process X

15 21 / Section 5.1,

Note 1

Missing note on file types added X

16 22 / Section 5.2 Street Type 11 – removal of 1990-01-01 within STATE_DATE F

17 24 / Section 5.2 New note 4 for STREET Record X

18 24 / Section 5.2 New note 5 for STREET Record X

19 24 / Section 5.2,

Table S3

Street State alignment to the NSG F

20 24 / Section 5.2,

Table S5

Street Classification alignment to the NSG F

21 17 / Section 5.3 New note 1 for STREET_DESCRIPTOR updates X

22 26 / Section 5.3 New note 2 for STREET_DESCRIPTOR Records X

23 26 / Section 5.3 New note 3 for STREET_DESCRIPTOR Records X

24 29 / Section 5.4 Note 1 amended on BLPU Record X



27 30 / Section 5.4 Note 4 removal of validation of ward and parish code

Fields

X

28 30 / Section 5.4 New Notes 7, 8, 9 and 10 on BLPU Record X

Revisions



March 2016

Page 11 of 63


Page / Section

Number

Revision

Type

29 31 / Section 5.4 Table B4 changed to allow any state codes to be used

with Candidate Records

X

30 31 / Section 5.4 Table B4 removal of BLPU state code 7 from permitted

values for historical logical status BLPU Records

X

31 32 / Section 5.4 Table B5 changed definitions X

32 33 / Section 5.5 Note 2 and Table P1 added F

33 36 / Section 5.6 Changes to notes in Application Cross Reference

Records and standardisation of source dataset id

coding scheme

X

34 36 / Section 5.6 Table A1 added Status of Application Cross Reference

Records made Mandatory / Optional on the SOURCE

type

F

35 40 / Section 5.7 Note 3 provides further explanation of use of

POSTAL_ADDRESS flag

X

36 41 / Section 5.7 Amendment to note 4, 6 and 8 X

37 41 / Section 5.7 Addition of note 11 to remove Mandatory status of

LPI_KEY for Candidate Records

X

38 41 / Section 5.7 New notes 12, 13 and 14 on LPI Record X

39 42 / Section 5.7 Changes to Tables L1, L2, L3 and L4 F

40 44 / Section 5.8 Insertion paragraph 5.8.1 to reference Appendix 5 for

the two new Fields – CONFIDENCE_LEVEL and

POLY_VERSION_NUMBER

X

41 44 / Section 5.8 Insertion of two new Fields – CONFIDENCE_LEVEL and

POLY_VERSION_NUMBER

F

42 45 / Section 5.8 Change to SOURCE_DESCRIPTION status to Optional and

insertion of Table BE1

F

43 50 / Section 5.11 Note 3 and Table M2 added for language code BIL F

44 53 / Section 6.1 Further example of processing order in COU files X

45 55 / Section 6.5 Addition of a BLPU hierarchy example X

46 56 / Appendix 1 Revised BLPU Classification coding scheme at Appendix

1. New primary and secondary BLPU Classifications for

emergency services moved to new table

X

47 58 / Appendix 2 New Appendix 2 F

48 90 / Appendix 3 Amendments to Appendix 3 X

49 92 / Appendix 4 Amendments to Appendix 4 and addition of note on

need for close date

X

50 94 / Appendix 5 New Appendix 5 X

51 Street Cross Reference Type 12 Record removed from

specification as DEC-NLPG only has requirement for the

capture of a level 1 Street gazetteer

F

52 Change of field name POSTALLY_ADDRESSABLE to

POSTAL_ADDRESS

F

Revisions



March 2016

Page 12 of 63

Revisions from version 2.1 to version 2.2 (unpublished)

Page / Section

Number

Revision

Type

1 Various Sections detailing changes from DTF 6.3 have been

removed

T

2 Various Change to restrict update date to no later than present day F

3 5 / 4.1 UHF format should be UTF

Files produced using Unix file encoding are invalid

Exclusion of double quotes and commas from text strings

T

F

X

4 6 / 4.3 Inclusion of Provenance Records in exports is Conditional on

LLPG holding BLPU polygons

X

5 7 / 4.4 Addition of section on File Naming X

6 14 BLPU co-ordinate ranges to start from 1 rather than 0 F

7 15 / Table B1 Addition of Change type “C” for Candidates F

8 15 / Note 3 Addition of BLPU_STATE _DATE as Mandatory value for

Provisional LPIs

F

9 16 / Table B4 Revision of permitted alternatives X

10 18 / Notes Xref notes renumbered from 1 to 3 T

11 18 / Note 1 Revision of renumbered note 1 to enforce XREF_KEY naming

conventions

X

12 18 / Note 2 Revision of renumbered note 2 to enforce SOURCE naming

convention

X

13 18 / Note 3 Revision of renumbered note 3 to take into account use of

cross references to inform NLPG advance of new and

changed addresses

X

14 20 Addition of Change type “C” for Candidates F

15 21 / Note 1 Revision of note to enforce LPI_KEY naming conventions X

16 22 / Note 3 Revision of note to clarify use of POSTALLY_ADDRESSABLE

flag

X

17 22 / Note 5 Revision of note on use of logical status 5 X

18 Section 6 Section on implementation timetable removed T

19 30 / Section 6 New Section – Operational guidelines added

Order within COU files

Re-use of UPRNs

Re-use of LPI and XREF keys

Monthly health checks

BLPU hierarchy

X

20 Section 7 Section on accreditation removed T

21 Appendix A Addition of emergency services primary and secondary

BLPU classes.

Further secondary BLPU classes under the “Parent” primary

class.

F

F

X

Revisions



March 2016

Page 13 of 63

Revisions from version 2.1 to version 2.2 (unpublished)

Page / Section

Number

Revision

Type

Revision to explanatory note

22 Appendix B Contents removed to separate document X

23 Appendix C Contents removed to separate document X

24 Appendix D Street naming and numbering to be dealt with within a

separate document entitled “NLPG advance”

X

24 Appendix D Explanatory notes on use of cross references added X

25 Appendix E Revision of description of language rules for Welsh LPIs X

26 Appendix F Addition of appendix F on Street Only BLPUs X

1 Introduction



March 2016

Page 14 of 63

1. Introduction

1.1. Background

1.1.1. This document details the latest version of the GeoPlace Data

Transfer Format 7.3.3.1 (DTF7.3.3.1) for Addresses specification.

1.1.2. This is a consultation version of the GeoPlace Data Transfer Format

DTF7.3 v3.1 for Addresses, Fourth Edition.

1.1.3. DTF7.3 v3.1 Fourth Edition is designed to specify the format of all

the elements required to transfer files known as DCA Address

Updates from an LLPG to GeoPlace and supply transfer files to

Ordnance Survey AddressBase® Incremental Change Supply

(ABICS) users. Some LLPG software is also used to hold and

provide Full Supply LSG files to GeoPlace.

1.1.4. This document, (DTF7.3 v3.1), should be referenced to the

following consultation version of the:

GeoPlace Data Entry Conventions and Best Practice for

Addresses (DEC-Addresses) consultation version 3.4 March

2016;

1.1.5. The main purpose of this document is to provide the technical

specification for software designed to manage land and property

data in compliance with the GeoPlace DEC-Addresses version

consultation version 3.4.

1.1.6. This document is primarily for the use of software developers who

provide Gazetteer Management Systems for:

Authority Address Custodians in DCA Participating Authorities.

Ordnance Survey AddressBase® Incremental Change Supply

(ABICS) users.

1.2. Notification of changes to DTF7.3

1.2.1. Any planned changes to this document will be published on the

GeoPlace website (www.geoplace.co.uk) with an indication of

timescales for implementation. For detailed information about

GeoPlace DTF7.3.3.1 validation and health check codes, see the

resources area of the GeoPlace website.

http://www.geoplace.co.uk/

1 Introduction



March 2016

Page 15 of 63

1.3. Definitions used throughout this document and the GeoPlace DEC-

Addresses version 3.4

Verb Implication Context

Must An absolute

requirement

BS 7666-1:2006 and BS 7666-2:2006 GeoPlace

DEC-Addresses document implementation

requirement.

Shall An absolute

requirement

BS 7666-1:2006 and BS 7666-2:2006 standard

requirement.

Should A recommendation. BS 7666-1:2006 and BS 7666-2:2006 standard or

a GeoPlace DEC-Addresses document

implementation recommendation. A

particular item may be ignored, but the full

implications shall be understood and carefully

weighed beforehand.

May Permission BS 7666-1:2006 and BS 7666-2:2006 standard or


implementation permission.

Can Possibility or capability BS 7666-1:2006 and BS 7666-2:2006 standard or


implementation information.

Is Description BS 7666-1:2006 and BS 7666-2:2006 standard or


implementation description.

For a glossary of defined terms, see Appendix A of the GeoPlace

DEC- Addresses version 3.4. Terms which appear in the glossary of

defined terms are identified within the document by a capital first

letter.

References to Sections are shown in bold.

Field names used in the attribute tables are shown by the use of all

capitals, for example, STREET_NAME.

2 GeoPlace implementation of BS7666



March 2016

Page 16 of 63

2. GeoPlace implementation of BS7666

2.1.1. The integrity between an LLPG and address information held by

GeoPlace in GeoHub is maintained by the use of a number of

Fields some of which are additional to core BS 7666 requirements.

The GeoPlace implementation of BS 7666-2:2006 also includes a

number of supplementary items to support the service delivery

requirements and use of address information. The main

supplementary items are summarised below:

Data Item Record

Type

Comments

PARENT_UPRN 21 Permits the explicit statement of hierarchical

relationships between BLPUs, in particular Parent and

Child relationships and in some instances grandparent

and grandchild relationships in complex commercial

and communal residential buildings.

ORGANISATION 21 Provision to capture the commercial occupier name of

a business related BLPU.

POSTAL_ADDRESS 24 Indicator as to whether Object receives mail.

POST_TOWN 24 Posttown allocated by Royal Mail to assist delivery.

Application Cross

Reference Record

23 Inclusion of Application Cross Reference type Record

rather than use of EXTERNAL_CROSS_REFERENCE Field

on BLPU.

PROV_KEY 22 Unique identifier used in the recording of BLPU

provenance Records.

XREF_KEY 23 Unique identifier used in the recording of BLPU

Application Cross Reference Records.

LPI_KEY 24 Unique identifier used in the recording of LPI Records.

WARD 21 Textual identifier for the associated WARD the BLPU

resides in.

PARISH 21 Textual identifier for the associated PARISH the BLPU

resides in.

CHANGE_TYPE All Indicator used to determine how a Record must be

modified within a composite or alternative

gazetteer/application.

PRO_ORDER All Integer value that specifies the order in which the

Records in the transfer file should be processed.

RECORD_IDENTIFIER ALL Integer value that identifies the Record.

3 Data Format



March 2016

Page 17 of 63

3. Data Format

3.1. Formats of data types

3.1.1. In each of the Records all data items (Fields) listed in this

specification must be included in the order that they occur in the

relevant Record definition. Each Field must be separated from the

previous one by a comma.

3.1.2. All Fields in each of the Records are defined using one of the

following data types:

Data Type Format Comments

Date BS ISO 8601 All dates shall be recorded

consistently in the extended format

CCYY-MM-DD.

Time HHMMSS The 24 hour clock format is used

where HH=hour, MM=minute and

SS=seconds.

Integer (I) Contains any whole positive

number value.

Fields do not need any leading

zeros. Leading zeros will be ignored

if present. Fields must not have

thousands separators.

Number (N) Contains any positive numeric

value and mantissa if required.

Fields do not need any leading

zeros. Leading zeros will be ignored

if present. Fields must not have

thousands separators.

Text (T) All text Fields must be enclosed in

double quotes (“).

The double quotes must be

ignored as part of the text.

3.1.3. All Fields specified as Mandatory must contain data. The inclusion

of data in other Fields is either Optional or Conditional.

3.1.4. If a Field has no value in a Record, two commas must be placed

together in the Record (one for the end of the previous Field and

one for the end of the null Field). If the null Field is a text Field

include double quotes between the two commas, for example:

,””,

3 Data Format



March 2016

Page 18 of 63

3.2. Transfer File Format

3.2.1. DCA Address Updates must be transferred using a Unicode

character set (UTF-8) including ISO-8859-14 (Welsh characters) as a

Comma Separated Value (CSV) DTF7.3 transfer file.

3.2.2. For Full Supply transfer files, if there are fewer than 1 million

Records, the transfer file must be a single file. If there are more

than 1 million Records, the transfer file can be split into multiple

transfer files using volume numbers.

3.2.3. For COU transfer files, each file must use a separate unique volume

number regardless of its size.

3.2.4. The transfer file should contain a number of different Record types,

one for each of the different DTF7.3 Records. These Records are

described in detail in this document.

3.2.5. The first Field in each of these Records must be a Record identifier,

which determines the content and format of the remainder of the

physical Record.

3.2.6. There must be one Record per line in each file. A comma must not

be placed at the end of each row in the file.

3.2.7. The file must not be prepared using Unix text file encoding.

3.2.8. Double quotes and commas must not be used within Fields

specified as text.

3.3. Record order

3.3.1. The following rules apply to the order of the Records in a DTF7.3

transfer file:

All transfer files must contain Header Records and Trailer

Records as the first and last Records in the transfer file.

All DCA Address Updates either Full Supply or COU transfer

files must contain the type 98 KEY SEQUENCE as the

penultimate Record.

All DCA Address Update COU transfer files must have a

running sequential number (processing order number) added

to all Records other than the HEADER, LLPG METADATA, KEY

SEQUENCE and TRAILER within a volume to show the order of

3 Data Format



March 2016

Page 19 of 63

Record processing. This number can have a maximum of 16

digits.

The order of all other Records within each DCA Address

Updates Full Supply transfer file is unimportant.

If GeoPlace receives multiple volumes within a single DCA

Address Update, the volumes will be processed in order

according to the volume number in the HEADER Record and

in the file name.

If GeoPlace receives two or more single volume DCA Address

Update transfer files from a DCA Participating Authority, the

files will be processed in date and time order.

3.4. Required Records

3.4.1. The table below shows the Mandatory, Conditional and Optional

Record types that are transferred to and from GeoPlace with all

DCA Address Update, COU or Full Supply transfer file volumes.

Record

Type

Record Description Full Supply

transfer file

sent to

GeoPlace

COU transfer

file sent to

GeoPlace

Full Supply

transfer files sent

from GeoPlace

to an ABICS user

COU transfer

files sent from

GeoPlace to

an ABICS user

10 Header Mandatory Mandatory Included Included

11 Street Record Mandatory Conditional Included Conditional

12 Street Cross Reference n/a n/a Excluded Excluded

13 Elementary Street Unit n/a n/a Excluded Excluded

14 ESU Co-ordinate n/a n/a Excluded Excluded

15 Street Descriptor Mandatory Conditional Included Conditional

21 Basic Land and Property Unit Mandatory Conditional Included Conditional

22 Provenance Conditional Conditional Excluded Excluded

23 Application Cross Reference Conditional Conditional Conditional Conditional

24 Land and Property Identifier Mandatory Conditional Included Conditional

25 BLPU Extent Optional Optional Excluded Excluded

26 BLPU Extent Polygon Optional Optional Excluded Excluded

27 BLPU Extent Polygon Vertex Optional Optional Excluded Excluded

29 LLPG Metadata Mandatory Optional Excluded Excluded

98 Key Sequence Mandatory Mandatory Excluded Excluded

99 Trailer Mandatory Mandatory Included Included

3 Data Format



March 2016

Page 20 of 63

3.4.2. The inclusion of Provenance Records in any transfer file from an

LLPG is Conditional on that LLPG holding BLPU polygon

information.

3.4.3. The following rule applies to Application Cross Reference Records:

Application Cross Reference Records must be present in

transfer files from an LLPG if the data is linked to the external

local authority application datasets as specified in Table A1,

Section 4.6.

3.5. File Naming

3.5.1. All DCA Address Updates, COU and Full Supply files transferred

from an LLPG to GeoPlace must be named as follows:

nnnn_ccyymmdd_vv.csv where:

o nnnn is the Local Custodian Code as recorded in the

HEADER Record within the transfer file.

o ccyymmdd is the date the transfer file was created.

o vv is the volume number of the transfer file

(corresponding to the VOLUME_NUMBER Field in the

HEADER Record for the transfer file.) This must be

numeric, with leading zeroes where necessary.

o csv is a constant and shows that the transfer file contains

comma separated values.

3.5.2. The full transfer file name must be unique. GeoPlace can only

accept one instance of any given filename as a COU transfer file.

3.5.3. COU transfer files should be transferred to GeoPlace in

chronological order.

3.6. ABICS DTF7.3 transfer files

3.6.1. If GeoPlace receives a request for an ABICS Full Supply or COU

transfer file, the following variations to the rules defined in this

documents version of DTF7.3 apply:

The LOCAL_CUSTODIAN_CODE in the type 10 Header Record,

see Section 4.1, will be LOCAL_CUSTODIAN_CODE = 9999 to

show that each DTF7.3 transfer file has been generated by

GeoPlace.

3 Data Format



March 2016

Page 21 of 63

The CUSTODIAN_NAME in the type 10 Header Record, Section

4.1, will be CUSTODIAN_NAME = “GEOPLACE LLP”.

A type 29 LLPG Metadata Record will not be included in the

transfer file.

A type 98 Key Sequence Record will not be included in the

transfer file.

Records within ABICS Full Supply transfer files will be supplied in

the following Record Type order:

Type 10 Header Record,

Type 11 Street Record,

Type 15 Street Descriptor (grouped by USRN),

Type 21 BLPU Record,

Type 24 LPI Record (grouped by UPRN),

Type 99 Trailer Record.

Type 23 Application Cross reference Records will only be

included in ABICS Full Supply or COU transfer files if they relate

to linked type 24 LPI Records in a Bilingual Gazetteer.

3.6.2. ABICS DTF7.3 transfer files will contain data dependent upon the

following requirements of the recipient:

A single transfer file containing data for a single DCA

Participating Authority administrative area.

A single transfer file containing data for more than one DCA


A collection of transfer files covering more than one DCA


4 Record Types



March 2016

Page 22 of 63

4. Record Types

4.1. Header Record

HEADER RECORD (type 10)

Field Description Type Value Status

RECORD_IDENTIFIER Identifies this Record as a

Header Record.

I 2 10 Mandatory

CUSTODIAN_NAME Name of data provider

organisation.

T 40 Mandatory

LOCAL

_CUSTODIAN_CODE

Unique identifier for the

data provider code –

defined in the GeoPlace

DEC-Addresses.

I 4 Mandatory

PROCESS_DATE The date when the

gazetteer transfer set

was created.

Date Mandatory

VOLUME_NUMBER The sequential number of

the volume in the transfer

set.

I 2 1-99 Mandatory

ENTRY_DATE Date of data entry for

this volume.

Date Mandatory

TIME_STAMP Time of file creation in

HHMMSS format.

Time HHMMSS Mandatory

DTF_VERSION Version number of the

DTF specification used.

T 7 “7.3.3.1” Mandatory

FILE_TYPE Details of file content. T 1 “F”, “C” or “X”

See Notes 1, 2

and 3 below.

Mandatory

Record Example:

10,"CORNWALL",840,2006-07-04,1,2006-07-04,153742,”7.3.3.1”,”F”

Notes:

1. If the transfer file is a Full Supply from an LLPG, the FILE_TYPE = “F” must be

present.

2. If the transfer file is a COU from an LLPG, the FILE_TYPE = “C” must be

present.

3. If the transfer file is a file containing Candidate Records the FILE_TYPE =

“X” must be present.

4 Record Types



March 2016

Page 23 of 63

4.2. Street Record

STREET RECORD (type 11)



Street Record.

I 2 11

Mandatory

CHANGE_TYPE Change identifier. T 1 See Table S1

below.

Mandatory

PRO_ORDER Integer value that

specifies the order in

which the Records in the

transfer file should be

processed.

I 16 Mandatory

USRN Unique Street Reference

Number.

I 8 Mandatory

RECORD_TYPE Street type. I 1 See Table S2

below.

See Note 5

below.

Mandatory

SWA_ORG_REF_NAMING The code of the SNN

Authority, or the Local

Highway Authority if a

RECORD_TYPE = 3 -

numbered Street.

I 4 Mandatory

STATE A code to identify the

current state of the Street.

I 1 See Table S3

below.

Optional

STATE_DATE Date at which the Street

achieved its current state

in the real world.

Date Present day or

earlier.

Optional

STREET_SURFACE A code to identify the

surface finish of the Street.

I 1 See Table S4

below.

See Note 3

below.

Optional

STREET_CLASSIFICATION A code for the primary

Street classification.

I 2 See Table S5

below. See

Note 4 below.

Optional

VERSION Version number of the

Street Record.

I 3 0

See Note 1

below.

Mandatory

RECORD_ENTRY_DATE The date that the Record

was entered into the LSG.

Date Present day or

earlier.

Mandatory

4 Record Types



March 2016

Page 24 of 63

STREET RECORD (type 11)


LAST_UPDATE_DATE The date on which any

attribute of the Record

was changed.

Date No earlier than

entry date or

later than

present day.

Mandatory

STREET_START_DATE The date on which the

Street was approved.

Date Present day or

earlier.

Mandatory

STREET_END_DATE The date on which the

Street ceased to exist in

the real world (that is the

date when the Street was

Permanently Stopped Up

or no longer existed in the

real world and Street state

code STATE = 4 -

permanently closed. See

Table S3 below.

Date Greater than

or equal to

STREET_

START_DATE

and less than

or equal to

present day.

See Note 2.

Conditional

STREET_START_X The X (easting) coordinate

of the start point of the

Street.

N 7.2 80000.00-

656100.00

Mandatory

STREET_START_Y The Y (northing)

coordinate of the start

point of the Street.

N 7.2 5000.00-

657700.00

Mandatory

STREET_END_X The X (easting) coordinate

of the end point of the

Street.

N 7.2 80000.00-

656100.00

Mandatory

STREET_END_Y The Y (northing)

coordinate of the end

point of the Street.

N 7.2 5000.00-

657700.00

Mandatory

STREET_TOLERANCE The tolerance of the start

and end co-ordinates (in

metres).

I 2 0-99 Mandatory

Record Example:

11,”I”,1,31401554,1,840,2,2003-04-01,1,8,0,2006-01-10,2006-06-01,2003-04-

01,,194325.00,53673.00,194462.00,53910.00,10

Notes:

1. VERSION = 0 for all applications. If the version number is used in the LLPG,

only the latest (highest version number) must be transferred to GeoPlace.

4 Record Types



March 2016

Page 25 of 63

2. If the latest (highest version number) of a Street is closed, all BLPUs and LPIs

associated with that Street must also have an End Date and a

LOGICAL_STATUS = 8 – Historical be used, (see Table B2, Section 4.4).

3. STREET_SURFACE = null. If code values 1, 2 or 3 are required for local use,

they should be sourced from those present in an LSG via the appropriate

Authority Street Custodian.

4. STREET_CLASSIFICATION = null. If code values 4, 6, 8, 9 or 10 are required

for local use, they should be sourced from those present in an LSG via the

appropriate Authority Street Custodian.

5. The use of Street RECORD_TYPE = 9 – Description used for LLPG access

must be limited to rivers, railways, canals or waterways only. The

STREET_DESCRIPTOR Field (type 15 Street Descriptor Record, see Section

4.3) must contain one of these words as part of the description of the

feature.

Table S1 - Change types

Type CHANGE_TYPE

I Insert

U Update

D Delete

Table S2 - Street types

Type RECORD_TYPE

1 Official Designated Street Name

2 Street Description

3 Numbered Street

4 Unofficial Street Description

9 Description used for LLPG access

4 Record Types



March 2016

Page 26 of 63

Table S3 - Street state codes

Code STATE Maximum Permitted Tolerance

Value 1 Under construction 50m

2 Open 10m or half the carriageway width

whichever is the smaller

4 Permanently closed1

(STREET_END_DATE must be entered)

10m if closed date is later than 1st

October 2013

5 Street for addressing purposes only 10m

Table S4 - Street surface codes

Code STREET_SURFACE

1 Metalled

2 Unmetalled

3 Mixed

Table S5 - Street classification codes

Code STREET_CLASSIFICATION

4 Pedestrian way or footpath

6 Cycletrack or cycleway

8 All vehicles

9 Restricted byway

10 Bridleway

1 A permanently closed Street is one that no longer exists in the real world. These are Streets that have been physically

removed.

NOTE: This should not be used when a Street has been Permanently Stopped Up, but is physically still in the real world.

4 Record Types



March 2016

Page 27 of 63

4.3. Street Descriptor Record

STREET DESCRIPTOR RECORD (type 15)


RECORD_IDENTIFIER Identifies this Record

as a Street Descriptor

Record.

I 2 15 Mandatory

CHANGE_TYPE Change identifier. T 1 See Table S1,

Section 4.2.

Mandatory



which the Records in

the transfer file should

be processed.

I 16 Mandatory

USRN Unique Street

Reference Number.

I 8 Mandatory

STREET_DESCRIPTOR Name, description or

Street number.

T 100 See Note 1 below. Mandatory

LOCALITY_NAME Locality name. T 35 Conditional

TOWN_NAME Town name. T 30 See Note 2 below. Conditional

ADMINSTRATIVE_AREA Local Highway

Authority name.

T 30 See Note 3 below. Mandatory

LANGUAGE A code identifying the

language in use for

the descriptive

identifier.

T 3 See Table SD1

below.

See Notes 4 and 5

below.

Mandatory

Example:

15,”I”,3,31401554,"GREAT CHARLES CLOSE","","ST STEPHEN","CORNWALL",”ENG”

Notes:

1. If the type 15 Street Descriptor Record is the only Record that is changed,

there is no need to alter the LAST_UPDATE_DATE for the corresponding

type 11 Street Record, see Section 4.2, at the same time.

2. TOWN_NAME is Mandatory for Street RECORD_TYPE = 1 – Official

designated Street name and 2 – Street description. It is Optional for Street

RECORD_TYPE = 3 – Numbered Street, 4 – Unofficial Street description and

9 – Description used for LLPG access.

3. ADMINISTRATIVE_AREA names are provided in Appendix B of the

GeoPlace DEC-Addresses v3.4 documentation. For Districts this name

4 Record Types



March 2016

Page 28 of 63

must be the name of the County Local Highway Authority and must

exclude the phrase ‘County Council’ (see Appendix B of the GeoPlace

DEC-Addresses v3.4). For all types of Unitary the name must be the name

of the Local Highway Authority and exclude the word council, borough or

metropolitan etc. (See Appendix B of the GeoPlace DEC-Addresses v3.4).

4. Welsh authorities maintaining a Bilingual Gazetteer must transfer two Street

Descriptor Records for each Street Record; one for the Welsh language

(LANGUAGE = CYM) and one for the English language (LANGUAGE =

ENG). If the Street has not officially been translated into Welsh then the

same description should be entered for both Welsh and English Records.

5. English authorities must only submit one Street Descriptor Record for each

Street Record; this must be for the English language only (LANGUAGE =

ENG).

Table SD1 - Language codes

Code LANGUAGE

ENG English

CYM Welsh

4 Record Types



March 2016

Page 29 of 63

4.4. Basic Land and Property Unit Record

BASIC LAND AND PROPERTY UNIT RECORD (type 21)



BLPU.

I 2 21 Mandatory

CHANGE_TYPE Type of Record change. T 1 See Table B1

below.

Mandatory





processed.

I 16 Mandatory

UPRN Unique Property

Reference Number.

I 12 Mandatory

LOGICAL_STATUS Logical Status of the

BLPU.

I 1 See Table B2

below.

See Notes 1 and

2 below.

Mandatory

BLPU_STATE A code identifying the

current state of a BLPU.

I 1 See Table B3

below.

See Note 3

below.

Conditional

BLPU_STATE_DATE Date at which the BLPU

achieved its current state

in the real-world.

Date See Note 3

below.

Conditional

BLPU_CLASS Classification code for

the BLPU.

T 4 See Notes 10, 11

and 12 below.

Mandatory

PARENT_UPRN UPRN of Parent Record. I 12 Conditional

X_COORDINATE A value on the X axis of

the National Grid of

Great Britain.

N 7.2

80000.00-

656100.00

Mandatory

Y_COORDINATE A value on the Y axis of

the National Grid of

Great Britain.

N 7.2

5000.00-

657700.00

Mandatory

RPC Representative Point

Code.

I 1 See Table B5

below.

See Notes 8 and

9 below.

Mandatory

LOCAL_CUSTODIAN_C

ODE

Unique identifier of the

Authority Address

Custodian.

I 4 Mandatory

4 Record Types



March 2016

Page 30 of 63

BASIC LAND AND PROPERTY UNIT RECORD (type 21)


START_DATE Date on which this BLPU

was defined.

Date Up to current

day.

Mandatory

END_DATE Date on which this BLPU

ceased to exist or

became a rejected

Candidate.

Date Not earlier than

Start Date

See Note 6

below.

Conditional

LAST_UPDATE_DATE Date this Record was last

updated. (Note 9)

Date No earlier than

entry date or

later than

present day.

Mandatory

ENTRY_DATE Date of data entry. Date Mandatory

ORGANISATION Name of current

occupier on the fascia of

the BLPU.

T 100 Optional

WARD_CODE The ONS code of the

electoral ward (ENG) or

electoral division (CYM)

name in which the BLPU

is situated.

T 10 See Note 4

below.

Optional

PARISH_CODE The ONS code of the

Parish, Town or

Community Council in

which the BLPU is

situated.

T 10 See Note 4

below.

Optional

CUSTODIAN_ONE Reserved Field. I 2

CUSTODIAN_TWO Reserved Field. I 2

CAN_KEY Candidate key. T 14

Record Example

21,”I”,4,100040141620,1,,,”RD01”,,195012.00,57462.00,1,840,2001-04-04,,2001-04-

10,2001-04-06,””,”00AAFJ”,”00BX006”,,,”“

Notes:

1. BLPU LOGICAL_STATUS = 5 – Candidate (see Table B2), must only be used

when BLPUs are transferred as Candidate Records from GeoPlace to the

Authority Address Custodian for review.

2. BLPU LOGICAL_STATUS = 7 – Rejected external (see Table B2), must only be

used when the Authority Address Custodian rejects a Candidate Record

supplied by GeoPlace.

4 Record Types



March 2016

Page 31 of 63

3. If a BLPU has a LOGICAL_STATUS = 6 - Provisional (see Table B2), the BLPU

STATE (see Tables B3 and B4) and BLPU_STATE_DATE, are Mandatory. These

Fields are Optional for BLPUs with any other LOGICAL_STATUS (see Table

B4).

4. GeoPlace does not currently validate the contents of the WARD_CODE

Field or the PARISH_CODE Field for the following reasons:

Ward and parish boundaries change frequently.

The addition, removal or change of the codes allocated to ward and

parish boundaries by ONS takes much time.

Time lags are possible between the changes, the release of the details

of these changes by the ONS and the updating of the validation

routines in GeoPlace or in software systems used to maintain LLPGs.

Authority Address Custodians and software vendors should use the

latest lists available from the ONS currently available from

http://www.ons.gov.uk/ons/index.html

5. Only certain combinations of BLPU and LPI LOGICAL_STATUS are allowed,

see Table B4.

6. BLPUs with End Dates must have a BLPU LOGICAL_STATUS = 7 - Rejected

Candidate, 8 - Historical or 9 - Rejected Internal (see Table B2).

7. BLPU LOGICAL_STATUS = 9 – Rejected internal (see Table B2), must be used

only when data from an internal source within the DCA Participating

Authority is wrong. These Records should be deleted or archived from the

LLPG to prevent further use or confusion.

Street BLPU Rules

8. RPC = 4 – Start of referenced Street, should be assigned only to Street BLPU

Records together with a BLPU_CLASS = PS – Street Record.

9. The inclusion of Street BLPUs facilitates the linking of other data to incidents

at that Street such as community safety incidents, noise complaints and

environmental health cases. Street BLPU Records must be created for

each USRN of Street RECORD_TYPE = 1 – Official designated Street name

and 2 – Street description and can be created for Street RECORD_TYPE = 3

– Numbered Street, 4 – Unofficial Street description and 9 – Description

used for LLPG access, recorded in the ASG. The following rules must be

applied when a Street BLPU Record is created:

Street BLPUs shall not be submitted to GeoPlace for any out of area

Streets held in an LLPG.

For each Street (open or closed) a BLPU and LPI pair must be created.

http://www.ons.gov.uk/ons/index.html

4 Record Types



March 2016

Page 32 of 63

If the Street is open, the LOGICAL_STATUS of the BLPU and the LPI

Records must = 1 - Approved.

If the Street is closed, the LOGICAL_STATUS of the BLPU and the LPI

Records must = 8 – Historical and an end date must be entered. If the

closure is permanent the BLPU STATE = 4 – No longer existing, must be

used and an appropriate date must be entered into the BLPU state

date Field.

The PAO for a Street BLPU must be a textual description of “STREET

RECORD”.

The following preferred rules should be applied when a Street BLPU

Record is created:

o Assign the coordinates from the Easting and Northing

coordinates associated with the start of the referenced Street, as

defined in the GeoPlace DEC-Addresses v3.4, Section 6.3.20.

o Use RPC = 4 – Start of referenced Street.

o Use BLPU_CLASS = PS – Street Record.

However, if a Street is longer than 750m the following rules may be

applied:

o Assign the coordinates from the Easting and Northing

coordinates associated with the mid point of the level 3 Street

carriageway between the start and end points, as defined in the

GeoPlace DEC-Addresses v3.4, Section 6.3.20.

o Use RPC = 1 - Visual centre.

o Use BLPU_CLASS = PS – Street Record.

Classification Rules

10. For details of BLPU_CLASS codes, see Appendix C of the GeoPlace DEC-

Addresses v3.4 which contains the following:

Appendix C, Section 1 – A table that shows the Classification of

BLPU Objects.

Appendix C, Section 2 – An alphabetical list of Objects and their

Classification codes.

Appendix C, Section 3 – A list of inserted BLPU Classification codes

for the GeoPlace DEC-Addresses v3.4.

Appendix C, Section 4 – A list of retired BLPU Classification codes.

Appendix C, Section 5 – A list of items which must not be submitted

as Objects to GeoPlace.

4 Record Types



March 2016

Page 33 of 63

11. BLPU Classifications must follow the BLPU-CLASS codes, in Appendix C of

the GeoPlace DEC-Addresses v3.4.

For example, the BLPU Classification for an animal sanctuary is as follows:

Primary code C

Secondary code N

Tertiary code 05

The full BLPU Classification is therefore represented by “CN05”.

12. BLPU Classifications should not be hard coded into any LLPG

management systems because the BLPU_CLASS codes in use will be

extended either as coverage extends to currently under represented

classes of an Object or as the users require a finer level of granularity.

Table B1 - Change types

Type CHANGE_TYPE Type CHANGE_TYPE

I Insert D Delete

U Update C Candidate

Table B2 - BLPU Logical Status codes

Code LOGICAL_STATUS Code LOGICAL_STATUS

1 Approved 7 Rejected External (see Note 2 above)

5 Candidate (see Note 1 above) 8 Historical

6 Provisional 9 Rejected Internal (see Note 7 above)

Table B3 - BLPU state codes

Code STATE Code STATE

1 Under construction 5c Planning application received

2 In use 6 Planning permission granted

3 Unoccupied 7c Planning permission refused

4 No longer existing Null

Note c – Records with a BLPU_STATE = 5 - Planning application received or 7 – Planning

permission refused, must not be submitted to GeoPlace.

4 Record Types



March 2016

Page 34 of 63

Table B4 - Permitted BLPU / LPI Logical Status and BLPU Logical Status / state

combinations

BLPU

Logical

Status

Mandatory single LPI

Logical Status Record

Other Permitted multiple

LPI Logical Status value Permitted BLPU state codes

1 1 1a, 3, 5b, 6, 7, 8, 9 Null, 1, 2, 3

5b 5b 5b 1, 2, 3, 4, 6

6 6 6, 7, 8, 9 1, 5c, 6, 7c

7 7 7, 9 Null, 1, 2, 3, 4, 6

8 8 7, 8, 9 Null, 4, 7c

9 9 9 Null, 1, 2, 3, 4, 5c, 6, 7c

Note a – Multiple Approved Preferred LPIs are only allowed if they have different

languages.

Note b – LOGICAL_STATUS = 5 – Candidate, is reserved for transferring Candidate

Records from GeoPlace to the Authority Address Custodian for review.

Note c – Records with a BLPU_STATE = 5 - Planning application received or 7 – Planning

permission refused, must not be submitted to GeoPlace.

Table B5 - BLPU RPC

Code RPC Code RPC

1 Visual centre (see Section

6.3.11.2 to 7 of GeoPlace DEC-

Addresses v3.4).

4 Start of referenced Street

2 General internal point (see

Section 6.3.11.8 to 9 of

GeoPlace DEC-Addresses v3.4).

5 General point based on postcode

unit

3 SW corner of referenced 100m

grid square

9 Centre of DCA Participating Authority

area

4 Record Types



March 2016

Page 35 of 63

4.5. Provenance Record

PROVENANCE RECORD (type 22)



Provenance Record.

I 2 22 Mandatory


Section 4.2.

Mandatory





processed.

I 16 Mandatory


Reference Number.

I 12 Mandatory

PROV_KEY Unique key for the BLPU

Provenance.

T14 See Note 1

below.

Mandatory

PROVENANCE_CODE Identifies the BLPU

Provenance Extent

derivation.

T 1 “T”, “L”, “F”,

“R”, “P”, “O”,

“U”

See Table P1

below.

Mandatory

ANNOTATION Supplementary

information to support

the

PROVENANCE_CODE.

T 30 Optional


START_DATE Date of start of this

Provenance Record.

Date Not later than

current date.

Mandatory

END _DATE Date of end of this

Provenance Record.

Date Optional

LAST_UPDATE_DATE Date of last update. Date No earlier

than entry

date or later

than present

day.

Mandatory

Record Example:

22,”I”,5,100040141620,“0840P000000001”,"P","",2001-04-06,2001-04-04,,2001-04-10

4 Record Types



March 2016

Page 36 of 63

Notes:

1. The PROV_KEY must be identified according to the following convention:

nnnnPsssssssss, where:

o nnnn is the Local Custodian Code as defined in the

appropriate BLPU Record for the UPRN recorded in the

Provenance Record.

o P is the identifier for the Provenance Record type.

o sssssssss is the sequence number associated with the

Provenance Record, padded with leading zeros as

required.

The sequence number must be incremented with the addition or creation

of each Provenance Record in the LLPG.

If a Provenance Record is deleted from an LLPG the sequence number

must not be reused.

Similarly any ‘gaps’ in sequence number must not be filled.

The last sequence number used must be in the LAST_PROV_KEY Field

required in the type 98 Key Sequence Record, see Section 4.12,

associated with each COU or Full Supply transfer file.

2. The Provenance Record must be in the transfer file when type 25 BLPU

Extent, see Section 4.8, type 26 BLPU Extent Polygon, see Section 4.9 and

type 27 BLPU Extent Polygon Vertex, see Section 4.10 Records are

transferred to GeoPlace.

Table P1 - Provenance Record

Provenance

Code

BS7666

Definition

Referenced Data

Source

Source Examples

“P” Inferred from

physical

features.

Map or co-ordinate

based data. Imagery or geo-

referenced map

product.

“O” Occupancy. Residential property

address file. Council tax; Electoral

Register; Housing.

“U” Inferred from

use. Commercial

property address

file.

Business Rates

“T” Registered title. Property ownership. HM Land Registry; local

authority terrier.

4 Record Types



March 2016

Page 37 of 63

Table P1 - Provenance Record

Provenance

Code

BS7666

Definition

Referenced Data

Source

Source Examples

“L” Unregistered

land title. Property ownership. Asset Register.

“F” Formal tenancy

agreement. Property ownership. Asset Register.

“R” Rental

agreement. Property ownership. Asset Register.

4 Record Types



March 2016

Page 38 of 63

4.6. Application Cross Reference Record

APPLICATION CROSS REFERENCE RECORD (type 23)


RECORD_IDENTIFIER Identifies this Record as an

Application Cross

Reference Record.

I 2 23 Mandatory


Section 4.2

Mandatory

PRO_ORDER Integer value that specifies

the order in which the

Records in the transfer file

should be processed.

I 16 Mandatory

UPRN Unique Property Reference

Number.

I 12 Not required for

rejected

Candidate

Records. See

Note 3 below.

Mandatory

XREF_KEY Key value to uniquely

identify the Application

Cross Reference Record.

T 14 See Note 1

below.

Mandatory

START_DATE Date this change

originated.

Date Not later than

current date.

Mandatory

LAST_UPDATE_DATE Date of last update. Date No earlier than

entry date or

later than

present day.

Mandatory


END _DATE The date on which the

external cross reference

ceased to exist.

Date Optional

CROSS_REFERENCE Primary key of

corresponding Record in an

external data-set.

T 50 Mandatory

SOURCE External data-set identity. T 6 See Table A1

below.

See Note 2

below.

Mandatory

Record Example:

23,”I”,6,100040141620,”0840X000000001”,2001-04-04,2001-04-10,2006-01-09,

,"1857530000","0840CT"

4 Record Types



March 2016

Page 39 of 63

Notes:

1. The XREF_KEY must be identified according to the following convention:

nnnnXsssssssss where:


appropriate BLPU Record for the UPRN recorded in the

Application Cross Reference.

o X is the identifier for the Application Cross Reference

Record type.

o sssssssss is the sequence number associated with the

Application Cross Reference Record, padded with

leading zeros as required.

The sequence number must be incremented with the addition or creation

of each Application Cross Reference Record in the LLPG.

If an Application Cross Reference Record is deleted from an LLPG, the

sequence number must not be reused.


The last sequence number used must be in the LAST_XREF_KEY Field

required in the type 98 Key Sequence Record, see Section 4.12,

associated with each COU or Full Supply transfer file.

If a Local Custodian Code is only three characters, that is, less than 1000,

the code must be “left padded” with a single zero, thus for example, an

Xref Key for Local Custodian Code 2114 is 2114X000000001 but an Xref Key

for a Local Custodian Code 630 is 0630X000000001.

2. The Data Source must be a concatenation of the Local Custodian Code

followed by a two character dataset identifier code for the Data Source.

For details of the Data Source identifier codes see Table A1 below.


the code must be left padded with a single zero, thus for example, the

council tax Application Cross Reference for Local Custodian Code 2114 is

2114CT but the one for Local Custodian Code 630 is 0630CT.

GeoPlace does not accept any Application Cross Reference Records

supplied with Data Source Records in the four character DTF6.3 format or

4 Record Types



March 2016

Page 40 of 63

any Application Cross References without a valid, appropriate and

correctly formatted Local Custodian Code in the first four characters.

Table A1 - Data Source identifier codes

Dataset

ID

Data Source Capture within LLPG Part of COU or Full

Supply transfer files

to GeoPlace

BC Building Control Optional N

BG Linked LPI (Bilingual

Gazetteers Only – see LPI

Record Note 20)

Conditional Y

CM CRM Optional N

CT Council Tax Mandatory Y

EH Environmental Health Optional N

EM Estates Management Optional N

ER Electoral Registration Mandatory Y

FI Finance Optional N

HO Housing Optional N

IA Candidate Record

received from GeoPlace

Conditional Y

LB Listed Buildings Optional N

LC Land Charges Optional N

ND Non Domestic Rates Mandatory Y

OS Ordnance Survey

received from GeoPlace

Optional Y

PA Postcode Address File Optional Y

PL Planning Optional N

RC Refuse Collection Optional N

S1 SNN Conversion Mandatory Y

S2 SNN Demolition Mandatory Y

S3 SNN New Build Mandatory Y

S4 SNN Rename / Renumber Mandatory Y

S5 SNN Retrospective Mandatory Y

4 Record Types



March 2016

Page 41 of 63

4.7. Land and Property Identifier Record

LAND AND PROPERTY IDENTIFIER RECORD (type 24)


RECORD_IDENTIFIER

Identifies this Record as a

Land and Property

Identifier.

I 2 24 Mandatory

CHANGE_TYPE

Identifies the type of

change associated with

this Record.

T 1 See Table B1,

Section 4.4 Mandatory

PRO_ORDER

Integer value that




processed.

I 16 Mandatory


Reference Number. I 12 Mandatory

LPI_KEY Unique key for the LPI. T 14 See Note 12

below. Mandatory

LANGUAGE

A code identifying the

language used for the

descriptive identifier.

T 3

See Notes 9

and 16 to 23

below.

See Table SD1,

Section 4.3.

Mandatory

LOGICAL_STATUS Logical status of this

Record. I 1

See Notes 6, 7,

8 and 9

below.

See Table L1

below.

Mandatory

START_DATE Date this Record was

created. Date

Not later than

current date. Mandatory

END_DATE Date this Record ceased

to exist. Date

Not earlier

than start

date.

Optional



changed. Date

No earlier than

entry date or

later than

present day.

Mandatory

SAO_START_NUMBER I 4 Conditional

SAO_START_SUFFIX T 2 Conditional

SAO_END_NUMBER I 4 Conditional

4 Record Types



March 2016

Page 42 of 63

LAND AND PROPERTY IDENTIFIER RECORD (type 24)


SAO_END_SUFFIX T 2 Conditional

SAO_TEXT Secondary Addressable

Object description. T 90 Conditional

PAO_START_NUMBER I 4 See Note 2

PAO_START_SUFFIX T 2 See Note 2

PAO_END_NUMBER I 4 See Note 2

PAO_END_SUFFIX T 2 See Note 2

PAO_TEXT Primary Addressable

Object description. T 90 See Note 2

USRN Unique Street reference

number. I 8 Mandatory

LEVEL

Memorandum of the

vertical position of the

BLPU.

T 30 Optional

POSTAL_ADDRESS

Flag to show that BLPU

receives a delivery from

the Royal Mail or other

postal delivery service.

T 1

“A”, “P”, “Y”,

“N” or “L”.

See Note 4

below.

See Table L2

below.

Mandatory

POSTCODE

Allocated by the Royal

Mail to assist in delivery of

mail.

T 8 See Note 10

below. Conditional

POST_TOWN

Allocated by the Royal

Mail to assist in delivery of

mail.

T 30 See Note 10

below. Conditional

OFFICIAL_FLAG Status of address. T 1

“Y”, “N”, “R”,

“C” or null.

See Note 11

below.

See Table L3

below.

Optional

CUSTODIAN_ONE Reserved Field I 2

CUSTODIAN_TWO Reserved Field I 2

CAN_KEY Candidate key. T 14

Record Example:

24,”I”,7,100040141620,”0840L000000001”,”ENG”,1,2001-04-04,,2006-01-09,2006-06-

06,,””,,””,””,10,””,,””,”HOLLY HOUSE”,31401062,””,”Y”,”PL26 8EH”,”ST AUSTELL”,

“”,,,” “

4 Record Types



March 2016

Page 43 of 63

Notes:

1. The LPI_KEY must be identified according to the following convention:

nnnnLsssssssss where:


appropriate BLPU Record for the UPRN recorded in

the LPI.

o L is the identifier for the LPI Record type.

o sssssssss is the sequence number associated with the LPI

Record, padded with leading zeros as required.

The sequence number must be incremented with the addition of each LPI

Record.

If an LPI Record is deleted, the sequence number must not be reused.


The last sequence number used must be in the LAST_LPI_KEY Field required

in the type 98 Key Sequence Record (see Section 4.12) in each Full Supply

or COU transfer file.


the code must be “left padded” with a single zero, thus for example, the

LPI_KEY for Local Custodian Code 2114 is 2114L000000001 while those for

Local Custodian Code 630 is 0630L000000001.

2. At least one of the following Primary Addressable Object attributes must

be present in each LPI Record.

PAO_START_NUMBER

PAO_TEXT

Both can exist if they form part of the address for the BLPU.

If there is an entry in the PARENT_UPRN Field at least one of the following

Secondary Addressable Object attributes should be present in one LPI

Record.

SAO_START_NUMBER

SAO_TEXT

Both can exist if they form part of the address for the BLPU.

3. If an LLPG is flagged as a bilingual gazetteer in the type 29 Metadata

Record (see Section 4.11), then two characters are permitted in the

PAO_SUFFIX and SAO_SUFFIX Fields. Otherwise, only a single character is

permitted in these Fields.

4 Record Types



March 2016

Page 44 of 63

4. For details of permitted POSTAL_ADDRESS values, see Table L2. The

following rules must also be applied to the POSTAL_ADDRESS values:

If the POSTAL_ADDRESS = “Y” – A Postal Address, a POSTCODE and

POSTTOWN must be completed.

If the POSTAL_ADDRESS = “A” – An assumed posttown and postcode, a

correctly formatted postcode and the correct posttown must be

entered. For postcode format rules, see Note 9 below.

If the POSTAL_ADDRESS = “N” – Not a Postal Address, no postcode or

posttown must be entered, unless the LPI has a LOGICAL_STATUS = 6 –

Provisional.

If the POSTAL_ADDRESS = “P” – A pseudo postcode, a postcode may

be entered but no posttown must be entered. For postcode format

rules, see Note 9 below.

If the POSTAL_ADDRESS = “L” – A Postal Address where the Postcode

used is a large user Postcode, a full, correctly formatted postcode and

the correct posttown must be entered. For postcode format rules, see

Note 9 below.

5. If an LPI Record is associated with a USRN which is not within the

administrative area of the DCA Participating Authority, the Street Record

must not be included in any Full Supply or COU transfer file sent to

GeoPlace.

6. LPI LOGICAL_STATUS = 5 – Candidate must only be used if BLPUs or LPIs are

transferred as Candidate Records from GeoPlace to the Authority Address

Custodian for review, see Table L1.

7. LPI LOGICAL_STATUS = 7 – Rejected External must only be used when the

Authority Address Custodian rejects a Candidate Record supplied by

GeoPlace, see Table L1.

8. Only certain combinations of BLPU and LPI LOGICAL_STATUS are allowed.

For further details, see Table B4, Section 4.4.

9. There must be only one LPI with a LOGICAL_STATUS = 1 – Approved

Preferred, for each BLPU with a LOGICAL_STATUS = 1 – Approved, unless a

second LPI has been created with a different language flag. Only English

(ENG) or Welsh (CYM) Records must be created, (see Table SD1, Section

4.3).

10. All postcode values must conform to the format rules laid down by the

Royal Mail, see:

http://www.royalmail.com/personal/help-and-support/How-do-I-address-

my-mail-correctly, accessed February 2016.

http://www.royalmail.com/personal/help-and-support/How-do-I-address-my-mail-correctly

http://www.royalmail.com/personal/help-and-support/How-do-I-address-my-mail-correctly

4 Record Types



March 2016

Page 45 of 63

11. The OFFICIAL_FLAG = “R” and “C”, have the following meanings:

OFFICIAL_FLAG = “R”. A postcode was requested from the Royal Mail

AMU by an Authority Address Custodian.

OFFICIAL_FLAG = “C”. An address was confirmed by the Authority

Address Custodian / SNN Officer. The address is ready for notification

to a specified list of third parties, (see Table L3 below).

12. The LPI_KEY is not Mandatory for Candidate Records.

13. If a BLPU is associated with a Street RECORD_TYPE = 9 – Description used

for LLPG access, an Alternative LPI, see Table L1), must be created linking

the BLPU to the most appropriate Street RECORD_TYPE = 1 – Official

designated Street name or 2 – Street description. The exception is if a

Street BLPU is created for a Street RECORD_TYPE = 9. In that case the

Approved Preferred LPI must reference the Street STREET_TYPE = 9, and an

Alternative LPI should not be created.

14. If a BLPU is associated with a Street RECORD_TYPE = 3 – Numbered Street

or 4 – Unofficial Street description, this must be only as an Alternative LPI.

No Approved Preferred LPIs, (see Table L1), must be associated to a Street

RECORD_TYPE = 3 – Numbered Street or 4 – Unofficial Street description.

The BLPU must also be associated with a Street RECORD_TYPE = 1 – Official

designated Street name or 2 – Street description, by its Approved

Preferred LPI.

15. The exception is if a Street BLPU is created for a Street RECORD_TYPE = 4 –

Unofficial Street description. In that case, the Approved Preferred LPI must

reference the Street RECORD_TYPE = 4 – Unofficial Street description and

an Alternative LPI should not be created.

LANGUAGE Rules

16. If an address is provided in an LLPG which is a bilingual gazetteer, both an

ENG LPI and a CYM LPI must be provided. A bilingual gazetteer is

identified in the LLPG Metadata Record using the code BIL in the

language Field, (see Table M2, Section 4.11).

17. Thus, for example, a public building such as a library, must be recorded in

the LLPG as a BLPU and must have two Approved Preferred LPIs

(LOGICAL_STATUS = 1), one with the language flag set to “ENG” (English)

and the other to “CYM” (Welsh) with the Addressable Object either

translated into or captured in the appropriate language. Sometimes,

there is no difference between these values, for example property

numbers, as no literal translation is either applicable or appropriate.

4 Record Types



March 2016

Page 46 of 63

18. Any number of further Alternative or Historical LPIs can be held and

flagged under the appropriate language. For example, the Welsh

speakers in the community may have a local descriptive name for the

library but for each LPI created in one language a mirror version must be

created in the other language, thus, there is a 1:1 relationship between

each ENG and CYM LPI.

19. The LPI keys of each ENG and CYM LPI which relate to each other must be

concatenated and entered into the cross reference table with a source

code of BG. Thus, the CROSS_REFERENCE for an ENG LPI with an LPI key of

6820L000000001 which has a 1:1 relationship with a CYM LPI with an LPI key

of 6820L000000002 is 6820L0000000016820L000000002. If a BLPU has

multiple LPI pairings more than one Application Cross Reference Record

must exist. This applies to Records with any LOGICAL_STATUS.

20. There is not always a complete translation of all address elements,

therefore it follows that not all locations have a direct alternative

language translation and some property names or place names are the

same in either language. If this is the case the Authority Address

Custodian must ensure that both language versions of the LPI Records are

recorded consistently.

21. Each LPI Record must be identified according to which language is in use.

This language information must be recorded against each LPI.

Table L1 - LPI Logical Status codes

Code LOGICAL_STATUS Code LOGICAL_STATUS

1 Approved Preferred 7 Rejected External (see Note 7 above)

3 Alternative 8 Historical

5 Candidate (see Note 6 above) 9 Rejected Internal

6 Provisional

4 Record Types



March 2016

Page 47 of 63

Table L3 - Official Address codes

Value Description

“Y” Official Address

“N” Unofficial Address

“R” Postcode and posttown requested from the Royal Mail

“C” Postal Address confirmed and ready for notification

null Not defined

Table L2 - Postal Address codes

Value Description Posttown Field

Completion

Postcode Field

Completion

“Y” A Postal Address Mandatory Mandatory

“N” Not a Postal Address No data entered

unless LPI Logical

Status is set to

Provisional LPI.

No data entered

unless LPI Logical

Status is set to

Provisional LPI.

“A” An assumed posttown and postcode for

the Object if it is associated with an

existing Postal Address, that is, an Object

which can receive mail but the posttown

and postcode has not been officially

allocated by the Royal Mail. For

example bedsits within a house.

Mandatory Mandatory

“P” A pseudo postcode for the Object if it is

associated with a postcode in the

vicinity of the Object to be described. It

must not be used as a Postal Address.

For example, a car park or an area of

land.

No data entered Mandatory

“L” Postcode and posttown used as a large

user Postal Address.

Mandatory Mandatory

4 Record Types



March 2016

Page 48 of 63

4.8. BLPU Extent Record

BLPU EXTENT RECORD (type 25)



BLPU extent. I 2 25 Mandatory

CHANGE_TYPE


change associated with this

Record.

T 1 See Table S1,

Section 4.2. Mandatory

PRO_ORDER Processing order serial

number. I 16 Mandatory


Number. I 12 Mandatory

PROVENANCE_CODE Provenance of the BLPU. T 1 Mandatory

START_DATE Date this Record was

created. Date

Not later than


END_DATE Date this Record ceased to

exist. Date

Not earlier

than start

date.

Optional



changed. Date Mandatory

SOURCE_DATE Date of the source of the

BLPU extent data. Date Mandatory

SOURCE_DESCRIPTION

Source and / or relevance

of the data representing

the BLPU.

T 30 Optional

Record Example:

25,”I”,8,100040141620,”T”,1,2006-02-05,,2006-02-05,2006-06-01,2006-01-01,”Asset

Register”

4 Record Types



March 2016

Page 49 of 63

4.9. BLPU Extent Polygon Record

BLPU EXTENT POLYGON RECORD (type 26)


RECORD_IDENTIFIER


BLPU Extent Polygon

Record.

I 2 26 Mandatory

CHANGE_TYPE



Record.

T 1 See Table S1,


PRO_ORDER

Integer value that specifies




I 16 Mandatory



START_DATE Date this Record or version

was created. Date

Not later than


END_DATE Date this Record ceased to

exist. Date

Not earlier

than start

date.

Optional


PROVENANCE_CODE Provenance of the BLPU. T 1

“T”, “L”, “F”,

“R”, “P”, “O”,

“U”, see Table

P1, Section

4.5.

Mandatory

POLYGON_NUMBER

Number that uniquely

identifies the polygon within

those representing the BLPU

extent.

I 2 1-99 Mandatory

POLYGON_TYPE

Whether the polygon is

included or excluded from

the BLPU extent.

T 1 H or blank Mandatory

EXTERNAL_POLYGON_I

DENTIFIER

Unique identifier of the

discrete real world

topographic feature held

within a GIS.

I 20 Optional

VERTEX_COUNT

Number of vertices

described by ordered co-

ordinate pairs – including

I 16 Optional

4 Record Types



March 2016

Page 50 of 63

BLPU EXTENT POLYGON RECORD (type 26)


coincident start and finish

vertices.


changed. Date Mandatory

Record Example:

26,”I”,9,100040141620,2006-01-01,,2006-06-06,”T”,1,”H”,,4,2006-06-06

4 Record Types



March 2016

Page 51 of 63

4.10. BLPU Extent Polygon Vertex Record

BLPU EXTENT POLYGON VERTEX RECORD (type 27)


RECORD_IDENTIFIER


BLPU Polygon Extent Vertex

Record.

I 2 27 Mandatory

CHANGE_TYPE



Record.

T 1 See Table S1,


PRO_ORDER

Integer value that specifies




I 16 Mandatory



PROVENANCE_CODE Provenance of the BLPU

extent. T 1

“T”, “L”, “F”,

“R”, “P”, “O”,

“U”, see Table

P1, Section

4.5.

Mandatory

POLYGON_NUMBER

Number that uniquely

identifies the polygon within

those representing the BLPU

extent.

I 2 1-99 Mandatory

VERTEX_ORDER

Sequential counter which

shows the order of the

vertices forming the BLPU

polygon.

I 16 Mandatory

POLY_X_COORD The easting co-ordinate of

the vertex. N 11 Mandatory

POLY_Y_COORD The northing co-ordinate of

the vertex. N 11 Mandatory

Record Example:

27,”I”,10,100040141620,”T”,1,1, 195012.0000,57462.00000

Notes:

1. A new polygon must be created only if a new UPRN is required as a result of

real world change, as described in the GeoPlace DEC-Addresses v3.4, which

4 Record Types



March 2016

Page 52 of 63

causes the BLPU extent to change, for example, if a property is demolished or

a split or merger occurs.

An existing polygon should be corrected if it is subject to change for one of

the following reasons:

Improvement in source data.

Change to mapping.

Change due to extension/acquisition of new land.

Change due to reduction in land in real terms.

4 Record Types



March 2016

Page 53 of 63

4.11. LLPG Metadata Record

LLPG METADATA RECORD (type 29)


RECORD_IDENTIFIER Identifies this Record as

LLPG metadata. I 2 29 Mandatory

GAZ_NAME

Name of the gazetteer.

For example, LLPG for

Camden.

T 60 Mandatory

GAZ_SCOPE

Description of the

content of the gazetteer

For example, all basic

property units with some

land parcels.

T 60 Mandatory

TER_OF_USE Geographic domain of

the gazetteer. T 60 Mandatory

LINKED_DATA

List of application

dataset used to update

the LLPG.

T 100 Optional

GAZ_OWNER

The organisation with

overall responsibility for

the gazetteer. This is the

DCA Participating

Authority for LLPG.

T 60 Mandatory

NGAZ_FREQ

Frequency with which

LLPG is maintained and

sent to GeoPlace.

T 1

“D”, “W”, “F”,

“M”.

See Note 1

below.

See Table M1

below.

Mandatory

CUSTODIAN_NAME

Organisation or

department responsible

for the compilation and

maintenance of the

data in the gazetteer

that is the DCA

Participating Authority.

T 40 Mandatory

CUSTODIAN_UPRN

UPRN of Authority

Address Custodian

location.

I 12 Mandatory

LOCAL_CUSTODIAN_CO

DE Issued by GeoPlace. I 4 Mandatory

4 Record Types



March 2016

Page 54 of 63

LLPG METADATA RECORD (type 29)


CO_ORD_SYSTEM

Co-ordinate reference

system used in the

gazetteer to describe

position, that is the

National Grid of Great

Britain.

T 40 British

National Grid Mandatory

CO_ORD_UNIT Measure of coordinates

used within the gazetteer T 10 Metres Mandatory

META_DATE Date metadata was last

updated. Date Mandatory

CLASS_SCHEME

Classification scheme

used for all multiple value

specified Fields for

example GeoPlace DEC-

Addresses v3.4.

T 40 Mandatory

GAZ_DATE

Date at which the

gazetteer can be

considered to be current.

Date Mandatory

LANGUAGE

Language(s) used for

descriptors within the

gazetteer.

T 3 See Table M2

below. Mandatory

CHARACTER_SET T 30 Mandatory

Record Example:

29,”Cornwall Council LLPG”,”All residential and commercial premises within

Unitary area”,”Cornwall Council”,”DC/BC/CTAX/EREG/PLAN/SNN”,”Cornwall

Council”,”W”,”Planning”100041031005, 840,”British National Grid”,“metres”,2007-

01-02,”DEC-Addresses v3.4”,2006-07-01,”ENG”,”English”

Notes:

1. The update frequency Field NGAZ_FREQ shows the update frequency

agreed between GeoPlace and the Authority Address Custodian. In the

case of an agreed daily update frequency, a “blank” transfer file is

required on days when no changes have been made. That is, a file which

only contains a Header, Key Sequence and Footer Record.

2. The LLPG Metadata Record must be sent to GeoPlace with an LLPG Full

Supply transfer file and subsequently whenever the Authority Address

Custodian makes a change to the LLPG Metadata Fields.

4 Record Types



March 2016

Page 55 of 63

3. The language code of BIL must be used in the LLPG Metadata Record

only to show that both English and Welsh are fully represented on equal

terms in the gazetteer.

Table M1 - LLPG Update Frequency

Code NGAZ_FREQ Code NGAZ_FREQ

“D” Daily “F” Fortnightly

“W” Weekly “M” Monthly

Table M2 - Metadata Language codes

Code LANGUAGE

“ENG” English

“BIL” Bilingual using English and Welsh languages

4 Record Types



March 2016

Page 56 of 63

4.12. Key Sequence Record

KEY SEQUENCE RECORD (type 98)



key sequence Record.

I 2 98 Mandatory

LAST_LPI_KEY Highest value LPI_KEY

used in LLPG.

T 14 Mandatory

LAST_PROV_KEY Highest value PROV_KEY

used in LLPG.

T 14 Conditional

LAST_XREF_KEY Highest value XREF_KEY

used in LLPG.

T 14 Conditional

LAST_UPDATE_DATE Date on which the key

sequence Record was

last updated.

Date Mandatory

TIME_STAMP Time on which the key

sequence Record was

last updated.


Record Example:

98,”0840L000000001”,”0840P000000004”,”0840X000000009”,2006-07-04,153742

Notes:

1. LAST_PROV_KEY is Mandatory if polygons are held in the LLPG.

4 Record Types



March 2016

Page 57 of 63

4.13. Trailer record

TRAILER RECORD (type 99)



Trailer Record.

I 2 99 Mandatory

NEXT_VOLUME_NUMBER The sequential number of

the next volume in the

transfer set. If this is the

last volume,

NEXT_VOLUME_NUMBER =

0 must be present.

I 2 0-99 Mandatory

RECORD_COUNT Count of the number of

Records in the volume

(excluding the Header

Record, LLPG metadata,

key sequence and Trailer

Records).

I 12 Mandatory


TIME_STAMP Time of file creation in

HHMMSS format.


Record Example:

99,0,239223,2006-07-04,153742

5 Operational Guidelines



March 2016

Page 58 of 63

5. Operational Guidelines

5.1. Order within COU files

5.1.1. The processing order number of each Record shows how the

Record appears in the file. The following rules must be applied to

help ensure Full Supply and COU transfer files are processed

correctly:

If new Records are inserted, (CHANGE_TYPE = “I” see Table S1,

Section 4.2) the Records must appear in the COU transfer file in

the following order:

o Street (type 11).

o Street Descriptor (type 15).

o BLPU (type 21).

o LPI (type 24).

o XREF (type 23).

If Records are deleted (CHANGE_TYPE = “D” see Table S1,

Section 4.2) the Records must appear in the COU transfer file in

the following order:

o XREF (type 23).

o LPI (type 24).

o BLPU (type 21).

o Street Descriptor (type 15).

o Street (type 11).

If an existing Approved Preferred LPI (LOGICAL_STATUS = 1, see

Table L1, Section 4.7) is changed to an Alternative LPI

(LOGICAL_STATUS = 3) or Historical LPI (LOGICAL_STATUS = 8),

the update Record (CHANGE_TYPE = “U” see Table S1, Section

4.2) must precede the insertion of the new LPI (CHANGE_TYPE =

“I” see Table S1, Section 4.2) in the COU transfer file.

If an existing Approved Preferred LPI is deleted and a new

Approved Preferred LPI is added, the delete Record

(CHANGE_TYPE = “D” see Table S1, Section 4.2) for the existing

LPI must precede the insertion of the new LPI (CHANGE_TYPE =

“I” see Table S1, Section 4.2) in the COU transfer file.




March 2016

Page 59 of 63

If the Parent UPRN Field in the BLPU Record is used to identify a

hierarchy as described in Section 4.5 , the members of the

hierarchy must be inserted in order of seniority, that is,

grandparents before Parents, Parents before children and

children before grandchildren.

If members of a hierarchy are deleted, all members of the

lowest level must be removed before deleting the member

from the next level up.

A BLPU must not have two LOGICAL_STATUS = 1 - Approved

Preferred LPIs at any time. Therefore if a BLPU has more than

one LPI and the Logical Statuses are changed, this must be

done in the order shown in the example below:

o A BLPU has two LPIs, one with a LOGICAL_STATUS = 1

(Approved Preferred LPI, see Table L1, Section 4.7) and the

other with a LOGICAL_STATUS = 3 (Alternative LPI, see Table

L1, Section 4.7):

• Change the current Approved Preferred LPI

(LOGICAL_STATUS = 1) to an Alternative LPI

(LOGICAL_STATUS = 3).

• Upgrade the existing Alternative LPI Record

(LOGICAL_STATUS = 3) to Approved Preferred LPI

(LOGICAL_STATUS = 1).

5.2. Re-use of UPRNs

5.2.1. A UPRN can be removed from general circulation in the following

ways. GeoPlace will permanently remove the Record from

GeoHub, where:

All associated BLPUs and LPIs are LOGICAL_STATUS = 9 -

Rejected Internal, see Table B2, Section 4.4 and see Table L1,

Section 4.7 with the appropriate End Date added and this

status is included in the COU transfer file.

The Record is deleted by the Authority Address Custodian and

this deletion is included in the COU transfer file.

The BLPUs and LPIs associated with a UPRN do not appear in a

Full Supply transfer file when a resynchronisation takes place.




March 2016

Page 60 of 63

5.2.2. As soon as any of the above requests are received and processed

by GeoPlace the UPRNs involved are effectively out of circulation.

Also all users are advised to remove the UPRNs and associated

Records from their systems.

5.2.3. To preserve data integrity GeoPlace will keep details of any

“removed” UPRNs and will prevent their re-use.

5.2.4. The following operational guideline is issued to formalise the rules

applied by GeoPlace and should be adopted by all parties

involved in LLPG maintenance:

If a BLPU exists but there are valid LPIs that are no longer

required, these LPIs should be set as Historical LPIs

(LOGICAL_STATUS = 8 – Historical, see Table L1, Section 4.7).

If a BLPU (and its associated LPIs) is demolished or changed

into a new BLPU, this BLPU should be set as a BLPU

LOGICAL_STATUS = 8 – Historical and kept in the LLPG.

Any errors that are identified in the LLPG, for example LPIs

spelt incorrectly, spurious LOGICAL_STATUS = 3 - Alternative

LPIs, duplicate BLPUs or duplicate LPIs should be deleted from

the LLPG.

GeoPlace, on receipt of a COU transfer file containing an LPI

LOGICAL_STATUS = 7 - Rejected Record will remove that

Record from its systems and, if a BLPU and all associated LPIs

are marked as LOGICAL_STATUS = 7 - Rejected, add the UPRN

to the GeoHub archive file. All UPRNs added to the GeoHub

archive are frozen, which means they cannot be re-used,

even if the rejection of the BLPU and LPI in question is made in

error.

If an LLPG Full Supply to GeoHub re-synchronisation is

requested, GeoPlace will assume that the transfer file supplied

is a Full Supply transfer file from the LLPG and will place any

UPRNs held in GeoHub that do not appear in the Full Supply

transfer file into the GeoHub archive. Any UPRNs placed in

the GeoHub archive cannot be re-used.

5.3. Re-use of LPI and Xref keys

5.3.1. If an LPI or Application Cross Reference Record is moved to the

GeoHub archive because it is rejected or deleted as described




March 2016

Page 61 of 63

above, the LPI or XREF key used for that Record will be archived

too and no longer available for use or re-use.

5.3.2. If an Application Cross Reference Record or an LPI Record is

attached to an incorrect BLPU and therefore has an incorrect

UPRN, the Record cannot be simply moved to the new UPRN via a

COU transfer file to GeoPlace. The Authority Address Custodian

must do the following things and these changes must be shown in

the COU:

Set the incorrect Application Cross Reference or LPI Record to

historical or rejected or delete the incorrect Record.

Create a new Application Cross Reference or LPI Record with

a new Application Cross Reference or LPI key associated with

the correct UPRN.

5.4. BLPU Transformations and UPRN data integrity

5.4.1. Authority Address Custodians must not reallocate or create a new

BLPU if there has not been any real world Object physical change.

UPRNs must endure for the lifetime of a BLPU as set out in the

Property Lifecycle section (GeoPlace DEC-Addresses v3.4, Sections

11.2 – 11.5) so that users can rely on the UPRN for internal data

linking.

5.5. Monthly Health Check

5.5.1. GeoPlace sends all Authority Address Custodians a Health Check

report each month. This report identifies any Records held in

GeoHub for that DCA Participating Authority that contravene any

of the Health Checks defined in the GeoPlace DTF7.3 Health

Check document that is current at the time of generation. For

details of the latest GeoPlace DTF7.3 Health Checks, see the

GeoPlace website.

6 Relationship Diagram



March 2016

Page 62 of 63

6. Relationship Diagram

Index



March 2016

Page 63 of 63

Index

Addressable Object 42, 43, 45

Alternative LPI 45, 58-60

Approved Preferred LPI 35, 44, 58, 59

ASG 32

Bilingual 8, 20, 28, 29, 40, 43, 45-46, 55

BLPU 15, 18, 19, 20, 25, 29-36, 42-46, 48-52, 58-61

Candidate 19, 22, 30-34, 38, 40, 42, 44-46

Child 15, 59

Classification 23, 25, 26, 29, 32, 33, 54

COU 19-21, 28, 30, 36, 40, 43, 44, 49, 58-61

extent 18, 35, 36, 48-52

Full Supply 13, 17-21, 30, 36, 39, 40, 43, 44, 54, 58, 59, 60

hierarchy 59

land parcel 53

language 27-28, 34, 41, 44-46, 54-55

Authority Address Custodian 13, 29

Local Custodian Code 19, 20, 29, 36, 39,40, 43, 53

Local Highway Authority 23, 27-28

locality 27

Logical Status 25, 29-34, 41, 44-47, 58

LPI 15, 20, 25, 31-32, 34, 40-41, 43-47,56, 58-61

Official Address 47

Parent 15, 29, 33, 43, 59

Postcode 34, 40, 42, 44, 45, 47

RPC 29, 31, 32, 34

Street Description 25, 27, 31, 45

Street Name 25, 27, 31, 45

Street type 23, 25, 45

town 27, 30

Documents

GeoPlace Data Transfer Format 7.3 for Addresses DTF7.3 Version … · 2020. 10. 9. · 01.02.12 GeoPlace™LLP Revisions to align DFT7.3 v3.1 Third Edition (February 2012 to published