ThinkGeo.com    |     Documentation    |     Premium Support

CustomColumnFetch is slower then SymbolValueRenderer?

#1

I am converting the 2.0 code to 3.0 but have some serious performance issues so I think I'm not doing it right. 


I have a CustomOverlays with a ShapeFileFeatureLayer with about 5000 polygons. That goes on top of a google map. I have about 22 valueStyle on this layer. 


So I'm trying to have 22 different AreaStyles depending on some data I get from the database. So the result would be a map with 22 regions who have different colors. (not all polygons are covered, only about 800 in this 22 region example) 


To achieve this I'm using the FeatureSource.CustomColumnFetch event and a RequiredColumnNames that isn't in the shpae file. This seems to be slow. Slower then the SymbolValueRenderer I used to use? Is this normal? My CPU goes to 100% for minutes but eventually it shows the map correctly. 


How much does this event get called? Once for each polygon for each CustomStyle? Is this the way to do what I want to do with the new version? 


Thanks!



#2

It seems that all the CustomColumnFetch events are executed again when I pan the map? 
  
 Is there a way to add a coluln dynamically to the layer and fill out the values so that it doesn’t have to work through the event? 
  


#3




 


Elm,


As ValueStyle needs to choose the right style from many candidates for each feature,  it is slow especially when it includes many value Items.  To solve that, we introduced DictionaryValueStyle which uses Dictionary instead of Collection for the style matching, please have a try and it will improve the performance significantly.


Here is how to implement the DictionarValueStyle with complete code.


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


About CustomeColumnFetch event, it will be raised once for each polygon.  So if there are 100 polygons within the current extent and every feature has one custom column, it will be raised 100 times even there are 22 styles on it. I'm a bit interested on your FeatureSource_CustomColumnFetch method, is there a big “switch case” (or “if else”) statement inside to set every feature's column value based on its ID? You can also try Dictionary there if you didn't do it which will also raise the performance.


If you are using CustomColumnFetch, you do not need to set the RequiredColumnNames yourself. (I.E, for the sample Feature layer->AddMyOwnCustomDataToAFeatureLayer, there we do not set RequiredColumnNames).


Whenever you pan, the CustomColumnFetch will be raised to get the column data for the new feature. Like  mentioned above, you can use a Dictionary as a cache in the  FeatureSource_CustomColumnFetch method.


Thanks,


Ben






#4

Hi Ben, 
  
  
 I was already using a Dictionary in the CustomColumnFetch method. I tried the DictionarValueStyle implementation and I think the performance is much better now. I’m not using the CustomColumnFetch anymore as well. The idea is to click on a polygon to ‘select’ it (assign  hashstyle to it). I still ‘looks’ slow because I need to refresh the overlay on each click. There are a lot of polygons so it is not really possible to achieve what I want in javascript select. I guess there is no other solution? 
  
 Thanks!

#5

Elm, 
  
 Just want to make sure that when you click on a polygon to ‘highlight’ it, what you did is to get that polygon and add it to an inMemoryFeatureLayer in a separate  LayerOverlay, so you just need to redraw that LayerOverlay which only includes the layer you want to refresh.  
  
 Even with doing that, it’s impossible to make a postback select as fast as a javascript select. Maybe you can try Callback which is usually having better performance. 
  
 Thanks, 
  
 Ben 


#6

Thanks ben this is working much better. 
  
 You said that only the overlay that I call Redraw on should be redrawn. Does this mean the other overlays shouldn’t refresh? I can clearly see that the other overlays are also remvoed from the map and drawn again? 
  
 Thanks!

#7

Elm, 
  
 Yes, only the overlay that we call Redraw on should be redrawn. But all the overlays, no matter with Redraw() or not, will refill into the map after every refresh. The difference is that the Redrawing overlay gets the image from server, while the other overlays gets image from the browser cache. 
  
 I’ve add it in our Tracking system to see if we can avoid refill the images to map if the overlay isn’t with redrawing. Thanks very much for pointing it out. 
  
 Thanks, 
  
 Ben

#8

Hi Ben,


 


will this issue be implemented in the next release?


 


Thanks!


 



#9

Hi Elm,


In fact, we can not avoid refilling the images after a post back because it is the web application mechanism, but if the map control is in an update panel the refill process is so fast that you can not see the refill effect at all. This is because the overlay which doesn’t need to redraw has already been cached in the client side DOM tree and doesn’t request images from server side.
Please take a look at the effect of “Find the Feature the User Clicked” sample which is located in “HowDoISamples/Getting Started”. There are there overlays in that sample and the map just redraws the top overlay when you click on the map control.
Any more questions please let us know.
Thanks,
Sun