The attached files show what I see when I run the SDK Samples Browser and choose the OSM or Bing provider examples. Basically the map tiles appear in the wrong places and so you get a mixed-up "jigsaw puzzle" effect. This doesn't happen at the initial zoomed-out level, but happens immediately when I change the zoom. It also happens as I scroll around.
However, I only see this when running inside our corporate network! I don't see the problem when running the same SDK sample on my home network. The same is true for several of my colleagues.
Our IT manager says this problem must be due to a bug in Telerik. He also reports that he sees the problem on his home network and he produced a similar screenshot.
How can I go about troubleshooting this issue? What could be causing the map tiles to get mixed up?
15 Answers, 1 is accepted
Once in a while a scrambled tiles issue pops up. Nevertheless, we can't reproduce it on our side. But it seems that, mostly, this could happen when a proxy server is used or there are internet (or other network) connection issues. You can double check if your work systems are making their data transfer with the world wide via a proxy. And also your can see your internet performance.
Also, you can try different tile caching options for the map. By default RadMap uses the built-in .NET caching mechanism and the default request cache level is set to CacheIfAvailable. You can try different levels using the map provider's RequestCacheLevel property and set the IsTileCachingEnabled property to False. Another thing you can try is to manually delete the tiles cache.
string profile = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
string cachePath = profile + "\\TelerikMapCache";
Directory.Delete(cachePath, true);
Any additional information about your device/network setup could be useful for investigating this.
Regards,
Martin
Telerik by Progress

Hi, turns out we are using Sophos proxy in our internal network and your OSM example demonstrates it is broken! :)
We can create or stop the problem by changing proxy settings in the Internet Options dialog in Control Panel (also clearing the browser cache between tests, as the broken/good data remains in the cache which can cause further confusion when troubleshooting).
Thanks for your help. We are now looking for business approval to buy Telerik licenses.

Hello Martin,
You had mentioned in this post that you were able to workaround the issue "by changing proxy settings".
Do you remember what settings you had changed?

I work alongside Daniel. As far as I am aware we got a temporary fix for this by requesting our network admin to configure the proxy so that requests to OSM and Bing map servers are allowed straight through. It appears that without this the Sophos proxy caches tiles, and it seemed like the cache behaviour was incorrect. We've raised this with Sophos but have not had any more permanent resolution of the issue.
Pete.

I am seeing this exact behaviour (wrong map tiles loading/map tiles jumbled up) for Bing & OSM providers on my work network. I have checked with our IT dept and we are not using any kind of proxy for out internet connection. When I first tried the RadMap control several months ago it all worked perfectly, loading all tiles as expected.
Is there anything else I can try to resolve this?
I have tried both of the options below on a very simple view in a WPF desktop application but still get tiles loading as in the attached image. I have tried setting IsTileCachingEnabled = false and all options for RequestCacheLevel. Also tried manually deleting the cache. None of this had any noticeable effect.
<
telerik:RadMap
HorizontalAlignment
=
"Stretch"
VerticalAlignment
=
"Stretch"
>
<
telerik:RadMap.Provider
>
<
telerik:BingRestMapProvider
ApplicationId="<BINGMAPSAPPLICATIONID>" />
</
telerik:RadMap.Provider
>
</
telerik:RadMap
>
<
telerik:RadMap
HorizontalAlignment
=
"Stretch"
VerticalAlignment
=
"Stretch"
>
<
telerik:RadMap.Provider
>
<
telerik:OpenStreetMapProvider
/>
</
telerik:RadMap.Provider
>
</
telerik:RadMap
>

Hi Tim,
We faced similar issues here. IT department initially assured us that it must be a problem with our application or with the Telerik mapping code. Do you see the problem in other environments i.e. outside your work network? If not, then that pretty much proves it's a network issue.
Pete

I have tried this on my home network that definitely does not use a proxy and has a very high download speed and stable connection. I have created a very basic WPF app (see attached) - a single window, one grid and the map with an OSM provider - to test this with and this issue is still present there. I can't upload that app here as Telerik only allow images and files under 2Mb...
I understand that Telerik support may be having a hard time replicating this issue but dismissing it as a network issue without being certain that that is actually the cause is not particularly helpful, especially when it appears to me at least not to be caused by that.
I have now tried all suggestions in this thread (checking for proxy, map cache options, etc) plus everything else I can think of and I am still seeing this issue...

