Select to view content in your preferred language

Data type of output from calculate fields

816
4
Jump to solution
06-07-2023 02:23 PM
MattEdrich
Frequent Contributor

Hello all,

We are experimenting with methods of digitizing a workflow that previously involved recording field data by hand, taking a photo of the worksheet, submitting that as an image response in Survey123, transferring the field data to an Excel spreadsheet (also by hand), and then having some Excel macros finish the effort for us. The workflow in question involves a fair amount of algebra and trigonometry, which I attempted to automate as calculations in the survey form so that we could cut out most of the steps outlined above and just have a feature report create a table of all the calculated values from the field. However, I apparently have a reference error in my form and I suspect it has to do with misunderstanding the output of certain calculate fields in the whole sequence of calculations. I am not able to share the entirety of my XLSForm; however, I don't think I need to in order to resolve this issue.

I have a ${positionfactor} field that determines the sign needed to multiply values by, based on specifically where and how the values were collected in relation to the asset. Its calculation cell in the XLSForm is: if(((${guy_a_obs}='direct' and ${guy_a_obs_whole_shift}='right') or (${guy_a_obs}='thru' and ${guy_a_obs_whole_shift}='left')),1,-1). I expected the output of this calculation to be an integer (1 or -1), but I suspect that I am getting the string of each integer instead. ${positionfactor} is used later on in the following formula: (${positionfactor} * ${guy_a_whole_hdist} * (tan(${guy_a_obs_whole_ddconvert}) * 57.295779513)). However, when I look at a record of this survey exported to Excel, I see the following error: 

ReferenceError: positionfactor is not defined in expression: (positionfactor * guy_a_whole_hdist * (tan(guy_a_obs_whole_ddconvert) * 57.295779513))


However, there are definitely positionfactor values populated for all records in this particular repeat:

Determines the actual shift vector based on <FIELD LOGIC>
-1
-1
1
1
-1
-1
1
1

 

Here is the actual definition of positionfactor in the XLSForm (I removed all the blank cells as there are only 4 columns used):

type: integername: positionfactorlabel: Determines the actual shift vector based on <FIELD LOGIC>calculation: if(((${guy_a_obs}='direct' and ${guy_a_obs_whole_shift}='right') or (${guy_a_obs}='thru' and ${guy_a_obs_whole_shift}='left')),1,-1)

 

Given all this, the only explanation I can come up with is that S123 is trying to multiply a string by various decimals, and that freaks it out. I am thinking of simply ensuring positionfactor is an integer in the calculation that it is used in (int(${positionfactor} etc etc) - will this do the trick? Or am I way off base here and just missing something obvious?

I think issues like this have tripped me up before, expecting one datatype as output and actually getting another. I know that I have seen others mention it as a significant stumbling block around these forums. Where can I find the documentation on output datatypes in S123 calculations?

1 Solution

Accepted Solutions
DougBrowning
MVP Esteemed Contributor

Yes calculate defaults to string.  You can use the bind::type column to fix this.

Other newer option is to set as int type then use the hidden appearance.

Hope that helps

View solution in original post

0 Kudos
4 Replies
DougBrowning
MVP Esteemed Contributor

Yes calculate defaults to string.  You can use the bind::type column to fix this.

Other newer option is to set as int type then use the hidden appearance.

Hope that helps

0 Kudos
MattEdrich
Frequent Contributor

Hmmmm I had type=integer, and I believe the appearance was set to hidden as well and that was the result I posted above 🤔 as of now I have set the bind::type to esriFieldTypeInteger and changed the type of positionfactor to calculate....

Is this a super confusing part of S123, or is it just me?

 

0 Kudos
DougBrowning
MVP Esteemed Contributor

To be clear bind::type should have the option int and this binds the type inside the form only.

bind::esri:fieldType has the option esriFieldTypeInteger and it controls what the feature service type will be.

You maybe seem to have mixed and matched them?  You said calculate and I assumed you mean calculate type.  The integer thing should work but I always use the old way.

Once I got used to the string thing its fine.  

0 Kudos
MattEdrich
Frequent Contributor

I appreciate that, Doug. I was able to work out the issue by following the 'old way' as the 'new' method just didn't come together for me reliably. It is unfortunate, in my opinion, that the error in question didn't arise when I ran Esri's onboard Analysis tool - finding it after ~40 records had been submitted meant that I had to create a new version of the survey form with the correctly formatted bind::type fields, which themselves took a bit of annoying experimentation and ironing out before going fully live, and I still had to meticulously insert number() calls in many places to bridge gaps. 

For those curious, there is indeed documentation on this - it is a single bullet point right above 'Complex mathematical functions' here. 

Esri's Analysis tool gets an F- in this case.