Additional fields for traffic model

[ReinhardBiegelIntech]

Besides sensor-specific applications we would like to use OSI for the traffic model in our agent based simulation.

Currently we are evaluating if a higher-level container for lanes and junctions will be needed (Roads).

For efficient agent-to-agent relations and comparisions, we require an additional lane-based coordinate system. It shall consist of the longitudinal and lateral position on the lane, the height (relative to a reference height), and the relative orientation to the lane (yaw).

We're appreciating any feedback on this topic and we'd like to propose our changes after an initial discussion.

@mohammadbahram what do you think? I guess for an agent OpenDirve would be a better format even for building up a street map?

[mohammadbahram]

@ReinhardBiegelIntech and @CarloVanDriestenBMW: We have already discussed this issue more often. In my opinion, OSI is not suitable for the traffic model (Smart Agents). That was not the purpose of OSI from my point of view. Complex APIs are required for driver modeling, which must, among other things, provide the road data with all the associated relations, etc.. In SPIDER it is basically the Xface structure which provides all this information and is not without reason so complex (Ok, a refactoring would be good here and there in code :) ).

[pmai]

I agree with @mohammadbahram on this; in the future, if such traffic model data is to be exchanged between Independent Software modules (something that XFace serialization also provides), I think it could be implemented as an additional layer on-top/beside OSI, using similar mechanisms (currently Proto Files as IDL and Protobuf encoding, but in the future likely something like OMG IDL and multiple encodings (e.g. DDS-XTypes)). I.e. it would be distinct message types in any case...

If needed for short term use, you can of course also just extend OSI messages with own private fields (e.g. using field ids > 100000 for example), which would be compatible with existing OSI modules, like sensor models, since unknown fields are ignored.

[mohammadbahram]

@pmai @ReinhardBiegelIntech @CarloVanDriestenBMW : Perhaps OSI has to be renamed to "Open Sensor Interface", in order to avoid such ambiguities?

I guess it is too late fort that ^^

Update:
@mohammadbahram and @ReinhardBiegelIntech we will think about a global interface architecture that allows integrates the requirements of OpenPass, e.g. a "osi_world_interface" or something alike

[clemenshabedank]

With an initiative from the SETLevel 4to5 project, the topic of enabling to connect Traffic Participant models is currently being introduced with OpenSimulationInterface/osi-sensor-model-packaging#56 and #401.
Any contribution or ideas better tailoring the OSI content for this usecase (e.g. with the introduction of lane-based coordinate system, as stated above, or something else) is welcome to join the discussions in the respective workpackages.
If someone is interested, please answer here, and I will try to make sure to invite him/her to the respective meetings.
@ReinhardBiegelIntech

[clemenshabedank]

Issue being closed because topic handled elsewhere.