Author: Darth Autocrat

This is the category that a user picked this job type from at the time of input. The field serves two purposes: 1) The name is used in consumer surface similar to the heading name today (i.e., grouping jobs under the category. 2) The gcid is needed mainly for free-formed entries, for which GMB needs to map them to corresponding categories in the frontend, if applicable. Notice that the name and the id are both not expected to be in sync with gcid deprecation or location category change per product decision. In other words, they are not guaranteed to stay in sync, only guaranteed true at time of creation.

This protocol buffer represents the association between a segment and a landmark feature. Notes: – References to TYPE_SEGMENT features should always point to the even sibling. – Self-references are allowed but the referencing segment’s sibling is required to have a self-reference as well (the above requirement to always reference the even sibling still applies).

Describes an individual road lane. Not only driving lanes, but also parking and biking lanes are covered by this. Note that we may eventually add curbs and walking to this schema. MOTIVATION/DESIGN DISCUSSION The intent of this schema is to model a schematic representation of the road for a bunch of use cases within GMM, navigation, map tiles. For rendering, we do not want to represent the geometry of each lane exactly, but do want to model types/width/gaps/lane markings so that a schematic rendering can be made. For navigation, we model lane connectivity and restrictions per lane, so that Pathfinder can potentially pick routes based on lanes, and definitely use the lanes to better describe the path to the driver. This schema is driven by the GT team, which is likely to be the only provider of this data. It is based on compromises that we are working out with other teams, based on what our operators can reasonably collect and what is useful. See docs here: https://docs.google.com/a/google.com/document/d/11XJ1WvqS5Sm7MxWXzzc3tnsk49VhrR3BYFjiRMAzYm0/edit?hl=en_US https://docs.google.com/a/google.com/document/d/1nzdupynTUKE8xY8JcfvQbU-KWtCJ6IwHiTaCxuq40EM/edit?hl=en_US Note: Some lane information (width, surface type, etc) may duplicate or contradict information stored at the segment level.

Represents a piece of text with an associated language.

A locale is a meta-feature that describes the geographic extent of localization preferences such as the local language, and formatting conventions for numbers, dates and monetary values. Multilingual areas may be contained by multiple locales. We try to model locales fine-grained enough for deciding which languages are typically used within a city. For example, while French is an official language for all of Switzerland, we would prefer to have Zurich contained by a separate (more fine-grained) Swiss-German locale indicating that German, not French, is the predominantly spoken language in this city. Note that language borders are frequently considered a political question and often don’t have clearly defined extents. For example, California has a significant Spanish-speaking population, but Spanish is not an official language of California.

Media item attached to an element of price list.

Feature ID forwardings. There are many different types of ID forwardings, some of which are attached to live features, others to removed features. This information is available in multiple forms (with different completeness guarantees): (1) in RPC responses to read requests to the live Geo repository; (2) on disk, as part of the metadata section of features found in the (inactive) features snapshots; (3) on disk, as part of a separate feature_id_forwardings side table.

A globally unique identifier associated with each feature. We use 128-bit identifiers so that we have lots of bits available to distinguish between features. The feature id currently consists of a 64-bit "cell id" that sometimes corresponds to the approximate centroid of the feature, plus a 64-bit fingerprint of other identifying information. See more on each respective field in its comments. Feature ids are first assigned when the data is created in MapFacts. After initial creation of the feature, they are immutable. This means that the only properties that you should rely on are that they are unique, and that cell_ids often – but not always – preserve spatial locality. The degree of locality varies as the feature undergoes geometry changes, and should not in general be considered a firm guarantee of the location of any particular feature. In fact, some locationless features have randomized cell IDs! Consumers of FeatureProtos from Mapfacts are guaranteed that fprints in the id field of features will be globally unique. Using the fprint allows consumers who don’t need the spatial benefit of cell ids to uniquely identify features in a 64-bit address space. This property is not guaranteed for other sources of FeatureProtos.