Dynamic choice list with search appearance works inconsistently

[SFM_TravisBott]

I have a survey created in Survey123 Connect 3.20.63.

My issue: two questions with dynamic choice lists using search appearance work very inconsistently. They take a geopoint question, buffer it by a specified distance, an use that buffer to query a layer with ~6k polygons. Sometimes it works perfectly, and pulls in the 2-4 polygons near the point, as appropriate. Other times it pulls in all 6k records until you've moved the point it references.

Questions are configured exactly has recommended here: LINK

Note: the whole operation takes place within a repeat.

Additional background: This survey has two geopoint questions. The first is the 'incident point' and the second is the 'treatment point.' The impact point is calculated initially from the incident point as its default location, and the user is urged to move it. The survey was originally configured to use the dynamic choice list based on the incident point. When that was the case I never had this issue. When switching the choice list to the treatment point these inconsistent results started happening. There is a bit of a chain of calculations that generate the treatment point, but I've added some dummy fields to make sure the values are pulled and they are.

searchUrl: concat("TRMTName?url=https://myurl.gov/arcgis/rest/services/CalMapper/CM_GDTreatments/FeatureServer/2&units=esriSRUnit_St... ASC","&distance=",${SearchDistance})

Search appearnce: w1 field-list search(${searchURL},'intersects','@geopoint',${Treatments_point})

${Treatments_point} is generated by concatenating the extracted X and Y values from ${Incidents_point}. This whole part works just fine. It's only since the search appearance came from the ${Treatments_point} rather than the ${Incidents_point} that I've had issues.

Any ideas what gives?

[DougBrowning]

My thought would be its running the search before the geopoint gets filled in.  Does the question have say a relevant on it to wait for the geopoint to populate first?  I think you are saying you have a geopoint calc from another geopoint?  That could cause the delay or the order is off.  It probably does a the search appearance before the calc for the geopoint.  Common issue.

[SFM_TravisBott]

@DougBrowning Those are good thoughts. A few things: I did not have a relevant telling it it wait until the ${treatments_point} is not empty, but the parser didn't like it due to dependency issues.

I did, however, add two dummy fields to extract the x and y values from the ${treatments_point} and it does, so the form certainly thinks the point has a value. I can also submit the form, and the point carries over, even if I don't touch the map.

The other oddity in all of this is that occasionally I will launch the survey and it will work just fine without me doing anything. I can't find rhyme or reason to it. As the survey is launched from URL parameters I can replicate it, and one will work fine then I'll do the same parameters again and it does the goofy behavior.

[DougBrowning]

That almost sounds like a speed issue hitting the service.  

Hmm long shot but try adding a calculationMode=always to the pulldata line.  It may not like it but worth a shot.

Are you using a concat to make treatment points?

[SFM_TravisBott]

I am indeed using concat.

I've experimented with all of the calculation modes, to no avail. I had hoped by forcing the calculation for the point whenEmpty (can't have it be always, as it could get overwritten, and it was defaulted as empty) would have worked, as it would have actively calculated, but it didn't really work as expected. Instead the map is hidden and you're just prompted to hit the refresh. When doing so the map appears with the point and the subsequent calculation works but it's not the behavior I'm looking for.

[DougBrowning]

Can you use that concat field for the relevant of pulldata?  Or still dependency?

[SFM_TravisBott]

Still the dependency. I could try moving the concat to a landing field, then having a calculation to pull that as the point value. Then maybe it could split it out....