Skip navigation
All Places > Survey123 for ArcGIS > Blog > 2019 > May
2019

We do not seem to observe the stars as much as we used to, but it is fascinating to look up and think how much our life as a species has depended on a good understanding of the sky. We have dedicated this update to the comet Halley. Tomorrow, over 2,250 years ago, the first documented sighting of comet Halley was made by Chinese astronomers. It was sighted May 24, 240 B.C.  There are potentially earlier accounts from 467 B.C when Chinese and Greek astronomers logged the sighting of a comet, which could also have been comet Halley. We will go with the more certain date of May 24, 240 B.C and celebrate it along with this update of Survey123.

 

The passing of comet Halley has been very well documented since these initial accounts. Initially there was no evidence that all these sightings were of the same comet. The comet's periodicity was first determined in 1705 by English astronomer Edmond Halley, after whom it is now named. It visits us regularly every 75 years. It came last in 1983 and will return in July 2061.

 

This update is focused exclusively on the Survey123 website. Clear your browser cache!

 

Here is what is new:

 

Enhanced Integromat support

 

Integromat is an amazing online automation platform. With it you can easily automate tasks, visually connecting all sorts of apps together. We strongly believe that facilitating your work with platforms like Integromat can tremendously help you embed Survey123 within larger enterprise workflows, making sure your Survey123 data flows nicely into the way people work within your organization.

 

Many of you have been experimenting with Integromat and Survey123 since we first added support for webhooks in 2018. The uptake of webhooks with Survey123 has been pretty spectacular!  Some of the most common task automations we have seen include:

 

  • Automatically send an email or SMS when an inspection or incident report is submitted from Survey123.
  • Instantly add a new row into an Office 365 Excel spreadhseet when data is submitted from Survey123
  • Create a Workforce for ArcGIS assignment and a Google Calendar event when data is submitted from Survey123
  • Automatically reverse geocode the location a submitted survey and store the address in a GIS attribute of the submitted survey

 

We have worked closely with our friends at Integromat to add a new Survey123 Integromat module. This means that you can now bring your Survey123 data into Integromat much more easily and do much more with it than before. Jim Moore put together this brief but informative video to give you a quick overview of this new Survey123 Integromat module. Here it is:

 

 

In our Getting Started with Survey123 and Integromat blog post you will find a brief guide with resources to learn  the basics of working with Survey123 and Integromat.

 

For those of you already familiar with Survey123 and Integromat, you will find that this new module, lets you do some more advanced things you have been asking for.  For example:

 

  • Easily work with photo, signature and markup attachments. Include them as attachments in emails, upload them to Box, Microsoft OneDrive or Google Drive.
  • Automate report generation through the Survey123 Feature Report service. For example, for every survey submitted, automatically trigger a new  report using a custom template and then email or update that final report.
  • Trigger Integromat scenarios when Survey123 is used to update existing records*. Add a router in your Integromat scenario to do certain things if a record is submitted, and other things if the record has been updated.
  • Setup an Integromat scenario on top of ArcGIS Enterprise.

 

All of the above are covered in the Survey123 Tricks of the Trade: Integromat blog post.

 

* Please note that the field app will not trigger web hooks on edit events until our upcoming 3.5 update.

 

Delete and update submitted records (Survey123 website)

 

You can now use the Data tab in the Survey123 website to delete and update submitted records. This comes very handy if you need to do some quick cleanup of test data during your survey design process, or to make adjustments to already submitted data to your survey.

 

This is how it works: First login to the Survey123 web site, select a record in the table shown in the Data tab and then use the Edit button in the panel on the right to enable editing on the individual response form. Make your changes and submit.  The following animation shows the key steps:

 

 

You can use the Edit and Delete options for both surveys created in Survey123 Designer as well as Survey123 Connect. However, if your surveys were created in Survey123 Connect, be aware that the Edit button will be disabled when working against a survey with a repeat.

 

Update submitted records from a Survey123 web form

 

You may be already aware that you can update existing records in your feature layers using the Survey123 field app. Starting with this update you can update existing records with Survey123 from your web browser too! This is possible by opening your web form with URL parameters.  TheSurvey123 Tricks of the Trade: Web form URL parameters blog post introduces the concept of web form URL parameters. Now you can use URL parameters to edit existing records.

 

The syntax is fairly straight-forward:

 

  • Set the mode to edit: mode=edit
  • Pass the objectId of the record you want to update: objectId=13 for example.

 

