/*
 * Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
 * in compliance with the License. You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software distributed under the License
 * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express
 * or implied. See the License for the specific language governing permissions and limitations under
 * the License.
 */
/*
 * This code was generated by https://github.com/googleapis/google-api-java-client-services/
 * Modify at your own risk.
 */

package com.google.api.services.contentwarehouse.v1.model;

/**
 * This class represents a parsed field within an address. NOTE: if you add a field to this proto,
 * please update the AreAddressComponentsEquivalent() function in
 * google3/geostore/base/internal/addresscomponent.cc
 *
 * <p> This is the Java data model class that specifies how to parse/serialize into the JSON that is
 * transmitted over HTTP when working with the Document AI Warehouse API. For a detailed explanation
 * see:
 * <a href="https://developers.google.com/api-client-library/java/google-http-java-client/json">https://developers.google.com/api-client-library/java/google-http-java-client/json</a>
 * </p>
 *
 * @author Google, Inc.
 */
@SuppressWarnings("javadoc")
public final class GeostoreAddressComponentProto extends com.google.api.client.json.GenericJson {

  /**
   * The id of the corresponding Feature, if such a feature is defined. As discussed above for
   * feature_type, components of TYPE_FEATURE or TYPE_LANDMARK may have a corresponding feature id.
   * The value may be {@code null}.
   */
  @com.google.api.client.util.Key
  private GeostoreFeatureIdProto featureId;

  /**
   * For components of TYPE_FEATURE or TYPE_LANDMARK, this is the feature type (TYPE_COUNTRY,
   * TYPE_LOCALITY, TYPE_ESTABLISHMENT_POI etc.). Note that some features may not actually exist in
   * the geostore (e.g. a village that we've never heard of), in which case the feature_id will be
   * missing but the feature_type is still specified. Please refer to
   * IsValidAddressComponentFeatureType() in google3/geostore/base/public/addresscomponent.h for the
   * definitive list of feature types allowed for the type (either TYPE_FEATURE or TYPE_LANDMARK) of
   * components.
   * The value may be {@code null}.
   */
  @com.google.api.client.util.Key
  private java.lang.Integer featureType;

  /**
   * The order of this address component relative to the ones that share the same feature_type in
   * the AddressProto. For now, the primary use of this index field is to handle ordering issue of
   * multiple occurrences of AddressComponentProto with feature_type of TYPE_ROUTE (and subtypes),
   * or TYPE_POLITICAL, where the order of the address components matters as there are dependences.
   * 0 is the smallest valid index value, representing the most specific address component. Index
   * value of 1 represents a relatively less specific address component of the same feature_type on
   * which the 0-indexed address component depends.
   * The value may be {@code null}.
   */
  @com.google.api.client.util.Key
  private java.lang.Integer index;

  /**
   * The parsed_name field contains one or more names of an address component. Its actual contents
   * depends on where in the Geo/Google stack you are reading a feature: 1. When an address is
   * initially parsed via a feed or other raw input and structured as an AddressProto, parsed_name
   * should contain the set of names that corresponds to the (possibly normalized) raw text from the
   * raw input. 2. In MapFacts, the address component may be linked to an actual feature via
   * feature_id. Any address formatting directly from MapFacts should follow links to retrieve names
   * when possible. The parsed_name contents may be formatted directly if the address component is
   * unlinked following the same rules as selecting and formatting the name of a feature. The cached
   * parsed_name is regularly refreshed from the linked feature with the minimal set of names for
   * address components (usually just a single, preferred name, in the local language, plus a Latin-
   * script name: go/story-of-ac-names). 3. In serving systems, the names of linked features may be
   * denormalized into the parsed_name field to facilitate quicker address formatting or for simple
   * data filtering (e.g. finding all geocodes in California by name). If reading a feature from
   * such a system, the parsed_name field could contain multiple names in multiple languages that
   * reflect a cached copy of the names associated with the linked features. Formatting of such
   * names should follow the same rules as selecting and formatting the name of a feature itself.
   * The value may be {@code null}.
   */
  @com.google.api.client.util.Key
  private java.util.List<GeostoreNameProto> parsedName;

