ThinkGeo.com    |     Documentation    |     Premium Support

Label drawing performance issue

#1

 


I am trying to label the population of census blocks for Austin, Texas.  The data is included in the shapefile and the shapefile has a total of 35 columns and 675,062 shapes.  The area that is being drawn is at the 1:30,000 scale and includes approximately 2400 units to label.  In my test style, i have best placement set to false, overlappingrule to allowoverlapping, fittingpolygon false,  duplicate rune set to unlimited duplicates.


When panning or zooming at this level it takes 12 seconds to draw.  That seems excessively slow to me.  Am I missing something in my settings or is there some way to increase the performance?


Attached is a screen shot of the area that takes 12 seconds.  The center of the image is downtown austin for scale.




#2

Ed, 
  
 Welcome you to ThinkGeo Discussion forum. 
  
 Just make sure the performance issue you are talking about is the performance for panning or loading?  
  
 The panning performance issue refers the performance when panning, I have enhanced this performance quite a bit a few days ago. 
  
 The loading performance issue refers when you zooming or zooming out without tile cache set. This performance can be enhanced by a couple of ways, for example, by setting TileCache for your overlay or adjust the ZoomLevel etc. 
  
 Any more questions just feel free to let me know. 
  
 Thanks. 
  
 Yale 


#3

Yale, 
 It appears to be an issue with both.  When panning, it takes about 12 seconds to draw the new area.  When zooming out past level17 the performance gets worse.  I understand how the cache works but every time ithe user moved to a non cached area it would take 12 seconds.   
  
 I can limit the zoom level to where the performance is good, but it seems to me that at the 30,000 scale the performance should be better. 
  
 If you have any ideas I would be glad to them. 
  
 Thanks.

#4

Ed,


Thanks for your post and response, it seems your post are from different IPs, which made me mistake you are new to ThinkGeo components:).
 
So, when panning, you means that the 12 seconds is the time after MouseUp to the map was shown completely?  Did you set your overlay to BaseOverlay?
 
Thanks.
 
Yale

#5

Yale, 
 No worries, just checking in from home.  When i check the drawtime  of the overlay in overlaydrawn event, that is the time shown.  If i am just showing the lines without labels it performs well.  We were initially using the cachedfeature and I thought that might have been the problem because it would call the cumstomcolumn fetch event for each poly, so I added the data to the shapefile, built the index and the results are the same drawing from the shapefile data or the cached data. 
  
 So, the time is recorded from the overlaydrawn event, and the layer is not the baseoverlay. 
  
 Ed

#6

Ed, 
  
 Thanks for your response. 
  
 So your meaning is that the time was spent on the drawing of the labels? One way to make sure this is using Map Suite Explorer; just do the same thing in Map Suite Explorer to see its performance is the same with your application. 
  
 Thanks. 
  
 Yale 


#7

Yale, 
  
 I did try it and it seemed like it worked better in the explorer, but it also is only labeling about 10% of the units.  Since I am showing population i have to display duplicates otherwise blocks that all have 200 people for example will only be labeled once.  I could not set the properties on the text style to be the same as i have in my project so it is not a true test. 
  
 Ed

#8

Ed, 
  
 Thanks for your post and response. 
  
 The desktop edition cannot be faster than the Explorer, because it needs some other stuff to be done besides the drawing stuff. 
  
 If the drawing still take about 10 seconds in Explorer, I bet there are much more labels shown on this current extent. What is your opinion? 
  
 Any more questions just feel free to let me know. 
  
 Thanks. 
  
 Yale 


#9

Yale, 
 I agree the explorer was faster than  my application.  But in the explorer, only about 10% of the labels were being drawn as compared to the screen shot in my original post.   
  
 I think we are in agreement on this point.  But some of the properties i use, as stated in the first post, are not available in the sample explorer application so it was not really a fair comparison. 
  
 Ed

#10

Ed, 
  
 Yes, that is true. I agree with you completely now. 
  
 The other thing we can test is to use the Map Engine draw directly the way which the Map Suite Explore takes. 
  
 I am not sure you have the service edition or not, if not , you could download a trial version and follow the HowDoI sample for labeling, just change the data and label way. Basically, this should get the same result with Desktop Edition app while it will reflect the drawing time more acutely. 
  
 Any more questions just feel free to let me know. 
  
 Thanks. 
  
 Yale 


#11

Yale, 
  
 I don’t need to know how it works, I guess I was looking more for some best practices for labeling to achieve the best, fastest labeling for the scenerio presented in the original post.   
  
 There are alot of properties in the textstyle object but the documentation does not really explain what the settings do. 
  
 THanks, 
  
 Ed

#12

