Definiton of external references

[DerBaertige]

Description

OSI currently offers no options for an internal data management of the source of an object. Therefore an additional identifier is proposed to reference to external standards or external sources like models or physical sensors. For an exchange and a traceability, especially in the post processing of tests, it is important to identify the source of an object.

Currently, there is only a numeric identifier to describe the different object within OSI. As there should be an interoperability within other standards, especially the OpenX-Standards, but also third party simulations, an additional and more generic reference identifier is needed.

As the identification in different standards are more complex than only using a numeric id, a representation based on a list of strings is chosen. The background to this is the exemplary description of a Lane within other standards. OpenDRIVE 1.6 for example describes the outcome for an OSI-Lane bases on three different values and types:

• RoadId is defined as String
• S-Value of LaneSection is defined as Double
• LaneId is defined as Integer

Check the checklist

• My code and comments follow the style guidelines and contributors guidelines of this project.
• I have performed a self-review of my own code.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests / travis ci pass locally with my changes.

[DerBaertige]

The outcome of the Harmonisierungs Meeting (11.03.2021) was that an optional URI-reference to the origin source schould be added, as not alway the source (like the map_reference in GroundTruth) is known or defined within OSI.

In addition, the usage of the ExternalReference in the different messages has be defined as repeated value, as one object/segment can be derived from multible object and also multible sources.

[DerBaertige]

Outcome from the Harmonisierungs-Meeting (25.03.2021):

• The OpenDRIVE 1.6 Center-Lane reference can be dropped from the exemplary description, as it cannot become an OSI lane.
• Follow-up discussion with @thempen: For OpenDRIVE 1.6 a reference to a potential junction is not necessary, as the OpenDRIVE road description itself stores its own junction. Storing this data leads to unnecessary and derivable redundancy, since the id of t_road must always be part of the reference description.

[kmeids]

@DerBaertige, @thempen are there still any changes to be done or could this be set to readyForCCB ?

[DerBaertige]

@kmeids I am working on it and there are some changes the next days. After this and a final discussion in the Harmonization meeting, we can set it to ready for CCB.

[kmeids]

Output CCB 28.04.2021:

1. Check review comments.

[ThomasNaderBMW]

ßWe should point out, that this is not mandatory, but optional. Also at the lother places, what do you think

[kmeids]

Include URI as a suggestion instead of a must, considering that it can also be a model-reference.
Take a look at the map, and model references.
Possibly to adapt this definition also to model and map references.

[kmeids]

Insert list of predefined types (like those for OpenX) and general rules/guidance for user-defined standards or objects.

[kmeids]

Output CCB 12.05.2021:

1. Remove the version from the comment description, name should be enough (OpenDRIVE instead of OpenDrive 1.6)
2. Use the domain name notation, e.g. net.asam.opendrive instead of OpenDRIVE.
3. Indicate that the type field should be lower case.

[kmeids]

Add a note maybe:
More details on how identifiers are set to be used for referencing external objects are given in places where the ExternalIdentifier message is used.

[kmeids]

Output CCB 12.05.2021:

1. @max-rosin, documentation review to be done and please set the tag to "ReadyToMerge" when done.
2. @pmai to merge after Max is done.

[max-rosin]

@DerBaertige: The changes during doc review turned out quite big. Can you please review my changes in fc20c92 to make sure that I did not inadvertently change your intended meaning. If everything is alright, please add the "ReadyToMerge" tag. Thank you!

[DerBaertige]

@max-rosin: In general, everything is in my intended meaning. However, I noticed that for the description of the references to OpenX different phrases are used, is this intentional. Else, we should drop line 222 in osi_common.proto, looks like an older merge error. Can you check it? Thanks a lot.

1. For example, to reference (...) defined in (...) the items should be set as following:

• osi_trafficsign.proto (165)
• osi_trafficlight.proto (50)
• osi_lane.proto (58)

2. For (...) the items should be set as following:

• osi_roadmarking.proto (64)

3. For (...), references to (...) should be set as following:

• osi_object.proto (48, 56, 400)

[max-rosin]

@DerBaertige: I removed the stray line and aligned the wording across files.
In my opinion, the branch is ready to be merged.

[HendrikAmelunxen]

Output from Harmonization meeting (01.06.21):
@pmai Since Review by Max is done could you pleas merge (as aggreed with Kmeid in CCB)