ThinkGeo.com    |     Documentation    |     Premium Support

Async load of data from FeatureSource

#1

Hello,


I'm having an issue where I have multiple FeatureLayers which take a little time to load the required data from its FeatureSource... because of this, it prevents some of the base layers from drawing until these layers have been drawn.  I was wondering if you had a sample to load/draw these FeatureLayers in an asynchronous fashion so that when the user zooms, it looks like the map zooms right away, then the layers on top draw?


Thanks,


.Ryan.



#2

Ryan, 
  
 Thanks for your question, do you want we load base layer first and show that then asynchronous load the slow layers and show it? 
  
 I think if we can do that we maybe have a thread problem here. 
  
 I will make sure this and reply you tomorrow. 
  
 Regards, 
  
 Don

#3

Hi Don...


My overlay structure kind of looks like the following (in order of how I load it, so bottom most is on the top of my list):


 


Area Base Data


Imagery


Line/Text Base Data


My Map Data (really there are 10-15 different overlays here)


 


 


What I believe I have been seeing is when you zoom/pan the map, the map draws the overlays from top most (My Map Data in this case) to the lowest (Area Base Data in this case), and so the base map data is not drawn until all of my map data overlays are drawn... which could take a couple seconds depending on the data.  I've verified this by removing all my data layers and observed that the draw time went from a couple seconds to almost instant.  What I would like to see is when the user zooms, the base map data is drawn first, then my map data...  Right now because of the delay the users think that the entire map is slow, whereas if the base layers loaded, they would see the map do something right when they zoomed or panned.  I'm nto really sure the best way to do this, just draw whn the layer is done loading or actually mark some overlays as priority (in my case I really have 2 or 3 layers that I'd want to have drawing priority).  


Any advice would be appreciated.


 


.Ryan.



#4

Ryan, 
  
 If you put data in different overlay, the earlier added overlay will be rendered first, then the 2nd, the 3rd… one by one. 
  
 So if you want to let the fast overlay load first, you just need add that to map as the 1st overlay. 
  
 You said your “Area Base Data” load fast and some of your “My Map Data” load slow, so the “Area Base Data” shouldn’t wait the “My Map Data” overlays load ended, that’s a little strange.  
  
 We have sample “FindTheFeatureAUserClickedOn” in our HowDoISample, the worldMapKitOverlay load slow becasue need download image from network and the worldOverlay fast because local data, when you pan the map, you can see the worldOverlay render first then the worldMapKitOverlay rendered. 
  
 Could you have a look at the sample and compare your code? If you cannot found difference I think a simple sample will be helpful. 
  
 Regards, 
  
 Don

#5

Hi Don,


I'm using ShapeFileFeatureLayers as my base data.  As far as the layers containing my data, they are custom overlays (FeatureSourceMarkerOverlay) coming from a custom datasource which sometimes has delay.  When I zoom or pan, the background data (those overlays were added first) don't get drawin until all the data is loaded.  Now that I think about it, the machines we are testing on are single core, so the load could be locking up the drawing until they are done.  If this is the case, is there any way to say draw these overlays, then load the data of these overlays second?


.Ryan.



#6

 Ryan, just to add onto what Don has stated, you need to be conservative on you use of Overlays.  If you having 15 overlays, I have a sneaky suspicion that you have 1 layer in each overlay.  The more overlays you have, the worse the performance.  Recommended practice is to keep the number of overlays as small as possible and instead group a number a layers into one overlay, also setting the TileType of these overlay to MultipleTile for async tile creation .  This should eliminate the problem you are observing where map appears to lock up.   Also, be conservative on your use of MarkerOverlays.  Use InMemoryFeatureLayers with a regular LayerOverlays for optimal performance.


This should help with your performance.  Our application uses 3 overlays only but supports over 50+ layers.


See these posts:


gis.thinkgeo.com/Support/Dis...fault.aspx


gis.thinkgeo.com/Support/Dis...fault.aspx


gis.thinkgeo.com/Support/Dis...fault.aspx


 


Just to add, we use the WorldMapKit that contains about 100+ ShapeFiles for basemap and performance is very good on a fast machine.  



#7

Hi Klaus, 
  
 Thanks for your post.  The reason for so many overlays is I make use of Markers a lot, and each of those is their own overlay.  I plan at combining them into a single one in the future, but the majority of my time is spent actually querying the datasource rather than drawing the layer (I see the same thing happen even if there are no markers returned to be drawn)… so doing that should still speed it up some.  I have a couple ideas, but I just wanted to see if there was just something simple I was missing/doing wrong.  Thanks for you help. 
  
 .Ryan.

#8

Just as a note to my post 2 ago… I notice the delay even on my quad core machine, so it isn’t specific to a single core machine, although the delay is MUCH smaller.  I’ll see if I can come up with a sample in the next couple of days

#9

That was easier than I thought.  I attached a sample that has 2 overlays... the first being an OSMOverlay, the 2nd being a marker overlay whos feature source simple sleeps for 5 seconds, then returns an empty list.  If you use like zoom box, you can see that the map just sits there for 5 seconds before redrawing.  If you comment out the line that adds the delayed overlay, you can see that the map loads right away.  This is what I would like to happen even if my other overlays are taking a long time to draw.


 


Thanks,


Ryan



DelayTest.zip (13.6 KB)

#10

 This is an interesting post of which TileType.MultipleTile which is the default setting for LayerOverlay.TileType does not fix.  What is also interesting, but does not directly apply to Ryan scenario as he is using  FeatureSourceMarkerOverlay, is that for MultipleTile type, data retrieval is happening on a worker thread yet there is still a delay of 5 before the map renders after a zoom operation.    This should not be happening.  


 



#11

Ryan, 
  
 Is the FeatureSourceMarkerOverlay which you are using in your current project? 
  
 I build a test sample for LayerOverlay before and that shows the delay won’t happen, I think FeatureSourceMarkerOverlay should have some different. 
  
 Thanks for your sample, we will have a look at it. 
  
 Regards, 
  
 Don

#12

Klaus, 
  
 Thanks for your help with this problem, your reply is also very helpful! 
  
 Regards, 
  
 Don

#13

Hi Don, 
  
 Yes, I am using FeatureSourceMarkerOverlay.  Thanks for your help.  Any more questions feel free to let me know. 
  
 .Ryan.

#14

Ryan, 
  
 Because in our orginal test code we don’t use FeatureSourceMarkerOverlay, so I think we need have a solution or workaround for your situation. 
  
 I think our developer can give some response about this question next Monday. 
  
 Regards, 
  
 Don

#15

Ryan, 
  
 I have made sure that our FeatureSourceMarkerOverlay load synchronous. 
  
 I think we don’t have a plan to change our WpfdesktopEdition to make FeatureSourceMarkerOverlay load asynchronous. So I think the workaround should be use LayerOverlay to simulate how FeatureSourceMarkerOverlay works. 
  
 Regards, 
  
 Don

#16

Is there any workaround for this allowing us to simulate FeatureSourceMarkerOverlay being async?  The problem with LayerOverlay is that it does not give me all the nice stuff built in that Markers give me… If not I’ll have to figure out how to simulate instant fetch on my FeatureSource. 
  
 .Ryan.

#17

Is there a list somewhere of which Overlays are synchronous and which ones are asynchronous?  This would help greatly in deciding which types of Overlays to use.  Thanks. 
  
 .Ryan.

#18

Ryan, 
  
 If the instance of one overlay can set its tile type, this overlay are asynchronous. 
  
 Regards, 
  
 Don

#19

Ryan, 
  
 Follow our current logic, implement FeatureSourceMarkerOverlay asynchronous will get twinkling effect, that’s why we haven’t implement that yet. 
  
 So I think maybe you can implement that like this. If you are in lower zoom level (contains many markers), just use featurelayer to replace FeatureSourceMarkerOverlay and if customer zoom to high level(contains less markers) you can choose FeatureSourceMarkerOverlay. 
  
 Regards, 
  
 Don