control of $feature when using Test in Arcade editor

1103
10
11-17-2022 03:34 AM
JonathanBowes
New Contributor III

This maybe a "Doh" moment but I've been staring at this for so long now.

In AGOL Field Map, in a calculated expression, is it possible to control which $Feature the "Test" button runs the code on? It defaults to the first record and field in the table, in my case 733mm of rainfall. I would like to test the code on different row in the table. How can I do this?

JonathanBowes_0-1668684648075.png

Thanks for any help.

Jonathan

0 Kudos
10 Replies
JohannesLindner
MVP Frequent Contributor

You can edit the values used for testing with the pecil symbols right of the field names.JohannesLindner_0-1668686328838.png

 


Have a great day!
Johannes
0 Kudos
JonathanBowes
New Contributor III

Hi @JohannesLindner, thanks but I need to change the $feature from the first record in the table (OBJECTID=1) to OBJECTID=34 and hit the test button on that. It doesn't seem to be definable.

0 Kudos
JohannesLindner
MVP Frequent Contributor

You can't say "use this feature for testing".

You only can edit the field values it uses for testing.

 

Let's look at an example: Just return the count of features in a related table.

 

With the default $feature:

JohannesLindner_0-1668691670710.png

 

If I change the value of the field that is used for the relationship (it was 724):

JohannesLindner_1-1668691765702.png

 

 

Think about it this way: When you start the expression editor, it loads the values of the first feature and uses them to test and validate the expression (at least that's what I think it does). At this point, it doesn't have an actual connection to the feature anymore, it just uses the values. So to test the expression on different features, you can't change the feature it uses, you can only change the values.


Have a great day!
Johannes
jcarlson
MVP Esteemed Contributor

You can try putting this expression into a popup in a map viewer. When configuring popup expressions, the "test feature" is picked from the visible extent of the layer, so you could just zoom in on the specific item you want to test, then work on the expression there.

You could also write a whole separate expression that uses a filtered FeatureSet to specifically grab the feature you need, but that's a lot of extra work just to test the expression.

That said, I think it would be a fantastic addition if it were technically possible to do so. You should post an Idea about it, I'd totally vote for it! What you're describing is a much-loved part of QGIS for me; everywhere expressions are used in Q against a layer, you can toggle which feature to preview the output for. Having something like this available in AGOL would make building / testing expressions in Arcade that much more useful.

jcarlson_0-1668691097247.png

 

- Josh Carlson
Kendall County GIS
JustinReynolds
Occasional Contributor III

Some good answers above. 

I no longer bother testing with a specific feature; it is rarely convenient  or predictable enough for me.  Instead I just provide MOCK or TEST values.  When I go to production I comment out the test values and uncomment the production values... the opposite is true in development or testing.  I make sure I clearly identify the prod or test values with code comments.  Whether I'm writing the expressions or reviewing expressions others have written, MOCK values are required piece of the puzzle for our team.  This means that I don't have to know anything about the feature's schema or whether I'm looking at a feature of interest.  I can easily change the MOCKed value to test various logic or math without taking my attention off of the expression.

This can be done with $Geometry and featureset data as well.

JustinReynolds_0-1668697874755.png

 

- Justin Reynolds, PE
jcarlson
MVP Esteemed Contributor

I do that a lot, too, and it usually works for attribute-based expressions. Not as useful for expressions that are evaluating against geometry or doing spatial stuff, though, where you need to test some edge cases to see how they buffer / intersect / etc.

- Josh Carlson
Kendall County GIS
JustinReynolds
Occasional Contributor III

Yup, the spatial stuff is a mixed bag for me as well.  More often than not I do end up creating features with the geometry that I want to test.  I'm starting to create some generic geometry (on the side) using the geometry functions solely for injecting into my expression as mock geometry.  So if I'm looking for intersections I have mock data to test with that I can just plug in.  I still use real features to test the edge cases, same as you, and I still test in field maps if I need to see how thing go when the map scale changes.

When I'm working with Featureset data I'm usually after a single value or a dictionary representation of a feature(s).  In that case I'm mocking the Featureset as the resultant dictionary or value of interest.

- Justin Reynolds, PE
0 Kudos
jcarlson
MVP Esteemed Contributor

Oh, I like that! I'll have to start making a list of "sample geometries".

- Josh Carlson
Kendall County GIS
0 Kudos
JessePapez__-_RR
New Contributor II

Does anyone know if this functionality is still present in the current version of AGOL's "new map viewer"?  I am not seeing the same option to modify the test feature value in this environment.

0 Kudos