CEN/TR 14142-2:2011

SLOVENSKI STANDARD
01-oktober-2011
3RãWQHVWRULWYH%D]HQDVORYRYGHO.RQYHQFLMHRNDUWLUDQMXHOHPHQWRY
REUDYQDYDQMHQDþUWRYDQMDSUHGORJSUHGORJHQDVORYRYLQQDYRGLOD]DL]YDMDQMH
Postal Services - Address databases - Part 2: Element mapping conventions, template
design considerations, address templates and rendition instructions
Postalische Dienstleistungen - Adressdatenbanken - Part 2: Konventionen für die
Abbildung von Elementen, Hinweise für das Vorlagendesign, Vorschriften für
Adressvorlagen und -wiedergabe
Services postaux - Bases de données d'adresses - Partie 2: Conventions de disposition
des éléments, considérations relatives à la conception des modèles, instructions
relatives aux modèles d'adresse et à la présentation des adresses
Ta slovenski standard je istoveten z: CEN/TR 14142-2:2011
ICS:
03.240 Poštne storitve Postal services
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL REPORT
CEN/TR 14142-2
RAPPORT TECHNIQUE
TECHNISCHER BERICHT
August 2011
ICS 03.240
English Version
Postal Services - Address databases - Part 2: Element mapping
conventions, template design considerations, address templates
and rendition instructions
Services postaux - Bases de données d'adresses - Partie Postalische Dienstleistungen - Adressdatenbanken - Part 2:
2: Conventions de disposition des éléments, considérations Konventionen für die Abbildung von Elementen, Hinweise
relatives à la conception des modèles, instructions relatives für das Vorlagendesign, Vorschriften für Adressvorlagen
aux modèles d'adresse et à la présentation des adresses und -wiedergabe

This Technical Report was approved by CEN on 7 September 2010. It has been drawn up by the Technical Committee CEN/TC 331.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland,
Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2011 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 14142-2:2011: E
worldwide for CEN national Members.

