"How many graphics can I put on my map?" or "How many points can I put on a map?" are common questions. This help topic will try to provide some guidelines and best practices for determing how many graphics are appropriate for display on a map.
A sample app is available to aid in answering how many graphics are appropriate for a map. It does this by arbitrarily displaying a number of points on a map. The objective of this app is to see how many, and what type, of graphics you can add to a map before performance starts to suffer.
Since this is dependent on many factors, e.g. browser, hardware, map size, it is probably best to test how a map performs with 1,000 or 5,000 or even 20,000 graphics.
Sample app: Point Graphics Performance
Not all point symbols are equal in terms of performance. The demo above has an option to select symbol type so you can easily compare them in your own browser. In-house performance tests showed basic simple marker symbols are usually faster than picture marker symbols, although this can change depending on the specified symbol properties.
After determining what a browser can handle in terms of raw numbers, it is time to consider user experience. Does putting a map with thousands of point graphics on a 15" screen provide a meaningful user experience? In most cases, probably not. Besides looking for a general spatial distribution pattern, it is probably not helping a user discover much or answer any particular question by showing thousands of point graphics at one time. If you find yourself in this situation, it is a good time to consider using a raster surface (like a heatmap), filtering your data through queries, clustering or even aggregating the data beforehand. ArcGIS Online provides several services that summarize data or analyze patterns. Some of these include Aggregate Points, Calculate Density, Find Hot Spots etc.
Using polygon graphics is a bit more complex. Not only do you need to worry about the number of polygons, but the number of polygon vertices also needs to be considered. More detailed geometries take longer to transfer to the client, and once they make it to the client, they require more resources to display.
It is not always necessary to display complex geometries. They can slow down an application in query time, network time, and drawing time, while not adding anything of value if the details can't be seen.
Features can either be generalized in the database before being published to your server, or on-the-fly using the maxAllowableOffset
property on feature layers.
Using maxAllowableOffet can dramatically reduce feature sizes for detailed features.
See the Feature Layer Best Practices topic for more information on maxAllowableOffset.
Consider draw time and user experience when determining limits for drawing graphics on a map. Another two are query time and download time. Query time refers to the amount of time it takes a server to generate a response, whereas download time refers to the amount of time it takes for a client to download a response from a server. If too much time is spent on either of these, user experience suffers. If query and/or download takes too long, users may lose interest before the data arrives. Application developers should aim for minimizing download and query time. The best general strategy for both is for an app to only request the data it needs.