New Field Maps Calculated Expressions and Conditional Visibility

[RhettZufelt]

It appears as if the new Calculated Expressions still only work on non-editable fields..

Is there a setting for this so we can toggle this behavior on/off.  Seems that a feature to "help" populate the data and reduce required form input on certain features is nice, but if you can't edit the data for other features that don't fit the query it is very limiting.

Also, it appears as if a field is 'hidden' with a conditional visibility query, any data in the field is still being deleted.  Was there an option added to control this behavior as well?

Seems like the only way to hide a field without the data being deleted is to use Calculated Expressions.

So, if Calculated expressions can populate (and not delete hidden field values), seems we should be able to toggle that restriction off for any field.

R_

[DamonBreen]

When they released the Calculated expressions in Beta, the instructionals made it out that only non-editable fields would be able to use calculated expressions. From what I have seen, there is no workaround directly. However, you could set up a conditional in the calculated expression itself to determine whether that field should be populated or whether it should be left open for input. Without knowing what it is you're doing, I can't help much further than that. Something like a controlled subset of values depending on a previously selected value.

Give an example and maybe I can try to help a bit more.

[RhettZufelt]

I saw that in the Beta, and had some input.  But, as flaky as the beta site is, and absolutely zero feedback, not even sure if it is actually working or not.

In any case, one current example: Say I am collecting sign data, and my sign code domain (drop down pick list) has 265 different values in it (and growing).

Of them, say 30 of them will always have the same shape, background color, etc.  so I would like to populate these 5+ fields with known values  and hide them to make the form less daunting.

Now, in order to be able to populate the rest of the data, I will have to make 235 different calculate expressions OR, have no way to populate these fields for the other sign types. 

Of course, this is dumbing it down a bit, and I will would have several more calculated expressions to handle groups of signs, but would still end up with hundreds of expressions required.

Other than calculating key fields or record numbers, I'd have to think a bit to find a normal work case scenario where having the fields un-editable would be an advantage.  I guess if you were colleting data where every single possible combination of data/attributes is static and could be known well ahead of time, this would be perfect.  However, in the real world, this is rarely the case.

However, you could set up a conditional in the calculated expression itself to determine whether that field should be populated or whether it should be left open for input.

This is exactly what I am looking for, but, of course, the fields left open for input will need to accept input.

Thanks,

R_

[DamonBreen]

Yeah, so I think the way I would go about doing it is to identify the sign codes that will have matching and expected attributes, and use calculated fields to do the work where you can. Then for the sign codes that will need to have user input beyond the drop downs, I would add a new field as a catch all, and use the conditional expressions to determine whether they get a drop down selection or an open text box.

If sign codes a, b, c all have expected answers and can be calculated, then upon selecting sign code a, a conditional expression makes a drop down field called "ExpectedSize" or whatever to appear. But when they pick sign code d, which does not have expected answers, a second conditional expression makes a text box field called "UnexpectedSize" to appear. This allows the use of either, likely dependent on similar code for the calculated fields and for the conditional fields.

[RhettZufelt]

Thanks for the input, I was thinking along the same line, but was trying to avoid having to have duplicate fields for every field that I plan to calculate and then have the data scattered across columns that would later need to be calculated back into one.

So far, the best workaround I have come up with IS to have duplicate fields for each, but, use calculated field(s) to edit the non-editable fields.

So, for BG_Color I'd have a BG_Color2 field, and if the BG_Color2 field is populated, use that value to populate the original BG_Color field.

So, for a stop sign:

IIf(IsEmpty($feature.BG_Color2),
     IIf($feature.SIGNcode == 'Stop', 'Red', ''), $feature.BG_Color2)

So, if I just pick "Stop" from the code list, and the BG_Color2 field is empty, it will populate BG_Color with "Red".  However, if I type "White" in the BG_Color2 field, it will override the non-editable field, and put "White" in there.

Of course, this requires that I now have a bunch of other fields visible in the form, and only used for override of this odd limitation.  Which, of course, is the opposite of streamlining the data entry form and very confusing to the field personnel.

So, at this point, is seems that the field crew is going to be stuck entering the exact same values hundreds of times a day since setting a field calculation on it essentially locks that field from normal entry OR I have to duplicate a bunch of fields and the form then becomes unwieldy.

Even though it is risky calculating/modifying hosted feature layers as it can break everything you have set up, another option was to just hide all those fields and query/calculate the values at a later date.  

Problem here is that this is an inventory/inspection collection map.  So, it is possible to preform an inspection on/edit existing signs.  The way smart forms are set up, if I hide these fields, any existing data gets set to Null for all of them.  So, since these two features designed to help streamline data entry either lock or clobber the data, seem like very limited use case for each.

R_

[DamonBreen]

So I think you could use conditional expressions on these same "extra" fields to hide them automatically. So in this case, if you pick Stop for the sign code, then the conditional expression on BG_color2 would be hidden, and the BG_color  would have a similar conditional expression except for when you do "Stop" it would show, instead of hidden. You would have multiple fields capturing the same data, but you could do a calculated field later to concatenate all of the items into one field for reports or analysis. 

I'm in the same boat a lot of times on whether or not I want to go the extra mile on the back end to make it marginally easier for the guys in the field, so I get where you're coming from. I know the developers have made it seem like there is some major problem with the conditional expressions as of Thursday, so I hope a lot of what we are seeing is that, and not a heavy limitation on the capabilities.

[RhettZufelt]

I find that if I don't make the data collection as simple as possible, especially with something monotonous like this, then I'm the one that ends up doing all the extra work due to all the errors/omissions/etc. that pop up, as well as have to hear all the complaints.

Now that the EA forums is letting me in again, I see that they have apparently included the ability to toggle fields as editable or not by code to allow for calculating or editing.  However, still no web interface or way to author these expressions yet. (Hopefully the Null/NotNull fields when hiding with conditional visibility option is there now also).

Looks like best bet for me is to wait and see if this function gets updated where it fits my use case(s).

Thanks again for the input,

R_

[Will_Hughes]

I need this functionality. It would be nice to have to option to allow users to edit a field with a calculation. Sometimes I need to pull attributes from another layer but the data might have changed so having the option to edit the field with calculation would be good. 

[beachcamp]

The addition of the ability to edit calculated fields would be huge. As it is I feel like I really need to think twice before utilizing this functionality, it's almost more detrimental than not as it stands. There are so many places I would love to use a calculated field, but without the ability to edit before submission I often can't allow it.

I use the same functionality in Survey123 and it's great, but there the field can be edited. Why the change?

[PGebhardt_Stone_Env]

Agreed, it would be helpful to allow editing of calculated fields after they are populated. In my instance, a field populates based on an intersection with a road dataset. If the point is close to the intersection of two roads, it may populate based on one of the roads, when I want it to be the other.