Handling of the map

Currently the loading of and access to the map is handled in a more or less provisory way through IEnvironment::CreateMap(), the ILaneLocationQueryService and the ICoordConverter. There is the idea to change handling of the map. The list of painpoints and the full requirements still have to be written down in detail.

This issue should serve as a platform to identify the requirements and discuss concepts. The development approach will be discussed in the next OpenPASS meeting on the 12th of May.

Refinement

Customers

• Who are the actual users?
  • Mercedes-Benz & BMW (OpenPASS)
  • Ansys & BMW (internal SiL simulator)
  • Mercedes-Benz (internal simulator)
• Who are further stakeholders?
  • BMW / Thomas Bleher (Human in the loop Driving Simulator)
  • Mercedes-Benz (Human in the loop driving simulator)
  • Bosch (yase framework)

Requirements

As provider of a simulation toolchain I want to integrate different map engines through defined interfaces so that I am able to offer map support without implementing a map engine myself.

As provider of a simulation toolchain I want to integrate multiple map formats (e.g. OpenDRIVE, NDS).

As internal BMW SiL simulator customer I want to have an interface between the environment and the map engine so that the map engine is decoupled from the environment.

The scenario engine still must have access to the map either through the environment or directly.

Microscopic queries still have to be possible so that I'm able to use all details which a specific map format offers.

As provider of a simulation toolchain I want to have macroscopic queries to a map engine so that I'm able to get successors/adjacent lanes/routing information for all map formats.

The information where to find the map data has to allow for map specific information (e.g. area to load for NDS maps).

I want to re-use as much as possible types from other open source projects (e.g OSI) so that we don't reinvent the wheel and improve compatibility with OSI.

Key questions to clarify

• do we want to have an interface which is totally agnostic of the map format (e.g. road availability, configure OpenCRG loading)? => yes

• do we need the possibility to load the map not completely on startup but during runtime when needed? => yes

Customer Value

• What is the value we deliver?
• What are the problems we solve?
• What is the unique selling point of our Feature/Increment or are there already any Solutions we could profit from?

Acceptance Criteria: functional

(independently testable~, at least one for each implementation step~, clear pass and fail results~, Focus on what (customer use) not how (technical implementation)

Acceptance Criteria: non functional

Dependencies

Clarify Dependencies between other Areas and define them~, give a List to affected Topics/Epics and categories as upwards and downwards dependencies

Risk to fail Release Goals

• Knowledge Bottlenecks
• Unknowns ...

Possible Solutions

gather Ideas

Potential Epic Split

Be always aware of the scope and size. If the epic is not splittable~, please also indicate that here.

((Is it possible to split the epic? If so~, what would be the rough blocks that the epic could be split into?MVP?

Description

Some thing missing~, which is not documented above.