欢迎来到麦多课文档分享! | 帮助中心 海量文档,免费浏览,给你所需,享你所想!
麦多课文档分享
全部分类
  • 标准规范>
  • 教学课件>
  • 考试资料>
  • 办公文档>
  • 学术论文>
  • 行业资料>
  • 易语言源码>
  • ImageVerifierCode 换一换
    首页 麦多课文档分享 > 资源分类 > PDF文档下载
    分享到微信 分享到微博 分享到QQ空间

    CEN TS 15873-2009 Postal Services - Open Standard Interface - Address Data File Format for OCR VCS Dictionary Generation《邮电业 开放标准接口 OCR VCS词典生成用地址数据文件格式》.pdf

    • 资源ID:592588       资源大小:935.77KB        全文页数:30页
    • 资源格式: PDF        下载积分:10000积分
    快捷下载 游客一键下载
    账号登录下载
    微信登录下载
    二维码
    微信扫一扫登录
    下载资源需要10000积分(如需开发票,请勿充值!)
    邮箱/手机:
    温馨提示:
    如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
    如需开发票,请勿充值!如填写123,账号就是123,密码也是123。
    支付方式: 支付宝扫码支付    微信扫码支付   
    验证码:   换一换

    加入VIP,交流精品资源
     
    账号:
    密码:
    验证码:   换一换
      忘记密码?
        
    友情提示
    2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
    3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
    4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。
    5、试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。

    CEN TS 15873-2009 Postal Services - Open Standard Interface - Address Data File Format for OCR VCS Dictionary Generation《邮电业 开放标准接口 OCR VCS词典生成用地址数据文件格式》.pdf

    1、DD CEN/TS15873:2009ICS 03.240; 35.240.60NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAWDRAFT FOR DEVELOPMENTPostal Services OpenStandard Interface Address Data FileFormat for OCR/VCSDictionary GenerationThis Draft for Developmentwas published under theauthority of the Standard

    2、sPolicy and StrategyCommittee on 31 January2010 BSI 2010ISBN 978 0 580 64241 8Amendments/corrigenda issued since publicationDate CommentsDD CEN/TS 15873:2009National forewordThis Draft for Development is the UK implementation of CEN/TS15873:2009.This publication is not to be regarded as a British St

    3、andard.It is being issued in the Draft for Development series of publications andis of a provisional nature. It should be applied on this provisional basis,so that information and experience of its practical application can beobtained.Comments arising from the use of this Draft for Development arere

    4、quested so that UK experience can be reported to the internationalorganization responsible for its conversion to an international standard.A review of this publication will be initiated not later than 3 years afterits publication by the international organization so that a decision can betaken on it

    5、s status. Notification of the start of the review period will bemade in an announcement in the appropriate issue of Update Standards.According to the replies received by the end of the review period,the responsible BSI Committee will decide whether to support theconversion into an international Stan

    6、dard, to extend the life of theTechnical Specification or to withdraw it. Comments should be sent tothe Secretary of the responsible BSI Technical Committee at BritishStandards House, 389 Chiswick High Road, London W4 4AL.The UK participation in its preparation was entrusted to TechnicalCommittee SV

    7、S/4, Postal services.A list of organizations represented on this committee can be obtained onrequest to its secretary.This publication does not purport to include all the necessary provisionsof a contract. Users are responsible for its correct application.Compliance with a British Standard cannot co

    8、nfer immunityfrom legal obligations.DD CEN/TS 15873:2009TECHNICAL SPECIFICATIONSPCIFICATION TECHNIQUETECHNISCHE SPEZIFIKATIONCEN/TS 15873March 2009ICS 03.240; 35.240.60English VersionPostal Services - Open Standard Interface - Address Data FileFormat for OCR/VCS Dictionary GenerationServices postaux

    9、 - Interface de standard ouvert - Format defichiers de donnes dadresses pour la gnration dudictionnaire OCR/VCSPostalische Dienstleistungen - Offene Normschnittstelle -Adressdateiformat fr die Generierung von Wrterbchernin OCR/Videocodier-SystemenThis Technical Specification (CEN/TS) was approved by

    10、 CEN on 1 March 2009 for provisional application.The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit theircomments, particularly on the question whether the CEN/TS can be converted into a European Standard.CEN memb

    11、ers are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS availablepromptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)until the final decision about the po

    12、ssible conversion of the CEN/TS into an EN is reached.CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland,France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, P

    13、oland, Portugal,Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.EUROPEAN COMMITTEE FOR STANDARDIZATIONCOMIT EUROPEN DE NORMALISATIONEUROPISCHES KOMITEE FR NORMUNGManagement Centre: Avenue Marnix 17, B-1000 Brussels 2009 CEN All rights of exploitation in any form and by any

    14、 means reservedworldwide for CEN national Members.Ref. No. CEN/TS 15873:2009: EDD CEN/TS 15873:2009CEN/TS 15873:2009 (E) 2 Contents Page Foreword 31 Introduction 42 Scope and purpose52.1 Scope 52.2 Purpose .53 Related Standards .73.1 UPU S42 74 Symbols and Abbreviations .75 XML Schema adressTree 85.

    15、1 , and 95.2 Address Tree in , and .95.3 Attributes for , and 115.4 String parts in , and . 115.5 Ranges in , and 125.6 Aliases in , and . 135.7 other XML files 145.8 Linking addresses via 155.9 Project specific part of the XML schema . 166 XML Schema addressDeltaTree 186.1 Joining deltas via and fi

    16、le names 196.2 Update actions , and . 197 Miscellaneous . 21Annex A 22A.1 General XML Schema part . 22A.2 Example for a project specific XML Schema part . 24A.3 Initial addressTree Example 25A.4 Update addressDeltaTree Example. 26A.5 Updated addressTree Example . 27DD CEN/TS 15873:2009CEN/TS 15873:2

    17、009 (E) 3 Foreword This document (CEN/TS 15873:2009) has been prepared by Technical Committee CEN/TC 331 “Postal Services”, the secretariat of which is held by NEN. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CEN and/or CENELE

    18、C shall not be held responsible for identifying any or all such patent rights. According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria, Cyprus, Czech Republic, De

    19、nmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and the United Kingdom. NOTE This document has been prepared by experts from CEN/TC

    20、 331 and UPU, in the framework of the Memorandum of Understanding between UPU and CEN. DD CEN/TS 15873:2009CEN/TS 15873:2009 (E) 4 1 Introduction In initial meetings of CEN/TC331/WG3 interfaces which will benefit from standardization have been identified and agreed on. Candidates for Open Interface

    21、standardization are: interface between the image handler and automatic address readers or video coding places; interface from machine control to Barcode Printers; interface from machine control to Barcode Reader / Verifier; interface between scanner, image handler and machine control; file format of

    22、 Sort Plan; MIS Interface (Statistics); file format of Address data files. The new intended standard deals with the file format of Address Data Files. OCR results and video coder inputs have to be verified against the “real” existing addresses in order to reach high recognition rates combined with l

    23、ow error rates. For that purpose postal operators provide postal address directories to the OCR/VCS suppliers. Usually different postal operators use different file formats for these (source) directories. In typical postal automation systems these files will be processed by directory generation soft

    24、ware which creates application specific loadable data. This data usually referred to as “operational directory” is heavily compressed and contains access tables tailored for the specific reading software. Usually different OCR/VCS suppliers use different operational directory formats. This standard

    25、shall define a common Address Data File format for postal address directories to be provided from the postal operators to the OCR/VCS suppliers. This Address Data File format shall be designed to hold all information necessary to support address reading and video coding software including data requi

    26、red for special recognition tasks e.g. forwarding applications. DD CEN/TS 15873:2009CEN/TS 15873:2009 (E) 5 2 Scope and purpose 2.1 Scope This document defines a file format for the generation of postal address directories. It is designed to hold all information necessary to support address reading

    27、software including data required for forwarding applications. In typical postal automation systems these files will be processed by directory generation software which creates application specific loadable data. This data usually referred to as operational directory is heavily compressed and contain

    28、s access tables tailored for the specific reading software. Not in the scope of this document are topics external to file like compression, checksums, the interface for transmission to the supplier, modification permissions, error handling on inconsistent data and undo in updates. 2.2 Purpose The fo

    29、rmat has been designed with the following requirements in mind: must be able to hold the following data: addresses composed of address components (including aliases and range-data); person and organization names; address codes typically used as sort codes; links between addresses e.g. for use in for

    30、warding; should not restrict character encoding; easily customizable for specific applications; should allow complete as well as incremental updates, i.e. change-only data; it must be possible to split data in multiple files for better handling. The ideas behind this format are as follows: The forma

    31、t is based on XML. The basic XML structure is general. Project(the term project is used throughout this document to describe a specific application such as address data for a specific country or postal organization) specifics are coded as attributes. This should make it easier to build project indep

    32、endent parsers and tools. Address data can be structured hierarchically. An address component appearing in a lot of addresses shall be written once as parent node in all addresses it is used in the XML address tree. Beyond the pure address data, there are general as well as optional project specific

    33、 attributes on the level of address components and string parts. In favour of faster parser execution and smaller file sizes the names of XML elements appearing very often are short strings. DD CEN/TS 15873:2009CEN/TS 15873:2009 (E) 6 Semantics are defined only in a basic manner and have to be compl

    34、eted in the project specific tailoring process. E.g. a street without numbers in the data may be interpreted as a street which has no numbers, or where all numbers are valid. Due to this users must be aware that the interoperability of this Technical Specification may be limited to be applied to the

    35、 specific project. DD CEN/TS 15873:2009CEN/TS 15873:2009 (E) 7 3 Related Standards 3.1 UPU S42 1) UPU S42 is beginning with version -5 a two part standard. Part a contains concepts and the theoretical language description. Part b contains practical examples from different countries and may be supple

    36、mented with new examples in some future. 2) UPU S42a defines components an address is composed of as well as postal entities which can be “described” using these address components. The standard goes into great detail in defining a globally usable set of specific address components such as “postcode

    37、”, “door”, . 3) UPU S42b describes how to write an address given its constituting address components. It uses templates to describe the order, line-breaks, etc. The templates are country specific (US, Brazil, England, .) and also uses an country specific subset of the globally defined types. 4) UPU

    38、S42 address components are assumed to have a type and a string. They do not have additional attributes and do not have aliases. 5) UPU S42 does not define a format for an individual address = address-component collection and does not define a format for an address directory = set of addresses. 6) UP

    39、U S42 has no concept of sort codes or forwarding information. UPU S42 will not conflict with the format defined in this document as it targets at a completely different application and type of information described. The only thing in common with address data are the address-component definitions the

    40、mselves. These could be used in customizing the ADF for a specific project. UPU S42s excellent glossary should be reused where applicable. 4 Symbols and Abbreviations XML eXtended Markup Language ADF Address Data File DD CEN/TS 15873:2009CEN/TS 15873:2009 (E) 8 5 XML Schema adressTree The syntax is

    41、described as an XML schema, divided into a general and a project specific part. The general part of the XML Schema defines the basic structures. It uses some types and attribute groups to be defined in the project specific part. Basically the structure spans a tree of address components represented

    42、by XML elements . The general part of the schema is listed in section A.1A.1. The project specific part is explained in section 5.9. This document contains also another XML Schema addressDeltaTree explained in chapter 6. The following Figure 1 shows the general structure of the XML schema. Since the

    43、 project specific part does not change the general structure the diagram is independent from any project specifics. Figure 1 General data structure of the XML schema DD CEN/TS 15873:2009CEN/TS 15873:2009 (E) 9 5.1 , and Below the XML root element is one and one section. The stores a string and optio

    44、nally a list of global aliases. Aliases are described in section 5.6. A version string of the data contained in the file is stored in the element. 5.2 Address Tree in , and Addresses are stored in an address tree corresponding to the XML elements , and . is the root node of this tree, address compon

    45、ents stored in are the nodes and may be additional leafs. Explanation on the element follows in section 5.8. One complete address corresponds to one leafs root path. Each nodes root path identifies a partial address. Other XML elements and attributes carry additional information for the address tree

    46、 node. allows to split data into multiple files. One address component in XML element holds a type mentioned in attribute tp and a string in child elements or and . Attribute tp and other optional attributes for are described in section 5.3. Other optional child elements are described in the followi

    47、ng sections. In this context one address component holds just a name with a type and does not necessarily describe a real thing or place. Also abstract data like delivery point codes, sort codes or else may be stored in address components represented as XML elements . Example: Some addresses in vari

    48、ous formats: In a table: Country City Street HNr GERMANY BERLIN GERMANY KONSTANZ BUECKLESTR 1 GERMANY KONSTANZ BUECKLESTR 2 GERMANY KONSTANZ BUECKLESTR 3 GERMANY KONSTANZ BUECKLESTR 4 As address tree: Figure 2 Addresses formatted as an address tree Country GERMANYCity BERLIN City KONSTANZStreet BUEC

    49、KLESTRHNr 1HNr 2HNr 3HNr 4 DD CEN/TS 15873:2009CEN/TS 15873:2009 (E) 10 Address tree representation in XML: 0 GERMANY BERLIN KONSTANZ BUECKLESTR 1 2 3 4 The following verbose XML representation of this example is more like the address table. Each address is written as a child path of the element. Both XML representations are equivalent. Usage of the short form as shown above is strongly recommended, due to less file size overhead and less risk of dupl


    注意事项

    本文(CEN TS 15873-2009 Postal Services - Open Standard Interface - Address Data File Format for OCR VCS Dictionary Generation《邮电业 开放标准接口 OCR VCS词典生成用地址数据文件格式》.pdf)为本站会员(吴艺期)主动上传,麦多课文档分享仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文档分享(点击联系客服),我们立即给予删除!




    关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

    copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
    备案/许可证编号:苏ICP备17064731号-1 

    收起
    展开