References may not be consistent

[arauschert]

Describe the bug

There are two concepts of references:

1. model_reference (reference to 3d model asset)
2. ExternalReference (which can reference also a 3d asset)

This may confuse the user.

For example in the RoadMarking element, there is no model_reference attribute, while for all other elements (traffic light, traffic sign, ground truth, moving object, stationary object) there are model_references.

A second example would be that the BoundingBox element also has a model_reference attribute, which duplicates the model_reference attribute of the parent elements (traffic light/sign, moving object...).

Furthermore, the road marking element of type stop line, where there is no direct link to the corresponding traffic sign / traffic light.

Describe the expected behavior

The question would be in references can be defined in a consistent way.

Show some screenshots

[pmai]

There are two concepts of references:

1. model_reference (reference to 3d model asset)
2. ExternalReference (which can reference also a 3d asset)

While they both reference something that is not shipped with OSI (hence the "reference" in the name), the intent is different:

• External Reference as used in the objects/etc. provides references to sources of the given information, e.g. OpenDRIVE or OpenSCENARIO Ids. There is no ready-made use of these for 3D assets. One can define this if one wants to, but that is outside of the OSI-specified content.

• model_reference is currently the way to attach 3d assets, even though the way of resolving these and their formats is currently up to the user again, as no common consensous for this exists for all use cases. This might be enhanced with additional information going forward, however no one has yet proposed a specific extension here.

This may confuse the user.

It really should not, at least as far as OSI documentation goes there is no suggestion that I'm aware of, that would recommend the use of ExternalReference for 3D assets... If some other standard suggests this and defines the semantics, then it should provide for rules on the relationship to model_reference, and all should be clear again.

For example in the RoadMarking element, there is no model_reference attribute, while for all other elements (traffic light, traffic sign, ground truth, moving object, stationary object) there are model_references.

I think a good case could be made to add model_reference to RoadMarking, however it would have to be clarified what kind of model is expected there for which cases, as there are multiple types of road markings, and the role of the model might differ (or not - someone working out a proposal should look at this).

A second example would be that the BoundingBox element also has a model_reference attribute, which duplicates the model_reference attribute of the parent elements (traffic light/sign, moving object...).

It does not duplicate it, as the only use of BoundingBox elements is in the form of sub-bounding boxes (the overall bounding box of an object is never represented as a BoundingBox element), and this allows the attachment of models to these seprately defined parts. If this is done, then this obviously provides an alternative to the model_reference on the top-level (if the receiver information choses to use the sub-bounding boxes and referenced models), if it is not supplied then only the overall model is available.

Furthermore, the road marking element of type stop line, where there is no direct link to the corresponding traffic sign / traffic light.

I do not quite understand this sentence, as there is no road marking element type stop line in OSI: Either you have a road marking element with TYPE_SYMBOLIC_TRAFFIC_SIGN, and proper codes to signify a stop line, or you have a road marking with TYPE_GENERIC_LINE, that however does not represent a stop line.

[arauschert]

Hi @pmai ! Thanks for your answers.
The part that confused me about referencing 3d models in the ExternalReference is here:

If we use GroundTruth::model_reference we can leave this field empty. Does that mean that the ExternalReference refers to a 3d model asset rather than an OpenDRIVE file?

I think a good case could be made to add model_reference to RoadMarking, however it would have to be clarified what kind of model is expected there for which cases, as there are multiple types of road markings, and the role of the model might differ (or not - someone working out a proposal should look at this).

Yes, hat would be great because we're missing the model_reference attribute in the RoadMarking element and would need it. How should we proceed with this? To me it would be quite straightforward to add it. Which different types of road markings do you mean? They are all painted on the road surface.

About the stop line: sorry, I was a bit unclear. Yes, I mean a road marking element with TYPE_SYMBOLIC_TRAFFIC_SIGN. How can this be semantically linked to a traffic light?

[pmai]

Hi @pmai ! Thanks for your answers. The part that confused me about referencing 3d models in the ExternalReference is here: If we use GroundTruth::model_reference we can leave this field empty. Does that mean that the ExternalReference refers to a 3d model asset rather than an OpenDRIVE file?

Thanks for pointing this out, I think this sentence is really likely to lead to confusion, and we should change that. The meaning was likely intended to convey that if neither map_reference nor model_reference are present in GroundTruth, one might want to use ExternalReference to provide an OpenDRIVE map, so that some roadmap/environment model is present, not to suggest that this is another way to provide a 3D model. However there are a) far less confusing ways to express that, and b) use cases that do not need any enivronment/road network model beside the info contained in OSI, so the suggestion is even confusing in this regard.

I'll make a note to propose changed wording here, that more clearly points this out.

That being said, since ExternalReference is neutral in the kind of info it can reference, one could use it to also reference 3D assets, however that would need layered specs to ensure this is uniformly handled and understood, so I would try to stay with model_reference when that is sufficient.

I think a good case could be made to add model_reference to RoadMarking, however it would have to be clarified what kind of model is expected there for which cases, as there are multiple types of road markings, and the role of the model might differ (or not - someone working out a proposal should look at this).

Yes, hat would be great because we're missing the model_reference attribute in the RoadMarking element and would need it. How should we proceed with this? To me it would be quite straightforward to add it. Which different types of road markings do you mean? They are all painted on the road surface.

I think a PR could be easily generated to add the model_reference; the analysis I would see is whether the role of the model_reference is really the same for all kinds of road markings, or whether there are special rules needed for some of them, i.e. is the role of the model referenced the same for a generic line as it is e.g. for a symbolic traffic sign. If this can be answered in the affirmative, then wording to that effect explaining in the field description would be sufficient; if there are maybe certain differences, then this should be pointed out. I am not saying that there need to be differences, I'm just noting that the proposer should think this through given that road marking is a bit of a mixed bag. Other than that the PR should really be straight forward.

About the stop line: sorry, I was a bit unclear. Yes, I mean a road marking element with TYPE_SYMBOLIC_TRAFFIC_SIGN. How can this be semantically linked to a traffic light?

There is currently no way to link this directly in OSI, the same as e.g. for a stop sign and its stop line, which are just a sign and a roadmarking assigned to the same lanes/logical lanes and somewhat colocated, but there is no direct link. Similarly, currently there is no semantic information on the role that colocated traffic signs and traffic lights play, e.g. a stop sign and a traffic light colocated on the same pole: Currently the receiver needs to analyse this based on lane/logicallane-validity and colocation on their own.

One could use mapping information via ExternalReference to the same OpenDRIVE entity to surmise this, however this seems very roundabout; so one could think of introducing direct linking within signs, roadmarks and traffic lights to convey such information.

Probably the easiest would be to have related_trafficsigns, related_trafficlights, related_roadmarkings repeated Identifier fields in all of these, however that should probably be discussed in a broader group...

[arauschert]

I think a PR could be easily generated to add the model_reference; the analysis I would see is whether the role of the model_reference is really the same for all kinds of road markings, or whether there are special rules needed for some of them, i.e. is the role of the model referenced the same for a generic line as it is e.g. for a symbolic traffic sign.

I checked the specification and didn't find any difference in the role of the different road marking types that would affect the model_reference.
The proposal for the description of the model_reference attribute would be analog to the other elements with a model_reference attribute:

    // Opaque reference of an associated 3D model of the road marking.
    //
    // \note It is implementation-specific how model_references are resolved to
    // 3d models.
    //

For the linking topic we can also create a new issue.

[jdsika]

I would love to have a constructive (partial) solution for v3.8.0 . Let us discuss this in the next meeting.

[asadekasam]

OSI CCB 30.10.2025: @arauschert can create a PR for resolution