Contents Page
1 Scope .6
2 Normative references .7
3 Terms and definitions .7
4 Symbols and abbreviations .7
5 Element Mapping Conventions and Template Design Considerations .7
5.1 About Element Mapping Conventions .7
5.2 Element Mapping Conventions .7
5.2.1 Basic Rule Regarding Addressee .7
5.2.2 No Mailee Without Addressee .8
5.2.3 Mailee Not Both Preceding and Succeeding .8
5.2.4 Indirect Identification of Addressee and Mailee .8
5.2.5 Granularity Constraints .8
5.2.6 Cross Reference Addresses .9
5.2.7 Path addresses . 10
5.2.8 Dual Addresses . 11
5.2.9 Sectoral Addresses . 11
5.2.10 Inverted Order of Address Lines . 11
5.2.11 Logical vs. Sequential Assignment . 11
5.2.12 Extension vs. Multiple Secondary Identifiers . 12
5.2.13 Postcode vs. Sorting Code . 12
5.2.14 Country Name Position . 12
5.3 About Template Design Considerations . 12
5.4 Template Design Considerations . 13
5.4.1 Supported Cases of Addressee and Mailee . 13
5.4.2 Generic Initial Template Section for Addressee and Mailee . 14
5.4.3 Modality: Required and Optional . 16
5.4.4 Cardinality . 16
5.4.5 Cardinality Constraints . 17
5.4.6 Element Sub-Types. 17
5.4.7 Criteria for Element Sub-types . 17
5.4.8 Element and Element Sub-type Boundary Issues . 18
5.4.9 Element and Element Sub-type Boundary Issues . 18
5.4.10 Segment Numbering . 18
5.4.11 Segment Replication . 18
5.4.12 Abstract Elements vs. Elements Which May Be Populated . 19
5.4.13 Character Sets . 19
5.4.14 Left and Right Justification . 19
5.4.15 Trigger Conditions . 19
5.4.16 Starting Position . 19
5.4.17 Migrating Elements and Migration Precedence . 19
6 Generic rendition instructions . 20
6.1 Append . 20
6.2 CONCAT . 21
6.3 CONCATWL . 21
6.4 CONTACTWLR . 22
6.5 CONCATWR . 22
6.6 LITERAL . 23
7 Australia . 24
7.1 Address template in Natural Language Notation . 24
7.2 Address examples . 25
7.3 Address template in PATDL . 26
8 Brazil . 35
8.1 Address template in Natural Language Notation . 35
8.2 Address examples . 36
8.3 Address template in PATDL . 38
9 Canada . 48
9.1 Address template in Natural Language Notation . 48
9.2 Address examples . 49
9.3 Address template in PATDL . 50
10 Chile . 59
10.1 Address template in Natural Language Notation . 59
10.2 Address examples . 61
10.3 Address template in PATDL . 62
11 Finland . 68
11.1 General information . 68
11.2 Address template in Natural Language Notation . 68
11.3 Presentation rules . 69
11.4 Address examples . 70
11.5 Address template in PATDL . 71
12 France . 79
12.1 General information . 79
12.2 Address template in Natural Language Notation . 79
12.3 Presentation rules . 80
12.4 Address examples . 81
12.5 Address template in PATDL . 82
13 Germany . 91
13.1 Address template in Natural Language Notation . 91
13.2 Address examples . 92
13.3 Address template in PATDL . 93
14 Italy . 100
14.1 Address template in Natural Language Notation . 100
14.2 Address examples . 101
14.3 Address template in PATDL . 103
15 Morocco (French) . 117
15.1 Address template in Natural Language Notation . 117
15.2 Presentation rules . 117
15.3 Address examples . 117
15.4 Address template in PATDL . 118
16 Morocco (Arabic) . 122
16.1 Address template in Natural Language Notation . 122
16.2 Address examples . 123
16.3 Address template in PATDL . 124
17 Netherlands . 128
17.1 General information . 128
17.2 Address template in Natural Language Notation . 128
17.3 Presentation rules . 129
17.4 Address examples . 130
17.5 Address template in PATDL . 131
18 New Zealand . 139
18.1 Address template in Natural Language Notation . 139
18.2 Address examples . 140
18.3 Mapping national elements to standard elements . 142
18.4 Rendition instructions . 142
18.5 Address template in PATDL . 143
19 Portugal . 154
19.1 Address template in Natural Language Notation . 154
19.2 Address examples . 155
19.3 Address template in PATDL . 156
20 South Africa . 165
20.1 Address template in Natural Language Notation . 165
20.2 Address examples . 167
20.3 Address template in PATDL . 168
21 United Kingdom . 176
21.1 General information . 176
21.2 Mapping national elements to standard elements . 177
21.3 Address template in Natural Language Notation . 177
21.4 Presentation rules. 181
21.5 Address examples . 184
21.6 Rendition Instructions . 185
21.7 Address template in PATDL . 187
22 United States of America . 203
22.1 General information . 203
22.2 Address template in Natural Language Notation . 203
22.3 Representation rules . 204
22.4 Address examples . 205
22.5 Mapping national elements to standard elements . 207
22.6 Door types and approved abbreviations . 207
22.7 Preceding and succeeding thoroughfare qualifiers and approved abbreviations . 208
22.8 Rendition instructions . 208
22.9 Address template in PATDL . 209
23 Venezuela . 219
23.1 Address template in Natural Language Notation . 219
23.2 Address examples . 221
23.3 Address template in PATDL . 222

Foreword
This document (CEN/TR 14142-2:2011) has been prepared by Technical Committee CEN/TC 331 “Postal
Services”, the secretariat of which is held by NEN in collaboration with UPU.
NOTE This document has been prepared by experts coming from CEN/TC 331 and UPU, under the framework of the
Memorandum of Understanding between the UPU and CEN.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.
1)
This document (CEN/TR 14142-2:2011), is the CEN equivalent of UPU standard S42-6 Part B. It may be
amended only after prior consultation, between CEN/TC 331 and the UPU Standards Board, in accordance
with the Memorandum of Understanding between CEN and the UPU.
2)
The UPU’s contribution to the document was made, by the UPU Standards Board and its sub-groups, in
accordance with the rules given in Part V of the "General information on UPU standards".
This document is the equivalent to Part B of a two-part UPU Standard, S42: International postal address
components and templates. S42 was originally published as a single part standard covering the definition of
address components and postal address templates with examples, but has been split into two parts in order to
separate the general aspects which apply to all countries and which can be expected to remain stable from
the specific aspects which apply to each country considered in itself and conventions adopted by the working
group which may be modified in the light of further experience.
EN 14142-1:2011 contains the conceptual hierarchy of segments, constructs, elements and element sub-
types, code tables, and the definition of the template languages in order to account for addresses from
countries around the world. CEN/TR 14142-2:2011, this part, contains the specific natural language and XML
templates, rendition instructions, mapping conventions, and presentation guidelines for each country’s
addresses that have been provided to the UPU.

1)
The Universal Postal Union (UPU) is the specialized institution of the United Nations that regulates the universal postal service. The
postal services of its 189 member countries form the largest physical distribution network in the world. Some 5 million postal employees
working in over 660 000 post offices all over the world handle an annual total of 425 billion letters-post items in the domestic service and
almost 6,7 billion in the international service. Some 4,5 billion parcels are sent by post annually. Keeping pace with the changing
communications market, posts are increasingly using new communication and information technologies to move beyond what is
traditionally regarded as their core postal business. They are meeting higher customer expectations with an expanded range of products

