@@ -302,13 +302,22 @@ message LogicalLane
302302 //
303303 repeated ExternalReference source_reference = 3 ;
304304
305- // Reference to the physical lane this logical lane belongs to.
305+ // Reference to the physical lanes this logical lane belongs to.
306306 //
307307 // This makes it possible to get detailed information on the physical lane
308308 // properties, e.g. the visual colors of the boundaries, the road
309309 // condition, etc..
310310 //
311- // TODO Should this be a repeated field? Imagine the following scenario:
311+ // Note: a logical lane may consist of several physical lanes (in a row).
312+ // At any one S position, a logical lane should only reference one physical
313+ // lane. Several logical lanes may reference the same physical lane (see
314+ // drawing below).
315+ //
316+ // Logical lanes should not extend beyond intersections. All logical lanes
317+ // on intersections should end at the latest at the border of the
318+ // intersection.
319+ //
320+ // Example:
312321 // <pre>
313322 // ---------------------------------
314323 // l1 l2
@@ -321,22 +330,21 @@ message LogicalLane
321330 // lane marking is present. And l3 is one lane covering the whole road
322331 // (because no road marking is present).
323332 //
324- // Now there are two basic possibilities to define the logical lanes:
325- // - There could be two logical lanes: one encompassing l4, part of l3 and
326- // l5; another encompassing l2, part of l3 and l1. In this case, one
327- // logical lane can map to a number of physical lanes, and the mapping
328- // should include s positions, so it is clear which part of the logical
329- // lane maps to which physical lane.
330- // - There could be 6 logical lanes: l1, l2, l4, l5 and two lanes for each
331- // halve of l3. Then each logical lane would map to a single physical
332- // lane, but logical lanes would have to be split each time a lane
333- // marking appears or disappears.
333+ // This would typically be presented as two logical lanes:
334+ // - One encompassing l1, part of l3, and l2
335+ // - The other encompassing l4, part of l3 and l5
336+ //
337+ // In this example, both logical lanes would reference l3. Their shared
338+ // LogicalLaneBoundary would cut through the middle of l3.
339+ //
340+ // physical_lane_reference does not give any information how much of the
341+ // area of a physical lane is covered by a logical lane.
334342 //
335343 // \rules
336344 // refers_to: Lane
337345 // \endrules
338346 //
339- optional Identifier physical_lane_id = 4 ;
347+ repeated PhysicalLaneReference physical_lane_reference = 4 ;
340348
341349 // The reference line for this logical lane
342350 //
@@ -554,6 +562,30 @@ message LogicalLane
554562 TYPE_CURB = 16 ;
555563 }
556564
565+ //
566+ // \brief Reference to a physical lane.
567+ //
568+ message PhysicalLaneReference
569+ {
570+ // Id of the physical lane referenced.
571+ //
572+ // \rules
573+ // refers_to: Lane
574+ // \endrules
575+ //
576+ optional Identifier physical_lane_id = 1 ;
577+
578+ // S position on the logical lane where the physical lane starts
579+ //
580+ optional double start_s = 2 ;
581+
582+ // S position on the logical lane where the physical lane ends
583+ //
584+ // Requirement: end_s > start_s
585+ //
586+ optional double end_s = 3 ;
587+ }
588+
557589 //
558590 // \brief Connection to another lane (predecessor or successor)
559591 //
0 commit comments