  /**
   * Any numerical address component may optionally be specified as a range. For example if a
   * component of TYPE_STREET_NUMBER has the optional "range" attribute, then it represents a range
   * of addresses rather than a single address (see AddressRangeProto for details).
   * The value may be {@code null}.
   */
  @com.google.api.client.util.Key
  private GeostoreAddressRangeProto range;

  /**
   * A place for clients to attach arbitrary data to an address component. Never set in MapFacts.
   * The value may be {@code null}.
   */
  @com.google.api.client.util.Key
  private Proto2BridgeMessageSet temporaryData;

  /**
   * Additional text to append before and/or after the parsed_name, when the address is formatted.
   * Multiple instance should represent translations. Currently, this is only permitted on
   * TYPE_LANDMARK components, and only one instance is permitted.
   * The value may be {@code null}.
   */
  @com.google.api.client.util.Key
  private java.util.List<GeostoreTextAffixProto> textAffix;

  /**
   * Every address component has a type. Most address components correspond to one of the feature
   * types defined in FeatureProto, so rather than defining a separate category system here, instead
   * we mark them as TYPE_FEATURE and store the FeatureProto type in the feature_type() field. This
   * is how we handle countries, cities, streets, etc. However, there are a few types of address
   * components that do not have a corresponding feature type (e.g. PO boxes). These components have
   * their type defined here. An address component of TYPE_STREET_NUMBER may correspond to a
   * physical entity that defines a street number, such as a geocoded address or a land parcel. In
   * this case, the address component may have a link to the corresponding feature. A good reference
   * for what types of address components are possible is the xAL standard, which is a published XML
   * schema: http://www.oasis-open.org/committees/ciq/download.shtml. This standard is the basis of
   * the PostalAddress protocol message.
   * The value may be {@code null}.
   */
  @com.google.api.client.util.Key
  private java.lang.String type;

  /**
   * The id of the corresponding Feature, if such a feature is defined. As discussed above for
   * feature_type, components of TYPE_FEATURE or TYPE_LANDMARK may have a corresponding feature id.
   * @return value or {@code null} for none
   */
  public GeostoreFeatureIdProto getFeatureId() {
    return featureId;
  }

  /**
   * The id of the corresponding Feature, if such a feature is defined. As discussed above for
   * feature_type, components of TYPE_FEATURE or TYPE_LANDMARK may have a corresponding feature id.
   * @param featureId featureId or {@code null} for none
   */
  public GeostoreAddressComponentProto setFeatureId(GeostoreFeatureIdProto featureId) {
    this.featureId = featureId;
    return this;
  }

  /**
   * For components of TYPE_FEATURE or TYPE_LANDMARK, this is the feature type (TYPE_COUNTRY,
   * TYPE_LOCALITY, TYPE_ESTABLISHMENT_POI etc.). Note that some features may not actually exist in
   * the geostore (e.g. a village that we've never heard of), in which case the feature_id will be
   * missing but the feature_type is still specified. Please refer to
   * IsValidAddressComponentFeatureType() in google3/geostore/base/public/addresscomponent.h for the
   * definitive list of feature types allowed for the type (either TYPE_FEATURE or TYPE_LANDMARK) of
   * components.
   * @return value or {@code null} for none
   */
  public java.lang.Integer getFeatureType() {
    return featureType;
  }

  /**
   * For components of TYPE_FEATURE or TYPE_LANDMARK, this is the feature type (TYPE_COUNTRY,
   * TYPE_LOCALITY, TYPE_ESTABLISHMENT_POI etc.). Note that some features may not actually exist in
   * the geostore (e.g. a village that we've never heard of), in which case the feature_id will be
   * missing but the feature_type is still specified. Please refer to
   * IsValidAddressComponentFeatureType() in google3/geostore/base/public/addresscomponent.h for the
   * definitive list of feature types allowed for the type (either TYPE_FEATURE or TYPE_LANDMARK) of
   * components.
   * @param featureType featureType or {@code null} for none
   */
  public GeostoreAddressComponentProto setFeatureType(java.lang.Integer featureType) {
    this.featureType = featureType;
    return this;
  }

