ThinkGeo.com    |     Documentation    |     Premium Support

Truncated features when using cache

#1

Good afternoon,


I've been working with both FileBitmapTileCache and InMemoryBitmapTileCache and have found pieces of features are truncated when using these two cache modes.  Below, after having panned the map, you can see a missing vertical area where there is a gap in both the roads and buildings stretching from the intersection of E Orange St. and Cottage Avenue (about 1/4 the way from the left) down across E. King St.  If I use FileBitmapTileCache and track down the tile(s) the features are missing there, so it looks like the problem is in the tile generation.  As shown below, both roads and buildings are truncated.


   

junk.JPG640×527 90.1 KB


Is this a known issue? 


Thanks,


Allen Huber



#2

 


Allen,
 
It’s a weird issue, I try to reproduce your problem at my local machine but failed, could you provide a simple sample to us that can recreate this problem easily and then we can run it to find the real problem. If it needs some special data which you don’t want to others know, you can send it to support@thinkgeo.com and let him forward to Yale and James.
 
Thanks
James

#3

Hi James, 
  
 I did not know if this was a “known issue” so I didn’t spend a lot of time trying to identify the exact conditions.  It seemed that it happened after I had zoomed in a bit, but that might just be due to the fact when I zoomed in I could pan and new tiles were generated.  I will plan on looking into this further sometime today to see if I can isolate it a bit more.   
  
 Thanks, 
 Allen

#4

Allen, 
  
 This is an issue we have encountered before, but it is expected to have been fixed. Now, as James said, we cannot recreate this issue on our side, so it would be very helpful if you could send us a sample code to identify this issue. 
  
 Any more questions please feel free to let me know. 
  
 Thanks. 
  
 Yale

#5

Yale, 
  
 I will try to get more info to you on how to recreate this.  Using a cache has helped with the overlay redraw times but unfortunately has not decreased the CPU use, so we’re still trying to wade through all that at the moment.  Once we get that fixed I presume we will go back and see if the cache actually improves overall performance enough to be worth it. 
  
 Allen

#6

Allen,


Thanks for your post and feedbacks.
 
I think the draw will still take up CPU even though we use the cache system; Still it need to fetch tiles from disk (I/O) and draw those tiles into map control which will take up CPUs. As my experience, I think the use of Cache system will make performance much better especially when you have very complicated data.
 
Thanks.
 
Yale

#7

Yale, 
  
 Oh sure…I completely understand there will be some CPU activity caused by the cache. 
  
 Each time OverlayDrawn fired I was collecting the times for further analysis, and it appears that the processing done on an ever-increasing collection of these statistics was more of a CPU hog than I had expected…on a lower-end laptop we were hitting 100% CPU after a period of time, and since more stuff was being stored from each redraw it never got a chance to recover and brought the machine to its knees.  I even saw slow interface redraw on a desktop after a while.  I reduced the amount of stuff I was collecting and the CPU performance was greatly improved.   
  
 Enjoy the weekend… 
 Allen

#8

Allen, 
  
 Thanks for your feedbacks, any more questions please feel free to let me know.  
  
 James 


#9

Hello Allen,


I also have this drawing problem if I use caching system. It appears if we work with map control and activated MultiThread-Mode.


gis.thinkgeo.com/Support/Dis...aspx#19536


Please check if you are working in MultiThread-Mode.


Thomas



#10

Thomas, 
  
 I don’t think I’m using multithreading.  To the best of my knowledge, the default is single-thread and I know I haven’t changed it.  (I tried in a test program and immediately encountered those errors you get when trying to access the interface on a different thread and simply didn’t bother working with it any more.  I know this is not a MapSuite restriction; I’ve seen it when working with threads in other applications.)  I believe when I first noticed the bad tiling I was using the memory cache and switched to the file cache to see if it was different.  I initially was using file cache and didn’t see it, but I was just zooming in and out and not doing any of the panning which seems to be a contributing factor.  I am still planning to look at this further but it got bumped down in priority a little so it may not happen for a few days. 
  
 Allen

#11

Allen,


There is a sample “UsingTileCache” in HowDoI sample to show how to use FileBitmapTileCache, we have tested it by using our data, we did many operation for map, such as zoom in deeply, pan around, it works properly. Could you try to test it by using your data? If it works too, I think maybe your code is incorrect, you can provide your code and we can figure out what problem is; if it doesn’t work, you can provide your data to us and we can debug the code to find the problem. If the data is too large or you think it’s private, you can send to support@thinkgeo.com and let him forward to James.


Let me know if you have more comments.


Thanks,


James


 



#12

Hi James, 
  
 I’m not sure how there can be an error in my code.  I believe it was confirmed in another forum posting that it takes all of two lines of code to turn this on.  It seems that from the programmer’s point of view it either works or it doesn’t…and the first time I tried it it didn’t work because I didn’t have a subfolder named after the cache Id.   (The two lines of code I used were modeled after the HowDoI sample, by the way.  It seems nobody thinks I research an issue before I bring it to the forum!) 
  
 Anyway, I was panning around a fairly complicated map yesterday afternoon (actually it was the boss panning the map) and we continued to see this, but I have not yet determined any kind of pattern which would allow me to reproduce the problem on demand.  I did notice that it only appeared to happen when a certain type of road crossed a tile edge at a certain scale, so perhaps it’s related to a style at a certain scale, or a specific layer of data.  Once I can isolate it to a smaller data set and reproduce it upon demand I will let you guys know.   
  
 Thanks, 
 Allen

#13

Allen,


 I'm sorry, I did not mean that you didn't research the issue, just because we couldn't reproduced the problem, and we didn't have the data which caused the issue, so I just proposed a way we could try, we need to know if it's some special data to cause the issue or not.
 In the picture which you provided, there is a strange thing that the orange road looks like have more seam than the building upper the road, I think if the issue was caused by the tile edge, both the road and the building should had the same seams, same weight and same height. We will try some other way to reproduce the problem, it's much easier if you can provide the data or some sample code even it’s not incomplete, and i hope we can figure this out as soon as we can.
Let me know if you have more comments.
Thanks,
James

#14

Hi James, 
  
 Sorry about that comment.  I just mention that because I’m frequently told to check a sample program or forum posting and most of the time I’ve already seen them.  I know it’s best to point us programmers to the simplest solutions first.  I am not as patient as I should be. 
  
 Yes, that orange road is really odd!  As I said before, I’ve been trying to find a pattern where I can duplicate this, but I haven’t been able to do so and it’s not my #1 priority at the moment.  I want to research CPU use (not just OverlayDrawn times) with and without the cache…and if we actually see any difference it probably will become a higher priority.  As has probably been mentioned, most of our users operate with laptops that are about 1/2 to 1/3 as powerful as a desktop, so CPU usage is important.  I would not expect you to spend a lot of time on this cache problem.  Whenever I can supply data and a process that duplicates it, I will.   
  
 Thanks! 
 Allen

#15

Allen,


OK, we will have a test then once the demo is ready. :)


James