For example:

https://survey123.arcgis.com/share/815b69a16e2f474e93da7e2eb0255e5d?mode=edit&objectId=13

 

Editing is not supported in web forms published prior to this update. If you want to edit records with surveys you published in the past you have two options:

 

    1) Dynamically upgrade your survey at run-time by adding the version=latest URL parameter

    2) Republish your survey to force a version upgrade at publishing time.

 

The key to all of this is to somehow dynamically construct the URL with the objectId of the record you want to update. In the Survey123 Tricks of the Trade: Editing records in a web form blog post this is all discussed in more detail.

 

Other enhancements and fixes

in the Survey123 website and Survey123 web app

 

 

  • Save Survey As... now works also against surveys that you do not own. 

 

This is very handy if you want to clone survey designs within your ArcGIS organization. Create a survey first using Survey123 Designer, then share the survey with someone else by granting access through the Viewer group sharing settings in the Collaborate page. Next, have that second person login into the Survey123 website and show 'Surveys I can view results for' in the survey gallery. The Save As option will be available on the survey tile menu to clone the survey. 

 

 

The Save As... option in the Survey123 website is only available for surveys authored in Survey123 Designer. If you want to clone a survey authored in Survey123 Connect, use the Save As... option in Survey123 Connect

 

  • You can now quickly switch between ArcGIS accounts in the Survey123 website without having to logout.

 

  • An option to optionally propagate selection filters between the Data and Analyze pages has been added.

 

Filter Options in Data Page

 

  • BUG-000113962 Unable to type certain Japanese character in the hints and explanations of headers in the Survey123 for ArcGIS Web Designer.
  • BUG-000120077 Unable to export data from Survey123 website when logged in as a member having 'User' Role and ‘Creator’ User Type.
  • BUG-000120887 When opening an existing Survey123 for ArcGIS form from ArcGIS Online using the 'Manage in Survey123 Website' option, the error message, "Your account () is not licensed for Survey123. Please ask your organization administrator to assign you a user type that includes Field/Essential Apps..." is returned.
  • BUG-000120055 Reports may fail to generate from a survey response that contains a repeat with many high resolution images.
  • BUG-000120222 Unable to generate a Survey123 for ArcGIS Report if there is an IFstatement containing a choice with an apostrophe.
  • BUG-000120851 Survey123 for ArcGIS web app displays the World Geocoding Service (WGS) on geopoint questions, despite removing WGS from the organization's Utility services.
  • ENH-000115658 Allow for the functionality to configure right to left labels and choices in Survey123 forms.
  • BUG-000113592 Questions label disappear from the survey when default language is changed from English to French or Spanish in a browser.
  • BUG-000112106 Survey123 for ArcGIS web app does not respect the language settings of date type questions in the browser.
  • BUG-000114761 Field Matching and string-length(.) constraints cause a green "It's an invalid answer." subtext to persist in Survey123 for ArcGIS web site under the questions that are constrained that does not disappear after fulfilling the constraints or leaving the fields blank.
  • BUG-000115247 Survey123 for ArcGIS web application does not respect the default language settings in the browser.
  • BUG-000117184 Submitting an Image through the Image Upload Question in Survey123 through the Web Designer in a Desktop Browser fails if the Survey was created with the Web Designer
  • BUG-000116320 The Survey123 for ArcGIS web app displays Image and Geopoint questions in English even if the web browser is set to another language in Internet Explorer.
  • BUG-000120426 Conditional calculations do not populate as expected for select_one questions in the Survey123 for ArcGIS web app.
  • BUG-000118413 Reverse geocoding results are different between Survey123 Connect and Survey123 web application.
  • BUG-000120387 Survey123 web app fails to record time when a time between 12PM and 1PM is selected
  • BUG-000121290 Loading a survey in a web browser with a Toolbar Background Color assigned causes the default color scheme to show momentarily before switching to the chosen color.
  • BUG-000120589 When editing surveys published in Connect the prompt to save changes on exit is not necessary if changes were published, does not work if changes were not published.

 

 

About the next update

 

 

As mentioned above, this update is exclusive to the Survey123 website. As usual we wanted to release both updates for the website and Survey123 field app together, but we decided to pull back on the Survey123 field app at this time. We are doing our best to bring some important fixes you have reported to the Survey123 field app soon. The current schedule is set for an update in 5 weeks (late June 2019). Our Survey123 for ArcGIS Early Adopter Program is making early beta builds of our next update available for testing.  The Survey123 website will also be updated in late June.

