Add visualization of OpenCRG road and road patches by using $ROAD_CRG_VISUALIZATION / $ROAD_CRG_VISUALIZATION_PATCH_#

[jkoppena]

In Adams, one can visualize part the road and/or patches by adding the specification in a $ROAD_CRG_VISUALIZATION data block and $ROAD_CRG_VISUALIZATION_PATCH_# for road patches, as shown by the example below:

$ROAD_CRG_VIsUALIZATION
*visualization_increment_u = 0.25
*visualization_increment_v = 0.25
visualization_start_u = 0.0
visualization_start_v = -3.00
visualization_end_u = 48.97
visualization_end_v = 3.00
$
$ROAD_CRG_VISUALIZATION_PATCH_1
visualization_increment_u = 0.014
visualization_increment_v = 0.0132
visualization_start_u = 20.0
visualization_start_v = -1.7
visualization_end_u = 22.0
visualization_end_v = 1.7
$
$ROAD_CRG
reference_line_start_u = 0.0000000000000000e+00
reference_line_end_u = 4.8969999999999999e+01
...

It is proposed to make this a standard keyword for OpenCRG.

[jorauh]

I agree to implement some feature like this, but we should really take care not to clutter the existing simple CRG file structure.

• Having one optional block "$ROAD_CRG_VISUALIZATION" would be easy to be handled in the standard (and implementation).
• Having an (uncounted, undefined) number of optional or additional blocks "$ROAD_CRG_VISUALIZATION_PATCH#x" is cumbersome

We already discussed the problems occuring with multiple blocks with identical identifiers, this is currently not monitored and signaled as error by the matlab reader.
Having an (uncounted, unknown) number of optional or additional blocks makes this monitoring more complex and error prone.
My proposal for this feature is to have just one (optional) block, and maybe some well defined syntax to define more than one patch for visuaization inside this block. This removes potential complexity from all implementations not using the visualization feature.
How are the patches used today? Are they just defining a consecutive sequence of visualization patches? Could we handle this with some additional keywords defining a looping behavior?
Proposals for a well defined and simple syntax for more than one visualization patch inside the single visualization block are welcome!

Implementation hint:
This extra block should be handled by the FILEREF feature like the MODS and OPTS block: if defined in the first CRG file, it replaces any definition in the second CRG file.