ArcUser Online

Enhancing ArcSDE Layer Display Speed
By Danny Krouk and Girk Cakmak, Esri-California

ArcSDE provides high-performance, enterprisewide data serving solutions for GIS data. In the GIS world, we like our layers to be large and seamless, but most of our work gets done in small areas of those large layers. Much of the real benefit of ArcSDE is in its ability to solve this "give me a small piece of this big area" problem.

However, what happens when your GIS users need to work with the full extent of large layers? ArcSDE will serve that data up, but your users should be prepared for a wait as tens of megabytes traverse the network from the database to their application.

The problem of how to deliver huge amounts of data across a network is a tricky one. There are no easy answers. However, ArcSDE has a little-known utility called sdegroup that can help with some aspects of this problem. If your primary objective is improving the display speed of large extent draws, sdegroup may offer some benefits. This article describes what sdegroup does, its pros and cons, and some best practices for implementing it.

The sdegroup Command

The sdegroup command allows you to create summarized or grouped copies of ArcSDE layers. These grouped layers look just like regular layers, but they draw more quickly. The improvement in drawing speed can be quite dramatic. In informal testing, sdegroup layers displayed between two and 10 times faster than the original ArcSDE layers.

Of course, there is a trade-off. Because sdegroup layers have no attributes, most identify or attribute query functionality on sdegroup layers is eliminated and options for symbology are limited. Although sdegroup layers are just for display, they do display quickly and that can supply a piece that may be missing in your ArcSDE solution.

An example illustrates this point. Users get the original ArcSDE layer when working in manageably sized areas but, as they zoom out and performance degrades, original layer drawing is suppressed and the sdegroup layer draws instead. In principle, this is how sdegroup layers are beneficial.

A Bit More Detail

The reason sdegroup layers do not have any meaningful attributes is because the sdegroup command merges features that are near one another in space. Merging saves on storage space and allows more rapid data retrieval. For example, consider a layer of street data. If we place an imaginary grid over the street network, all of the features in a single grid cell are merged into a single geometry. If the 100 block of State Street and the 700 block of Main Street fell in the same grid cell, those features would be merged together. The geometry would look the same but if you selected either State or Main, the new grouped feature (containing both the 100 block of State Street and 700 block of Main Street) would be selected. In this case, the original attributes of both blocks cannot meaningfully serve this grouped geometry. Called grouping by tile, this is the default behavior of sdegroup.

However, there is a way to maintain one attribute on an sdegroup layer. This can be useful if you need an attribute for symbology purposes. For example, in a layer of sewer mains, one attribute may indicate the service region. Typically, when users draw the data at the full extent, they want to see the pipes colored by service region. Instead of grouping by tile, grouping features by the service region attribute will result in all of the pipes in each region being grouped into a single feature. While not very useful for seeing details, such as the material or diameter of a particular pipe segment, grouping by attribute maintains an attribute that allows for the generation of necessary symbology.

Either strategy—tile or attribute—involves a bit of a balancing act. You want to group features to improve display speed. However, you also want the group size to be fairly even. Using the street network example, if you grouped the street layer by street type, you would have many streets, boulevards, and avenues but few highways, circles, and places. However, these features would not be near each other in space and this would limit performance. In addition, groups can become too large. While grouping all features into only one or two groups might work well when displaying the layer at the full extent, zooming in 50 percent would require accessing the whole layer—just what you are trying to avoid by using an sdegroup layer.

There is another major limitation with sdegroup layers. Apply sdegroup to a point layer, you get a point layer. Apply sdegroup to a line layer, you get a line layer. Apply sdegroup to a polygon layer, you get a line layer. Yes, you read that correctly—sdegroup polygon layers don't exist because the Open GIS Consortium (OGC) and SQL Multimedia (SQLMM) standards both stipulate that polygon elements within a multipolygon feature may not intersect at a line or polygon. Given this restriction, there are two choices—dissolve the interior boundaries to create one big polygon or treat the polygons as lines. Because sdegroup treats the polygons as lines, although sdegroup can be applied to a parcel layer, you cannot have a fill symbol on the result. However, this can be handled by having these lines draw on top of a less detailed solid-fill background, such as a jurisdiction boundary or land use polygon layer.

Continued on page 2