I'm using the pulldata calculation in Survey123 Connect to populate a form with the lower and single tier municipality of the geopoint question in my survey, ${test_loc}.
I'm using the publicly available layer from my organization: https://ws.lioservices.lrc.gov.on.ca/arcgis2/rest/services/LIO_OPEN_DATA/LIO_Open03/MapServer/14
In my XLSX form, the calculation field is filled with the following text to grab the municipal name short form from that layer:
pulldata("@layer", "getValueAt", "attributes.MUNICIPAL_NAME_SHORTFORM", "https://ws.lioservices.lrc.gov.on.ca/arcgis2/rest/services/LIO_OPEN_DATA/LIO_Open03/MapServer/14", ${test_loc})
However, something strange is happening. If I place my geopoint in, say, Pembroke Ontario, the field gets filled: "PEMBROKE". If I put my geopoint in Peterborough Ontario, the field remains empty.
What's going on here? Peterborough and Pembroke both have very similar looking entries in that layer, and the layer has queries enabled...
Thanks for any hints you might have.
Solved! Go to Solution.
My organization responded to me and said,
“Certain parts of the municipality data can be trying to return very detailed geometry results (i.e. shoreline river borders). Can try not returning geometry from the web request and see if that works. Add the following red text (?returnGeometry=false) to the end of the Service call URL: https://ws.lioservices.lrc.gov.on.ca/arcgis2/rest/services/LIO_OPEN_DATA/LIO_Open03/MapServer/14?ret...
I am skeptical that this is actually the issue, as the three areas I tested (Peterborough, Barrie, and Brockville) do not look very complex, but I tried their suggestion.
After publishing with the fix:
Based on your examples I think it is because Peterborough returns just 1 record and Pembroke is returning 3. This probably means there is a list returned if 3 and not a list for the one maybe? That would mess up the parsing. I would think the multiple list would trip it up not the single result. Sorry not sure and no idea how to fix. But I will take a close look at the JSON returned.
Thanks for digging, @DougBrowning . However, shouldn't my request only select one of those records from Pembroke with a geopoint? E.g., my point only falls in one of Pembroke's features (selected), in the middle of town:
@DougBrowning I thought your hunch was correct - I tried Barrie (1) vs Belleville (3) and Barrie does not work. However, Brampton (1 record) works, and Brockville (3) does not.
@DougBrowning curiously, a simple intersect with a test layer and this particular layer did not work in Pro.
However, the same error occurred with another similar layer from my organization that IS working with the pulldata command, so maybe a red herring.
Weird I wonder if it is corrupted or slow? I looked at this for a but but I dont see anything.
@DougBrowning , FYI - I'm going to ask my organization about this layer. I just spoke with the layer maintainer, who gave me another version of this feature class to test (hosted on AGOL, rather than via a Server Service). The other version of the data (which should be exactly the same) works. Something fishy going on but getting closer to a resolution.
My organization responded to me and said,
“Certain parts of the municipality data can be trying to return very detailed geometry results (i.e. shoreline river borders). Can try not returning geometry from the web request and see if that works. Add the following red text (?returnGeometry=false) to the end of the Service call URL: https://ws.lioservices.lrc.gov.on.ca/arcgis2/rest/services/LIO_OPEN_DATA/LIO_Open03/MapServer/14?ret...
I am skeptical that this is actually the issue, as the three areas I tested (Peterborough, Barrie, and Brockville) do not look very complex, but I tried their suggestion.
After publishing with the fix: