GeostoreAddressProto

AI Overview😉

  • The potential purpose of this module is to accurately identify and store address information associated with a feature or location. This includes parsing and structuring address components, handling multiple address lines, and storing metadata.
  • This module could impact search results by improving the accuracy of location-based searches, providing more precise results when users search for specific addresses or locations. It may also influence the ranking of search results by considering the relevance and accuracy of address information associated with a feature or location.
  • To be more favorable for this function, a website could ensure that its address information is accurate, complete, and consistently formatted. This includes providing multiple address lines when necessary, and structuring address components in a logical and standardized way. Additionally, websites could provide metadata about their address information, such as language and country, to help search engines better understand and utilize this data.

Interesting Module? Vote 👇

Voting helps other researchers find interesting modules.

Current Votes: 0

GoogleApi.ContentWarehouse.V1.Model.GeostoreAddressProto (google_api_content_warehouse v0.4.0)

This class represents an address, partial address, or address range. It is intended to be attached to features to identify their address(es). Some important points about addresses: - The addresses in the Geo Schema do not include a component for the name of the feature, i.e. they are not self-referential. For example, the name of a feature might be "Zack's Pizza" and its address would be "123 Main Street". Similarly, streets, cities, and counties do not include themselves as part of their address. The address of "Seattle" is "King County, Washington, USA". If want to construct an address that does include the feature name, you can simply prepend it to the other address components. - Lakes, mountains, and other natural features do not normally have addresses. Countries also do not have addresses because they are at the top of the political hierarchy. - Address components in the Geo Schema are listed in a particular order, independent of the conventions used by the country in which they occur. The basic order is "smallest to largest" starting with street numbers and routes, then political features, and ending with postal features. The exact rules are defined by the implementation of the AddressComponentOrdering::IsLessThan() function. - Some types of address components may occur more than once in an address. For example, a UK address with a "dependent thoroughfare" would have two components of TYPE_ROUTE (i.e. street names). These are listed in the order they are normally written.

Attributes

  • addressLines (type: list(GoogleApi.ContentWarehouse.V1.Model.GeostoreAddressLinesProto.t), default: nil) - The unparsed portion (lines) of the address. An address can have multiple unparsed portions. Multiple unparsed portions sharing the same language should be modeled as one address_lines instance having multiple lines. Historically, we also supported unparsed portions in different languages, but we no longer do. Consequently, only one value is allowed for this field despite the fact that it is repeated. See go/address-lines-multi-language for information about why we made this change. If any components are filled in, this is supplemental to (i.e. disjoint from) them. Furthermore, this must be the most specific portion of the address (except for the portion, if any, stored in the name field of feature.proto). Unparsed lines are always formatted together in a block. Other address components are never formatted between the address lines. This doesn't imply that the address lines are always either the first or the last part of the formatted output.
  • component (type: list(GoogleApi.ContentWarehouse.V1.Model.GeostoreAddressComponentProto.t), default: nil) - A list of parsed address components, e.g. the street, city, etc. An address range is one type of component.
  • crossStreet (type: list(GoogleApi.ContentWarehouse.V1.Model.GeostoreAddressComponentProto.t), default: nil) - DEPRECATED This field is now deprecated (see b/33268032). If you want to store cross street information as part of an address, use the address_lines field.
  • metadata (type: GoogleApi.ContentWarehouse.V1.Model.GeostoreFieldMetadataProto.t, default: nil) - Field-level metadata for this address.
  • partialDenormalization (type: GoogleApi.ContentWarehouse.V1.Model.GeostoreAddressProto.t, default: nil) - reserved
  • templateId (type: String.t, default: nil) - The opaque ID of the address template that contains rules for structuring this address. The id of the address template can be retrieved using google3/geostore/address_templates/public/address_templates.h
  • temporaryData (type: GoogleApi.ContentWarehouse.V1.Model.Proto2BridgeMessageSet.t, default: nil) - A place for clients to attach arbitrary data to an address. Never set in MapFacts.

Summary

Types

t()

Functions

decode(value, options)

Unwrap a decoded JSON object into its complex fields.

Types

Link to this type

t()

@type t() :: %GoogleApi.ContentWarehouse.V1.Model.GeostoreAddressProto{
  addressLines:
    [GoogleApi.ContentWarehouse.V1.Model.GeostoreAddressLinesProto.t()] | nil,
  component:
    [GoogleApi.ContentWarehouse.V1.Model.GeostoreAddressComponentProto.t()]
    | nil,
  crossStreet:
    [GoogleApi.ContentWarehouse.V1.Model.GeostoreAddressComponentProto.t()]
    | nil,
  metadata:
    GoogleApi.ContentWarehouse.V1.Model.GeostoreFieldMetadataProto.t() | nil,
  partialDenormalization: t() | nil,
  templateId: String.t() | nil,
  temporaryData:
    GoogleApi.ContentWarehouse.V1.Model.Proto2BridgeMessageSet.t() | nil
}

Functions

Link to this function

decode(value, options)

@spec decode(struct(), keyword()) :: struct()

Unwrap a decoded JSON object into its complex fields.