Open GoogleCodeExporter opened 9 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
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
Issue 207 was fixed after the 3.0.6 release.
Original comment by neilboyd
on 18 Jan 2012 at 6:17
[deleted comment]
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
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
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
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
facing same problem with 3.0.10.
Original comment by akram10....@gmail.com
on 22 Jul 2013 at 8:49
[deleted comment]
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
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
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
Test the update and report results back!
Original comment by kurtzm...@gmail.com
on 17 Aug 2013 at 10:11
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
See also issue 67: https://github.com/osmdroid/osmdroid/issues/67
Original comment by neilboyd
on 17 Jun 2015 at 8:54
Original issue reported on code.google.com by
mirko.ha...@googlemail.com
on 17 Jan 2012 at 2:33