  /**
   * The order of this address component relative to the ones that share the same feature_type in
   * the AddressProto. For now, the primary use of this index field is to handle ordering issue of
   * multiple occurrences of AddressComponentProto with feature_type of TYPE_ROUTE (and subtypes),
   * or TYPE_POLITICAL, where the order of the address components matters as there are dependences.
   * 0 is the smallest valid index value, representing the most specific address component. Index
   * value of 1 represents a relatively less specific address component of the same feature_type on
   * which the 0-indexed address component depends.
   * @return value or {@code null} for none
   */
  public java.lang.Integer getIndex() {
    return index;
  }

  /**
   * The order of this address component relative to the ones that share the same feature_type in
   * the AddressProto. For now, the primary use of this index field is to handle ordering issue of
   * multiple occurrences of AddressComponentProto with feature_type of TYPE_ROUTE (and subtypes),
   * or TYPE_POLITICAL, where the order of the address components matters as there are dependences.
   * 0 is the smallest valid index value, representing the most specific address component. Index
   * value of 1 represents a relatively less specific address component of the same feature_type on
   * which the 0-indexed address component depends.
   * @param index index or {@code null} for none
   */
  public GeostoreAddressComponentProto setIndex(java.lang.Integer index) {
    this.index = index;
    return this;
  }

  /**
   * The parsed_name field contains one or more names of an address component. Its actual contents
   * depends on where in the Geo/Google stack you are reading a feature: 1. When an address is
   * initially parsed via a feed or other raw input and structured as an AddressProto, parsed_name
   * should contain the set of names that corresponds to the (possibly normalized) raw text from the
   * raw input. 2. In MapFacts, the address component may be linked to an actual feature via
   * feature_id. Any address formatting directly from MapFacts should follow links to retrieve names
   * when possible. The parsed_name contents may be formatted directly if the address component is
   * unlinked following the same rules as selecting and formatting the name of a feature. The cached
   * parsed_name is regularly refreshed from the linked feature with the minimal set of names for
   * address components (usually just a single, preferred name, in the local language, plus a Latin-
   * script name: go/story-of-ac-names). 3. In serving systems, the names of linked features may be
   * denormalized into the parsed_name field to facilitate quicker address formatting or for simple
   * data filtering (e.g. finding all geocodes in California by name). If reading a feature from
   * such a system, the parsed_name field could contain multiple names in multiple languages that
   * reflect a cached copy of the names associated with the linked features. Formatting of such
   * names should follow the same rules as selecting and formatting the name of a feature itself.
   * @return value or {@code null} for none
   */
  public java.util.List<GeostoreNameProto> getParsedName() {
    return parsedName;
  }

  /**
   * The parsed_name field contains one or more names of an address component. Its actual contents
   * depends on where in the Geo/Google stack you are reading a feature: 1. When an address is
   * initially parsed via a feed or other raw input and structured as an AddressProto, parsed_name
   * should contain the set of names that corresponds to the (possibly normalized) raw text from the
   * raw input. 2. In MapFacts, the address component may be linked to an actual feature via
   * feature_id. Any address formatting directly from MapFacts should follow links to retrieve names
   * when possible. The parsed_name contents may be formatted directly if the address component is
   * unlinked following the same rules as selecting and formatting the name of a feature. The cached
   * parsed_name is regularly refreshed from the linked feature with the minimal set of names for
   * address components (usually just a single, preferred name, in the local language, plus a Latin-
   * script name: go/story-of-ac-names). 3. In serving systems, the names of linked features may be
   * denormalized into the parsed_name field to facilitate quicker address formatting or for simple
   * data filtering (e.g. finding all geocodes in California by name). If reading a feature from
   * such a system, the parsed_name field could contain multiple names in multiple languages that
   * reflect a cached copy of the names associated with the linked features. Formatting of such
   * names should follow the same rules as selecting and formatting the name of a feature itself.
   * @param parsedName parsedName or {@code null} for none
   */
  public GeostoreAddressComponentProto setParsedName(java.util.List<GeostoreNameProto> parsedName) {
    this.parsedName = parsedName;
    return this;
  }

