Auto-download that handles higher speeds of movement (motor vehicles etc.)

[mnalis]

Use case

When user is not on foot but as a passenger in a car or public transport, the speed of the vehicle is such that auto-download of quests is not useful - the bbox it downloads seems to be small and centered around the user, and it the case of car, by the time the quests are presented, the user has already left the area.

(This issue is additionally compounded by #3051 which further slows solving quests in such cases.)

Proposed Solution

It would nice if such cases of higher moving speed could be detected, and bigger bboxes downloaded then, so the auto-download actually manages to show quests to the users in the area they are in by the time download and parsing completes (instead of showing long-past area that is currently the case).

It might (or might not - perhaps just a bigger bbox is just fine) need to consider direction of movement and/or current speed in order so the longer download times do not negate positive effects of bigger bbox. The discussion with more ideas, details and pictures was started in #2457 (reply in thread)

The currently only known workaround is that the user manually preloads all the way it will travel with car in advance, but that is not only menial and time consuming (as we don't have preload-by-gpx like suggested in #473), but often impossible (as the exact route that will be taken is in many cases not known in advance)

[westnordost]

Won't work. An even bigger bbox will take even more time.

…

On July 12, 2021 1:33:46 PM GMT+02:00, Matija Nalis ***@***.***> wrote: **Use case** <!-- Provide a clear and concise description of *your use case* and what you thus think is missing, and why. --> When user is not on foot but as a passenger in a car or public transport, the speed of the vehicle is such that auto-download of quests is not useful - the bbox it downloads seems to be small and centered around the user, and it the case of car, by the time the quests are presented, the user has already left the area. (This issue is additionally compounded by #3051 which further slows solving quests in such cases.) **Proposed Solution** <!-- There may be several different solutions for your idea or use case, add your deliberations about it here to help out sort out the best one. Also, add screenshots or mockups to visualize your idea, if applicable. --> It would nice if such cases of higher moving speed could be detected, and bigger bboxes downloaded then, so the auto-download actually manages to **show quests to the users in the area they are in** by the time download and parsing completes (instead of showing long-past area that is currently the case). It might (or might not) need to consider direction of movement and/or current speed in order so the longer download times do not negate positive effects of bigger bbox. The discussion with more ideas, details and pictures was started in #2457 (reply in thread) The currently only known workaround is that the user manually preloads all the way it will travel with car in advance, but that is not only menial and time consuming (as we don't have preload-by-gpx like suggested in #473), but often impossible (as the exact route that will be taken is in many cases not known in advance) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #3052

-- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[mnalis]

@westnordost one of the ideas to address that was making the bbox thin but long and in front of direction of movement instead of around current position (so same area/same speed as smaller square currently used) - but I can see there are cases where it might not be fully possible (eg. when moving at NE direction eg. at 45 degrees, bbox will be as wide as it is long)

[peternewman]

We've now got parallel issue and discussion discussions, but one potential solution (or at least improvement):
#2457 (reply in thread)

If you keep the same Bbox though, and have you placed at 6 o'clock (rather than in the middle as currently), you've doubled the useful area you're loading, without changing the size of the data being loaded.

[smichel17]

Let's just move all the discussion here, copying over the worthwhile parts.

The algorithm pseudocode I posted there

autoDownload() {
    val position = getCurrentPosition()
    val speed = getMaxSpeedInLast5Minutes()
    if (speed < 16_KMH) {
        downloadBbox(normalSquareBbox(position))
    } else {
        val direction = getCurrentMovementDirection()
        val thinBbox = longThinBbox(position, direction, speed) // higher speed = longer bbox
        downloadBbox(thinBbox) // wait for completion
        val newPosition = getCurrentPosition()
        if (distanceBetween(position, newPosition) < SHORT_DISTANCE) {
            // They haven't moved very far, so maybe they got off the car/bus/train.
            // So, download the regular bbox. They might also be stopped or in traffic,
            // but in any case they're moving slow enough that we have time for the normal download.
            val (left, right) = normalSquareBbox(newPosition).excludeOverlap(thinBbox)
            downloadBboxes(left, right)
        } else {
            // They've moved far enough that there's no point in downloading the normal bbox
            // It's going to be behind them anyway. Instead, get the next long thin bbox
            autoDownload()
        }
    }
}

A long, rectangular bbox can be split into a sequence* of several smaller, square bboxes. A 45 degree bbox can be split into a sequence of rectangular bboxes, like:

111
 222
  333
   444

*actually this is another good use case for flows, but that level of implementation is not important yet.

[westnordost]

The problem with any smartness like that is that it is a never ending source of confusion and/or necessary improvements

[smichel17]

That's fair, and I think @peternewman's bbox-with-offset idea is the best [compromise] so far.

[westnordost]

This is still the kind of smarthness I am talking about.

[mnalis]

A long, rectangular bbox can be split into a sequence* of several smaller, square bboxes. A 45 degree bbox can be split into a sequence of rectangular bboxes

For the record, that is the way the JOSM seems to do when one right clicks on .gpx and chooses Download from OSM along this track, although it has some more smarts to detect when it is worthwhile to merge several small requests into one bigger request (the issue being that each additional request increases the latency, unless you do them in parallel, which adds complexity and makes it more likely to be classed as an abuse of ToS).

So I would also prefer to keep it simple, so my initial suggestion was "just do the bigger bbox if we're moving fast (or even simpler, always do bigger bbox)". But if that indeed makes download too slow (has anyone tried and run the numbers on that?) than something more complex might be the only option to solve the problem.

While @peternewman idea does require some "smartness", it might be reasonable compromise. I understand why "automagic smartness" is frowned upon (from both technological debt and UX point of view), and that this suggestion is also not ideal - but neither is being effectively unable to map while in passenger seat.

[matkoniecz]

thin but long and in front of direction of movement instead of around current position

This will result in smartness that will work 70% time, fail 30% of time and result in continuous stream of issues.

Note that even motorway have curves, and lower class roads will change direction even more often.

(I also had this idea but to work well it would need to be coupled with routing app)

[smichel17]

Okay, one more idea, and if this is rejected by @westnordost then let's close this issue as wontfix and think of some other way to solve the problem:

1. Download the exact same area bbox as present, but split the bbox into quarters, and pick the order of downloading based on the direction of movement. Illustration: the post-it is the normal bounding box, the arrow is the direction, the numbers are the order of bboxes that are actually downloaded.

   
   • If the user is moving fast, they do not have to wait as long before quests appear, since it is only 1/4 of the bbox.
   • From a quick look at the code, this is already done if we try to download a bbox which is too large, although it does not consider direction of movement and I think the data is not stored in the db until all 4 sections have finished downloading.

2. Optional: Before starting the download of each quadrant, check the user's current location. If it's too far away from that quadrant, just cancel the download.

   • This frees up bandwidth for the next automatic download which has presumably been added.
   • It might be a reasonable thing to do regardless of any other changes to download strategy — if I am in a car, I don't care to waste time and bandwidth downloading an area which is already a kilometer behind me.

[westnordost]

1

This is not how the download works. It would be four separate downloads then.

---

As mentioned before, really the most viable solution would be the following. I am writing this down in case someone wants to try implementing this, I won't:

The download currently works like this: If the tile at zoom 16 around the user's position has not been downloaded already, download it. This is very fast because it is a very small area. (After) it has been downloaded already, calculate the estimated map data density from that. Based on the map data density, choose the size of the larger download bounding box. I.e. on the countryside, it will likely download a larger area, in the city center, it will be quite small. As the first download, the bbox is actually snapped to a grid of tiles at zoom level 16. So...

• change nothing for the "download tiny bbox to estimate map data density"
• track the user's GPS position for up to the last minute or so
• on "real" download, calculate the vector from the position 20s seconds ago or so to the position now. Using this vector, calculate a new center point for the download bbox from current position + vector and use that for download. If one wants to be more cautious with this smartness, one could cut the vector in half and/or require that the current position is still in the download bbox.

[rhhsm]

The solutions above all seem to be very complicated and probably not working in most cases. When I was once using SC on a moving train with slow on-board wifi, I'd move the map area ahead in the direction I was moving, and would manually download an area where I was expecting quests that could be solved (around a station where the train would stop, for instance). However, the auto-download was bothering me because it was automatically downloading areas that I had already passed, so there was insufficient bandwidth left to download the area I was interested in. It would help a lot to be able to switch off auto-download.

[westnordost]

So I will close this as will not fix. If someone would like to try this out and see if this brings about any improment however, feel free to try it: #3052 (comment)

However, on success, I can not guarantee if I would merge the PR then because it also depends on the complexity of the implementation introduced. (Every complexity introduced is a liability to maintain)

[endolith]

#4999