How can I design an ODK2 form for longitudinal tree study?

Greetings to ODK2 users. I am a novice starting to design XLSforms for ODK2. I’ll provide a little background on my project first, which hopefully will give some context to my questions (at the end). Apologies in advance for the length of this, and many thanks in advance for any advice you can provide.

What is the problem? Please be detailed.
XLSform design

What ODK tool and version are you using? And on what device and operating system version?
ODK2 on Samsung TabActive

What steps can we take to reproduce the problem?
Background: Our project is a longitudinal (long-term) study of trees in research plots. We currently use a proprietary (not open source) mobile application for data collection, and it works well, but is out of date and has become prohibitively expensive to update. Thus the switch to ODK2! I’m hoping to develop a workflow structure in ODK2 that is similar to what we developed in the proprietary application.

Basic workflow

  1. Main menu: select the research plot from a lookup list of about 30 sites (choices). Each site has anywhere from 100 to 4000 trees, so across 30 sites there are many thousands of trees in the database. Once the specific plot is selected, the user will have multiple options (sub-menus?):
    a. Measure a tagged tree
    b. Edit measurement data
    c. Generate a list of trees not measured (missing trees)
    d. Add a new tree (“ingrowth”)
    e. Edit ingrowth data
    f. Edit tree mortality data
    g. Enter notes about study site
    h. Edit notes about study site

  2. Within the sub-menu “Measure a tagged tree” the form should prompt the user to enter a tree tag number (TreeID). Look up that tag number using the pulldata function to populate several fields on the form so the user can see the previous measurement data (e.g., tree diameter, species, stem condition).

  3. Record the new measurement data and use the calculate function to compare the current measurement (tree diameter) with the previous measurement. Give a warning message if the tree has shrunk.

  4. Go back to step #2 to select another tree to measure. Repeat until all tagged trees are measured.

  5. Some trees die since the previous measurement, and we want to record different types of data on these dead trees. Is this done via a cascading select? That is, if a tagged tree is now dead, should the user be directed to a new child form, or would the necessary fields be revealed within the tree measurement form?

Questions:

  • Should all of the previously measured trees be part of a single repeat group?
  • Is there a way to determine and display which tagged trees were missed (i.e., not yet measured)? I just read a post from Adrian who uses the COUNTIF function to track the number of entries. Is that correct way to go about tracking which trees have been measured, and conversely, which have not?
  • In the course of measuring previously tagged trees, we also encounter new trees that haven’t been tagged and must add them to the database. I envision this being a separate form, but it would have to be accessible at any time during the measurement of the previously tagged trees. Any suggestions on how we might build in this capability?

Hi @RJP! Excited to hear that you are going to be learning the ODK tools and I see that you have lots of questions!

Before we can provide very helpful answers though (and we may need to split up these questions into a few!), hoping you can answer for us a fundamental question: Are you using ODK1 or ODK2? I am particularly confused because you are referring to XLSforms, which are part of ODK1:
https://docs.opendatakit.org/xlsform/
but ALSO refer to specifically ODK2. In ODK2 there is XLSXconverter, which is like XLSforms but for ODK2:
https://docs.opendatakit.org/odk2/xlsx-converter-intro/

If you are not sure the difference/which you want see:
https://docs.opendatakit.org/odk2/select-tool-suite/
It does sound like from what you want to do with sites and then trees within sites you may want the sub-form structure of ODK2.

The ODK1 and ODK2 tools are different (and have different documentation), so the answers to all your other questions will depend on which you are using.

Best,
Caroline

Hi Caroline, and thanks for the quick reply! I definitely want to use ODK2, so I appreciate the heads up on needing to use XLSconverter.

Rob,

App Designer is used for developing ODK2 Survey Apps.

https://docs.opendatakit.org/odk2/app-designer-intro/

@RJP,

Okay, great, so if you are using the ODK2 tools, please note that all the syntax will be different than ODK1 (e.g. pulldata is not a thing). So please spend some time reading the ODK2 docs specifically!

I am going to now attempt to tackle some of your questions!

In terms of your basic workflow,

  1. Yes, 30 sites with a site form and then within a site a tree subform should make it possible, generally, to do what you want. For the multiple options, those wouldn’t be sub-menus, I think it would be different screens (for example, edit an existing tree, add a tree) that write to the same table but have (some) different questions for a-f, and then just an additional screen for g-h (enter and edit seem like the same thing).

  2. So for the suform measure a tree, you can have loaded existing tree ids or when adding new trees generate the id to be unique. However, I am wondering if you maybe even want to have sites with tree subforms and then a measurement subforms (three-level), then you can have multiple measurement observations per tree. And you can pull in the last time information with async_assign.

  3. You can definitely calculate: with calculate and assign: https://docs.opendatakit.org/odk2/xlsx-converter-reference/?highlight=calculation#id3 and then use an if statement in order to then display a note if negative.

  4. With sub-forms for trees and measurements it will be easy to go “up” and “down” levels to do this. You can also make sure all trees are measured with a check on the site level on the next screen after measurement, something like checking that the last updated date is today.

  5. I would use sub-forms to manage this as well, maybe even writing to the same tree sub-form, but having a section on if a tree is dead. The necessary fields could easily be contingent on an if in the same form, e.g. a question of “is this tree dead?” and if so, the dead questions.

For questions:

With subforms each tree that has been previously measured will have a subform, and you can add new trees.

There are a couple ways to do this: you can order the trees by (orderby) last updated date in the subform, so you can see the trees not yet done at the start or end. You can also use the check I mentioned earlier to make sure all get updated.

You can either add new trees in the same spot as edit trees, or have two different spots, add new trees and edit trees, and not allow adding in edit. display.hide_add_instance can suppress the add, display.hide_delete_button can suppress the delete (I don’t think these are documented yet).

Hope that starts you off! If you have further questions or troubles it may help to ask them as smaller separate pieces :slight_smile:

Best,
Caroline

Caroline, George - thank you for steering me in the right direction. Very helpful! In the future I’ll submit less-convoluted questions. :slight_smile: