A sample data model for field data collection

Your data model may be based on paper forms, project requirements, and so on, depending on your current workflow. This example is based on a Red Cross paper form.

In this example, the form (shown below) is a paper form used by field workers after a natural disaster to perform damage assessment of property. You will create a data model based on this paper form.

American Red Cross Onsite Detailed Damage Assessment form

Typically, a point feature class is the best type of feature class to use if your field inspection is on features that don't exist as physical entities (in this case the Damage Assessment form), so you would first create a point feature class in a file-based or an SDE geodatabase.

Note:

If you plan to use ArcGIS for Server, which allows you to synchronize your data with the server directly from the field, you must store your feature classes in an SDE database with data registered to the server. You must also create a GlobalID field for the feature class to make it editable by a mobile application. You can do this in ArcGIS for Desktop.

Based on the values required on the form, the following fields and field types are used:

• Assessor Identification (text)
• Assessor Name (text)
• State (text)
• County (text)
• City/Community (text)
• Assessment Date (date)
• Street Name (text)
• House Number (short integer)
• Unit/Apartment Number (short integer)
• Occupant Name (text)
• Damage Classification (long integer)
• Number of Floors (short integer)
• Is There a Basement (short integer)
• Is the Electricity On (short integer)
• Water Level in Living Area (Inches) (short integer)
• Water Level in Basement (short integer)
• Occupancy Type (short integer)
• Description (text)

Subtypes and domains can be used to improve data quality and data entry speed. Since you can categorize the inspections based on the Damage Classification field, you can use that field to define subtypes. The subtype values—Destroyed, Major, Minor, Affected, and Inaccessible—will be presented in the field applications as if they're different types of inspection features. Based on each subtype value, you can further define the default values for the fields. For example, for the properties of "Minor" type, you can set the Water Level in Water Level in Living Area value as 0, while you can set other values for the same field for other subtypes.

You can also use domains to ensure data integrity. There are two types of domains: coded domains, which allow only specific values you define for the data model; and range domains, which allow field crews to enter a value within a specific range. You can set up a Yes, No, or Unknown coded domain for the Is There a Basement and Is the Electricity On fields, and you can set up a range of 0–5 for Number of Floors if you know in advance that all buildings in the area to be inspected have five stories or less.

When a field worker first collects a feature, the default value entered for an attribute is set by the subtype chosen. The field worker can change the default value by choosing a new value from the pick list of possible coded domain values, or he can enter a value that falls within the range. Using subtypes and domains improves speed and reduces data entry errors in the field and the amount of time spent on post-field QA/QC and editing.

This project also requires a few photos to be taken at each inspection location. To enable this capability, create an attachment relationship on the inspection point feature class within the geodatabase.