and value-added services.
2)
The UPU's Standards Board develops and maintains a growing number of standards to improve the exchange of postal-related
information between posts, and promotes the compatibility of UPU and international postal initiatives. It works closely with posts,
customers, suppliers and other partners, including various international organizations. The Standards Board ensures that coherent
standards are developed in areas such as electronic data interchange (EDI), mail encoding, postal forms and meters. UPU standards are
published in accordance with the rules given in Part VII of the General information on UPU standards, which may be freely downloaded

from the UPU world-wide web site (www.upu.int).
Introduction
The postal service provides letter, package and parcel delivery on a global and universal basis, without the
need for recipients to enter into explicit service contracts. Postal addresses, which combine private recipient
information with publicly known delivery point data, provide the mechanism through which mailers specify
the intended recipient and the means by which the postal operator can fulfil its delivery commitment.
Traditionally, postal operators have been highly flexible with regard to the manner in which postal items can
be addressed: any form and content of address was acceptable as long as it permitted sufficiently
unambiguous determination of the delivery point. Even today, many posts pride themselves on their ability,
using staff intelligence and local demographic knowledge, to deliver postal items carrying incomplete or
unusual address representations.
However, increasing volumes and labour cost rates long ago reached the point at which automation became
not only economic, but essential. As a result, it has become more and more vital to ensure that the vast
majority of postal items are addressed in a way which can be processed automatically, without risk of
misinterpretation.
Today, the vast majority of postal items carry printed addresses which are extracted from computer
databases.
Such databases need to be maintained in the face of population mobility, creation and suppression of delivery
points and changes in their specification such as renaming of streets, renumbering of properties, etc.
Moreover, there is a growing tendency for companies to exchange or trade address data and, in the context of
the European Single Market, for companies in one country to hold address data of organisations and
individuals in other countries, which might use different approaches to the structuring of printed addresses.
In this context, the UPU Postal Operations Council's POST*Code Project Team charged its sub-project team
2 to develop a standard, covering the definition of address components and postal address templates. This
standard, International Postal Address Components and Templates, is the result of this development.
1 Scope
This part of the standard describes the address templates for each country, i.e. the specific way an address is
formatted in each country, indicating in particular the order in which the various elements appear. The address
templates may include rendition instructions, specifying how elements are to be rendered for printing.
EN14142-1:2011 contains material that is not country-specific and is expected to remain stable for a
significant period of time. CEN/TR14142-2:2011 contains the country specific information as well as explaining
mapping conventions and design considerations that are generic in scope but are still evolving and have a
current status rather than a fixed resolution.
What then are the characteristics of the generic material in Part 2? As an example, the definition of (40.17
district) as a postal address element is stable and not country-specific, for example, and thus the definition is
assigned to Part 1. At the same time, some of the uses of (40.17 district) to represent different levels and
positions, while occurring in one or more specific country templates, reflect generic element mapping
conventions and generic template design considerations. These generic conventions and considerations are
explained in Part 2, along with generic rendition instructions used in country templates, together with the
country templates, country-specific rendition instructions, and presentation rules defined by each country.

