topic Re: Pulldata GetRecordAt Fails with Service Sublayer in ArcGIS Survey123 Questions

Pulldata GetRecordAt Fails with Service Sublayer

jfischer91 — Tue, 03 Jun 2025 18:27:51 GMT

I'm trying to build a survey that will automatically populate the Township, Range, and Section values when the user drops a point. The pulldata returns JSON when querying the main layer, but returns it intermittently with sublayer 1, hardly ever with sublayer 2, and never with sublayer 3, which is the one I need (PLSS Intersected). Example result in screenshot.

I'm new to Survey123 but after watching @IsmaelChivite's tutorial about "GetRecordAt", I tested it with a different layer and it works perfectly. The layer I'm trying to query does have a lot of attributes, that's the only thing I can think that would be different. Query is enabled on both and both are public and accessible. Test layer shown as last record in table.

decimal	DLat	Latitude (DD)	round(pulldata("@geopoint", ${location},"y"), 6)
decimal	DLon	Longitude (DD)	round(pulldata("@geopoint", ${location},"x"), 6)
text	PLSS_json	PLSS JSON	pulldata("@layer", "getRecordAt", "https://services2.arcgis.com/FiaPA4ga0iQKduv3/arcgis/rest/services/Public_Land_Survey_System_view/FeatureServer/3", ${location})
text	GetJSON_TEST	Test JSON	pulldata("@layer", "getRecordAt", "https://services.arcgis.com/P3ePLMYs2RVChkJx/arcgis/rest/services/World_Administrative_Divisions/FeatureServer/0", ${location})

Re: Pulldata GetRecordAt Fails with Service Sublayer

DougBrowning — Tue, 03 Jun 2025 18:28:13 GMT

Try taking that round out of there. Pulldata really does not like being inside any functions. Gets posted a lot. I do not think you would want to round anyway.

Re: Pulldata GetRecordAt Fails with Service Sublayer

jfischer91 — Tue, 03 Jun 2025 18:30:42 GMT

Hi @DougBrowning, thanks for responding. I actually haven't had any troubles with the Lat/Lon values, they populate every time. The issue I'm having is with the PLSS_json line. It's also confusing because I can get successful results consistently with a test layer, in the last line, but not the PLSS_json one.

Re: Pulldata GetRecordAt Fails with Service Sublayer

DougBrowning — Tue, 03 Jun 2025 18:34:10 GMT

Ok next it could be returning a really long string. Try setting bind::esri:fieldLength column to something high like 2000.

Re: Pulldata GetRecordAt Fails with Service Sublayer

jfischer91 — Tue, 03 Jun 2025 18:36:56 GMT

I hadn't included that in my main post, but it is already set at 2000. Here's a screenshot of the JSON when I use the "/0" layer, instead of "/3".

Re: Pulldata GetRecordAt Fails with Service Sublayer

DougBrowning — Tue, 03 Jun 2025 18:38:24 GMT

When I look at that service there is no layer 3?

Re: Pulldata GetRecordAt Fails with Service Sublayer

jfischer91 — Tue, 03 Jun 2025 18:40:39 GMT

The link I included is directly to layer 3, this is the link to the main service:

https://services2.arcgis.com/FiaPA4ga0iQKduv3/ArcGIS/rest/services/Public_Land_Survey_System_view/FeatureServer

Re: Pulldata GetRecordAt Fails with Service Sublayer

DougBrowning — Tue, 03 Jun 2025 18:57:51 GMT

Ok I was on the one above. I wonder if it is the really tight visibility settings?

I would also try even bigger on the size just in case.

Re: Pulldata GetRecordAt Fails with Service Sublayer

jfischer91 — Tue, 03 Jun 2025 19:09:54 GMT

What do you mean by "visibility settings"? You mean when each layer is visible? I was wondering if that had something to do with it too, if Survey123 queries layers at a certain scale. But I tried zooming way in on the map when placing the point, and that didn't seem to change anything.

I tried increasing the field size to 5000, that didn't help.

Re: Pulldata GetRecordAt Fails with Service Sublayer

DougBrowning — Tue, 03 Jun 2025 20:03:48 GMT

This seems to point to that and makes some sense

Performing an Intersect on a Service:

When performing an intersect analysis on a layer service, the resulting layer will inherit the scale visibility settings of the original layer service.
If the intersect analysis is performed within the layer's defined scale range, the resulting layer will be displayed.
If the intersect analysis is performed outside of the layer's defined scale range, the resulting layer will not be displayed.

Re: Pulldata GetRecordAt Fails with Service Sublayer

Neal_t_k — Tue, 03 Jun 2025 20:48:02 GMT

Is it possible that intersect layer is just too big. I loaded it up for a test since it is a public service and the form loads incredibly slow compared to the state level layer. I tested it manually from the rest api and there is no issues, so I wonder if it is just loading the entire layer and it is bogged down?

Do you need the entire US, would it be feasible to export your area of interest and host it yourself?

Re: Pulldata GetRecordAt Fails with Service Sublayer

jfischer91 — Tue, 03 Jun 2025 22:09:30 GMT

Interesting, I'll have to look more into that. I wonder if there's any way to set the scale that Survey123 does the Intersect at.

Re: Pulldata GetRecordAt Fails with Service Sublayer

jfischer91 — Wed, 04 Jun 2025 22:22:20 GMT

I'd prefer to avoid self-hosting if possible. I'm new to Survey123, but I assumed that using pulldata would basically just query the REST API anyway, so you're not really loading all the data into anything, it's just using the coordinates you submit. Is that not an accurate statement?

Re: Pulldata GetRecordAt Fails with Service Sublayer

DougBrowning — Thu, 05 Jun 2025 12:30:04 GMT

Forgot but have you tested setting a relevant on the calls to check for the lat/long being filled in first. like string-length(${DLat}) > 0. I am still not sure on the round as the order of operations it runs the calcs comes up again and again. There are tons of posts of pulldata not working properly when it is inside a function. The form does not run calcs from top to bottom. It does things more by the type. So runs defaults, then appearance, then calcs, then pulldata kind of thing. pulldata is just so picky and you are stringing them together by pulling the lat/long. It could be running the PLSS calls before the lat/long is there. And the fact it happens on all of them.

You could also test calculationMode=always on these just to see.