Designing Geodatabases for Transportation. J. Allison ButlerЧитать онлайн книгу.
in a decentralized editing process, where multiple data sources may combine data, you will benefit from one of two additional actions. Should there be only a few editing agencies, you can start each NextID Table with different seed numbers so that each has a single numeric range to work with—one big enough to never extend into another agency’s range. If there are several data suppliers, then you can use an identifier that consists of two parts: an agency identifier and the sequence number generated by the NextID Table approach. The latter option was proposed in the FGDC’s Transportation Feature Identification Standard.
Globally unique identifier. If you want to ensure that the row identifier is always unique across the geodatabase, you can create a field of the GUID type. A GUID consists of 36 characters enclosed in curly brackets {} and is designed to be unique in the world. (When we said it was globally unique, we meant it!) ArcGIS uses GUID fields internally to manage feature replication. You can use the same technique when you expect to share data with outside users and want to ensure that your feature identifiers do not conflict with other users’. If your database management system supports the GUID data type, ArcGIS will only need 16 bytes to store the field’s value. Otherwise, 38 bytes will be required.
Binary large object. A BLOB is just a big box in which to put data of any structure. It can be a scanned document image, or a video of a crash scene. It can even contain computer software. Whatever you put in a BLOB field is yours to manage. ArcGIS can put it in the field and take it out, but you must write or acquire the software needed to understand what a field with this data type contains.
Attribute domains
An attribute domain is a rule that limits users’ data entries to a specific set of valid choices. A domain is a declaration of acceptable values for a field. Data quality is improved if you can keep obviously bad data out. Someone may still make a bad choice, but at least it is not something completely unexpected.
Figure 3.7 Domain control To ensure that only valid data gets into the database, you must control data entry. A common approach is to convert relatively limited value domains to a list of valid choices, each of which is represented by an abbreviation, called a code. The coded value can be put in a data table as a foreign key that points to a “lookup table” that stores what the value really means. (The code attribute is a candidate key, so it meets the requirements for this one-to-many relationship.) This operation requires software that can check an entry against the legitimate values stored in the look-up table. Attrib2 contains foreign key values tied to Lookup Table : Code. Every person who writes a computer program to utilize the same lookup table must provide the same code.
A lookup table is the traditional way to control a domain consisting of a finite list of choices. You create a column in the entity attribute table that includes a foreign key to the lookup table that contains the meaning of various coded values. Your data entry application builds a pick list from the lookup table’s rows, and users pick one of the available selections. This process requires you to create a table for each domain you want to control and write the software needed to get the input screen to go to the lookup table for the values of each field it controls.
Figure 3.8 Geodatabase domain control classes The geodatabase supports two domain control methods: numeric range and coded values. Domains are named and apply to an entire workspace, even across datasets within that workspace.
The geodatabase greatly reduces your workload when using attribute domains. You need only tell ArcGIS what you want to do and it takes care of the work. The earlier geodatabase conceptual class model showed the abstract Domain class. Figures 3.8 and 3.9 show the details. There are two specializations of the Domain class, one for numeric range domains and one for coded-value domains. Using the domain control function in ArcGIS is fairly simple.
First, specify a domain name. You also can enter a small description for what the domain contains. You will enter the domain name in the data dictionary row describing a field each time you use this domain.
Next, specify the data type, which must be the same as any field to which you apply the domain. You can use text, short integer, long integer, float, double, and date data types in a domain class.
Then tell ArcGIS which kind of domain you want to use: numeric range or coded value. For a numeric range domain, specify the minimum and maximum values. For a coded-value domain, list the code and (optionally) its description. The data type of the code value must match that of the domain class.
The last thing you tell ArcGIS is the split and merge policies to employ. A split policy will control what value is entered in the new child objects when the parent is split. Specify one of three choices: default value, duplicate, or geometry ratio. The default value policy means that the default value for the field specified in the data dictionary will be placed in both child objects. The general expectation of this policy is that the user will need to enter an appropriate value. The duplicate policy will place the parent’s value in both child objects. The geometry ratio policy will proportionately divide the parent value among the child objects. This option only applies to feature classes. It is useful for such attributes as area, where each child feature will get the quantity determined by its size as a percentage of the parent.
Figure 3.9 Domain control in the geodatabase ArcGIS saves you all the programming required for domain control using lookup tables by supplying the required software in the geodatabase itself. Coded value and numeric range domains can be defined for a geodatabase workspace. Since these domain controls are established at such a high level in the geodatabase, they will be applied globally across the dataset of tables and feature classes by reference to the domain’s name.
The merge policy you specify will control what happens for the field controlled by the domain class when you put two features together. Merge policies are similar: default value, sum values, and geometry weighted. The default value policy works the same as for a split; the default value defined for the field is placed in the resulting combined feature. The sum values policy will add the value in this field for the two contributing features and place the total in the field for the resulting feature. The geometry weighted policy will take the weighted average of the values supplied by the two contributing features based on the ratio of the two features’ geometry. For lines, the weight is determined by relative length. For polygons, the weight is determined by relative area.
Valid value tables
Sometimes using a domain class is not enough to reflect the rich mix of attribute controls you need to employ. In such cases, you can use a structure called the valid value table. Such a table includes rows that reflect the combinations of values that are legitimate.
Figure 3.10 Valid value tables In this illustration, we need to control RouteType, which is based on a combination of urban type, functional class, and jurisdiction type. Each of these three variables is separately controlled by a coded value domain, but only certain combinations are valid. For instance, “rural minor collector” is valid but “urban minor collector” is not. The RouteType_VVT table stores the legitimate combinations and can serve to control Route table entries for the RouteType column using custom tools.
The