  /**
   * Any numerical address component may optionally be specified as a range. For example if a
   * component of TYPE_STREET_NUMBER has the optional "range" attribute, then it represents a range
   * of addresses rather than a single address (see AddressRangeProto for details).
   * @return value or {@code null} for none
   */
  public GeostoreAddressRangeProto getRange() {
    return range;
  }

  /**
   * Any numerical address component may optionally be specified as a range. For example if a
   * component of TYPE_STREET_NUMBER has the optional "range" attribute, then it represents a range
   * of addresses rather than a single address (see AddressRangeProto for details).
   * @param range range or {@code null} for none
   */
  public GeostoreAddressComponentProto setRange(GeostoreAddressRangeProto range) {
    this.range = range;
    return this;
  }

  /**
   * A place for clients to attach arbitrary data to an address component. Never set in MapFacts.
   * @return value or {@code null} for none
   */
  public Proto2BridgeMessageSet getTemporaryData() {
    return temporaryData;
  }

  /**
   * A place for clients to attach arbitrary data to an address component. Never set in MapFacts.
   * @param temporaryData temporaryData or {@code null} for none
   */
  public GeostoreAddressComponentProto setTemporaryData(Proto2BridgeMessageSet temporaryData) {
    this.temporaryData = temporaryData;
    return this;
  }

  /**
   * Additional text to append before and/or after the parsed_name, when the address is formatted.
   * Multiple instance should represent translations. Currently, this is only permitted on
   * TYPE_LANDMARK components, and only one instance is permitted.
   * @return value or {@code null} for none
   */
  public java.util.List<GeostoreTextAffixProto> getTextAffix() {
    return textAffix;
  }

  /**
   * Additional text to append before and/or after the parsed_name, when the address is formatted.
   * Multiple instance should represent translations. Currently, this is only permitted on
   * TYPE_LANDMARK components, and only one instance is permitted.
   * @param textAffix textAffix or {@code null} for none
   */
  public GeostoreAddressComponentProto setTextAffix(java.util.List<GeostoreTextAffixProto> textAffix) {
    this.textAffix = textAffix;
    return this;
  }

  /**
   * Every address component has a type. Most address components correspond to one of the feature
   * types defined in FeatureProto, so rather than defining a separate category system here, instead
   * we mark them as TYPE_FEATURE and store the FeatureProto type in the feature_type() field. This
   * is how we handle countries, cities, streets, etc. However, there are a few types of address
   * components that do not have a corresponding feature type (e.g. PO boxes). These components have
   * their type defined here. An address component of TYPE_STREET_NUMBER may correspond to a
   * physical entity that defines a street number, such as a geocoded address or a land parcel. In
   * this case, the address component may have a link to the corresponding feature. A good reference
   * for what types of address components are possible is the xAL standard, which is a published XML
   * schema: http://www.oasis-open.org/committees/ciq/download.shtml. This standard is the basis of
   * the PostalAddress protocol message.
   * @return value or {@code null} for none
   */
  public java.lang.String getType() {
    return type;
  }

  /**
   * Every address component has a type. Most address components correspond to one of the feature
   * types defined in FeatureProto, so rather than defining a separate category system here, instead
   * we mark them as TYPE_FEATURE and store the FeatureProto type in the feature_type() field. This
   * is how we handle countries, cities, streets, etc. However, there are a few types of address
   * components that do not have a corresponding feature type (e.g. PO boxes). These components have
   * their type defined here. An address component of TYPE_STREET_NUMBER may correspond to a
   * physical entity that defines a street number, such as a geocoded address or a land parcel. In
   * this case, the address component may have a link to the corresponding feature. A good reference
   * for what types of address components are possible is the xAL standard, which is a published XML
   * schema: http://www.oasis-open.org/committees/ciq/download.shtml. This standard is the basis of
   * the PostalAddress protocol message.
   * @param type type or {@code null} for none
   */
  public GeostoreAddressComponentProto setType(java.lang.String type) {
    this.type = type;
    return this;
  }

  @Override
  public GeostoreAddressComponentProto set(String fieldName, Object value) {
    return (GeostoreAddressComponentProto) super.set(fieldName, value);
  }

  @Override
  public GeostoreAddressComponentProto clone() {
    return (GeostoreAddressComponentProto) super.clone();
  }

}
