WIP: Route eating prototype

[Fabi755]

Here my final candidate for route drawing improvements inclusive route eating. @boldtrn let me know if you if you agree with this implementation. After that I will clean up the code and add tests and documentation.

I marked the duplicated and outdated NavigationMapRoute class as deprecated. Followed by them I removed MapRouteLine and extracted the logic to separate classes:

MapLibrePrimaryRouteDrawer --> Creates required layers and generates the geo source for the primary route. Here the route-eating feature is included. MapLibreCongestionPrimaryRouteDrawer --> Creates required layers and generates the geo source for the primary route congestion segments. This will also supporting the route eating feature. MapLibreAlternativeRouteDrawer --> All (other) alternative routes are drawn by this class. MapLibreCongestionAlternativeRouteDrawer --> Congestion segments for all (other) alternative routes are drawn by this class. MapLibreRouteArrow (Already existing class) --> Draws arrows for the next maneuver MapLibreWayPointDrawer --> Draws the waypoints

All drawers are delegated by the NavigationMapRoute as it was before.

The drawer components can now injected in the constructor. This allows all users to set custom implementations for route drawing. If the fields are NULL, we use the MapLibre default drawers.

If you agree with this implementation I will continue with the tasks around this implementation. These things to do are:

• [ ] JavaDoc
• [ ] Add, update and fix tests
• [ ] Maybe adjust naming
• [ ] Validate and improve class & function scopes
• [ ] Improve congestion performance
• [ ] Check & solve open code-todos

The congestion logic needs also some performance improvements, while it's a bit lagging. If you use the MapLibrePrimaryRouteDrawer (without congestion) it works well on my tests. Additionally I tried to move some route logic in a background task, but the thread creation seems to took longer than the calculation itself. I not 100% sure how the native line drawing is working, but maybe here is more potential to improve the performance. Also the FPS throttling for (location puck and route eating) is only used on full navigation UI implementation. Here we can add same logic for the custom implementation. The route eating is disabled by default for now.

---

Is route eating the official name for this? 🤔

[Fabi755]

For example nearest point on line can be quite costly for larger geometries.

I changed now the logic. The route is prepared and calculated on setRoute. This will reduce the calculations on updateRouteProgress. Only the animated path needs to be calculated, and the current step needs splitted into two features.

This works very well for the MapLibrePrimaryRouteDrawer (without congestion). And okay working for long routes. Only the setRoute hangs on initial preparements, but I think, we can outsource to a background task.

The congestion drawing also works, but is still lagging a little bit. But these congestion states are a lot of small segments to draw.. there are potential to improve here much more.

[Fabi755]

I would suggest now, that I clean up the code, add missing things like documentation and tests. And try again to give more performance to the drawing logic.

Then I would expect that we can merge this into main. The route eating is disabled by default, and the users can test and decide by them self if they want to use this feature. Maybe some other developer has good ideas for more improvements later.

Any objections?

[boldtrn]

Fine by me, thanks for working on this. The only important thing right now from point of view is, that we don't create performance issues for non route-eating users.