Pre-loading area should guarantee full offline usage for that area

[mnalis]

Use case
I often plan to go out mapping in area without mobile reception, or with device without mobile data access capabilities.
I scroll the map while home on WiFi and manually use Scan for quests here button, to pre-download both the map and quest data. I have cache size set to largest (and it is more than big enough), and I would like to be able to use both map and quest in SC when I go out to that area (eg. I would expect both of them to be available for at least 48h after a download, preferably a week)

And it works like that sometimes. But uncomfortably often what happens instead, is that I download the data and verify both map and quests are visible, and a day (or even just a few hours later sometimes, as it happened to me other day) later when I go out the JAWG map is gone, leaving only quests without background map, which makes quests quite hard (and sometimes impossible) to solve.

I guess it is likely because JAWG map tiles cache have different timeout which is not affected by Scan for quests here manual quest download button, so tiles might be just hours before expiration when user download quests, and so will still expire few hours later (unaffected by user manual download request).

Related: #3133

Proposed Solution
I would propose that when the user clicks Scan for quests here button, that SC insures that this area (not just quests, but Jawg map tiles too) will remain available for longer time (a week or two?) - memory limits permitting of course.

Few of the ideas how to accomplish that:

• when Scan for quests here button is pressed, also force Jawg map tiles re-download for that area (perhaps only force Jawg re-download if we're using WiFi, in order not to slow down on-the-train download #3231 nor drain battery #3243? Or only force Jawg re-download if it is about to expire soon?)
• when Scan for quests here button is pressed, do not redownload Jawg map if already existing for that area, but just update their expiration timestamps (that will let Jawg tiles be "stale" a little longer in such case of forced manual download - but better be little stale than nonexistent)
• allow some other way so users can preload data for offline use (like #473 or something else) and be sure that data will remain for a week or so, and not disappear in most unfortunate moment

[peternewman]

I also do a lot of offline mapping and don't seem to experience this much, only occasionally when I'm revisiting an area I haven't been to for some time. Although I'll often find if I zoom out and back in again I can at least get a low-res base map (e.g. no road widths, just thin lines for them).

[mnalis]

@peternewman yes, I too think it only happens when you move to area that has been downloaded previously (if it weren't downloaded previously, then it would be downloaded for the first time, and thus would get maximum expire which would be exactly what we want for mapping session). Zoom in/out didn't help for me (likely for the same reason as above: it probably depends on did you visit that area at that zoom level before).

(eg. if one always only visited new areas never visited before, the problem would likely never manifest.)

[westnordost]

I would propose that when the user clicks Scan for quests here button, that SC insures that this area (not just quests, but Jawg map tiles too) will remain available for longer time (a week or two?)

It does.

And they are deleted after 14 days. After 1 day, they are marked as "old" (i.e. if there is an internet connection, app tries to refresh them).
Maybe the problem is a really bad internet connection, i.e. app notices that it has an internet connection and tries to download them, but it takes forever (no reply). Not sure what happens in that case, but I would think that after you run into a HTTP timeout, the "old" tile in the cache should be shown.

In any way, it uses a HTTP cache, so I have no control over that. Consequently, there is nothing I can fix on StreetComplete. Maybe create a tricket at tangram-es (after you confirmed what exactly is happening, see paragraph above). The optimal behavior would be that the old tile is shown as long as the new one hasn't been successfully downloaded yet.

[mnalis]

As an update; there might also be external actors which cause that.

For example, on Huawei EMUI 11 (Android 10), there is a system app called Optimizer which has features which might remove cache of installed apps. Especially suspicious options are called Smart Tune-up and Auto-clean junk files

[InsertUser]

I find that map tile cache nearly always expires way before quest cache. Either that or tiles fail to download in the first place and don't retry on error. This means an area looks "saved" on the overview at home, and then suddenly leaves you in a beige wasteland without warning. Might be nice if the OSM data that has been downloaded was rendered on device at high zoom (would help with recently traced building too), but I'm sure this would be a lot of work to implement.