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

Attributes

• canEnter (type: boolean(), default: nil) - RESERVED
• canExit (type: boolean(), default: nil) - RESERVED
• featureId (type: GoogleApi.ContentWarehouse.V1.Model.GeostoreFeatureIdProto.t, default: nil) - The ID of the feature that defines the access point. The bounding box of the feature is expanded to include the bounding box of the feature with the access point in accordance with the standard practice for bucketing map/reduce operations. See the wiki page at http://wiki/Main/OysterBucketingMapReduce for more information. For access points to TYPE_SEGMENT features, this may be re-derived if necessary by looking up the nearest segment to existing geometry.
• featureType (type: integer(), default: nil) - The type of the feature. Required, to allow handling the access point differently based on feature type. For access points to non-TYPE_SEGMENT features, this cached type also makes things easier for clients that aren't running a bucketing map-reduce. For access points to TYPE_SEGMENT features, this is used to find to find the nearest segment of the given type.
• levelFeatureId (type: GoogleApi.ContentWarehouse.V1.Model.GeostoreFeatureIdProto.t, default: nil) - For indoor access points, this should be set to the level that the access point is on. The feature_id should point to the indoor segment, but when it is missing or invalid, and we need to derive it from geometry, only segments on this level will be considered. For non-indoor access points, level should remain unset, and when we derive feature_id from geometry, only segments not on any level (non-indoor segments) will be considered. The bounding box of the level feature is expanded to include the bounding box of the feature with the access point in accordance with the standard practice for bucketing map/reduce operations. See the wiki page at http://wiki/Main/OysterBucketingMapReduce for more information. (Though in general the feature should reside on the level already anyway..)
• metadata (type: GoogleApi.ContentWarehouse.V1.Model.GeostoreFieldMetadataProto.t, default: nil) - Field-level metadata for this access point.
• point (type: GoogleApi.ContentWarehouse.V1.Model.GeostorePointProto.t, default: nil) - For access points to non-TYPE_SEGMENT features, the location of the access point. For access points to TYPE_SEGMENT features, this can be supplied as a fuzzy access point that is not guaranteed to be on the correct side of road. It should not be used by end clients in case of TYPE_SEGMENT access points.
• pointOffSegment (type: GoogleApi.ContentWarehouse.V1.Model.GeostorePointProto.t, default: nil) - If the access point is defined by a TYPE_SEGMENT feature, this is the location of the access point displaced slightly to the correct side of the segment. This offset is in a direction perpendicular to the direction of travel along the segment. The actual offset distance is unspecified. It would typically be relatively small (approximately 1 meter). You can subtract the "off segment" point from the "on segment" point to get a vector of unknown length pointing from "on segment" point to the "off segment" point. You can then scale that vector to whatever length you want. Note that extending this displacement vector a large distance (10s of meters) may result in a new point that is in the middle of some other feature (park, street, intersection). This is the preferred basic geometry field for incoming data from editing clients and importers, if side-of-road is well-established.
• pointOnSegment (type: GoogleApi.ContentWarehouse.V1.Model.GeostorePointProto.t, default: nil) - If the access point is defined by a TYPE_SEGMENT feature, this is the point on the centerline of the segment that is closest to the actual access point. May be re-derived if necessary to maintain precise placement on segment.
• priority (type: String.t, default: nil) - LINT.ThenChange(//depot/google3/geostore/cleanup/callbacks/\ ID_DUPLICATE_ACCESS_POINT.cc)
• segmentPosition (type: number(), default: nil) - If the access point is defined by a TYPE_SEGMENT feature, this is the location of the access point expressed as a fractional distance along the segment. The value runs from 0 to 1 inclusive. May be re-derived if necessary to maintain precise placement on segment.
• unsuitableTravelMode (type: list(String.t), default: nil) - This list represents the travel modes for which this access-point should be avoided. If this list is empty, the access-point is suitable for any travel mode. If all access points are unsuitable for the current travel mode, client should revert to other heuristics (e.g. feature center). This is only used for access points to TYPE_SEGMENT features; access points to non-TYPE_SEGMENT features, e.g. TYPE_ESTABLISHMENT_POI features with gcid:transit_station GConcepts are just identified by feature_type and feature_id.