I’ve been doing some work with the OpenStreetMap layer and have notice a little quirk when zooming in and out on the map (using version 8.0.0.46) I’ve been using the mouse wheel to do the zoom (because it’s so convenient) but now and again I’ll see a tile on the map that doesn’t belong there. It’s the tile from another zoom level see it in the attached image. I can make the happen fairly regularly and am using the following code to add the layer:
I don’t think there’s anything non-standard here. I’ve tried it with the stretch transition mode and with a tile cache too. The tile won’t be replaced with the correct one until I restart the program (I’m guessing the temporary OpenStreetMap cache in somewhere like c:\users\tmp<something> gets deleted).
It may be the case that moving the mouse while zooming out is a contributing factor, but it is fairly easy to reproduce within a couple of minutes.
Yes, your code looks pretty standard, but no matter how I played on zoomIn and zoomOut, I didn’t reproduce your issue with both 8.0.0.46 and the latest dll package, The below is my test code:
Map1.MapUnit = GeographyUnit.Meter Map1.CurrentExtent = New RectangleShape(-13939426.6371, 6701997.4056, -7812401.86, 2626987.386962)
Dim osm As New OpenStreetMapOverlay() 'osm.TileCache = New FileBitmapTileCache(@"D:\cache","wpf") osm.TransitionEffect = TransitionEffect.None Map1.Overlays.Add("osm", osm) Map1.Refresh()
Would you please check your sample again or try the latest dll package?
I tried with the 8.0.0.56 assemblies and see the same kind of behaviour. I think it’s most likely connected with multithreading, the mouse interactions - clicking, mousewheel zooming and moving all at the same time (logitech m705).
I don’t know if this exception is connected - I’ve only ever encountered it twice:
A first chance exception of type ‘System.IO.IOException’occurred inmscorlib.dll
Additional information: The process cannot access the file ‘C:\Users\mark\AppData\Local\Temp\MapSuite\OpenStreetMapTmpTileCache\88339156-261f-483e-b577-1a5e706dc36e\18055.9555200119\12867\9201.png’because it is being used by another process.
It’s not a huge issue for us - restarting the app clears the cache therefore fixing the broken tiles and I doubt our users will be zooming around the map quickly.
I tried it again in another machine but still failed to recreate the issue. From the exception, it is related with the default temp cache, I am guessing disabling the temp cache would avoid it by setting the TileCache property on OpenStreetMapOverlay as null or give another tile cache. Some codes like the below:
//osm.TileCache = null; osm.TileCache = new FileBitmapTileCache("D://Cache","OSM");
I am wondering if the issue is happened in the other target machines, would you try it? Hope it helps. Thanks, Troy
tried the two methods you suggest and I’m seeing the issue where the tile cache is used. When the cache is set to null/nothing I’m not seeing any misplaced tiles. After I found an instance of where there was a misplaced tile, I searched through the cache and found the wrong tile stored in among the others. I’ve attached all the files from the particular directory.
Thanks for the screenshots, we recreated your issues and we are looking on this. Any updates, I will update here. Before we solve it, please set the cache to null.
Thanks for the waiting. This issue have been fixed, please try the latest version(8.0.0.69 or 8.0.69.0). If the issue persists, please feel free to let us know.
