be more aggressive with caching

[Kieran Fleming]

The program isn't downloading the tiles fast enough if the user is driving fast or if the network's slow. Need to preload tiles more

[Will Uther (willu-mailinglists)]

See also the patch in Issue #20...

[chris_debian (cjhandrew)]

Willu,

Can you just check that this is up-to date and that the 'percentage completed' is correct.

Many thanks,

Chris.

[Will Uther (willu-mailinglists)]

I have no idea what the goal for this issue is.

I agree that being able to pre-download tiles would be a good thing. That's why I wrote the patch in Issue #20. That patch was rejected.

[chris_debian (cjhandrew)]

Kieran,

Can you add any clarity to this?

Thanks,

Chris.

[Kieran Fleming (kieran-fleming)]

What I meant by the comment was that when I'm driving at 60km/h, not even a 3G connection can download the tiles fast enough. It's especially bad if you're driving diagonally. Willu had fixed this in #70 but I found that it tried to download too much and slowed my phone down. I think the way to fix this issue is to preload tiles only in the direction that the user is travelling.

[chris_debian (cjhandrew)]

kizza wrote:
> What I meant by the comment was that when I'm driving at 60km/h, not even a 3G connection can download the tiles fast enough. It's especially bad if you're driving diagonally. Willu had fixed this in #70 but I found that it tried to download too much and slowed my phone down. I think the way to fix this issue is to preload tiles only in the direction that the user is travelling.

Kizza,

Do you know whether this is possible and if so, whether it is within scope for the 1.0 release?

Thanks,

Chris.

[droidguy (stan-berka)]

The answer to this issue seems for me to be what my old GPS did. If you moved faster, it automatically zoomed out. The idea seems also logical to me: the faster you move, the less you care about details.

kizza wrote:
> What I meant by the comment was that when I'm driving at 60km/h, not even a 3G connection can download the tiles fast enough. It's especially bad if you're driving diagonally. Willu had fixed this in #70 but I found that it tried to download too much and slowed my phone down. I think the way to fix this issue is to preload tiles only in the direction that the user is travelling.

[chris_debian (cjhandrew)]

droidguy wrote:
> The answer to this issue seems for me to be what my old GPS did. If you moved faster, it automatically zoomed out. The idea seems also logical to me: the faster you move, the less you care about details.
>

This seems really sensible. I guess we need to work out what zoom levels are display for each range of speed.

Chris.

[chris_debian (cjhandrew)]

chris_debian wrote:
> droidguy wrote:
> > The answer to this issue seems for me to be what my old GPS did. If you moved faster, it automatically zoomed out. The idea seems also logical to me: the faster you move, the less you care about details.
> >
>
> This seems really sensible. I guess we need to work out what zoom levels are display for each range of speed.
>
> Chris.

Hi, all.

This Issue seems to have 'lost its way'. Can anyone help?

Chris.

[chris_debian (cjhandrew)]

Droidguy,

Are you able to help with this?

Chris.

[droidguy (stan-berka)]

Do you think we can have OSN change the zoom level depending on __Current Speed__ from the tripstats? That would be a relatively simple solution and I could help with it.

[chris_debian (cjhandrew)]

droidguy wrote:
> Do you think we can have OSN change the zoom level depending on __Current Speed__ from the tripstats? That would be a relatively simple solution and I could help with it.

This sounds like a very good idea, to me.

Are there several zoom levels?

I'm thinking something like:

Zoom level 1: Speed 0-10mph (walking)

Zoom level 2: Speed 11-20mph (cycling)

Zoom level 3: Speed 21-40mph.........

Zoom level 4: ...........

Zoom level 5: ...........

Does that sound sensible? I think we'd have to experiment with the speed ranges and I'm not sure how many zoom levels exist.

Chris.

[Murphy (murphy2712+launchpad)]

droidguy wrote:
> Do you think we can have OSN change the zoom level depending on __Current Speed__ from the tripstats? That would be a relatively simple solution and I could help with it.

The actual problem about caching is that tiles are requested too late: when we actually need them to be displayed.
So when network is slow or disconnected, map is blank.
It is indeed a big problem on the high zoom level because maps moves faster: the autozoom functionality[A] you propose is one way to prevent this.
But we could also force caching by downloading tiles that are nearby, especially at high zoom level.

A word about Google Maps Navigation: it downloads all the tiles (yes it is bitmap!) about the trip when requesting the routing.
And by "all the tiles" I mean all interesting tiles, depending on zoom levels which are determined by the speed we should drive during the calculated trip.
These tiles are very compressed images (faster to download) and do not have any text on them. All the text is downloaded separately so they could use the tiles in every orientation (3D navigation) just by sticking the text at the correct position (near corresponding roads, places), but never upside down so we could read it.

I think the issue we must deal with is a mix of this one and #20:
preloading tiles that are on the calculated road, depending on a predicted autozoom[B] (so also implement autozoom[A]).

An other issue is that we should display extrapoled tiles on nearby zooms[C]: it's a shame to see a blank tile (while requesting), if zoom+1 and zoom-1 are available we could display them, even it's not very accurate, it's better than a blank one!

A last idea for today :)
It should be possible to make zoom in and out smoother using an transition animation[D] (and of course we need to display extrapoled tiles[C] for this, waiting for real tiled).

What do you think about creating issue for [A], [B], [C] and [D]?

[chris_debian (cjhandrew)]

Murphy,

Thanks for taking the time to define your points. I think quite a lot of confusion exists around these issues and you have done a good job of 'breaking them out'. I think looking at the issues we have and then creating additional issues as you suggest would be a good idea. The target release version could then be looked at for each.

If anybody else thinks this is a good idea, then we will go ahead and do it. Another thought, do we know what AndNav did about these issues?

Thanks again, Murphy.

Chris.

Possible issues:

[A] Autozoom functionality. (Issue description needed before Issue is created)
[B] Preloading tiles that are on the calculated road, depending on a predicted autozoom. (Does an issue exist already?)
[C] Display extrapolated tiles on nearby zooms. (Issue description needed before Issue is created)
[D] Make zoom in and out smoother using an transition animation. (Issue description needed before Issue is created)

[chris_debian (cjhandrew)]

4 new issues created. They have not been given target releases. Please add your comments to these issues and if you feel you can help, please take ownership of them. If you have a preferred target release date, please email the osn-dev list to discuss, then we will implement it.

Thanks,

Chris.