Changing Question Types for Ongoing Project (Decimal to Calculate)

1. What is the issue? Please be detailed.
I have an ongoing project hosted on ONA where I'm measuring the value of tree diameters. With small trees, we've been using a caliper. Now with bigger trees we need to measure the circumference with measuring tape and calculate the diameter.

My original diameter question named "plant_trunk_diameter" was a decimal type question. In order to maintain consistency, I'd like to keep that question as the one that stores the trees diameter, even if it is calculated from the circumference. My question is not technically how to do this, but what is the expected behavior in the database on the backend when changing the "plant_trunk_diameter" from a decimal type to a calculate?

I remember @LN mentioning that question types can always be changed from broad to more specific but not the other way around EX (integer changed to string but not vice versa.) I tried looking in the documentation for more details on changing question types for ongoing projects and couldn't find anything. Perhaps I've missed it and someone can point me in the right direction. Up to this point I've been very careful about never changing question types and I'm too scared to make this change for fear of losing data, but would be interested if there is more detailed documentation on changing question types for ongoing projects.

There's a chance that the behavior on ONA will be different from with Central? You may want to reach out to ONA support with this question - https://help.ona.io/contact-support/

You should also be able to test this rather quickly with a new form that has a single question?

i :green_heart: trees and science :straight_ruler: :smiley:
:deciduous_tree: :deciduous_tree: :deciduous_tree:

1 Like

Hi @Tyler_Depke,
Linked to @danbjoseph, I would suggest to test your type change stepwise this with a small form extract in an extra project. (Maybe include a text field to mark your step/version)

  1. deploy decimal type

  2. submit some cases (4)

  3. download/export data and review

  4. change type and redeploy form

  5. edit 2 (old) cases on server level (1 with modal edit, 1 with bulk edit)

  6. submit some cases (3-4)

  7. review table view

  8. download/export data and review

  9. edit 2 new cases on server level (1 with modal edit, 1 with bulk edit)

  10. review table view

  11. download/export data and review again.

1 Like

I have done something very similar - have you considered this approach?;

Add a field to enter circumference as a decimal, keep your diameter field as a decimal, but in the calculation column for it put something like round(${circumference} div (3.14159),2) and in the trigger column put ${circumference}. Then if the circ is entered, it will populate diam with a calculated value, but if diam is entered directly it won't be overwritten unless a circ is added later.

3 Likes

I ended up adding a calculation into the calculation column instead of changing the decimal question to a calculate. For some reason I sometimes get confused when putting calculations in non calculate question types, but this solves the current issue and attached is a basic example. Thanks again!

Diameter_Circumference_Example.xlsx (9.8 KB)

@danbjoseph and @wroos , I did end up verifying on a separate example project that ONA does preserve correct values after changing from decimal to a calculate question type in this instance.


I don't know if there is documentation with regards to changing question types, but it still would be nice to have a better understanding of what is possible while preserving data integrity because my current thinking is don't ever, ever ever ever...ever change question types. :wink:

2 Likes

Could you also test the edits and exports? As far as I know, bulk edit (Circumference, decimal) will not update/trigger the calculation.

Can you explain the last case, with 50 for the new Diameter variable, please? (Seems inconsistent with the calculated value)?

Hint: Any type change should always be fully tested on a clone form, including table view, download/export and edits on old and new data.
Of course, changing a variable name, will always create a new separate variable.

Is there a reason you could not use a diameter tape and not change the form at all?

1 Like

Award for the most elegant solution!

1 Like

I've primarily been measuring trees that will be planted and that have been planted so they are quite young and they typically range from 1/2cm to 3cm in diameter. With what seems like the fairly standard caliper size they only go up to about 15cm or so and the ends aren't long enough to be reliable on trees greater than about 10cm or so.

I should have deleted the 50 value submission at the end, I was just playing around with adding a new field. I also played around with changing an integer field to text and it maintained the values. When I looked at the export in excel, the integer values are stored as numbers (not text) even after changing the field to text. Oddly enough, after changing the integer field to text, if I enter only numbers in a text question, it shows up as a number in excel, but if any string/letter shows up, then it shows up as a string/text.

Time_Example_2024_08_08_19_58_55_495032.csv (4.4 KB)