Today we will explore how you can edit existing records using the Survey123 web app, also known as a web form. The idea is quite simple, we will populate the contents of a Survey123 web form using an existing record from a feature layer and let users update (edit) that information. When working this way, the submit button in the survey will update an existing record, as opposed to creating a new record for a new survey response.

 

This technique for editing data in a web form be quite handy. You can use it for example to let people review and modify existing submitted data, or to simply let them finish an uncompleted form. You can also incorporate web forms into QA/QC and data validation workflows.

 

Before we start, be aware that the editing of records in web forms is only available in the Survey123 web app after May 23, 2019 (version 3.4 and newer). I will describe later in this blog how you can make your surveys run in this latest version, even if you published it in the past in an earlier version.

 

The Basics

 

Editing of existing data in a web form is possible through the use of web form URL parameters. If you are not familiar with web form URL parameters in general, I strongly suggest you read the Survey123 Tricks of the Trade: Web form URL parameters first.

 

Here is an example:

https://survey123.arcgis.com/share/1cb28b212b5542acbbdbaa35feba0765?mode=edit&objectId=9

Note the two URL parameters:

 

  • objectId=9, this parameter loads the record in your feature layer with objectId 9 into your form. Of course, you can replace 9 with the specific objectId of the feature you want to load.
  • mode=edit, puts the web form in edit mode. This essentially ensures that when the user hits the submit button, the current record is updated. If the mode is not set to edit, the form will create a new record when submitted, even if the form was initialized with data from a particular record.

 

URL parameters are case sensitive. For example: objectId is not the same as ObjectID or objectID. If you see that your form is not loading the record you want, double check the spelling of the parameter, and also ensure the objectId you are trying to load exists.

 

As described above, the editing mode in web forms was incorporated in version 3.4. If you want to edit records using a survey that was published in the past, you can bring things up to speed in two different ways:

 

  • Upgrade your survey by simply re-publishing it. If you originally published your survey using Survey123 Web Designer, then use Designer to publish it again. You do not need to make any changes other than simply clicking the Publish button. The same goes with Survey123 Connect for ArcGIS: If you originally published your survey with Connect, go back to Connect and hit publish.
  • Upgrade your survey at run-time: You can alternatively add the version=latest URL parameter to force the survey to be loaded using the latest available Survey123 web app. Something like this:

 

https://survey123.arcgis.com/share/1cb28b212b5542acbbdbaa35feba0765?mode=edit&objectId=9&version=latest

 

My recommendation is that whenever possible you upgrade your surveys by re-publishing them. It will improve the initial loading time of the survey in the web browser, and it will guarantee that the behavior of your web form remains unchanged even if the Survey123 release changes.

 

From a practical perspective, the technique described above is useless unless you somehow present a ready-to-use link (URL) to the end user; A link that already includes the appropriate objectId to edit. Do not expect end users to modify that objectId manually in the web browser URL address!  I will next describe three scenarios to illustrate how you could apply this technique.


Launching an edit web form from a feature popup

 

Our first scenario allows users to navigate a map, and launch an edit web form from the popup of an existing record. The key is to customize the feature layer popup so it dynamically generates the correct URL to launch the survey. Once the popup is configured, you can use the web map within the ArcGIS Map Viewer, custom Web AppBuilder apps, Explorer for ArcGIS and any app that supports web maps.

 

Here is a brief step by step guide to configure your popups:

 

  1. Using the ArcGIS map viewer, add your survey feature layer (or hosted feature layer view) into a web map.
  2. Open the configure popup dialog for your survey feature layer.
  3. In the popup contents section, select a custom attribute display.
  4. Add the URL of your web form into the attribute display. Then add the mode and objectId parameters.
  5. Dynamically populate the objectId parameter using the OBJECTID field from your feature layer.
  6. Use the full web form URL with its parameters to create a link.
  7. Save the popup and test it out.

 

And here are the same steps in a short animation.

 

Editing Web Forms and Popups

 

Embedding an edit web form within Operations Dashboard for ArcGIS

 

The idea with this one is to add an embedded content element within the dashboard, and configure it to display your web form.  The URL of the web form will include the mode parameter set to edit and the objectId will be dynamically populated.  Using a filter action triggered by other element within the dashboard, such as a list, the embedded content element will refresh your web form with the relevant record to be edited.

 

At a high level, the steps are as follows:

 

  1. Set a refresh rate on a web map displaying your survey feature layer.
  2. Add your web map to a new dashboard and configure a list element to display survey records.
  3. Add an embedded content element. In the Data options, set the Type to Features and add the URL of your web form with the mode=edit  and objectId parameters. Make sure the objectId parameter is set to pull a value from the ObjectID column in the fields collection.
  4. Next configure a filter action on the list element and target your embedded content element.
  5. Click on a record in the list, and your web form in the embedded content element will display your record in edit mode.

 

The animation will guide you through the whole process. Click on the animation to make it larger.

 

Editing Web Forms in Dashboard

 

Including an edit web form link in an e-mail.

 

In this scenario, we will use a web hook to automatically send an e-mail to the user submitting the survey. This email will contain a link for the user to complete or make modifications at any time.  To do this you must be familiar with web hooks in general or with either Microsoft Flow or Integromat.   Like in the examples above, the trick is to be able to dynamically populate the objectId of the record you want to edit. Luckily enough, the payload of a Survey123 web hook includes information about the user submitting the data (if logged-in) as well as responses to questions in the survey. So as long as the user is logged-in or a specific question in the survey captures the contact e-mail, you can make this work.

 

Here are the high level steps:

 

  1. Create a new survey. If you plan to share your survey publicly, include an e-mail question and make it required. If  you plan to keep your survey secured, you will be able to get the e-mail from the logged in user's profile.
  2. Use Microsoft Flow or Integromat to automate e-mail notifications when your survey is submitted.  The objectId of the record submitted is included in the payload of the web hook. Simply add the objectId to the URL of your edit web form when you add the link in the body of your e-mail.

 

Here is some visual aid in case you are using Integromat.

 

Integromat

 

If you are using Integromat or Zapier, the pattern is pretty much the same: use the webhook payload to retrieve the objectId of the submitted record and use if for your edit web form url.

In this blog post, I describe some common techniques that will help you better understand and hopefully improve the quality of location data you get from field users.  Location data quality depends on multiple factors, including field conditions, field user skills and the hardware used. Having said this, a good smart form design can do a lot to help get the best possible quality location data.

 

This post focuses particularly on field data collection workflows where you will rely on integrated or external GNSS receivers to capture location data. It assumes familiarity with XLSForms, Survey123 Connect and the Survey123 field app.

 

Persisting Location Accuracy (Part 1)

 

If location quality matters to you, you should consider systematically storing the location accuracy of every record captured.  This is just as true for formal high accuracy field data collection workflows by professionals, as it is for casual field data collection by volunteers.  Horizontal accuracy is about the simplest and most important quality indicator of your location data.  Having field users understand the horizontal accuracy while they collect data is not enough; you need to persist it for every record captured, so you can analyze it later.

 

In XLSForm, you can store the horizontal accuracy as reported by your field device as follows:

 

typenamelabelcalculationbind::esri:fieldType
geopointlocationGPS Location
calculateaccuracyHApulldata("@geopoint",${location},"horizontalAccuracy")esriFieldTypeDouble

 

The key is the calculation in the second question of the survey.  It automatically gets the horizontal accuracy from the geopoint question and stores it in a field named accuracy. Since you do not want end users to overwrite this value, the sample above keeps the output of the calculation in a question of type calculate. Calculate questions are not presented to the end-user in the form, but their values can be be stored in ArcGIS.  In this particular case, since the horizontal accuracy is expressed in meters, the bind::esri:fieldType column has been set to esriFieldTypeDouble.  If the esri:fieldType value is not set explicitly, Survey123 will automatically store the calculated value as text.

Horizontal accuracy values are always expressed in meters.

          

I like to add a calculate like the above to every survey I prepare for field data collection. Looking at a dataset from field users without location accuracy information is not very comforting.  Without location accuracy information in a GIS dataset, what level of confidence can you have on those points in the map?  Capturing the horizontal accuracy like described here adds absolutely no overhead, and it always pays off.

 

In the next screenshot, locations captured along a trail have been buffered to visually represent the reported horizontal accuracy.  This simple visualization can provide you with great information about the quality of locations in your dataset. Before performing GIS analysis, you can set criteria to filter out records that do not meet a location accuracy threshold of your choice.

 

 