Terms in bold are defined either in clause 3, Terms and Definitions or clause 5, Postal Address Components.
The Brazilian postcode, for example, is saved in the format 99999999 in a database. However, in an address, the
postcode should be printed in the format 99999–999. The rendition instructions must therefore state that the Brazilian
postcode is printed with a dash between the 5th and 6th digits.
It is expected that Part 2 shall be modified from time to time to add new countries, modify country templates,
and as appropriate, to elaborate upon the element mapping conventions and template design considerations
and to amplify the roster of generic rendition instructions. Notwithstanding the potential for modifications, the
stable content of Part 1, taken together with the current understanding of these generic conventions and
parameters, including the NLT and PATDL templates for those countries represented, is intended when taken
together to comprise a consistent international standard.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
See Part 1 of this standard, EN14142-1:2011.
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN14142-1:2011 apply.
4 Symbols and abbreviations
See Part 1 of this standard, EN14142-1:2011.
5 Element Mapping Conventions and Template Design Considerations
5.1 About Element Mapping Conventions
Element mapping conventions are procedures developed within the CEN/TC331 to use elements, element
sub-types and their associated codes in agreed upon ways to handle various generic or specific situations that
arise when using the standard to develop postal address templates for different countries.
NOTE 1 Element mapping conventions determine how to deploy the roster of element and element sub-types,
particularly in situations where more than one alternative mapping is feasible.
NOTE 2 Element mapping conventions may help to determine how various address types, particularly those which are
distinctive or unusual, can be mapped while using the standardized elements and element sub-types.
NOTE 3 Element mapping conventions may help to determine how complex a branching structure within a template,
and in turn the entire structure of the template, needs to be to represent a set of addresses, and when it can be simplified.
5.2 Element Mapping Conventions
5.2.1 Basic Rule Regarding Addressee
By convention, each address as presented on a mail piece should have at most one logical addressee.
NOTE 1 If the mail piece is addressed to a person, the person is the addressee, and if to a company, the company is
the addressee. If it is addressed to two or more persons, they are jointly the addressee. There are then two physical
addressees but only one logical addressee. If it is addressed to a person at a company, the person is the addressee and
the company is the mailee, implicitly if not explicitly. Through the concept of an implicit mailee the precision of the
identification of the addressee is protected.
NOTE 2 In some countries, such as the United States, it is not customary to think of a mailee being present in an
address unless there is an explicit mailee role descriptor. There is an explicit mailee if the mail piece is addressed to one
party “in care of” a second party. In that case the second party is the mailee. It may be that in some countries, such as
developing countries with limited complexity in their address structure, even the explicit mailee is not recognized.
NOTE 3 Mail without an addressee is possible in many countries. This case is supported in this standard and can be
represented in address templates.
5.2.2 No Mailee Without Addressee
By convention, there can be no mailee without an addressee.
NOTE 1 The mailee has responsibility for assuring that the mail piece reaches the addressee, and in that sense the
mailee requires an addressee.
NOTE 2 Using this convention, and the basic rule regarding the addressee, it is possible to define which combinations
of addressee and mailee are supported in this standard. See 5.4 under Template Design Considerations.
5.2.3 Mailee Not Both Preceding and Succeeding
By convention, mailee information may either precede or follow the addressee, but not both at the same time.
NOTE 1 The preceding analysis implies that certain combinations of name and address elements are to be regarded
as invalid, or at least unsupported within the standard. The convention has been discussed that the addressee can be an
individual or an organisation but not both at the same time. Furthermore, there should not be a mailee without an
addressee. It is also expected that a mailee organisation can either precede or follow an individual addressee, but not both
at the same time. This simplifies template design for the addressee and mailee.
NOTE 2 In the process of designing templates, the focus has been on specifying the valid alternatives, not on
evaluating all possible combinations and then eliminating any that are not considered valid. However, the fact that some
combinations are invalid or unsupported should be taken into account by implementers of the standard. They will need to
decide on a case by case basis how best to handle the unsupported cases, either by discarding inputs that are considered
superfluous, or by allowing them to pass through the templates, or by processing them through customized template
extensions. In any event, a PATDL implementation should be capable of issuing warnings in such cases.
5.2.4 Indirect Identification of Addressee and Mailee
By convention, an addressee or mailee may be identified by name, or by title without a name, or by
organisational component, or by organisation name, or by a form of address.
NOTE 1 The title is located within the element hierarchy as part of the organisation information. However, as an
alternate way of designating an individual whose name one may not know, it is a form of individual addressee. Therefore
in the templates, and in the common initial section, title is associated in the same choice group with name elements rather
than with organisation elements. Though there has been some dialogue about whether there can be a title without an
organisation, there is no doubt that the title may be known and the associated organisational information not known.
NOTE 2 An addressee can be identified indirectly by a form of address such as “Postal Customer” or where
appropriate, not identified at all in the case of unaddressed mail.
5.2.5 Granularity Constraints
By convention, within a template, if a particular element is deployed, element sub-types of that element are
ineligible for use in that template, while if any of its element sub-types are deployed, an element is ineligible
for use in that template. This is a template level granularity constraint. Suppose that for each address
processed with the template, if an occurrence of a particular element is included in the rendition, its element
sub-types are not included in that rendition, while if any of its element sub-types are included in the rendition,
the corresponding occurrence of the element is not included in the rendition. This is an address level
granularity constraint.
NOTE 1 All CEN/TR4142-2 country templates have a template level granularity constraint.
NOTE 2 Under the template level granularity constraint, it is not correct to use (40.17) in one part of a template and
then decide to add (40.17-1-0) in another part. After all, (40.17-1-0) may have a specific meaning, rather than just being a
way to differentiate two placeholders for information items. The first instance may represent a preceding position, or a
primary level, or a specific representation. The first part may represent a type as opposed to an indicator. It is necessary to
take note of this in the context of implementation by matching levels of granularity when linking database cells to the
template.
NOTE 3 Situations may arise in implementation of this standard in which varying levels of granularity may be found
within an address dataset. If for some reason this situation is not resolved by further parsing an element or by combining
its element sub-types, it may be handled by a template modified to follow an address level granularity constraint. For
example, the template could branch between using an element and using its sub-types based on testing the content of the
element. In this situation, each address has its own granularity constraint, but at different levels of granularity for different
addresses.
NOTE 4 In implementation of this standard, if the element is treated as a programming object, there could be data
available upon request that can be accessed at both the element and element sub-type levels. If this flexibility could be
counted upon, so that requests can be handled flawlessly at the element or element sub-type level, then neither form of
granularity constraint may be needed.
NOTE 5 A postal service may have a limited amount of granularity in its database storage and identification of
elements in tables and columns. This may be because of a design that is not element based. It may be present even when
the design is element based, if the storing of constructs and complex combinations of elements saves on storage space or
combines sparse elements with more frequently occurring elements. In this event, the implementer of this standard may
define more granularity in deploying elements and element sub-types in a template then the underlying postal data
recognizes. This capability should be employed with discretion, however, since there may be complex parsing required to
fill the elements in the application database from the postal database. Notwithstanding this cautionary statement, this
additional effort is generally appropriate when the increased granularity provides for using elements and element sub-
types recognized in this standard.
NOTE 6 In the US, Main and Street are stored in separate fields, but Calle and Ortega are stored in the same field,
which generally stores the thoroughfare name. That is because Street is considered as a succeeding thoroughfare
qualifier, while there is no field for a preceding thoroughfare qualifier. In general it is appropriate for an application to store
the information the same way as it is stored in the postal database, although in this case that storage method is not
completely consistent with respect to the CEN/TR14142-2 elements. It would be consistent to store both Main Street and
Calle Ortega in (40.21 thoroughfare), though that would mean that two fields in the USPS database would have to be
combined to cover the case of Main Street. It would be consistent and appropriate to use three element sub-types for this
case and store Calle in (40.21-1-3 preceding thoroughfare qualifier) and Street in (40.21-2-3 succeeding thoroughfare
qualifier) while Main or Ortega is found in (40.21-1-1 thoroughfare name). That is how the USPS template is written.
NOTE 7 Some thoroughfare constructs have connecting words between the thoroughfare type and the root of the
thoroughfare name. An example is Rue de la Paix. In different countries, these are stored in postal databases in at least
three ways. In one case, “Rue” is stored as a thoroughfare type and “de la Paix” as the thoroughfare name. In a second
case, “Rue de la” is the thoroughfare type, and “Paix” is the thoroughfare name. In a third case, “Rue” is the thoroughfare
type, “Paix” is the thoroughfare name, and “de la” is stored in a separate field. The CEN/TR14142-2 element mapping
conventions do not prescribe a common approach to these situations, and yet it is appropriate for an application to store
the data in the way it is stored in postal databases, which would in this situation lead to different approaches for the
different countries. Therefore CEN/TR14142-2 includes the element sub-type “thoroughfare name prefix”, which in
combination with the other element sub-types for thoroughfare allows support for all three of the above alternatives.
5.2.6 Cross Reference Addresses
Cross reference addresses identify a delivery point by the intersection of two or more axes in a manner that
may not uniquely specify the delivery point.
By convention, cross reference addresses are mapped as supplementary delivery point data.
NOTE 1 Consider the hypothetical addresses “Third and Main” or “Calle 4 y Avenida 7”, which refer to the intersection
of two or more streets. This type of address may be considered inexact because it typically does not reference a delivery
point in a unique manner. There could be several delivery points at the intersection of Calle 4 and Avenida 7, and they
may not necessarily all have the same postcode.
NOTE 2 A more complex case including this feature can be found in Costa Rica, where there is a hybrid of a street
address and a cross street address. In the case from Costa Rica, the address line is “Calle 1 Ave 3 y 4 Casa 23”. This
contains a delivery point that may be uniquely specified, namely “Calle 1 Casa 23”. However, the question remains as to
how to map the additional information conveyed by “Ave 3 y 4”, which may be either supplementary or perhaps essential if
there are other streets nearby called “Calle 1”.
NOTE 3 This convention implies that it is not required to carry this sort of information in a separate element with its own
specific meaning, such as “cross reference information”, as part of a definition of standardized postal addresses. Defining
this data as supplementary is based on the belief that a standardized address structure should uniquely identify delivery
points. Cross reference information is very useful from time to time as part of a postal address. It enables a carrier or other
party to approach closer and closer to an address, and then see the del
...