GeostoreLaneProto

References to any gcid:physical_lane_marker features that bound this lane.

If the current lane is part of a merge/split area, indicates the type (split or merge) and whether the current lane is on the left or right or in the middle of the merge/split area, as seen in the direction of traffic. See go/lane-split-merge-schema

Gap between this lane and the next in meters. This is relevant when the divider is physical, or a wide painted area. For regular painted single or double lines, there is no gap. This distance is duplicated between the innermost lanes for each side. Note that this is not used to describe smallish islands - this is only for long-running gaps. In particular, this models the median width, the gap between HOV lanes/regular lanes on freeways, and the road verge between a curb and sidewalk. Note on split roads: We can model any split road with a median as a single sibling pair with this distance set to the width of the median, or as two one-way sibling pairs.

The most logical path for the center of an object to travel along within the lane. Typically, this is the lane's center line, but doesn't have to be.

Connections to lanes of other segments at the end of this segment. These connections model the connectivity where you don't have to do a lane change maneuver. If any lane connection is present, assume that all others are forbidden. Also note that segment level restrictions do apply if present, and can disallow some turn even if the lanes are connected. For instance, this can happen with timed or vehicle type based restrictions on the segment. If lane connectivity implies a segment-level restriction (can't transition to some target segment), that restriction will also exist as a segment level restriction. In effect - PathFinder does not have to look at lane connectivity to figure out segment connectivity. Example: Typically, lanes are just connected to one other lane. Example: A splitting lane is connected to the two resulting lanes. Example: At an intersection, a lane is connected to crossing lanes according to how lanes are painted across the intersection. In the common case, the target segment will be connected to the same intersection as this segment. That will however NOT be true for complex intersections where there is an intersection group. The connections will be across the whole group, connecting to one of the outgoing segments from the group. This is analogous to how we do turn restrictions around intersection groups.

clang-format on Whether the divider to the inside of this lane can be crossed. Note that we assume this is symmetric, and that this also describes whether someone in the next inside lane can cross to this one. The "inside" lane is the one with a lower lane_number. Note on lane markers: We do not model the painting, but only the resulting legality. There are many painted marker styles and colors that lead to the same legality. We expect Paint or Driveabout to render lanes stylized, with solid meaning "can't cross", and dashed meaning "can cross". Note on varying legality along segment: ALLOWED takes precedence - even if some small portion has a restriction (such as right before an intersection) , the lane change will be ALLOWED.

These indicate for what portion of the segment the lane's flowline exactly follows the segment, and the lane is of constant width. This will be set to not include the whole segment where there is a split/turn/merge at either end of the lane. The painting of the lane should completely synthesize the lane geometry outside of this portion, connecting it to neighboring lanes to make graphical nice.

Lanes are numbered from inside of the road outward, i.e. the lane next to the center line is lane 0. The lanes then stack outwards, towards the side that one drives on this segment (right or left). NOTE: do NOT use the lane_number as index for lookup. Lane_number is not guaranteed to match the segment.lane repeated field index.

A token that can be used to identify the version of the data about this lane.

Field-level metadata for this lane.

Restrictions that apply to this lane only. Examples include HOV lanes. If a lane restriction implies a segment-level restriction (can't route on the segment at all), that restriction will also exist as a segment level restriction. In effect - PathFinder does not have to look at lane restrictions to figure out segment restrictions.

True if this lane is usable in both directions (left-turn lane, reversing lane, one-lane road, etc). To get the total number of lanes for a road, add up the lanes in each direction counting 0.5 for each shared lane.

References to any gcid:physical_lane_marker features that intersect this lane, with the implication that a moving vehicle should stop there.

clang-format on LINT.ThenChange(//depot/google3/geostore/base/proto/segment.proto) Unlike the surface in SegmentProto, this field does not have a default value. This is because the lane-level surface overrides the segment-level surface. The lane's surface should be unset unless explicitly overriding the segment's surface.

clang-format on

Width of this lane in meters. In many cases, we will collect this data by dividing the total road width by the number of lanes. On accuracy: This is a rough average width along this segment. If and when we wanted to be more accurate, we'd extend this schema to have full polygons for segments/lanes rather than just this average width.