In the benche2drive dataset Python file, there is a function named get_map_info, which appears to be called multiple times during both training and evaluation.
Inside this function, I found the following structure related to filter_redundancy:
map_geoms = {}
for label, polyline in zip(gt_labels, polylines):
if label not in map_geoms:
map_geoms[label] = []
map_geoms[label].append(polyline)
def filter_redundancy(lane_list):
i = 0
while i < len(lane_list):
pop_i = False
if polyline.length < 2.0:
lane_list.pop(i)
break
...
for label in map_geoms:
map_geoms[label] = filter_redundancy(map_geoms[label])
As I understand it, the original purpose of filter_redundancy is to remove lanes whose length is less than 2 from lane_list (which corresponds to map_geoms[label], i.e., the polylines of a specific label).
However, inside filter_redundancy, the variable polyline is not defined locally and appears to be captured from the outer scope, where it is defined in the preceding for loop. In that case, polyline would refer only to the last value assigned in that loop, rather than the individual elements of lane_list.
Because of this, it seems that the function may not be checking the length of each lane correctly, and this behavior looks very likely to be a bug.
Could you kindly confirm whether this is intended behavior, or if this might indeed be an implementation issue?
In the benche2drive dataset Python file, there is a function named get_map_info, which appears to be called multiple times during both training and evaluation.
Inside this function, I found the following structure related to filter_redundancy:
As I understand it, the original purpose of filter_redundancy is to remove lanes whose length is less than 2 from lane_list (which corresponds to map_geoms[label], i.e., the polylines of a specific label).
However, inside filter_redundancy, the variable polyline is not defined locally and appears to be captured from the outer scope, where it is defined in the preceding for loop. In that case, polyline would refer only to the last value assigned in that loop, rather than the individual elements of lane_list.
Because of this, it seems that the function may not be checking the length of each lane correctly, and this behavior looks very likely to be a bug.
Could you kindly confirm whether this is intended behavior, or if this might indeed be an implementation issue?