Geography Reference
In-Depth Information
the page; then drag the very bottom of the set of tables toward the bottom of the page. The points have
Feature Identifiers (FID) of 501, 502, and 503. The lines have IDs of 701, 702, and 703. The polygons
have IDs of 901, 902, and 903. The lines were created to have length 100. The polygons were created to
have area 2000 and perimeter of 240.
The anomaly of interest is that the FIDs of the polygons are 2, 3, and 4, when you might expect 1, 2, and
3, as is the case with points and lines. The reason for this is that the first record (not shown) with FID 1,
is the so-called outside or external polygon—as mentioned before, it consists of the entire Earth except
for the areas delineated by the other polygons. We will come back to this shortly.
3.
Start a new map. Add all the shapefiles. Open and arrange their attribute tables. (Some of the
fields have been carried over because of the conversion from the coverages. Some are useless.
Others, like AREA and PERIMETER were just copied, but you should realize that area and
perimeter are
not
automatically calculated for shapefiles.) What I want you to see here is that
the FID records begin with zero instead of one or two.
4.
Start a new map. Add all the personal geodatabase feature classes. Open and arrange their
attribute tables.
Here, in keeping with the idea that features are objects, the identifier is called an OBJECTID instead of FID
(feature identifier). In each case the records are numbered starting with 1.
So, there is a lack of consistency with the feature identifiers between geodatabase feature classes,
shapefiles, and coverages. We just wanted you to be aware of this so that it won't mystify you in the future
when dealing with real data in these formats.
There is another reason to examine the geodatabase feature class tables. Leave these tables up so that
you can examine them.
Computers and Inexact Computation
The LENGTH, AREA, and PERIMETER field values in the attribute table were carried over from the coverages.
They are, respectively, 100, 2000, and 240, exactly. The Shape_Length of each line, in Attributes of
feat_num_lns, however, is calculated in the conversion. It displays as 99.999999. The Shape_Lengths
and Shape_Areas in the polygon table are likewise slightly inaccurate. As previously mentioned, computers
cannot be counted upon to give exact answers. The difficulty is that, while computers can usually do exact
arithmetic with integers, they cannot be exact with floating-point numbers, which may have fractional parts.
These errors occur because humans do arithmetic with decimal (base 10), and computers do arithmetic
with binary (base 2). For example, it is not possible to exactly represent the decimal number one-tenth
(0.1) in binary. One-tenth in binary is represented (imprecisely) by the sum of some of the fractional
powers of two: one-sixteenth, one-thirty-second, one-two-hundred-fifty-sixth, and so on. In binary one tenth
looks something like 0.000110011… To be exact, the number would have to have an infinite number of
bits.
10
(Some decimal fractions can be represented exactly in binary. For example, decimal 0.5 is 0.1 in
binary (that's 2 to the minus one power); 0.25 is 0.01; 0.75 is 0.11; you see the pattern.)
10
Don't look down on binary, however. Every number system has this problem. For example, you cannot represent the
number one-third in the base 10 [decimal] system in a finite number of significant figures. An example approximation
is 0.3333333333; and you can never do better than an approximation.
Search WWH ::
Custom Search