You can also use the location accuracy information to better understand in what conditions poor location data is created. You can analyze spatial patterns, identify particular users or devices that do not meet minimum standards.

 

Persisting Location Accuracy (Part 2)

 

The horizontal accuracy that Survey123 returns from a geopoint value is provided by the location sensor you are using.  On top of the actual value (say 6.2 meters for example), it is important to understand the level of confidence level for that value. That is, with what level of confidence will the location be within a radius of the horizontal accuracy reported (say within a radius of 6.2 meters of the point for example)? 

 

The Google Developer documentation, defines horizontal accuracy as the radius of 68% confidence. This is like saying that for Android devices, there is a 68% chance that the true location is within a radius equal to the reported horizontal accuracy. Apple has not documented their definition of horizontal accuracy.

 

When using external high accuracy GNSS receivers with Survey123, the confidence interval can be more accurately be defined if the receiver is able to report what is known as root mean square (RMS) accuracy. For RMS accuracy, the default CL (Confidence Level) is 68%. Some organizations require reporting accuracy with a 95% CL. If this is the case, the United States Federal Geographic Data Committee (FGDC), through its National Standard for Spatial Data Accuracy, establishes that the following factors should be applied:

 

  • 1.7308 for horizontal accuracy.
  • 1.9600 for vertical accuracy.

 

The conversion between RMS 68% CL and 95% CL applying the factors above should only be calculated, again, if the GNSS receiver is reporting horizontal accuracy using RMS.  In the Direct GNSS external receiver support in Survey123 3.3 blog post you can find an example of how you can use RMS horizontal accuracy values into a 95% confidence level.

 

For both built-in and external GNSS receivers, you can complement the reported horizontal accuracy with other commonly available location metadata such as the speed and also the position source type (Integrated GPS, external GPS, user-defined, etc). For a quick reference of other location metadata fields available, have a look at the Pulling data from geopoint questions blog post.

 

If you use external location sensors, such as high accuracy GNSS receivers, then you will be able to get a lot more location metadata with Survey123 such as the fix type (GPS, differential GPS, RTK fixed, RTK float, SBAS...), differential age, number of satellites used, etc. The complete reference guide of all location metadata you can extract is in our Geopoints—Survey123 for ArcGIS | ArcGIS help topic.

 

Persisting the location accuracy as a GIS attribute is generally a good idea, but it does not help field users understand how to to get a better location with Survey123.  Next, I will discuss a handful of techniques that will help end users actively contribute to higher location quality data.

 

 

Location Accuracy Threshold

 

The location accuracy threshold is an XLSLForm value expressed in meters.  When the accuracy threshold is not met, the map panel in the survey will be automatically highlighted in red and the location icon will spin.  This will give the field user a visual clue indicating that (1) a better location is desired and (2) that the Survey123 app is actively trying to get new locations to meet the threshold. 

 

Setting the location accuracy threshold in your smart form is a very simple way to visually alert end users when the location is not considered accurate enough.  A red map panel is an indication to end users that it is best to stay put and wait until the device is able to get a better location.  If for whatever reason the device cannot get the desired accuracy, the end user can manually tap on the spinning location icon to fix the geopoint.

 

The accuracy threshold is set, in meters, in the body::accuracyThreshold XLSForm column as shown below.  This column accepts integers and decimals, but not XLSForm expressions. That is, the accuracy threshold is a fixed value.

 

typenamelabelbody::accuracyThreshold
geopointlocationGPS Location5

 

It is important to train end users so they understand exactly what is happening when the map panel is red and the location icon spins.  While the location icon is spinning, Survey123 is actively retrieving new locations from the device. If the end user moves, the location will change!  This is very different to the typical behavior of the Survey123 field app, which by default will immediately fix the location after the form is open.

 

A conservative value on your accuracy threshold, can help reduce situations where field users report location data that is clearly below the capabilities of their device.  For example, when a device has been off for a while, the GPS may need some extra time to warm up before getting the best results.  If you know that in normal conditions, you can get your devices to report horizontal accuracy in a range between 5 and 10 meters, then you can conservatively set the accuracy threshold to 20 meters. This will cause the map panel to turn red only in exceptional cases, letting the user know that it is best to stay put and wait a bit in order to let the device get a better fix.  In normal conditions, the accuracy threshold will be met after a few seconds, the map panel will turn green and the location will be fixed. Figuring out such conservative value for the accuracy threshold requires some trial and error. It will vary depending on the range of devices used and average field conditions. 

 

