search

binex / osmdroid

Automatically exported from code.google.com/p/osmdroid
0 stars 0 forks source link

Mixed tiles from different TileSources after setTileSource() at runtime #298

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Change the TileSource with setTileSource(ITileSource) at runtime
2.
3.

What is the expected output? What do you see instead?
If you change the TileSource while it is loading tiles you will get mixed tiles.

What version of the product are you using? On what operating system?
3.0.6

Please provide any additional information below.
The problem is: in setTileSource(ITileSource) it clears the cache but do not 
stop the downloading tiles. So the cache is clear but the download still in 
progress. When it is finished it put the tile to the cache but the TileSource 
is now a different. 
So you need to stop the downloads when setTileSource is called.

Than it is possible to change the TileSource at runtime!

Original issue reported on code.google.com by mirko.ha...@googlemail.com on 17 Jan 2012 at 2:33

GoogleCodeExporter commented 8 years ago 
I think this is fixed by issue 207 which prevents the behaviour you described.

Original comment by neilboyd on 17 Jan 2012 at 3:58

GoogleCodeExporter commented 8 years ago 
I have seen this issue and i noticed that i use the 3.0.5 version. But after 
changing to the new 3.0.6 jar the issue is still the same.

i call setTileSource(some tileSource)
and while it is still loading (i see some gray areas on the map)
i switch to a different TileSource with setTileSource (via menu entry or 
something)

Then i see tiles from the TileSource befor mixed with the current TileSource

Original comment by mirko.ha...@googlemail.com on 17 Jan 2012 at 4:39

GoogleCodeExporter commented 8 years ago 
Issue 207 was fixed after the 3.0.6 release.

Original comment by neilboyd on 18 Jan 2012 at 6:17

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
The changes in the patch of issue207 are allready inside of my version i use...

Original comment by mirko.ha...@googlemail.com on 18 Jan 2012 at 1:18

GoogleCodeExporter commented 8 years ago 
I also have the up to date source and still see this problem.  I believe the 
tiles from the old provider actualy get written into the wrong filesystem cache 
area as I can open up the default viewer and see the same bad tiles without 
doing the runtime switch after I have done it once in my app.

Original comment by iforpow...@gmail.com on 18 Jan 2012 at 6:29

GoogleCodeExporter commented 8 years ago 
I just tried putting a call to clearQueue in setTileSource in MapTileDownloader 
unfortunatly I just end up with tiles not downloaded at all. I need to work 
some more on trying to understand how it all hangs together, just can't get my 
head around it yet...

Original comment by iforpow...@gmail.com on 18 Jan 2012 at 7:25

GoogleCodeExporter commented 8 years ago 
Now I want to known how to resolve the question ? anyone to tell me ,thanks. +1 
Me too!

Original comment by longgang...@gmail.com on 12 Oct 2012 at 2:32

GoogleCodeExporter commented 8 years ago 
facing same problem with 3.0.10.

Original comment by akram10....@gmail.com on 22 Jul 2013 at 8:49

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Confirmed this can be reproduced in OpenStreetMapViewer by changing "Map mode" 
while tiles are downloading. Original reporter's suggestion that 
setTileSource() "clears the cache but do not stop the downloading tiles" is 
likely the culprit.

Original comment by kurtzm...@gmail.com on 17 Aug 2013 at 9:27

GoogleCodeExporter commented 8 years ago 
So actually the problem is that the mTileSource is changing in the middle of 
MapTileDownloader.TileLoader.loadTile(). So it starts off by downloading from 
one tile source, but then ends up saving the downloaded tile as another 
TileSource which consequently puts it in the wrong tile directory. Plus the 
MapTileDownloader is accessing the mTileSource variable across multiple threads 
unsafely. I suspect the other modular tile providers are doing the same.

Original comment by kurtzm...@gmail.com on 17 Aug 2013 at 9:54

GoogleCodeExporter commented 8 years ago 
This issue was updated by revision r1289.

Access TileSource in a thread-safe way.
Get a reference to the TileSource at the beginning of TileLoader.loadTile() and 
use it for the entire method. Prevents issues when TileSource changes such as 
when the downloader downloads a tile with one TileSource but then incorrectly 
saves it using the new TileSource.

Original comment by kurtzm...@gmail.com on 17 Aug 2013 at 10:11

GoogleCodeExporter commented 8 years ago 
Test the update and report results back!

Original comment by kurtzm...@gmail.com on 17 Aug 2013 at 10:11

GoogleCodeExporter commented 8 years ago 
It seems saving the tiles in wrong folder issue is resolved but some times 
getting wrong tile on map when changing TileSource frequently.

Original comment by akram10....@gmail.com on 19 Aug 2013 at 5:22

GoogleCodeExporter commented 8 years ago 
See also issue 67: https://github.com/osmdroid/osmdroid/issues/67

Original comment by neilboyd on 17 Jun 2015 at 8:54