Designing Geodatabases for Transportation. J. Allison ButlerЧитать онлайн книгу.
through a FeatureCursor class to access Feature instances. Both paths point to functions supplied by the Row class, which includes the interfaces needed to change, compare, and edit records in the data table, and to report errors. All rows in a table have the same fields. The Table class uses the Field classes to help it understand what is in each row.
The data dictionary view
ArcGIS provides the means to view a table or feature class using the physical data model perspective. This is called the data dictionary view because it displays the contents of each table or feature class. You can see the name for the class and its type in the header. If it is a feature class, you will also be able to see the type of geometry used and whether it contains measure (M) and elevation (Z) values.
Figure 3.4 Tables and feature classes A geodatabase is seen as a collection of tables and feature classes. These examples show the minimal attributes such classes will contain. You may add many other attributes to any of these classes, but you cannot delete the mandatory attributes.
Below the header is a listing of each field in the class’s table. The first field will always be OBJECTID. If it is a feature class, you will also see a Shape field and, depending on the type of feature, Shape_Length and Shape_Area fields. ArcGIS adds these fields and you cannot delete them or change their parameters.
When you create a field, you must specify a data type, whether null values are allowed, a default value that will be entered if the user makes no specific entry, the name of a domain to control data entries, the precision and scale of numeric fields, and the length of a string field. The user can modify field parameters that are not set to a dark gray background. At minimum, you must specify the name and data type for each field, and the length of any text field. The default value of 0 for numeric precision and scale will produce the standard form of that data type for the selected database management system. Indeed, precision and scale parameters you enter will only be used if the database management system uses ArcSDE. As we show below, your parameters for numeric fields may be only advisory, as ArcGIS can change them to optimize performance in the database management system you are using.
Figure 3.5 The data dictionary view This view reveals the descriptive information stored in the Table and Field classes. Each Field class instance is shown as a row in the data dictionary view, with the attributes of each field shown in columns. The darker gray boxes represent field attributes that cannot be changed by the user because ArcGIS controls the value that goes there or the attribute does not apply to that field. Both the table and feature class versions show the same set of field definitions, except that the feature class has an additional field called Shape. The feature class also has information in the upper right corner that reveals what GeometryDef knows about the class, which is also reflected in the class description and icon in the upper left corner.
Geodatabase field types
You will need to select a data type for each field you add to a table in an object or feature class. This section will discuss the most common types we will use in transportation data modeling: text (defined as a string of characters of a given maximum length), a variety of number formats, date/time, globally unique identifier (GUID), and binary large object (BLOB).
Text. A field that contains text data consists of a string of alphanumeric characters. ArcGIS uses the Unicode format to store text to facilitate the multiple languages in the geodatabase. You use text for fields that contain letters, numbers with leading zeroes, and any data where the content cannot be clearly anticipated. Once you select the String data type, you will need to specify the maximum number of characters permitted for an entry. You can control the content of a text field by using a coded-value domain when the possible values to be entered are well known and of a fairly limited number of choices. The field properties of precision and scale cannot be entered as they apply only to numbers.
Short integers. The 2 bytes needed for a field using the short-integer data type is the fewest number of bytes of any number format. The actual range of numbers available in 2 bytes depends on the database management system you are using. In most database environments, this data type can hold whole numbers in the range of -32,768 to +32,767. If you use small integer numbers to represent values in a list of choices, you can control data entry for a short integer field using a coded-value domain or a range domain. The default precision for a short integer is zero; you can supply another value as a means of ensuring that numbers entered do not exceed a general range. The valid choices depend on the database management system you are using. Oracle has a maximum precision of 4, while DB2 and Informix set a single choice for precision of 5. You must leave a digit for a negative sign but not a positive sign. You cannot enter a value for the scale parameter.
Long integers. A long-integer field uses 4 bytes to store the number. The allowable range for long integers is a whole number in the general range of -2 billion to +2 billion. A long integer has a precision of 5 to 10. As with short integers, you must include a digit to accommodate any negative sign that may be permitted. You cannot set the scale parameter.
Floating-point numbers (single-precision numbers). The Float data type is the smallest numeric format that can include fractions. Like the long-integer data type, a floating-point number field requires 4 bytes of storage. You can set both precision and scale parameters for a floating-point number field. For example, if the largest value you anticipate being entered in a floating-point field is 999.99, then you would set the precision to 5 and the scale to 2. If a user tried to enter a number with three digits after the decimal, ArcGIS would display an error message. A floating-point number can accommodate a precision of up to 6 and a scale of up to 6, with scale always being equal to or less than precision. The maximum precision for any Float number type in a file data structure or a personal geodatabase is 6. You do not need to include a digit for the decimal point when determining the precision parameter, but you do for any permitted negative sign.
Double-precision floating-point numbers. The largest numeric format in terms of storage requirements is the double-precision number, which needs 8 bytes. You can define any precision of 7 or more and any scale value. You can put some big numbers in a double-precision field. There are, however, certain limits imposed by the database management system. The practical limit for an ArcSDE database is 15 digits. You can put larger numbers into a Double field, but it will be rounded and stored in scientific notation.
As we noted earlier, ArcGIS may change the parameters of a numeric field from those you entered. For example, if you specify a data type of Double but specify a precision of 6 or less, ArcGIS will create the field as a single-precision floating-point number. Any numeric field with a precision of 10 or less and a scale of 0 should be an integer data type. Even if you expect only whole numbers to be entered into a field, any precision greater than 10 should be defined as a Double data type. Using a precision of 0 and a scale of 0 will cause ArcGIS to try to create a binary field of the type selected.
Date and time. ArcGIS uses a single data type to store date and time information, regardless of how the underlying database management system deals with dates. The format is mm/dd/yyyy hh:mm:ss.sss, with an indication as to whether the time is a.m. or p.m. You do not have to use the information stored in both parts of the Date data type, but they will be included.
Figure 3.6 Creating unique identifiers To generate globally unique object and feature identifiers, you usually create them in a structured way. If your agency has a centralized database editing approach, then all you need is a NextID Table. Every time you create a new object or feature class instance, you read the appropriate value, add 1 to the value you read, and write the new identifier value for the next created