World interface fixes #263

[ReinhardBiegelIntech]

I'd like to show our first proposal of an "world interface" to the community. Feedback and questions are welcome.

[ghost]

Thank you very much for this PR. We will look into it the earliest we can!

[ghost]

Hello @ReinhardBiegelIntech,
sorry for the late reply.
I have tried to discover the intention behind the WorldInterface in your pull request. Unfortunately, I don't really get where this interface should be used. Is it meant to be an extension of the GroundTruth?
I also don't understand why, within an interface, map features are generated. In OSI, where not restricted to the use of OpenDRIVE maps. Wouldn't it be smarter to locate on a map in the user-code and generate road/lane information here? Regards, Ludwig

[ReinhardBiegelIntech]

Hello @LudwigFriedmannBMW,

Yes, the interface is meant to be an extension. Maybe the naming is a bit misleading. The name is just a first proposal originating from a short discussion between @CarloVanDriestenBMW and us at in-tech.

We would like to use this interface the generate a different look at the ground truth - more from the perspective of a simulator than from a sensor.
We are actively developing the openPASS simulator (https://projects.eclipse.org/projects/technology.simopenpass). We use a representation of the road network that's somewhere in between OpenDRIVE and OSI. We have chosen this approach to simplify queries on the map data from a driver's and/or navigation system's perspective.

So why this extension to OSI? We'd like to re-use the common parts of OSI to allow simulation of OSI-compatible sensors, and at the same time use the same serialization/deserialization mechanisms to exchange the "extended" ground truth with other systems.
For example, the simulator can calculate the position of a vehicle measured along a road's axis and then store this information inside the OSI WorldInterface for later reuse (by other components).

I hope this will somwhat answer your question. Please feel free to ask for more information.

[pmai]

For this to be included into OSI, the other components you mention would have to be specified, i.e. are the other components something that are not OpenPASS-specific? Only then placing this into OSI would make sense to me. Otherwise this can just be an OpenPASS-specific extension, living in OpenPASS, or am I missing something?

[ghost]

I'd like to rephrase the question: Would it be sufficient for your purpose if the user-specific implementation (OpenPASS) was provided a reference to the map (#277) in addition to geo-referenced (#275) Cartesian positions?

[ghost]

@ReinhardBiegelIntech I had a talk with Arun Das and reviewed your changes again. In my opinion your changes are already accounted for since OSI 3.0.0? Could you clarify the need for the road types and why you need the logical structure of a road? please have a look at the new doxygen documentation of lanes. There are a lot of images explaining their usage.

[ReinhardBiegelIntech]

@CarloVanDriestenBMW Thanks for the update on this issue. We will have a more detailed look at the latest OSI changes as soon as possible.

[ghost]

@ReinhardBiegelIntech it would be great to resolve this until end of this month if possible for you?

[ReinhardBiegelIntech]

I'm sorry that I wasn't able to answer your questions in time. We had a discussion about the future need for the WorldInterface today and decided not to pursue the integration of the WorldInterface into OSI anymore. So closing this PR was just in time.

@pmai To answer your last question: Yes, the idea was that "other components" reside outside of openPASS. But we currently have no need for that anymore.