You can also go with a more aggressive approach where the accuracy threshold is set closer to the limits of what field conditions and your hardware can typically provide. In this case, you will be using the accuracy threshold to constantly remind end users of the importance of getting the best location possible. With an aggressive accuracy threshold value, some users may not be able to get a horizontal accuracy value below the threshold.

 

Always be aware that the location accuracy threshold value by itself will not prevent users from submitting data below the threshold. If you do not want data to be submitted unless a specific accuracy threshold is met, then you will need to use constraints. We will describe this later in this blog.

 

Location Quality Expressions

 

Using XLSForm syntax you can build sophisticated validation rules for location data.  These XLSForm expressions can take into account the horizontal accuracy, and many other properties of your location data. You can also use other form data in your expressions. Here are some examples of location quality expressions you can build:

 

XLSForm expressionDescription
${speed}<0.2Speed is less than 0.2 meters per second.
${positionSourceType}=3Location has been captured with an external location sensor
${fixType}=4 and ${positionAccuracy}<1Location is RTK fixed and mean radial spherical error is less than 1 meter.
${differentialAge}<3Location's differential age is less than 2 seconds

 

You can use XLSForm expressions like the above in different contexts. For example, you can use them to show visual warnings to the field user using notes. See the Understanding Notes in Survey123 for details on using notes for this purpose.

 

You can also use apply these expressions to the constraint and bind::esri:warning columns of a geopoint question. If you apply them to the constraint column, the end user will not be able to submit the survey unless the expression evaluates to true and the map panel will be highlighted in red.   This is what is known as a hard constraint.  If you apply them to the bind::esri:warning column, the map panel will be highlighted in yellow when the expression is not met.  This will simply give end users a visual clue indicating that something is wrong with the location data.  That is a soft constraint.

 

 

The contraint_message and bind::esri:warning_message columns are used to provide users with a specific error or warning message. Here is a complete example illustrating how to use the bind::esri:warning column to display a warning if the location has been captured while moving at a speed larger than 0.2 meters per second.

 

typenamelabelcalculationbind::esri:warningbind::esri:warning_message
geopointlocationLocation${speed}<0.2Please do not move while fixing the location
calculatespeedSpeedpulldata("@geopoint",${location},"speed")

 

Typically, a location quality expression is going to validate some properties of your location data. For example, its speed, accuracy, etc. These properties are obtained through the pulldata() function. It is not good practice to combine the pulldata() function with any other XLSForm operator or function.  In the example above, I created a calculate question to get the user speed from the geopoint object first, and then I referenced that value in the bind::esri:warning column. In this way, the pulldata() function is left alone in its own question avoiding any potential issues.

 

Expressions in bind::esri:warning define soft constraints. Even if the condition is not met, users will be allowed to submit the survey.

 

In the next example, I use the constraint column to apply a hard constraint. The user will not be able to submit the survey unless the accuracy is less than 1 meter and the fix type is RTK.

 

typenamelabelcalculationconstraintconstraint_message
geopointlocationLocation${fixtype}=4 and ${pa}<1RTK fix and sub-meter accuracy are required.
calculatefixtypeFixpulldata("@geopoint",${location},"fixType")
calculatepaPApulldata("@geopoint",${location},"positionAccuracy")

 

In this example, I use a constraint to force users to use a GPS to set the location of the geopoint. If the user manually changes the location in the map, Survey123 will not let the submission go through.

 

typenamelabelcalculationconstraintconstraint_message
geopointlocationLocation${source}!=1
You can't manually set the location. Use the GPS.
calculatesourceSourcepulldata("@geopoint",${location},"positionSourceType")

 

Expressions in the constraint and warning columns are evaluated every time the value of the question changes. If you add expressions to these columns in a geopoint question, they will get evaluated as soon as the location is updated. 

 

Summary

 

A good smart form design can help field users capture better location data. Using XLSForm expressions we can actively check the quality of location data in the survey and provide users with clues to help correct issues.  XLSForm expressions can also be used to prevent users from submitting location data that does not comply with our own business rules.  Finally, XLSForm expressions allow us to store many location quality indicators as GIS attributes.  This information is very valuable to support QA/QC workflows and before analysis and visualizations of the data are performed.