Hi Tim,
I wasn't dismissing it as simply a network solution, and there may well be another cause in your case.. I was just relating a little more about what we found in my work environment. As regards reproduction. I'm pretty sure we saw the problem using a sample app shipped by Telerik (see initial post in this thread).
BTW it is possible to attach a small app to a forum post by changing the file extension (e.g. change zip to png).
Pete

Thanks Peter, sorry if I came across badly, I'm just really frustrated by this issue.
Did you ever get it working? You mention in both your posts that you saw the issue on your work network but never if you managed to get the sample app to work.
I can't upload my app here as it's 16Mb. I have created a support ticket and uploaded it there though so we will see what Telerik support have to say once they get to the ticket...
My test app is just a new WPF app with the XAML below as the MainWindow and references added to the Telerik libraries required to include RadMap. At anything other than the highest zoom level (showing entire map) I see tiles loading incorrectly.
<
Window
x:Class
=
"MappingTest.MainWindow"
xmlns:telerik
=
"http://schemas.telerik.com/2008/xaml/presentation"
mc:Ignorable
=
"d"
WindowStartupLocation
=
"CenterScreen"
Height
=
"768"
Width
=
"1024"
>
<
Grid
>
<
telerik:RadMap
Width
=
"1024"
Height
=
"768"
>
<
telerik:RadMap.Provider
>
<
telerik:OpenStreetMapProvider
/>
</
telerik:RadMap.Provider
>
</
telerik:RadMap
>
</
Grid
>
</
Window
>

Hi Tim,
By investigating the issue with our network admin we could see that requests to OSM or Bing were being intercepted by Sophos proxy, which was returning some cached result. The only "solution" we have is that our network proxy (Sophos) has been configured by our network admin to pass-through (i.e. bypassing the proxy cache) any network requests to the OSM and Bing servers. This fixed the problem for us and allowed our app, and the Telerik sample app, to work correctly.
Our suspicion is that there is a bug in Sophos proxy cache. I think we raised a ticket with Sophos for this issue but as far as I am aware we got no response. I'll post an update here if that changes.
Pete

OK, so after hours of testing I've finally fixed my Map. It was definitely a caching issue, despite me previously trying every combination of IsTileCachingEnabled and RequestCacheLevel options on both BingMaps and OSM providers.
Things that didn't work:
Changing IsTileCachingEnabled to false.
Any of the settings for RequestCacheLevel.
Manually deleting the cache (as suggested by Martin above).
Checking for proxied network connections.
What did work:
I set the provider to OSM and ran my app. Whilst it was running, in Visual Studio I used the Live Property Explorer to find the Provider property of the map. The OSM provider has a property called 'Layer' (BingMaps does not have this, although I guess it's 'Mode' property fulfils a similar function). When I changed this property from 'Standard' to 'Cycle' - after a short pause - suddenly the map loaded all tiles properly (albeit the 'Cycle' tiles). I then changed back to 'Standard' and all the tiles loaded correctly for that layer too.
I closed the app and changed the provider back to BingMaps, and when I ran the app again, it too loaded all tiles correctly.
IsTileCachingEnabled was true and RequestCacheLevel was CacheIfAvailable for both maps during this test.
I suspect that changing the Layer on the OSM map at run-time forced the cache to invalidate, although I can't say why this didn't happen when changing the RequestCacheLevel at design-time or run-time. Perhaps that is something that Telerik should investigate? It seems odd to me that the options to alter caching behaviour seemed to have no effect at all during hours of testing...
Thank you for sharing your workaround with our community.
Consider RequestCacheLevel property as .Net tile downloading caching mechanism. We use it this way:
this
.webClient =
new
WebClient();
this
.webClient.CachePolicy =
new
RequestCachePolicy(
this
.requestCacheLevel);
....
this
.webClient.DownloadDataCompleted +=
this
.OnDownloadDataCompleted;
this
.webClient.DownloadDataAsync(
this
.uri);
}
Changing the Layer of OSM forces update of all tiles which are requested for download. We have internal list of TileIds - objects storing the indices of the Tiles, this list is refreshed via threads and later used when downloading new tile images. Shorty said, we might have some threading problem which corrupts the request lists but, unfortunately, this is only a guess. Since we don't have an isolation as a base for investigation, we cannot make a good plan for improving this code.
Regards,
Petar Mladenov
Telerik by Progress

Old thread, but I just wanted to chime in that apart from proxy related issues, we have also experienced this problem on several clients that are using webroot antivirus.
Cheers. David Magnusson (on Viktors account)

That is interesting, as we also use Webroot. I will speak to our IT guys about it to see if that could be a possible cause.
