topic Re: Referencing a field in calculation parameter in ArcGIS Survey123 Questions

Referencing a field in calculation parameter

JillianStanford — Mon, 26 Aug 2024 20:28:14 GMT

I have a scenario where I allow the user to enter a dimension in feet (max_width_feet) and inches (max_width_inches). I then combine these into a single inches value (max_width) and store that in the feature layer. This is working fine.

What I can't figure out is how to populate the feet and inches fields from the max_width field when the user edits a previously submitted survey. If I try and reference max_width in the calculation parameter of max_width_feet and max_width_inches I get the following error:

It makes sense to me that a field can't reference a field that references the first field but what is the right way to do this? Is it something to do with calculation mode? Or am I not using default and calculation correctly?

Thanks!

Re: Referencing a field in calculation parameter

abureaux — Tue, 27 Aug 2024 17:59:41 GMT

If the survey is previously submitted, should the feet and inches boxes not already contain data from the previous submission?

Re: Referencing a field in calculation parameter

JillianStanford — Tue, 27 Aug 2024 18:02:01 GMT

No, because I'm not storing the feet and inches, I just want to store a single value that combines feet and inches into inches.

Re: Referencing a field in calculation parameter

abureaux — Tue, 27 Aug 2024 18:55:01 GMT

Since is sounds like there is a good use-case, why not just remove the 'null' parameter and let data be stored? That would resolve the issue it seems.

Re: Referencing a field in calculation parameter

JillianStanford — Tue, 27 Aug 2024 19:26:12 GMT

Sure, I could do that but why store a value across two fields when I can store it in one?

There must be other circumstances where you would want to present a value in a user friendly way in the survey and then store it in a more efficient way.

Thanks for your response!

Re: Referencing a field in calculation parameter

abureaux — Tue, 27 Aug 2024 19:47:34 GMT

Well, you just presented a valid case for having it stored in all three fields.

Your combined field is still your single source of truth. You'd just be saving those two other fields for cases where the inputs need to be edited. This is a common scenario. I maintain many fields I don't "need", but keep around because it is helpful for situations like this.

Should you ever need a "This layer is 100% final product only, no exceptions", you could set up a layer view that would exclude the "unnecessary" fields.

Basically, you can't extract data from your combined field and dump it back into the source fields with native functionality because it creates a circular reference. A field can't be its own source because it would endlessly cycle. You may be able to make a script that does that for you without producing a visible error. But it would still be a circular reference and unlikely to behave correctly. Just allowing those two fields to store data resolves all these issues.