Website changes: Caches loaded outside visible area

[moving-bits]

Originally posted by @MagpieFourtyTwo in #15543 (comment)

S/th new WRT caches in Live Map: Seems as if caches are downloaded, but not in the visible map area, only east of it ...
To reproduce:

1. swype to a map region which has not been visited before (and preferably contains no offline stored caches)
2. wait a few seconds (to give caches time to download - although you will see none)
3. in the currently visible region there are still no caches displayed
4. now move the map to the left (to see the region east of current section) BUT DO NOT LIFT YOUR FINGER
5. some caches will show up at the right display border, either in an vertical oval or vertical line
6. as soon as you lift your finger, the caches will disappear

Maybe the download order has been changed again ...?

[moving-bits]

Additional info, originally posted by @MagpieFourtyTwo in #15543 (comment)

As an alternative to "panning east", you can also quickly zoom out.
Effect is the same: Caches east of previous map region are shown for a second or so and then disappear.

[moving-bits]

Probably related to #15386

[MagpieFourtyTwo]

Yes, think so, too - but it's way more intense and "complete" right now.

[MagpieFourtyTwo]

But what I still don't get is, why the caches disappear as soon as I move the map halfway, i. e. until the displayed caches are shown, and lift the finger ... why does c:geo immediately "forget" caches it has just displayed ...? Wouldn't it be better to cache these for at least the session, if not even for a day or so ...?

[eddiemuc]

i will look into it starting now. Probably related to #15550

[eddiemuc]

In PR #15558 I tweaked a couple of parameters for our cache requests against gc.com to closer match the current way gc.com uses the APi itself. I did some tweakings w/o fully understanding WHY gc.com is doing this. For example:

• for searches of caches in a box (means: for map display) gc.com adds now a strange parameter rad=16000.. While this might e.g. mean "radius of search", strangely it always passes the number 16000 regardless of zoom level.
• for box searches gc.com passes sort=distance, but does NOT pass the dorigin parameter. This was previously used to pass the center from which to calculate the distances to sort by. I omitted this parameter too for box searches now
• for box searches (and all other searches) gc.com now always passes the parameter properties=callernote. This parameter was previously used to mark that for "found date" the date of another user shall be returned (used when filtering search using "found by"), now it seems to be passed always. Don't know why

I also increased the MAX_CACHES parameter for unified map to 2000. It was set to 500 which lead to loaded caches dissapearing from the map if total is more than 500.

I swept around in an area where I never cached or stored caches before (in my case: Australia/Sydney) and it seems to work fine except for some artefacts which I get when zooming into regions with mor than 500 caches. @moving-bits I assume this is somehow related to the "not-reloading-caches-when-reamining-in-same-area"-logic, I didn't want to mess with this.

[MagpieFourtyTwo]

Would say this the can be closed? At least over here loading of caches appears to work fine right now ...

[moving-bits]

Thanks for cross-checking. So let's close here for now.