False Positive check_asam_xodr_performance_avoid_redundant_info

[MHoehndorf]

Describe the bug
When checking polynoms for redundant elements we think that it would be better to always set soffset1 to 0.0 and set soffset2 to the length of the first polynom. Otherwise the same two polynoms might be recognized as redundant as well as not redundant, depending on where along the roads these polynoms are located.

To Reproduce

1. Validate the two files in OpenDrive.zip
2. BayArea_wrong_redundant.xodr leads to a redundant elevation element (polynom [6] and [7]). The same two polynoms are also present in the other file (BayArea_no_redundant.xodr), but right at the front of the road. There no error is found in the xodr file.

Expected behavior
No warning should occur for both files

[AsamDiegoSanchez]

09.01.2026: The OpenDRIVE CCB group would like to have a more explanatory screenshot or descriptions. @MHoehndorf could you please add more information to this issue? are you referring to this rule: asam.net:xodr:1.7.0:road.object.valid_s_length_for_repeat?

[MHoehndorf]

Hi,
as stated in the name of the issue the rule is asam.net:xodr:1.7.0:performance.avoid_redundant_info.
It is checked if two adjacent polynoms are redundant, which means that only one polynom would be needed.

BayArea_no_redundant.xodr:

BayArea_wrong_redundant.xodr:

In both files there are the same two adjacent polynoms (same a,b,c,d and lenth), the only difference is the position along the road. In BayArea_no_redundant.xodr the two polynoms are at the front of the road, in BayArea_wrong_redundant.xodr they are located a s~21. As they are the same polynoms we would expect them to be redundant or not to be redundant, but not redundant in the one file and not redundant in the other.