Ed, 
  
   Let me jump in and see if I can’t help.   
  
 1. I just want to make 100% you are building a spatial index for your shapefile.  That means there is an .idx and .ids with your shp files.  You build this using the ShapefileFeatureLayer.BuildIndex static method. 
  
 2. Are you drawing the polygons and labels as one layer?  If so for a test can you separate them.  Create one layer for the polygons and latter after that for the labels.  That means one layer has the area style and the other has the text style.  There is a property on your layers called DrawingTime, this it the time it took to draw the last time.  After you do a refresh or par check these two values, you don’t need to do it in en event you could just add a button to you app to check.  I need the values from the layers and not the overlay.  The overlay lumps them, I want to see the times for the labels and polygons separately.  This will allow me to see some real times and make 100% sure is the labeling.  At the same time I can get a feel for how long the polygons take to draw. 
  
 3. If just the polygons themselves take a few seconds to draw I would suggest you either simplify them into a new shapefile or you don;t draw them above a certain scale. 
  
 4. For the labeling the TextStyle has allot of optimizations for roads and that is a flaw I think.  If the label times are very slow then one approach would be for us to create a simple label style for you and we can cut our 90% of the extra logic and see how fast we can draw them in the best case.  That is actually fairly easy however we are dealing with polygons so we need to look at their points to see where to label and if you display allow of polygons with many points this will slow things down.  Simplifies polygons with half the number of points will increase the drawing speed dramatically.  We can help you with this as well. 
  
 5. I noticed form your screenshot that at that level you can barley even read the labels you have and 80% are just squeezed into nothingness.  I would suggest that it doesn’t make much sense to even label at the level you are showing me as it has not real use.  Allowing the user to zoom into will reduce greatly the number of polygons and speed up the labeling. 
  
 6. As a rule of thumb it takes longer to draw and label based on how much data there is.  This is directly effected by the number of records or the complexity of those records.  Sometimes you might have just five records but each record has 10,000 points which makes them complex.  you want to try and balance the record complexity with the scale you are working with.  For example I have a highway file for the US that is designed to display at the scale for showing the entire US.  it has just a few thousand points and displays quickly.  Of course I could not use that at lower levels as it would be inaccurate but at the same time I could not use the highly detailed file at high levels as it is made up of millions of points and would never get done drawing.  Labeling exacerbates the issue because not only does it have to look at the all the point sin the data but it needs to make decisions on the points.  Regular drawing just draws but labeling has to do some fitting and positioning etc so it is normally slower then drawing a feature. 
  
 7.  As we answer some of these questions there are some things we can do if you need to label many polygons like this.  One thing is that you can pre-compute the centers of the polygons and write it into the dbf of the shape file.  In this way we can write a quick customer labeled that can get the coordinates from the filed and it doesn’t need to compute any of the polygon information. 
  
 8. As you zoom out you could switch from Census block to census block group or tract.  These are higher level polygons and they may be more appropriate to show.  for example if you had population for every us country you could hardly show that at the full US level.  you would aggregate it up to the state level etc. 
  
 9. We have the census block data here as well and we can try to render it and label one of the columns.  It would be helpful if you could send us the code you use to render the layer.  That way we could see if there isn’t something else you might be doing that we can’t see. 
  
 David

#13

David,


Thanks for the response.  I'm going to try and answer your questions, and provide more information in the upcoming week. 


1.   The shapefile is indexed with the BuildIndex method.  The dbf is 42,581kb, the shp is 290,919kb, the idx is 38,344kb and the ids is 10,548.


2.  I will provide you this information on the drawing time later this week.


3.  The app has legal ramifications so simplification is not an option.


4.  It seems to be an issue with the number of polygons trying to be drawn.  I have some additional test to run this week to gather some numbers.


5.  Correct, I have implemented more scale dependency into the layers.  The lines and labels now turn on at different levels and I am using the levels that provided the greatest performance.  The clients found the solution acceptable.


6. Understood.


7. That is interesting.  We have written a custom label engine that will label all polygons that are in view.  We calculate if the centroid is visible, and if it is not, we bisect the polygon that is in view and place the point in the center.  This is being used in a limited fashion because of performance issues.


8.  That is something we are also considering.


9.  I am going to build a little project to send to you to demonstrate what is happening.  I think we are on the right track with the scale dependent drawing, but more information is better.  I will also include the code I discussed in question 7 and would like you to investigate implementing that functionality.  If it is a property like LabelAllPolygonsInView then it could be set by zoom level to increase performance.


 


I think we are close to an acceptable solution, but I would still like a review of what I am doing to make sure we are getting the most out of the sotware.  I will be sending a sample project later this week.


 


Thanks,


Ed



#14

Ed, 
  
   Sounds good, I am sure we can speed up the drawing time.  This is kind of a black art because data comes in so many shapes and sizes and everyone’s needs tend to be a little different.  After seeing the sample I should be able to turn something around quickly. 
  
 David

#15

David, 
  
 I have found the solution to the problem.  As I was building the test app, I was unable to reproduce the slowness that occurs on our app.  After additional review, our application had 2 paths for setting labels because we are using stacked labels, one method had the OverlappingRule set to NoOverlapping and the other set to AllowOverlapping.   
  
 Setting the OverLappingRule to AllowOverlapping resolved the issue.  This solution works for me because I can control the label with the scale dependency and turn them off before it gets to jumbled.   
  
 I still plan on sending the label in view project to see about implementing that feature in future versions. 
  
 Thanks, 
  
 ED

#16

Ed,  
  
 If your sample application is too large to attached to this post you can send your sample application to support @ thinkgeo.com or create a Customer Portal Ticket that can accept up to 500MB attachments. 
  
 Thanks!

#17

Ryan, 
 I have sent the sample app to support.  The sample I sent shows an enhancement I would like that lables all parts of a polygon nut just the centroid.  It also calculates a new label point if the centroid is outside of the polygon. 
  
 THanks, 
  
 Ed

#18

Ed,  
 Thanks for providing that sample. It will be forwarded to the Development team for review.

#19


Ed,


I have created a small sample to show how to label every part of multi-parts polygon, the key API is using LabelAllPolygonParts


cntyLabelLayer.ZoomLevelSet.ZoomLevel01.DefaultTextStyle.LabelAllPolygonParts = true;

Thanks


James


 


 




 




1801-LabelAllPolygonParts.zip (29.1 KB)

#20

Ed,


I have recevied your sample code and then I update a little bit to make it fit for your requirement.



Thanks


James


 



1813-ScalingTextStyle.zip (39.7 KB)