ThinkGeo.com    |     Documentation    |     Premium Support

Tile buffering when using WPF Edition as WMS Server Client

#1

I have posted this on the WMS Server board but it might actually be more relevant on this one so I though I should post it here as well. I am using the WPF Desktop Edition with the WMS Server.


You guys have added a little bit of a tile buffer around the visible extent in the WPF Client and this is definitely a step in the right direction but i still have a couple of issues that should be easy to fix and I think would create a better user experience.


The first issue is that most of the time, the tiles seem to be buffered as a square, rather then just scaling up the extents of the map control. Because the map control extents will almost always have a greater width then height what happens is that you can pan seamlessly (by this i mean that tiles are getting pulled in immediately because they are already on the client) vertically but not so much horizontally. Also the buffer doesn't not appear to be centered on the map extent i'm seeing it slightly skewed to being below the center point of map. Both of these issues are noticeable when you go to zoom out on a map as well as when panning. If there is some way to control this from the client that I have missed please let me know.


The third issue with the buffering is that ideally you would like to have it extend to the point where, when you zoom out, tiles are getting pulled in along every side - so that you don't get any blank area, even if it is all bit-blitted I think that would look better  - but I think coupled with that might have to be the intelligence to update visible tiles before buffer tiles and i wouldn't want to ask you to do anything which conflicts with my last post (made on the WMS Server board), and my biggest concern right now - which is that only one request is made from the client per map update.


Thanks,


Chris 



#2

Hi Christopher,



For your fist issue, the tile buffer property is the number of extra rows and columns of tiles on each side which will surround the minimum grid tiles to cover the map. For example, if we have one tile for current extent, and the TileBuffer is 1, we will get the tile as the following diagram.





So if you have 2 origin tiles, we will have 2 more tiles than the scenario above, which means it's not a square. I guess the square you saw is another situation that in higher levels such as 0-4. That's because the whole world has a restricted extent; for example in decimal degree is between -180 to 180 in horizontal and -90 to 90 in vertical; so in zoom level one, there is only one tile displays the whole map, and tile buffer is useless because it has been outside of the restricted area, so you saw the square effect. The same reason to the other levels. Hope it makes sense.



For your second issue, I guess what you mean is overlay or layer is not matched. I did some test but cannot recreate this issue, please see the screen-shot below. This sample set 4 as TileBuffer and the overlays are perfectly matches. Maybe I misunderstand your point, so please feel free to let me know.





I quite understand for the last issue you mentioned; but I'm not sure the solution you provided. Could you explain more so that we can consider to enhance our control?



Thanks and feel free to let me know if there is any misunderstanding.



Thanks,

Howard



#3

Howard, a couple of things - 
  
 If you take a look at the client app I  have put in our directory on your ftp site I think you’ll be able to see what I am talking about - but actually Khalil has pointed out that we should probably be using the SingleTile mode based on the need to make no more then a single map request per update. Also I think SingleTile mode looks better when zooming, although not panning (It seems like google somehow handles a zoom like your SingleTile mode but panning like your MultiTile mode - and this would be ideal). The SingleTile mode doesn’t seem to currently do any tile buffering - unless there is some way I can control that - if that is something you guys could add support for that would be great. 
  
 If you run that client app you’ll see that the initial extent covers a very small area. Now you are correct in that it turns out that the tiles cached are not exactly a square because it is caching 6x7 = 42 tiles - however this still does not correspond to the height/width ratio of the map extent and when you zoom out what you see is that the amount of blank area that is getting pulled in along each side is not uniform. There is enough of a buffer south of the visible map area that basically no blank area gets pulled in when zooming out and this would be ideal if it were the case for the north, east and west map borders as well. The goal for the buffering is to allow most pans to happen seamlessly - so there is no blank area getting dragged in, unless of course the user pans far enough in a single drag. So if this is the behaviour when panning south (which it it) we would like it be the behavior when panning north, east and west as well. 
  
 As far as what i said about getting the visible tiles first I think the important thing is that only one map request is being made to the server per map update and this means the server would have to have some kind of cleverness as far as which tiles to return first - and that all might be a little too cute i don’t know, if the tiles can be returned fast enough then it’s probably a non-issue. 
  
  
    
  
  
  


#4

Actually Howard it would probably be ideal if we could control on the client the extent to which it was tile buffering - while again it should be uniform on each side. 
  
 Thanks, 
 Chris

#5

OK - I went back and looked at Google again and realized they don’t actually support what I was talking about as far as pulling in tiles on zooming out - it’s just they’re so damn fast in downloading the tiles that it almost looks that way. I would be happy if you guys just supported tile buffering with SingleTile mode and then if i had the ability to control the size of the buffer that would be even better. 
  
 Thanks, 
 Chris

#6

Hi Christopher, 
  
 I’m glad that you noticed Google does not work as you mentioned. You know we did a lot of test to look for a balance between the performance and experience. Actually to improve your requirement, we did two changes which is pretty good. First of all, if you are using multiple tile type, the buffered tiles will load after the tiles in the visible extent are loaded. So that you don’t need spend much time on waiting the buffer tiles. The second change is that we enhanced the cache for the single tile, and the buffer for the single tile is available which enhances the performance a lot; hope it does the way as you mentioned. 
  
 All these changes are completed today; so please get the latest dll 4.0.111.0 tomorrow. 
  
 Thanks for your ideas and feel free to let me know if you have any queries. 
  
 Thanks, 
 Howard

#7

Thanks for putting that change in. This is something we will definitely use and if I can get the tiles down fast enough I could set the buffer as high as 3, which would allow zooming out with no blank area getting pulled in to view. The only issue i’m seeing with it is that some of the street names seem to get clipped when the TileBuffer property is set to 1 or more where as I’m not getting any clipping of street names if I don’t set the property so there is no buffer. Also if I set layerOverlay.LockLayerMode = LockLayerMode.DoNotLock - it throws this error - 
  
 Type ‘ThinkGeo.MapSuite.WpfDesktopEdition.WpfMap’ in Assembly ‘WpfDesktopEdition, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null’ is not marked as serializable. 
  
 I’m not sure that I even want to set this property but i just wanted to give you a heads up on that - and it might not be related to this change since i had never set this property before today.  
  
 Thanks, 
 Chris

#8

Hi Christopher,



The property DoNotLock property means when the tile drawing in multithread in default mode; some resources will conflict with drawing other tiles; for example layer; so we need lock the layer and then draw it; unlock the layer. While if you set the mode to DoNotLock, we will clone the layer object and draw every tile with the cloned layer so that we don’t need to lock the layer anymore. It speeds up the performance. But this property is not in the public release and some issue may exist during the clone. I just think there might be a property or field is non-serializable. So could you please show us the code for the LayerOverlay you are using? Or show us the full stack trace. If you are using event on the layer or style, please set this property to default mode.



For the other issue, the label might draws on the edge of the tile. I think the code below helps. Please set these properties on the layer which is clipped.

highlightLayer.ZoomLevelSet.ZoomLevel01.DefaultTextStyle.SuppressPartialLabels = true;
highlightLayer.DrawingMarginPercentage = 50;


Thanks, 

Howard