Author: Darth Autocrat

Represents a measurements, which is one of the possible Value types. A measurement value like "5.2 meter^2 / second" would be represented as: magnitude: 5.2 unit { unit_mid: "/m/mid_for_meter" power: 2 } unit { unit_mid: "/m/mid_for_second" power: -1 }

List of { predicate, { object } } to be processed as a Nested Struct. Nested Struct can be recursive. NestedStruct.property_value(i).value(j) may have nested_struct field.

A Topic represents a Knowledge Graph entity with its associated properties and their values.

Next id: 127

The Directory proto group holds snippet and title metadata which is made available to the snippet code. The proto group was originally created for metadata coming from the Google Web Directory (gwd) project. It has since come to be used to hold metadata from gwd and other sources.

The generic version of a snippet response

This class holds information about a single access point. An access point establishes a relationship between a feature (like a POI or building) and some other feature. For example, consider a TYPE_LOCALITY feature like Seattle. An access point might be the TYPE_AIRPORT feature for Seattle-Tacoma International Airport. The airport feature defines the access point to gain airplane-based access to Seattle. A feature like Seattle will typically have multiple access points. You can get to Seattle using airplanes, various forms of public transit, or by driving a car. Thus Seattle would have multiple access points. You may be able to get to Seattle by flying into SeaTac, or you might be able to fly into Boeing Field, or Paine Field in Everett. You could drive in from the North/South using I-5, or you could drive in from the East using I-90. Many access points are from the road network. Thus the access point for some building at 123 Main Street would likely be a segment that defines the 100-200 block of "Main Street". A feature at the corner of "Hollywood" and "Vine" streets might have access points from both named streets. Access points are an optional field. Data editors may ignore them when creating features or editing other fields. In these cases, other quality teams will synthesize and update them. Several fields are also optional, as they are derivable from other fields. Access points to non-TYPE_SEGMENT features should always have the following fields set: – feature_type – feature_id – point Location and reference fields: BASIC vs DERIVABLE Access points to TYPE_SEGMENT features must have all the following BASIC fields: – feature_type (of the segment, e.g. TYPE_ROAD or TYPE_VIRTUAL_SEGMENT) – point_off_segment (or point; see "fuzzy point" note below) – unsuitable_travel_mode (may be empty) – level (indoor access points only) The following are DERIVABLE fields, which should only be added if the supplier is confident about their accuracy: – feature_id – point_on_segment – segment_position Editing clients are encouraged to set all fields, but they may set only the BASIC fields, in which case quality teams may use the BASIC fields to snap to an appropriate segment and derive the remaining fields. Example: The segment is split, so that the portion that the access point is on has a new feature ID. Quality teams notice that the point_on_segment is no longer on the segment with feature_id, finds the new nearest segment based on feature_type and existing point_on_segment, and re-derives a new feature_id, point_on_segment, and segment_position, keeping other fields consistent. Fuzzy point special case If the editor does not have side-of-road information for access points or is otherwise unsure of the precise placement of the access point, it may supply the point field (and not point_off_segment) as basic data instead, in which case quality teams may generate the point_off_segment. Identity Access points are considered semantically equivalent if they have the same geometry, including derived fields, and the same references to other features (feature_id, level_feature_id). For the exact definition, see cs/symbol:geostore::AreAccessPointsEquivalent. Field definitions

Represents the unparsed portion of an address with an associated language.

This class represents a range of numbers in an address. It is an optional additional field in the ‘AddressComponentProto’ message. This structure can be used to model both single addresses and address ranges. There are two primary use-cases for address ranges: definitions and references. Ranges are being defined when they are present on the addresses of segment features. Ranges are being referenced when they are present on non-segment features. NOTE: If you add fields in this proto, consider updating the AreAddressRangesEquivalent() function in google3/geostore/base/internal/addressrange.cc

A container for speed limits that allows tagging with a correctness trust level.