Hi,
I've run into an issue that should be handled by the XamMap control. I'm using the XamMap control with OpenStreetMap tiles from MapQuest, but from time to time the control crashes with a System.NotSupportedException, thrown by the System.Windows.Media.Imaging.BitmapDecoder class in the Infragistics.Controls.Maps.XamMultiScaleImageView.DownloadClient_DownloadDataCompleted method. The exception message is ' No imaging component suitable to complete this operation was found.'.
The attatched zip-file contains a sample project XamMapException.csproj (in another zip-file) that can trigger the error. The zip-file also contains a screen dump of the VS2012 call-stack at the time of an exception (XamMapException.png) as well as a sample tile (60541.png) that looks to be causing the issue. The crash is most easily triggered by the sample application by zooming in to OSM zoom-levels 16-20 at e.g. Northern Africa, but I've experienced the crash at most other places as well from time to time.
After some debugging I think the cause of the error is due to the fact that the MapQuest OSM server do not necessarily return valid PNG-files for all tile requests. If I currently download e.g. the tile at the following url: http://otile1.mqcdn.com/tiles/1.0.0/osm/17/66229/60541.png, which is attched as 60541.png in the zip.file, I get a tile that does not contain a valid PNG image, but rather a string with the following text: 'The tile you requested is not available at the moment. Please try again later.'The associated web response has a content type of 'text/plain' instead of e.g. 'image/jpg'.
The issue looks to be discussed at this MapQuest forum thread as well:http://developer.mapquest.com/web/products/open/forums/-/message_boards/view_message/290730#_19_message_290306
Irrespective of the error cause, I think the XamMap control should catch any BitmapDecoder exceptions and not let them propagate to the user. The XamMap should just simply drop tiles that can't be decoded. There is no simple way for the user of the XamMap to handle these exceptions.
Regards,Leif
Hi Leif,Thank you for your forum post.In order to validate the image stream and let xamMap use only the valid tiles, you could handle XamMultiScaleImage's ImageStreamValid event and return false if the image stream is not valid. This way xamMap won't try to load it.Please let me know if you need further assistance on the matter.Regards,Milana Zhileva
since I've already implemented a caching/proxy mechanism for my custom MapTileSource I can avoid this issue by checking the received web request response's content type before passing tiles on to the XamMap. I haven't seen any crashes since I added this check.
However, I still beleive that the XamMap should properly handle the received tile stream itself, and not crash the control due to an invalid image stream. I consider this a XamMap bug. The XamMap should at least check the received response content type for valid image content before attempting to decode the data as an image. Additionally, the XamMap should handle any image decoding exceptions internally.
Hi Leif,I am glad you have resolved your issue.A possible approach to avoid the crash is to handle the ImageStreamValid event of xamMap's MultiscaleImage control and assert the validity of the image stream.Thank you for sharing your resolution and for providing a feedback.Best regards,Milana Zhileva
According to the change-log for the 13.1 August 2013 Service Release, this issue looks to be fixed in the XamGeographicMap. However, there is no indication that the issue is fixed in XamMap!
I reported this issue months ago. Why isn't a fix yet applied to XamMap since you have fixed it in XamGeographicMap ?
Hi Leif,Are you still able to reproduce the issue in XamMap?It is possible that the change is not listed in the changelog for the control but as far as we know the issue has been addressed for both XamMap and XamGeographicMap.Regards,Milana Zhileva
I don't currently have available the code the triggered this issue initially since I had to implement a tile caching mechanism anyway. This cache in effect works as a workaround for the issue since it makes all checks needed on the downloaded data before passing them on to the XamMap.
If the changelog for the XamMap indicates that this is fixed I guess it is. I was just a bit puzzled that the release notes indicated that a fix was applied to the XamGeographicMap class only.
Hi Leif,Thank you for the provided feedback.Please feel free to let us know if you have any other issues with this matter.Regards,Milana Zhileva