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 property damage assessment. 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); therefore, create a point feature class in a file-based or an SDE geodatabase.

Note:

For mobile services, the type of data repository used can potentially affect how you can use the data in the field. If your data comes from a file geodatabase, after you host it on ArcGIS Server, the data becomes read-only even though you have added a GlobalID to it. If your data is from an ArcSDE database and you do not register the data to the server before publishing, your data becomes read-only as well. However, these restrictions do not apply to feature services, that is, data is still editable even it has no GlobalID or stored in a file geodatabase.

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 iInches) (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 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 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 chosen subtype. The field worker can change the default value by choosing a new value from the pick list of possible coded domain values, or the field worker 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.