inconsistent road positioning comparing base and header file

[HeyImJordi]

A user came with a question about the positioning of crg road, they define a crg road in two ways:

Just one .crg file, belgian_block_extended.crg
Two crg files: belgian_block_extended_visualization.crg referencing the belgian_block_extended.crg

In case 1 they load the belgian_block_extended.crg in Adams, the starting position of the road is at x=-7.0 m (u=0,v=0)

In case 2 they load the belgian_block_extended_visualization.crg, the starting position x=0.0 (u=0,v=0)

It looks this has something to do with the ‘reference_line_offset_x’

Is that reference_line_offset_x not being read if the file is referenced by another one? This seems to be intended behavior, but is very unclear/annoying for a user.

roadfiles.tar.gz

[asadekasam]

OepnCRG CCB 2025.11.03: Classify after @jkoppena has a second look

[jkoppena]

Data from the Hexagon bugs database:

29 March 2018:
From Bernard (Vires):
I am working to give you a pre-release version of OpenCRG this week. While I was looking into the problem in which the offset of the reference line was not working when using a master file, I found out that this is not a bug directly. When loading include files, the code loads modifiers, options and data from the included file and in the end replaces the header with the one from the master file. The documentation says:

---

OpenCRG® files may contain references to other files, typically containing the actual data. In the "master" file, conventions for modifiers and options will typically be defined.

---

To solve the issue for the current version all the headers have to be defined in the master file. For the next version of the c-api I would propose that, as long as the master file contains no header fields, the one from the linked file will be taken. This solves the problem for the sample you sent me, but I am not sure if this a solution for how your customer is experiencing the problem initially because the header in the master file has to be empty.

I still have to discuss the changes with Marius. Still I want to provide you a preview version this week so you can do your testing next week.

31 March 2018:
I packed the OpenCRG 1.1.2 for you, so you can test it. The proposed change for included CRG in a master file did not go into this release.
After I spoke to Marius we are even more sure that this is a feature not a bug. We will discuss with Dr. Rauh on this.
The release has small changes in the Matlab API as well as in the C-API, please look into the release notes for more information.

[jorauh]

Without knowing what happend from 1.1.0 until now: the intended behavior war implemented in the Matlab API and was to be implemented in the C API resulting in identical behavior. The idea is to replace/modify the existing modifiers of an existing (big) crg file by a small file, which defines the new modifiers and includes the untouched big crg file. This allows to re-use of existing big crg files in many contexts without the need of modifying them.

[jorauh]

The intended behavior is documented in ./crg-txt/fileref.crg. It allows replacing the full MODS and/or OPTS block without touching the referenced (big) original crg file.

I could not download the above referenced sample files roadfiles.tar.gz
Please provide a sample if this feature implementation seems to be buggy.

This feature is not well documented in the full documentation at 4.4.7, so we should correct and add some words on it there.

[CarawaySeed42]

The link to the sample files is now fixed and the sample can be downloaded.

[jorauh]

Loading belgian_block_extended_visualization.crg by matlab's crg_read function fails, because the last (closing) $ line is missing.
After adding this line, both crg files can be loaded.
Since there is no MODS or OPTS block in the corrected belgian_block_extended_visualization.crg the resulting crg data struct is identical and will produce identical evaluation results.

This should also be true for any evaluation with the c-api. Did you check that already?

The extra visualization blocks provided for acar are not yet defined in the OpenCRG standard. The matlab's crg_read just ignores them. Are they supposed to show similar behavior as the OPTS and MODS blocks, i.e. the earlier read block overwrites the later read blocks completely?

I suppose this issue is related to adams/acar and it's visualization extensions. Please reopen if I am wrong.