Migrate data to map element detection

[Wolfybox]

hi, thanks for the great work.

In p13 of the paper, it states "Furthermore, we migrate our data to two subtasks: map detection and centerline perception."

To my knowledge, OpenLaneV2 provides lanelines highly coupled with lane segments, which are frequently divided when lanelines of either side change in type. Directly extracting each laneline from lane segments might lead to potential undesirable fragmentation of lanelines representation, which might confuse the model.

How exactly did you solve this problem? I am struggling merging these lanelines from lane segments.

Would there be any codes for migrating the data for map element detection?

[sephyli]

Hi, thank you for your question. We chose not to merge the segmented lanelines into a continuous one because the distinction between different lane types is important, and the lane segments effectively represent the drivable regions within a lane. During the experiment, the task of map element detection was performed using the segmented lanelines under a fair comparison.

[Wolfybox]

Hi, thank you for your question. We chose not to merge the segmented lanelines into a continuous one because the distinction between different lane types is important, and the lane segments effectively represent the drivable regions within a lane. During the experiment, the task of map element detection was performed using the segmented lanelines under a fair comparison.

Thanks for the quick reply.

Training map element detection with segmented lanelines does not quite make sense to me. Although it is reasonable to split laneline where lane types change, some lanelines of the same type are forced to be segmented when the laneline on the other side change in types. Below is an instance to futher clarify such circumstance:
----|-----
****|-----
"-" and "*" represents two different kinds of lanelines. "|" is a dividing mark that distinguishes two different lane segments.
Now because the right laneline "*" change to "-", the lane segment is divided. The left-laneline however, which does not change in type, got divided as well.
Perhaps OpenLane-V2 is designed and more suitable for learning at segment level. Doing general map element detection should need additional merging operation.

[Wolfybox]

Hi, thank you for your question. We chose not to merge the segmented lanelines into a continuous one because the distinction between different lane types is important, and the lane segments effectively represent the drivable regions within a lane. During the experiment, the task of map element detection was performed using the segmented lanelines under a fair comparison.

I tried extracting from lane segments all lanelines of the same type in one frame and then visualizing them on the bev plane. It gave me lots of overlapped and segmented lanelines.

[sephyli]

Under the given circumstance, these two lane segments in the top figure should be merged into one lane segment in our data processing.
However, sometimes, the merging process does not perform. This could happen in certain circumstances, including a merge/split or when one lane segment is in an intersection.

[sephyli]

Determining the best formulation only in the research field can be challenging. It often depends on the specific requirements of the downstream module.
If the downstream modules already rely on a continuous lane line representation, merging the predicted segmented lane lines becomes necessary. However, achieving this merging process is not straightforward unless some networks achieve a high precision and recall on this task.
For downstream modules that rely on the centerline representation, the formulation of lane segments can offer them a fresh perspective.

[Wolfybox]

Determining the best formulation only in the research field can be challenging. It often depends on the specific requirements of the downstream module. If the downstream modules already rely on a continuous lane line representation, merging the predicted segmented lane lines becomes necessary. However, achieving this merging process is not straightforward unless some networks achieve a high precision and recall on this task. For downstream modules that rely on the centerline representation, the formulation of lane segments can offer them a fresh perspective.

Thanks for reply.

I just found that MapTRv2 provides script to merge overlapped and joint lanelines with av2 api.
Since ol2 can be associated with av2 by source-id and timestamp. Maybe it is feasible to use av2's map annotation along with ol2's ?

[Wolfybox]

done with MapTRv2 script and some modification.