Unable to zoom in beyond a certain point

Description

Cause

There are a number of reasons a user may be unable to zoom in beyond a certain point.

TOLERANCES:
All features are defined by coordinates. In order for programs to display a feature, it must read all the coordinates. The coordinates are almost always read as "real" numbers, which means that the numbers have a decimal point. These real numbers always have a tolerance or rounding factor applied to them. The tolerance is applied because a computer cannot store the exact number. The exact value cannot be stored for several reasons. Some numbers have repeated values. One third, for example, is .33333. Other numbers have never been found. Pi, for instance, is often referred to as 3.1417 but the actual value of pi has not been found. The computer gives real numbers a tolerance, or rounding value called epsilon, to approximate the number. We say, for example, that pi is about 3.14.

How does the computer determine a tolerance? The tolerance a computer uses depends on the values it works with. If the numbers are in the millions the tolerance will be greater than numbers that are in tens. To understand how a tolerance works let's look at zooming in on data. To zoom in you use, for example, two points that define the rectangle you want to zoom in on. At some point, because of rounding by the floating-point processor in the computer, the coordinates of the points you use to define the rectangle will be identical. This happens when the difference between the coordinates for the rectangle fall within the epsilon, or rounding factor. When both values are within epsilon the cpu will not be able to tell that there is a difference between the two values. No further zoom in will be allowed because the two values will be treated as a point. You can’t zoom in on a point.

SOURCES OF DATA:
Tolerances for shapefiles and ArcSDE features are very different. The tolerances used for determining which coordinates get displayed in shapefiles are set by the computer through the tolerance, or epsilon, or by the program that displays the shapefile. With ArcSDE, a tolerance can be set when you load the data. The tolerance set for an ArcSDE layer will be used unless it's less than the tolerance used by the computer's floating point processor.

Features in ArcSDE and shapefiles are very sensitive to the extent of the data as well. The most common problem with features not being displayed in ArcSDE or even in shapefiles is that the extent of the layer or shapefile is not correct. If the extents are much larger than the area where the features are located the data will simply not be visible. Incorrect extent sizes are easy to fix in ArcSDE. The ArcSDE command sdelayer -o alter -E calc will set the layer extent by using the features in the layer to calculate a new extent for the layer. For displaying shapefiles the situation is very different. ArcGIs 8.1 and ArcView GIS 3.2 do not use extent information included in shapefiles. Applications like ArcView calculate extent "on the fly" to always show the data. Shapefile extents are changed by eliminating spurious data. In other words, if the features in a shapefile are not displayed, there is either a problem with the data or with the application showing the data.

Shapefiles and ArcSDE store coordinates differently. Shapefiles store coordinates with more precision. The coordinates in shapefiles are stored as a "double" or in two “words” (8 bytes). ArcSDE stores coordinates in one word (4 bytes), or half as much space. This means that the tolerance a computer will allow for shapefiles is much greater than the tolerance for an ArcSDE layer. The result is that you can always zoom further in on shapefiles than on an ArcSDE layer. The final word on this matter is that there is no threshold anyone can give you about the scale at which data will not display. We cannot say 1:2000000 or 1:2. The point at which features do not display is a function of the coordinate values of the features and the application you use to display them, not an abstract formula.

GENERALIZATION IN ArcIMS:
ArcIMS has two basic ways of rendering features on a map. ArcIMS can render features as an image or can send features to the client allowing the client to render the features locally.

Image generalization. When features are rendered as an image the spatial server component of ArcIMS converts the extent of the layer to pixels based on the size of the image the client browser will receive. The generalization process amounts to creating an image of the entire map extent. This means that if a client browser wants to see a 800 by 600 image of features in an area that is 800 by 600 no detail will be lost. However, if the client browser needs an image that is 800 by 600 for an area that is 3200 by 2400, some detail will be lost. In the latter case, features that are less than 3 pixels long may disappear altogether because features that fit in an area 3200 by 2400 will have to be represented in an area much smaller-800 by 600.

Image generalization does not change features. Image generalization tends to drop features from an image. The point at which features will drop is unique to each layer because the features on each layer are different. Each type of feature, point, line, and area, has a different shape and extent. Within a layer lines or areas may contain features with different shapes. The distribution of features in a layer is often unique to each layer as well. Although features may vary in size and shape, ultimately the entire layer is converted to an image based on the extent of the layer and the size of the image to be displayed in the browser. That is why the only consistent factors in determining which features appear in a layer are the extent of the map layer and the size of the image that will be displayed in the browser.

Feature streaming. This process is unique to ArcIMS. Feature streaming means that individual features are sent from the spatial server in ArcIMS directly to the client. Each feature is generalized on the server before it is sent to the client. A tolerance is used to drop coordinates from features much like the floating point processor drops coordinates. The tolerance is set within the feature service. This service takes each feature and drops coordinates based in part upon the size of the area the user wants to view. An additional assumption is made to determine the tolerance. This additional assumption is that the user will want to zoom in about 40 times. The value, 40, along with the size of the area the user wants to view determines the tolerance. The result is that features on a map will tend to change shape before the features are dropped entirely. The features will change shape because individual coordinates are dropped through the application of the tolerance value. If you zoom in or out far enough entire features may ultimately be dropped. The key factors in what is displayed in a feature service are the extent of the area that will be viewed and the coordinate tolerance for the features.

Other factors, such as the axl tags densify and densifyfeature are also important in showing features, however, the features that result are under the same constraints as any other feature served through an image or a feature service.

Workaround