postal_address.proto 6.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134
  1. // Copyright 2021 Google LLC
  2. //
  3. // Licensed under the Apache License, Version 2.0 (the "License");
  4. // you may not use this file except in compliance with the License.
  5. // You may obtain a copy of the License at
  6. //
  7. // http://www.apache.org/licenses/LICENSE-2.0
  8. //
  9. // Unless required by applicable law or agreed to in writing, software
  10. // distributed under the License is distributed on an "AS IS" BASIS,
  11. // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  12. // See the License for the specific language governing permissions and
  13. // limitations under the License.
  14. syntax = "proto3";
  15. package google.type;
  16. option cc_enable_arenas = true;
  17. option go_package = "google.golang.org/genproto/googleapis/type/postaladdress;postaladdress";
  18. option java_multiple_files = true;
  19. option java_outer_classname = "PostalAddressProto";
  20. option java_package = "com.google.type";
  21. option objc_class_prefix = "GTP";
  22. // Represents a postal address, e.g. for postal delivery or payments addresses.
  23. // Given a postal address, a postal service can deliver items to a premise, P.O.
  24. // Box or similar.
  25. // It is not intended to model geographical locations (roads, towns,
  26. // mountains).
  27. //
  28. // In typical usage an address would be created via user input or from importing
  29. // existing data, depending on the type of process.
  30. //
  31. // Advice on address input / editing:
  32. // - Use an i18n-ready address widget such as
  33. // https://github.com/google/libaddressinput)
  34. // - Users should not be presented with UI elements for input or editing of
  35. // fields outside countries where that field is used.
  36. //
  37. // For more guidance on how to use this schema, please see:
  38. // https://support.google.com/business/answer/6397478
  39. message PostalAddress {
  40. // The schema revision of the `PostalAddress`. This must be set to 0, which is
  41. // the latest revision.
  42. //
  43. // All new revisions **must** be backward compatible with old revisions.
  44. int32 revision = 1;
  45. // Required. CLDR region code of the country/region of the address. This
  46. // is never inferred and it is up to the user to ensure the value is
  47. // correct. See http://cldr.unicode.org/ and
  48. // http://www.unicode.org/cldr/charts/30/supplemental/territory_information.html
  49. // for details. Example: "CH" for Switzerland.
  50. string region_code = 2;
  51. // Optional. BCP-47 language code of the contents of this address (if
  52. // known). This is often the UI language of the input form or is expected
  53. // to match one of the languages used in the address' country/region, or their
  54. // transliterated equivalents.
  55. // This can affect formatting in certain countries, but is not critical
  56. // to the correctness of the data and will never affect any validation or
  57. // other non-formatting related operations.
  58. //
  59. // If this value is not known, it should be omitted (rather than specifying a
  60. // possibly incorrect default).
  61. //
  62. // Examples: "zh-Hant", "ja", "ja-Latn", "en".
  63. string language_code = 3;
  64. // Optional. Postal code of the address. Not all countries use or require
  65. // postal codes to be present, but where they are used, they may trigger
  66. // additional validation with other parts of the address (e.g. state/zip
  67. // validation in the U.S.A.).
  68. string postal_code = 4;
  69. // Optional. Additional, country-specific, sorting code. This is not used
  70. // in most regions. Where it is used, the value is either a string like
  71. // "CEDEX", optionally followed by a number (e.g. "CEDEX 7"), or just a number
  72. // alone, representing the "sector code" (Jamaica), "delivery area indicator"
  73. // (Malawi) or "post office indicator" (e.g. Côte d'Ivoire).
  74. string sorting_code = 5;
  75. // Optional. Highest administrative subdivision which is used for postal
  76. // addresses of a country or region.
  77. // For example, this can be a state, a province, an oblast, or a prefecture.
  78. // Specifically, for Spain this is the province and not the autonomous
  79. // community (e.g. "Barcelona" and not "Catalonia").
  80. // Many countries don't use an administrative area in postal addresses. E.g.
  81. // in Switzerland this should be left unpopulated.
  82. string administrative_area = 6;
  83. // Optional. Generally refers to the city/town portion of the address.
  84. // Examples: US city, IT comune, UK post town.
  85. // In regions of the world where localities are not well defined or do not fit
  86. // into this structure well, leave locality empty and use address_lines.
  87. string locality = 7;
  88. // Optional. Sublocality of the address.
  89. // For example, this can be neighborhoods, boroughs, districts.
  90. string sublocality = 8;
  91. // Unstructured address lines describing the lower levels of an address.
  92. //
  93. // Because values in address_lines do not have type information and may
  94. // sometimes contain multiple values in a single field (e.g.
  95. // "Austin, TX"), it is important that the line order is clear. The order of
  96. // address lines should be "envelope order" for the country/region of the
  97. // address. In places where this can vary (e.g. Japan), address_language is
  98. // used to make it explicit (e.g. "ja" for large-to-small ordering and
  99. // "ja-Latn" or "en" for small-to-large). This way, the most specific line of
  100. // an address can be selected based on the language.
  101. //
  102. // The minimum permitted structural representation of an address consists
  103. // of a region_code with all remaining information placed in the
  104. // address_lines. It would be possible to format such an address very
  105. // approximately without geocoding, but no semantic reasoning could be
  106. // made about any of the address components until it was at least
  107. // partially resolved.
  108. //
  109. // Creating an address only containing a region_code and address_lines, and
  110. // then geocoding is the recommended way to handle completely unstructured
  111. // addresses (as opposed to guessing which parts of the address should be
  112. // localities or administrative areas).
  113. repeated string address_lines = 9;
  114. // Optional. The recipient at the address.
  115. // This field may, under certain circumstances, contain multiline information.
  116. // For example, it might contain "care of" information.
  117. repeated string recipients = 10;
  118. // Optional. The name of the organization at the address.
  119. string organization = 11;
  120. }