WIP: [generator][core][android] Lanes refactoring #7077

Draft

AndrewShkrob wants to merge 1 commit from AndrewShkrob/android/lanes-refactoring into master

AndrewShkrob commented

2024-01-05 11:00:51 +00:00

Member

The primary aim of this PR is to enable the visualization of the recommended lane way and to display the correct turn image. The previous implementation lacked this functionality.

Details

New LaneWay structure: Transitioned from an array of enums to a single uint16_t variable where each bit corresponds to a separate lane way (refer to routing/lanes.hpp).
Turn lanes preprocessing by generator: From reverse;left;through|none||right to 137|0|0|16
- This solution is expected to reduce map size or at least not increase it.
- It should also expedite lane processing on the device.
Added all possible turns as per OpenStreetMap Key:turn.

The PR is currently incomplete but includes the previous functionality and does not introduce any changes to the UI.

TODO

Compare map sizes between old and new approaches.
Create new turn images that allow combining all (or at least some) possible turns for a single lane, as shown here:
Investigate the possibility of having 2+ recommended turns for a single lane.
Implement post-selection processing of recommended ways to reduce the total number of possible lane turns, simplifying image generation on the client. Examples:
- For instance, in cases like reverse;sharp_right;right;through, where the recommended turn is reverse, we can display only the active reverse or the active reverse with inactive through.
- Similarly, for a recommended turn of right in sharp_right;right;slight_right, displaying only right might be more feasible than showing all three turns simultaneously.
Incorporate support for both UTurnLeft and UTurnRight. Currently, the system only recognizes reverse as a UTurnLeft.

The primary aim of this PR is to enable the visualization of the recommended lane way and to display the correct turn image. The previous implementation lacked this functionality. ### Details - **New LaneWay structure**: Transitioned from an array of enums to a single `uint16_t` variable where each bit corresponds to a separate lane way (refer to `routing/lanes.hpp`). - **Turn lanes preprocessing by generator**: From `reverse;left;through|none||right` to `137|0|0|16` - This solution is expected to reduce map size or at least not increase it. - It should also expedite lane processing on the device. - Added all possible turns as per [OpenStreetMap Key:turn](https://wiki.openstreetmap.org/wiki/Key:turn). The PR is currently incomplete but includes the previous functionality and does not introduce any changes to the UI. ### TODO - [ ] Compare map sizes between old and new approaches. - [ ] Create new turn images that allow combining all (or at least some) possible turns for a single lane, as shown here: <img width="100" src="https://github.com/organicmaps/organicmaps/assets/10351358/2600ba37-ec3b-49cd-a66a-c6d96237dedf"/> - [ ] Investigate the possibility of having 2+ recommended turns for a single lane. - [ ] Implement post-selection processing of recommended ways to reduce the total number of possible lane turns, simplifying image generation on the client. Examples: - For instance, in cases like `reverse;sharp_right;right;through`, where the recommended turn is `reverse`, we can display only the active `reverse` or the active `reverse` with inactive `through`. - Similarly, for a recommended turn of `right` in `sharp_right;right;slight_right`, displaying only `right` might be more feasible than showing all three turns simultaneously. - [ ] Incorporate support for both `UTurnLeft` and `UTurnRight`. Currently, the system only recognizes `reverse` as a `UTurnLeft`.

Rows
Columns