road objects past road limits aren't generated when using paramPoly3 geometries

[dpjiitkgp]

File with_param_poly.xodr:
geometry: ParamPoly3
s_offset for object's outline: exceeds max s_offset of planview geometry
is odrviewer working: NO

File with_line.xodr:
Geometry: Line
s_offset for object's outline: exceeds max s_offset of planview geometry
is odrviewer working: YES

File with_param_poly3_soffset_within_limit.xodr:
Geometry: ParamPoly3
s_offset for object's outline: reduced s_offset so that It can fit within the limit of max s_offset of planview geometry
is odrviewer working: YES

param_poly_issue.zip

[pageldev]

This is because the ParamPoly3 geometry doesn't support interpolation past the ends. It's not so easy to fix this due to the way the ParamPoly3 is implemented.

As background: ParamPoly3 uses a CubicBezier under the hood. When the CubicBezier is created it gets sampled from the parametric t=[0.0, 1.0] and a lookup table arc length -> parametric t is created. So basically we can only get t-values for the range [0.0, arc length] and can't get any t-values for past-the-end values (s < 0.0 or s > arc length)

The next step would be extending CubicBezier::get_t to handle values that are not in the valid range. Probably by calculating the arc length for a given t on demand, which is an expensive operation. Alternatively ParamPoly3 could be extended to just linearly extend the ends (like adding Line geometries at the ends)

[tbleher]

I think the intention of the OpenDRIVE standard is that s coordinates of objects should always be inside the bounds of the road (though I notice that the latest standard is a bit unclear in that regard). If there is interest, I can bring up the topic in the ASAM OpenDRIVE CCB (of which I am a member), so it can be clarified in the standard.