GeostoreNameProto

AI Overview😉

  • The potential purpose of this module is to store and manage geographic feature names, such as street names, points of interest, cities, and buildings, in a way that accounts for language variations and different types of names (e.g., common names, postal codes, and internal IDs).
  • This module could impact search results by influencing how geographic features are indexed and retrieved. It may prioritize results that match the user's language and location, and provide more accurate and relevant results for searches that involve geographic features. Additionally, it may help to disambiguate searches that involve similar names or abbreviations.
  • To be more favorable for this function, a website could ensure that its geographic feature names are accurately and consistently represented, with language and location information properly specified. This could involve providing multiple names for a feature in different languages, using standardized abbreviations and acronyms, and ensuring that internal IDs and postal codes are correctly formatted. Additionally, a website could provide metadata and other relevant information about its geographic features to help improve the accuracy and relevance of search results.

Interesting Module? Vote 👇

Voting helps other researchers find interesting modules.

Current Votes: 0

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

A name for a Feature (street name, point of interest, city, building, etc). We currently use NameProto for two essentially disjoint purposes: 1. Common names, which can be language-specific, or have other kinds of variations. 2. Opaque IDs, such as postal codes, which only have the text field set, and potentially some flags. This includes internal-only features like template ids. Each NameProto representing a common name corresponds to an assertion that a fluent speaker or writer of a language would recognize NameProto.text to name the given feature in that language. As such, NameProtos are stored in a repeated field, often having: 1. multiple names with the same text and varying languages, and 2. multiple names with the same language and varying texts.

Attributes

  • flag (type: list(String.t), default: nil) - clang-format on The set of flags that apply to this name.
  • language (type: String.t, default: nil) - The external form of a Google International Identifiers Initiative (III) LanguageCode object. See google3/i18n/identifiers/languagecode.h for details. These strings should be treated as opaque blobs. You can use LanguageCodeConverter::FromOther to convert the string to a LanguageCode reference. You can then call methods on the LanguageCode class to extract language/script/region subtags (if any). See also http://g3doc/i18n/identifiers/g3doc/using-iii. We place extra restrictions on languages in addition to what the III library requires. See go/geo-schema-reference/feature-properties/languages. This field may be missing if the name does not have a concept of language but should be set if the language is unknown.
  • metadata (type: GoogleApi.ContentWarehouse.V1.Model.GeostoreFieldMetadataProto.t, default: nil) - Field-level metadata for this name. NOTE: there are multiple NameProto fields in the Geo Schema. Metadata here is only expected to be present on FeatureProto.name[].
  • rawText (type: String.t, default: nil) - DEPRECATED The name text provided in the original source data (UTF-8 encoding). This is the text provided in the source data unmodified with the exception of being converted to UTF-8 and stripping extra leading, trailing and duplicate whitespaces (if necessary).
  • shortText (type: String.t, default: nil) - The short name text (UTF-8 encoding). Acronyms/abbreviations should be consistently used, for example "NE 57th St" rather than "Northeast 57th Street", "N.E 57th St." or some other variant. This field should be populated with the chosen canonical version of the shortened name, based on per-term transformations. For feature specific abbreviations (such as 'CA' for 'California'), one should define a separate name with FLAG_ABBREVIATED set. For other variants of the shortened name that are not the canonical one, devise client based logic (ex: query rewriting rules).
  • temporaryData (type: GoogleApi.ContentWarehouse.V1.Model.Proto2BridgeMessageSet.t, default: nil) - A place for clients to attach arbitrary data to a name. Never set in MapFacts.
  • text (type: String.t, default: nil) - The name text (UTF-8 encoding). Acronyms/abbreviations should be fully expanded, for example "Northeast 57th Street" rather than "NE 57th St". They can be shortened at display or geocode time. This decision prevents ambiguity over such issues as whether "St" represents "Street" or "Saint". However, it pushes language-specific knowledge into code. We will have libraries and data files to contract acronyms/abbreviations at run-time.

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.GeostoreNameProto{
  flag: [String.t()] | nil,
  language: String.t() | nil,
  metadata:
    GoogleApi.ContentWarehouse.V1.Model.GeostoreFieldMetadataProto.t() | nil,
  rawText: String.t() | nil,
  shortText: String.t() | nil,
  temporaryData:
    GoogleApi.ContentWarehouse.V1.Model.Proto2BridgeMessageSet.t() | nil,
  text: String.t() | nil
}

Functions

Link to this function

decode(value, options)

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

Unwrap a decoded JSON object into its complex fields.