ArcPad and in-field data validation

A GIS is useless without data and equally as useless with bad data, so when collecting/editing data in the field you want to make sure that there is as much quality control as possible to provide the best platform for analysis/reporting/budgeting or whatever the tasks may be.

Many people associate ArcPad as a high end data collection application because of the vast GPS configurations and ability to control GPS quality collection. However the attributes (or information) associated with that position are just as critical. ArcPad actually has a very fine grain approach to data validation that can build upon the standard Geodatabase rules.

As a GIS team leader I want to have a high level of confidence that the data collected and ultimately published to a wider audience is truthful at the time of collection because business decisions and operating costs will depend on it. As a small team we don’t have the time or resources to run QA after the fact, so it has to be correct when the user presses OK!

This could mean that every potential data field needs its validity to be checked and this is where ArcPad steps in. Using a geodatabase you can build a schema to help with particular constraints such as subtypes, domains (both coded and ranges) and unique values; however within the tools of ArcPad you could build the intelligence of:

• Cross checking different attributes.
• Verify no “null” entries exist.
• Check calculated fields have reasonable results (no negative values).
• Make you recollect the geometry of a point if the PDOP was too high (>3.4) .
• The order you collect data on a form.
• Check the geometry of a point is inside a polygon before you enter data on a form (DIY Topology).
• Verify that there are no spaces or numeric characters in a text box.
• Disable custom tools because of the data you are using.

Via scripting you can enhance the in-field quality assurance by setting validation rules against pages and data controls.  The ThisEvent.Result property that is vital to all validation techniques. Also you need to set your routine to execute on an onValidate event of a control or page. But first, what is the ThisEvent object I hear you say?  The ThisEvent object represents an ArcPad event that is occurring at a particular time and supplies a series of standard properties such as object, name and result– analogy time.

A person is an object. It has properties such as NAME, AGE and GENDER. It also has events such as TALK, RUN and SIT.  However, using the ThisEvent object exposes that the RUN event has properties: DIRECTION and SPEED. So every time the person runs we can tell how fast they are going.

Generally any scenario will need a test which is represented as a set of questions such as:

If the textboxName has no value entered tell the user to fill in the Name text box -

If textBoxName = "" then                ThisEvent.Result = False                ThisEvent.MessageText  = “Please enter a Name”End If

This routine needs to be set to the control textBoxNames’ event - onValidate. This means that when the user presses OK on the form, it will check the value to see if it has a blank entry and if it does, an alert will pop up and keep the form open to amend. Oh and one of the best things about this is that it works the same on Shapefiles as it does with AXF layers.

It is important to note that every page control has an OnValidate event so you could have a myriad of tests run. You can even run a test at the page level so you run one routine and loop through every control to make sure it is true and correct.

As you develop your own quality tests you will probably notice there are many similar scenarios across projects and in fact you can use the ThisEvent object to help generalize/repurpose scripts but you’ll have to wait for another blog to learn about that.