mantle-api issueshttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues2024-03-20T07:07:33Zhttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/73Proposal to add UML diagrams to docs for further clarification of the interac...2024-03-20T07:07:33ZMartin StumpProposal to add UML diagrams to docs for further clarification of the interactions between classesThe documentation currently only shows, how singular classes and functions can be used.
However, it does not clarify how multiple classes and functions are meant to interact.
I propose to add UML diagrams to the documentation, wherever ...The documentation currently only shows, how singular classes and functions can be used.
However, it does not clarify how multiple classes and functions are meant to interact.
I propose to add UML diagrams to the documentation, wherever it makes sense to clarify such interaction.
To that end, we should settle on a definition of, and consise wording for the different subdomains covered by the API:
* Environment
* Scenario
* Simulator (Execution)
* ...
The diagrams could be added to a page that Doxygen calls a [Topic](https://www.doxygen.nl/manual/grouping.html).
See [add-plantuml-diagrams-to-docs](https://gitlab.eclipse.org/mstump/mantle-api/-/tree/add-plantuml-diagrams-to-docs) for a complete example using Doxygen with PlantUML and Doxygen Awesome:
![image](/uploads/c35954dbb6999edc1a9a1bb2b30a8422/image.png)
Cheers,
Martin
Martin Stump <martin.stump@mercedes-benz.com> on behalf of Mercedes-Benz Tech Innovation GmbH, [Provider Information](https://github.com/mercedes-benz/foss/blob/master/PROVIDER_INFORMATION.md)Martin StumpMartin Stumphttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/72Docs are incomplete, since the `mantle_api` ns is undocumented2024-03-20T07:07:33ZMartin StumpDocs are incomplete, since the `mantle_api` ns is undocumentedCurrently, Doxygen does not generate pages for most non-class constructs (e.g. enums and free funcs), since the `mantle_api` ns is undocumented.
Cheers,
Martin
Martin Stump <martin.stump@mercedes-benz.com> on behalf of Mercedes-Benz Te...Currently, Doxygen does not generate pages for most non-class constructs (e.g. enums and free funcs), since the `mantle_api` ns is undocumented.
Cheers,
Martin
Martin Stump <martin.stump@mercedes-benz.com> on behalf of Mercedes-Benz Tech Innovation GmbH, [Provider Information](https://github.com/mercedes-benz/foss/blob/master/PROVIDER_INFORMATION.md)Martin StumpMartin Stumphttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/31IEnvironment is not stepable2024-03-19T09:36:03ZMartin StumpIEnvironment is not stepableDear all,
`IEnvironment` does currently not mandate a `Step()` function cf. [`environmentInterface.h`](https://gitlab.eclipse.org/eclipse/simopenpass/opSimulation/-/blob/openscenarioengine-prototyping/sim/include/environmentInterface.h#...Dear all,
`IEnvironment` does currently not mandate a `Step()` function cf. [`environmentInterface.h`](https://gitlab.eclipse.org/eclipse/simopenpass/opSimulation/-/blob/openscenarioengine-prototyping/sim/include/environmentInterface.h#L24).
Is there a reason it should not be stepable?
Consider the following usage example:
```c++
std::shared_ptr<IEnvironment> m_environment;
std::shared_ptr<IScenarioEngine> m_scenario_engine;
SimulatorImpl::SimulatorImpl()
{
m_environment = std::make_shared<EnvironmentImpl>();
m_scenario_engine = std::make_shared<ScenarioEngineImpl>(m_environment);
...
}
void SimulatorImpl::Step()
{
m_environment->Step();
m_scenario_engine->Step();
...
}
```
If we agreed on making `IEnvironment` stepable, we could derive from `IStepable` e.g.:
```c++
struct IStepable
{
virtual ~IStepable() = default;
virtual bool PreStep() = 0;
virtual bool Step() = 0;
virtual bool PostStep() = 0;
};
```
The need for `PreStep()` and `PostStep()` would need to be discussed as well.
Cheers,
Martin
Martin Stump <martin.stump@mercedes-benz.com> on behalf of Mercedes-Benz Tech Innovation GmbH, [Provider Information](https://github.com/mercedes-benz/foss/blob/master/PROVIDER_INFORMATION.md)https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/74Gather Requirements for Interface between Environment and Simulator2024-03-19T09:36:03ZDavid WeißGather Requirements for Interface between Environment and SimulatorThere has been a discussion about how a simulator would interact with the environment (e.g. stepping) and it was agreed that there should be a new interface class in MantleAPI for that (see https://gitlab.eclipse.org/eclipse/openpass/man...There has been a discussion about how a simulator would interact with the environment (e.g. stepping) and it was agreed that there should be a new interface class in MantleAPI for that (see https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/merge_requests/138). For this I would like to gather the requirements of such an interface.https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/39Discussion: EntityRepository - Calling Delete invalidates iterator of GetEnti...2024-03-01T09:07:30ZRené Parisrene.paris@in-tech.comDiscussion: EntityRepository - Calling Delete invalidates iterator of GetEntitiesFrom the perspective of a C++ programmer it seems totally natural, that the following construct is a bug:
```cpp
for (const auto& entity : repository->GetEntities())
{
repository->Delete(entity->GetUniqueId());
}
```
Yet, I'd like to...From the perspective of a C++ programmer it seems totally natural, that the following construct is a bug:
```cpp
for (const auto& entity : repository->GetEntities())
{
repository->Delete(entity->GetUniqueId());
}
```
Yet, I'd like to open a discussion here if this is the user experience, the interface should offer.
I thought about some ways to solve that, e.g. using RAII
```cpp
auto manipulation_context = repository->GetManipulationContext();
for (const auto& entity : repository->GetEntities())
{
manipulation_context->Delete(entity->GetUniqueId());
}
// when the manipulation_context goes out of scope it actually executes all delete calls at once
```Jupp TscheakAndreas RauschertMartin StumpJupp Tscheakhttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/71MovementDomain is to inflexible for FollowTrajectoryControlStrategy2024-02-21T07:46:50ZDavid WeißMovementDomain is to inflexible for FollowTrajectoryControlStrategyCurrently every ControlStrategy has a predefined MovementDomain. For the FollowTrajectoryControlStrategy this is MovementDomain::kBoth. However the time of each PolyLinePoint is optional (as it is in OpenScenario). But only if the time i...Currently every ControlStrategy has a predefined MovementDomain. For the FollowTrajectoryControlStrategy this is MovementDomain::kBoth. However the time of each PolyLinePoint is optional (as it is in OpenScenario). But only if the time is given for each point, then the trajectory defines the movement of the vehicle in both domains. If there are no times given the trajectory defines only the path of the movement (in OSI it is then called FollowPathAction), i.e. the lateral movement. In this case the longitudinal movement has to be determined by other means. Since there can only be one ControlStrategy for each movement domain, in the current version of MantleAPI, it is not possible for the simulator the determine lateral movement in this case.Andreas RauschertAndreas Rauscherthttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/62Rename master branch to main2023-11-06T15:01:49ZRené Parisrene.paris@in-tech.comRename master branch to mainBoth the simulation core and the openScenarioEngine refrain from using the term "master" branch and follow the example of GitHUB (since Oct. 2020) to use a "main" branch instead.Both the simulation core and the openScenarioEngine refrain from using the term "master" branch and follow the example of GitHUB (since Oct. 2020) to use a "main" branch instead.https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/70Test uses deprecated API2023-10-17T11:38:22ZMichael BehrischTest uses deprecated APIinterface_test.cpp uses
```
auto& host_vehicle = repo.Create(0, "host", vehicle_properties);
```
It should probably replaced by
```
auto& host_vehicle = repo.Create("host", vehicle_properties);
```
at least this change makes the war...interface_test.cpp uses
```
auto& host_vehicle = repo.Create(0, "host", vehicle_properties);
```
It should probably replaced by
```
auto& host_vehicle = repo.Create("host", vehicle_properties);
```
at least this change makes the warning go away :-).https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/33Add mock code and unit tests to guarantee the stability of the API2023-10-17T11:23:41ZMartin StumpAdd mock code and unit tests to guarantee the stability of the APIDear all,
I believe we should begin adding more mock code and unit tests to guarantee the stability of the API in the future while working our way up to v1.0.0.
Creating mock classes for the whole API should be a community effort, sinc...Dear all,
I believe we should begin adding more mock code and unit tests to guarantee the stability of the API in the future while working our way up to v1.0.0.
Creating mock classes for the whole API should be a community effort, since it is tedious work that involves a lot of boilerplate code.
What we get in return, however, will be a way to automatically check for any break in the API, especially when we set up the CI for this project.
Additionally, consumers can use the mock code to implement the API.
I will provide a draft PR to start the discussion on how we could approach this.
I know that work has been started e.g. in `test_utils.h`, but as of now it is incomplete.
Cheers,
Martin
Martin Stump <martin.stump@mercedes-benz.com> on behalf of Mercedes-Benz Tech Innovation GmbH, [Provider Information](https://github.com/mercedes-benz/foss/blob/master/PROVIDER_INFORMATION.md)https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/57Proposal for creating an OpenPASS project versioning system2023-10-13T06:59:04ZStephen RyanProposal for creating an OpenPASS project versioning systemHi all,
Here is a collection of the information of the versioning from the various issues and merge requests.
## Versioning
### From [issues/43](https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/43):
It is proposed to u...Hi all,
Here is a collection of the information of the versioning from the various issues and merge requests.
## Versioning
### From [issues/43](https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/43):
It is proposed to use the industry-standard Semantic Versioning from [semver.org](https://semver.org/). This is summarized as:
> Given a version number MAJOR.MINOR.PATCH, increment the:
> 1. MAJOR version when you make incompatible API changes
> 2. MINOR version when you add functionality in a backward compatible manner
> 3. PATCH version when you make backward compatible bug fixes
>
> Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
Tags should be the semantic version, prefixed with "v", see https://github.com/cpm-cmake/CPM.cmake/wiki/Preparing-projects-for-CPM.cmake, and as an example see https://github.com/gabime/spdlog/tags.
## Changelogs
### From [issues/43](https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/43):
Ideally, the changelog would be automatically generated from the commit messages. These commits should be squashed. This can be done with the specification from [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/), which works well with Semantic Versioning. As a summary from the website:
> The commit message should be structured as follows:
>```
><type>[optional scope]: <description>
>
>[optional body]
>
>[optional footer(s)]
>```
So, an example message could be:
>```
>feat: allow provided config object to extend other configs
>
>BREAKING CHANGE: `extends` key in config file is now used for extending other config files
>```
The ways to indication version changes are:
- As a type, `fix` corresponds to an increment in the `PATCH` version in Semantic Versioning.
- As a type, `feat` corresponds to an increment in the `MINOR` version.
- `BREAKING CHANGE` in the commit body or a `!` after the type/scope indicates an increment in the `MAJOR` version.
More details are on the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) website.
### From [issues/33](https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/33):
Mocks and tests for the whole API would need to be implemented to detect incompatable API changes for incrementing the MAJOR version.
Benefits:
- Easy way of detecting major version changes, meaning API breaks. Automatic checking with CI.
- Consumers can use the mock code to implement the API.
Example implementation of the mock code has been done in [merge_requests/80](https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/merge_requests/80).
- The mock classes are a replacement of `test_utils.h`, which is split into multiple files, with one mock per class. E.g., `MockEnvironment` and `EnvironmentTest` for `IEnvironment`.
- Currently contains mocks for `IIdentifiable`, `IEnvironment`, `ILaneLocationQueryService`, and `IEntity`.
- Tested on Mercedes-Benz use cases.
## Release checklist
There should be a checklist for creating each release. As an example, this could be:
- Create release notes from commits
- Update the README or documentation to include information about each version, including release notes, known issues, and upgrade instructions.
- Use Git tags and releases to mark specific versions in the repository, making it easier to download a release
- Etc.
## Remaining work for the first release
- [ ] Create API Mocks for each class.
- [ ] Setup CI so that changelogs can be automatically created and major version changes can be detected.
- [ ] Think about how to enforce commit messages
- [ ] Set up squashing merge commits for every merge request
- [ ] Need a well formatted template for merge commit messages
Anything else?https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/67Fix CI script for doxygen2023-09-27T13:45:46ZNaida GoroFix CI script for doxygen- Ensuring that `doxy_version` is set.
- Filtering should be encapsulated to a function.- Ensuring that `doxy_version` is set.
- Filtering should be encapsulated to a function.René Parisrene.paris@in-tech.comRené Parisrene.paris@in-tech.comhttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/68CI Doxygen build: error: Problems running gswin32c.exe. Check your installation!2023-09-26T09:12:00ZRené Parisrene.paris@in-tech.comCI Doxygen build: error: Problems running gswin32c.exe. Check your installation!https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/65Pascal Name Conflict in MinGW2023-09-18T14:09:05ZRaghunandan Netrapalli MadhusudhanPascal Name Conflict in MinGWThe usage of current units library in the MantleAPI would generate a "pascal" name conflict when working on opSimulation in MinGW.
![image](/uploads/c877841c6d53e28add5c78935eb0d090/image.png)The usage of current units library in the MantleAPI would generate a "pascal" name conflict when working on opSimulation in MinGW.
![image](/uploads/c877841c6d53e28add5c78935eb0d090/image.png)https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/61Agenda for the meeting "IMap Interface - Revise current status"2023-09-06T15:23:31ZAnastasiia VolkovaAgenda for the meeting "IMap Interface - Revise current status"Hi all,
Please announce the topics you want to discuss on the meeting "**IMap Interface - Revise current status**" (28 July 2023).
Your offers will be gathered in agenda and a meeting summary will be compiled further.
Best regards, Ana...Hi all,
Please announce the topics you want to discuss on the meeting "**IMap Interface - Revise current status**" (28 July 2023).
Your offers will be gathered in agenda and a meeting summary will be compiled further.
Best regards, Anastasiiahttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/40Handling of the map2023-08-25T07:23:51ZAndreas RauschertHandling of the mapCurrently 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 ...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.https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/41Discussion: Basic calculations on internally used vector type2023-07-27T06:54:34ZRené Parisrene.paris@in-tech.comDiscussion: Basic calculations on internally used vector typeFollowing @jtschea's comment here, https://gitlab.eclipse.org/eclipse/openpass/openscenario1_engine/-/merge_requests/121#note_1114246, I also think that it's a good idea to have some basic calculations on our vector type directly in mant...Following @jtschea's comment here, https://gitlab.eclipse.org/eclipse/openpass/openscenario1_engine/-/merge_requests/121#note_1114246, I also think that it's a good idea to have some basic calculations on our vector type directly in mantle, such as length.
Please feel free to put your ideas and thought on that here.https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/18Collection of inconsistencies after initial assessment incl. potential for mo...2023-07-25T09:29:15ZMartin StumpCollection of inconsistencies after initial assessment incl. potential for modernizationDear all,
This issue is a container for all the little changes I would like to propose or discuss after my initial assessment of the code base.
- [x] `IsEqual` is not `noexcept`, but used in `noexcept` func, see [floating_point_helper...Dear all,
This issue is a container for all the little changes I would like to propose or discuss after my initial assessment of the code base.
- [x] `IsEqual` is not `noexcept`, but used in `noexcept` func, see [floating_point_helper.h:40](https://gitlab.eclipse.org/eclipse/simopenpass/scenario_api/-/blob/master/MantleAPI/include/MantleAPI/Common/floating_point_helper.h#L40)
- [x] add `override` keyword, e. g. [i_entity.h:101,107](https://gitlab.eclipse.org/eclipse/simopenpass/scenario_api/-/blob/master/MantleAPI/include/MantleAPI/Traffic/i_entity.h#L101)
- [x] add closing comments on namespaces, e. g. [orientation.h:32](https://gitlab.eclipse.org/eclipse/simopenpass/scenario_api/-/blob/master/MantleAPI/include/MantleAPI/Common/orientation.h#L32)
- [ ] discuss include style `""` vs. `<>`
- [ ] discuss ostream operators for all types
- [ ] discuss the rule of three/five/zero, e. g. [i_geometry_helper.h:28](https://gitlab.eclipse.org/eclipse/simopenpass/scenario_api/-/blob/master/MantleAPI/include/MantleAPI/Common/i_geometry_helper.h#L28), see [The rule of three/five/zero](https://en.cppreference.com/w/cpp/language/rule_of_three) and [C.21: If you define or =delete any copy, move, or destructor function, define or =delete them all](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rc-five)
- [x] discuss trailing return type
- [ ] fix/explain `IControllerConfig` copy ctor (`std::make_unique` on raw pointer into `std::vector<std::shared_ptr<>>`)
- [ ] fix var and param naming, e. g. [poly_line.h:36](https://gitlab.eclipse.org/eclipse/simopenpass/scenario_api/-/blob/master/MantleAPI/include/MantleAPI/Common/poly_line.h#L36)
- [ ] harmonize enum class defs, e. g. `weather.h` vs. `control_strategy.h` vs. `entity_properties.h`
- [ ] harmonize operator defs (some are friends, some are members etc.)
- [ ] if possible, use `constexpr` for operators, e. g. [orientation.h:84](https://gitlab.eclipse.org/eclipse/simopenpass/scenario_api/-/blob/master/MantleAPI/include/MantleAPI/Common/orientation.h#L31)
- [x] improve floating point comparison, see [Comparing Floating Point Numbers, 2012 Edition](https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/)
- [x] include what you use, e. g. `time_utils.h` is missing `#include <chrono>`
- [x] introduce `nodiscard` keyword, e. g. [i_geometry_helper.h:37](https://gitlab.eclipse.org/eclipse/simopenpass/scenario_api/-/blob/master/MantleAPI/include/MantleAPI/Common/i_geometry_helper.h#L37)
- [x] introduce ClangTidy, see #6 and !7
- [ ] Move `SetSpeed` to `IEntity`, see #8
- [x] reduce dir depth (move `include` and `test` to root dir)
- [ ] reduce magic numbers, e. g. [road_condition.h:32](https://gitlab.eclipse.org/eclipse/simopenpass/scenario_api/-/blob/master/MantleAPI/include/MantleAPI/EnvironmentalConditions/road_condition.h#L32)
- [x] reduce using directives, see #5
- [ ] remove superfluous ctors, e. g. [vector.h:27,29](https://gitlab.eclipse.org/eclipse/simopenpass/scenario_api/-/blob/master/MantleAPI/include/MantleAPI/Common/vector.h#L29)
- [ ] remove superfluous default init values, e. g. [i_controller_config.h:46](https://gitlab.eclipse.org/eclipse/simopenpass/scenario_api/-/blob/master/MantleAPI/include/MantleAPI/Traffic/i_controller_config.h#L46)
- [x] use `= default` for ctors/dtors, e. g. [i_controller_config.h:46](https://gitlab.eclipse.org/eclipse/simopenpass/scenario_api/-/blob/master/MantleAPI/include/MantleAPI/Traffic/i_controller_config.h#L32)
- [ ] use `auto`, apply AAA rule, see [GotW #94 Special Edition: AAA Style (Almost Always Auto)](https://herbsutter.com/2013/06/13/gotw-94-special-edition-aaa-style-almost-always-auto/)
- [ ] use `std::tie` for comparison, e. g. [entity_properties.h:168](https://gitlab.eclipse.org/eclipse/simopenpass/scenario_api/-/blob/master/MantleAPI/include/MantleAPI/Traffic/entity_properties.h#L168)
- [x] use `using` instead of `typedef`, e. g. [orientation.h:31](https://gitlab.eclipse.org/eclipse/simopenpass/scenario_api/-/blob/master/MantleAPI/include/MantleAPI/Common/orientation.h#L31)
After discussion, this issue can be split into smaller chunks for resolution.
Regards,
Martin
Martin Stump <martin.stump@mercedes-benz.com> on behalf of Mercedes-Benz Tech Innovation GmbH, [Provider Information](https://github.com/mercedes-benz/foss/blob/master/PROVIDER_INFORMATION.md)https://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/34Discussion: Gathering Map Query Interfaces2023-07-13T06:26:34ZXiao Panxiao.pan@ansys.comDiscussion: Gathering Map Query InterfacesIn this issue, we would like to collect the general and often-used query functions for the map, from existing projects:
- ASTAS
- OpenPass
- OSIQL
Note: this Issue is currently only visible to team members.In this issue, we would like to collect the general and often-used query functions for the map, from existing projects:
- ASTAS
- OpenPass
- OSIQL
Note: this Issue is currently only visible to team members.Xiao Panxiao.pan@ansys.comXiao Panxiao.pan@ansys.comhttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/56Unable to communicate acquire global position2023-06-22T13:27:30ZRené Parisrene.paris@in-tech.comUnable to communicate acquire global positionBoth, OpenSCENARIO and open_simulation_interface, support a routing actionto tell an entity that it should acquire a (global) position.
Reference:
- [AcquirePositionAction](https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_...Both, OpenSCENARIO and open_simulation_interface, support a routing actionto tell an entity that it should acquire a (global) position.
Reference:
- [AcquirePositionAction](https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/AcquirePositionAction.html)
- [osi3::TrafficAction::AcquireGlobalPositionAction](https://opensimulationinterface.github.io/open-simulation-interface/structosi3_1_1TrafficAction_1_1AcquireGlobalPositionAction.html)
Currently, I see no possibility to communicate this wish down to an environment simulator.René Parisrene.paris@in-tech.comAndreas RauschertRené Parisrene.paris@in-tech.comhttps://gitlab.eclipse.org/eclipse/openpass/mantle-api/-/issues/42Proposal: implement std::to_string for Mantle types instead of ostream operators2023-05-10T12:23:55ZMartin StumpProposal: implement std::to_string for Mantle types instead of ostream operatorsIf we implemented `std::to_string` for all Mantle types and dropped the ostream operators, we could get rid of the `ostream` header.
What do you think?
Cheers,
Martin
Martin Stump <martin.stump@mercedes-benz.com> on behalf of Mercedes...If we implemented `std::to_string` for all Mantle types and dropped the ostream operators, we could get rid of the `ostream` header.
What do you think?
Cheers,
Martin
Martin Stump <martin.stump@mercedes-benz.com> on behalf of Mercedes-Benz Tech Innovation GmbH, [Provider Information](https://github.com/mercedes-benz/foss/blob/master/PROVIDER_INFORMATION.md)