ThinkGeo Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Map Suite Performance Guide ======

{{section>upgrade_map_suite_to_10.0}}

<div msgbox>This guide is a work in progress.</div>

<div msgbox>The Map Suite Performance Guide was designed to be applicable across the Map Suite product line.  In some instances there may be minor coding difference between them and you may need to slightly tweak the code examples.</div>

===== Data =====
==== Building Spatial Indexes ====
==== Simply Data ====
==== Splitting Data by Classification ====
==== Grid Detailed Polygons ====
One way to dramatically increase performance is to grid your polygons, thus getting them into an optimized state for rendering.  What we want to do is get the average tile render time to be as low as possible.  Typically, the features that take the longest time to draw are high point-count polygon layers.  Imagine you are rendering a low-level tile that is essentially blank.  Most places are empty space at the lowest level, containing perhaps only a small road segment or something similar.  To render this, you typically use the country / region polygon to render the earth tone that is the background of your map.  There may also be large polygons as well which, while not in view, will be loaded as the tile being rendered is within their spatial bounding box.  In order for that simple tile to draw, it needs to read the large region polygon, which may have hundreds of thousands of points, and draw it.  While most or all of the points are clipped at run-time, it still takes time to load the bytes from disk, transform to well-known binary, clip them, etc.  In many examples, a simple tile can take 500 milliseconds to draw even though it is essentially blank.  This makes every area on the map very heavy and inefficient. 

To solve this issue, we suggest that you grid and split your polygon Shapefiles specifically for improved drawing speed.  In this process we take your original high point-count polygon and split it with a grid, with a size depending on the target scale, so that much of the old polygon's area is made of very simple squares with each being composed of just the square's edges.  When your simple tile goes to draw, it finds the simple square, draws that and the whole process avoids loading and drawing the tens of thousands of points.  We regularly see rendering times for the layer decrease from 500ms to less than 5ms. 

It is important to note that you want to change your styling so that you only fill in the new polygons and do not draw a border around them.  For drawing the actual border, in the case of a tile intersecting the real border, we have another approach.  In our utility we enable you to also convert your large polygon files to a split-up line file.  Using this method you can display a line file and style it for the border, and then display a fill-style Shapefile for the fill.  In this way your drawing speed will improve greatly.  A great way to find issues is to look at the render times per layer to see where bottlenecks are.  On each layer there is a DrawingTime property you can check after you draw.  This is invaluable to troubleshoot drawing performance related issues.

To help create the grid polygon layers, we have created a utility to assist you.  I suggest you play around with the scale and view the output to see what is going on.  The source is included so you can see what is happening and integrate this into other processes as necessary.  One important thing to mention is that I suggest doing this with nearly all of your high point-count polygon files.  Many times it is certain files that seem fine which are actually taking up all the rendering time.

<div captionwithborder floatleft>
{{:Map Suite Services Edition Sample Split Polygon Based On Grid Original.png?350px|Before Optimization}}
\\
Before Optimization
</div>
<div captionwithborder floatleft>
{{:Map Suite Services Edition Sample Split Polygon Based On Grid.png?390px|After Optimization}}
\\
After Optimization
</div>

<div newline></div>
**Resources:**

  * [[Map_Suite_Services_Edition_Spatial_Functions_Samples#Split_Polygon_Based_On_Grid|Utility: Split Polygon Based on Grid]]
  * [[http://download.thinkgeo.com/Videos/Wiki/IncreasingPolygonPerformance.wmv|Learning Video: Gridding Detailed Polygons for Increased Performance ]]

==== Remove Unnecessary Data ====
==== Projecting Data ====
===== Styles =====
==== Choosing Scales ====
==== Area Styles ====
==== Line Styles ====
==== Value Styles ====
==== Class Break Styles ====
==== Labeling ====
==== Custom Styles ====
==== Slower Styles ====
===== Layers & Overlays =====
==== Gathering Performance Data ====
==== InMemoryFeatureLayer ====
==== Pinning Files in Memory ====
==== Limiting Number of Features Drawn ====
==== Grouping Layers ====
==== Dynamic Features ====
==== Pregenerated Tile Cache ====
Pregenerating a tile cache allows your to render your vector data to raster tiles ahead of time for faster consumption in the future.  This systems is similar the ways that the large mapping providers such as Bing and Google export their data for consumption.  To help we have create the Tile Cache Generator utility, including source, which encapsulates best practices and many useful features when tiling your data.  Below is additional information on how tiling works, when you might use it, and its advantages and trade-offs.

=== Advantages ===
There are a number of advantages to pre-creating tiles but the biggest advantage to most of our customers is improved display performance.  Rendering vector data takes quite a bit of processing power depending on the number of records to draw, the size of the image and the complexity of the styles used.  In contrast once a tile has been rendered its display time is fixes regardless of the other factors listed above.  The difference is especially pronounces as the vector and style complexity rise.  

Another benefit to tiling is the ability to just distribute the raster data and not the vector data.  In many cases the precise vector data may be propitiatory and by providing the image you are not divulging the exact data in a format that can be easily reverse engineered.

=== Trade offs ===
The main problem with tiling is that the raster image represents a point in time regarding when the image was generated.  If the vector data is updated you need to re-generate the tiles to take that into account.  This may cause you the need to create a strategy to periodically refresh the tiles based on how frequently your data changes.  There are a number of ways this can be done efficiently such as re-generating only the tiles within the bounding box of the features that have changed.  

=== Common Scenarios ===
=== Temporary Tiling ===
=== Pre Tiling ===
==== GeoCache ====
===== WMS =====
User Tools

Site Tools

Page Tools
