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

Attributes

• featureId (type: GoogleApi.ContentWarehouse.V1.Model.GeostoreFeatureIdProto.t, default: nil) - 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.
• featureType (type: integer(), default: nil) - 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.
• index (type: integer(), default: nil) - 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.
• parsedName (type: list(GoogleApi.ContentWarehouse.V1.Model.GeostoreNameProto.t), default: nil) - 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.
• range (type: GoogleApi.ContentWarehouse.V1.Model.GeostoreAddressRangeProto.t, default: nil) - 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).
• temporaryData (type: GoogleApi.ContentWarehouse.V1.Model.Proto2BridgeMessageSet.t, default: nil) - A place for clients to attach arbitrary data to an address component. Never set in MapFacts.
• textAffix (type: list(GoogleApi.ContentWarehouse.V1.Model.GeostoreTextAffixProto.t), default: nil) - 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.
• type (type: String.t, default: nil) - 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.