[an error occurred while processing this directive][an error occurred while processing this directive]
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 strategytile or attributeinvolves 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 layerjust 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 correctlysdegroup 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 choicesdissolve 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