Relative waypoint limit for loading as route

[nrenner]

RouteLoaderConverter currently has an absolute maximum number of waypoints of 5000.

I think this is way too high, as a comparison, the limit of other services seems to be: openrouteservice.org: 50, graphhopper.com: 80 [1].

When the GPS device is set to record every second, lots of points are generated for a track. E.g. a track of 21 km results in 4594 waypoints with a tolerance of 0. That's a waypoint every 4.6 m. Nice to experiment with, but of no practial use and a total overkill for the client and the server, as every segment between two waypoints is requested separately.

So my idea is that we should have some kind of distance-relative limit as well, e.g. maximum number of waypoints per km.

@printpagestopdf what do you think?

[printpagestopdf]

The number of 5000 was only a guess without any real calculation behind it. So for sure we can change this limit. To make it dependant from the track data is a good idea. I haven't looked how to retrieve the length of the track, but it sounds useful. By the way, what would be your suggestion here?

Regarding the procedure: what is the normal way to make such a change? Are you doing it? Or if not do I have to make a new pull request?

[nrenner]

I haven't looked how to retrieve the length of the track

Probably turf.length, Leaflet has LatLng.distanceTo.

By the way, what would be your suggestion here?

I don't know, part of why I'm asking. You might have a better guess from working on it. Maybe somewhere between one waypoint per 100 m and 1 km?

Ideally the limit would be included in the slider value formula.

Regarding the procedure: what is the normal way to make such a change? Are you doing it? Or if not do I have to make a new pull request?

No general rule here. If you have the time and energy if would be great if you could help me and make a new pull request. Just make sure you sync the latest changes from upstream (see Syncing a fork), as I have already done some refactoring in 5ad12a7. Otherwise let me know and I'll do it.

[printpagestopdf]

I will make a pull request and try to change it (and will aks if I need help 😊)

[hoam68]

First of all thanks for this function (and for the whole application of course :-))! For re-planning tracks this function is absolutely necessary. What I did is to create just a simple formula like first point/last point, number of max. points (e.g. 200) and/or max. 5% of imported points. The calculated route was max. 1-3 points beside the original track (tracks between 50-60km).

[printpagestopdf]

@nrenner independently of this change I was thinking about if the brouter java server hast the ability to calculate a list of points (e.g. the whole route) than perhaps it would make sense to use this here for calculation (reducing the requests to 1, not the calculations themselve). Do you know if brouter is able to do so?

[nrenner]

BRouter server does support requests with more than two waypoints, but only returns a single track with no proper way to get the individual segments. We use that for download only. The client and leaflet-routing do not support it.

A single request would be nice for converting tracks, but generally I consider segment-based requests a feature for slower routers like BRouter.

And the goal for converting tracks should really be to minimize the number of waypoints needed, more waypoints also make editing harder. So any additional development efforts should rather go in that direction.

[rkflx]

I wonder if there is anything left to be done here, given #321 landed?

One more idea to speed things up: Why not send requests in parallel to the server (possibly clamped to nproc, or configurable in config.js)? The total CPU time spent should be about the same, while reducing wall clock time, in particular when installed on an idle local multicore machine.

[nrenner]

No, can be closed.

I think this is good enough now. Any further optimization should go into minimizing the number of waypoints needed to match the track.

I thought about an iterative approach, that would start with a low guess and re-route parts that don't match yet with added waypoints. But re-routing would need more resources, and I don't know if saving request overhead would make up for that.

See Map matching · brouter#222 and Reverse routing · brouter#223 for the proper solution. And we should finally implement GPX route support (#16) to reduce the need for track conversion, but i haven't taken the time yet to think about the way forward with formatting.