How to use pulldata from external source to set default geoshape?

[CharlesBailey]

I have a survey which pulls data from an external csv which has the centroids and extents of counties. It has a geopoint linked to the survey and a geoshape in a repeat. I am pulling the coords for the centroid of the selected county to set the initial geopoint, which works, but when I try to concatenate the coords from the extent to set the geoshape, nothing happens. I have verified by setting the calcs to decimal and text questions that everything is populating and I don't see anything wrong with it, but it just doesn't work. I've tried it inside and outside of the repeat. Can someone please tell me what I'm missing here? Survey folder attached. Thanks, cob 

[IsmaelChivite]

Hi. Looking at your XLSForm, it seems like your calculation generates a valid polygon.  However, the output of the calculation does not automatically set the value of your geoshape question when your geoshape question is within a repeat.

• If I keep the geoshape within the repeat, I need to click the 'refresh' button for the calculation to set the value of the question.  This is because somehow the geoshape question within the repeat is flagged as having a value entered by the user (which is not correct). When this happens, calculations do not overwrite the value unless the refresh button is pushed.

• If I remove the repeat, the value of the geoshape is set automatically as expected.

I do not quite understand why you want to have the geoshape within a repeat. Do you want people to enter multiple polygons? If so, why would you calculate the polygon with a value that is common to all repeat records?  Or is it because you want people to upload multiple files?  If so, you could simply apply the multiline appearance to your file question and leave the geoshape and file questions outside a repeat.

In any event, if for whatever reason you really need that geoshape to be within a repeat and have it calculated the way your XLSForm shows, then I suggest you open an Esri Technical Support incident. At first sight, the behavior does not seem correct.  The geoshape question should take the value of the calculation, just like the extCty does.

Finally, a couple of suggestions:

• You may want to use the minimal appearance for the county select_one
• The hidden appearance could also be handy to hide the multiple questions you have with intermediate values (MINX, MAXX, etc).  You may also want to set the esriFieldType column to null so these intermediate values are not sent to the feature layer

[CharlescobBailey]

Thanks for your response Ismael. I'm using the repeat because I thought it was the only way to use two geometries in one survey. There will only be one boundary but perhaps multiple files, but I could have used the multiline if I knew I could take the geoshape out of the repeat. However, I did get something to work and I'm reluctant to make many changes. I had it working perfectly in Connect but the published version had all sorts of problems. So right now I have the repeat with minimal appearance so it doesn't try to load the map until a county is selected which caused the panel to lock up even after a county was selected.. And the point has an if statement that loads a placeholder point if no county is selected - that caused a problem too. My folks don't like the minimal appearance for select one because the menu scroll isn't easy to use on some devices. The only thing left is sort of minor but driving me nuts. I changed the symbology of the geoshape as you described using the visualization tab, and it appeared to work fine but it isn't being honored in the web form. We will only be using the browser version for this survey. Am I wrong to expect the symbology to change in the web form? Thanks a lot Ismael - cob

[DataOfficer]

Hi @IsmaelChivite,

I am trying to use a pulldata function to pull in the geometry for a geoshape question, based on a select_one choice. Note that this is in a repeat. The geometry is moderately complex (up to 52 sets of coordinates to build the geometry string). Therefore, I have opted to store the geometry string as a single field in an external csv (e.g. 51.0718794880673 -0.832585294109184; 51.0716407642081 -0.833096529055853; 51.0713819551087 -0.833697778802456 ...).

I can successfully pull the geometry string in to a text field (called Geometry), but when I then use that field as the calculation for the geoshape it fails. I have tried the following in the calculation field:

• ${Geometry} - fails with the attached error message
• string(${Geometry}) - fails with the attached error message
• number({Geometry}) - doesn't fail loading in Connect, but the Geometry does not appear in the Geoshape question.

Is there a way to get this to work in the way I am doing it? Or will I need to have (52) separate columns in the csv being used by the pulldata and concatenate them as I would for a Geopoint question?

[GeomaticsPublisher]

hi I've also experienced the same issue. Have you found any solutions? 

I can also successfully pull the geometry string in to a text field (called Geometry), but when I then use that field as the calculation for the geoshape it fails.

If i put exactly the same string into the default column it draws the geoshape correctly som the geometry is ok but not being successfully used in the calculation. Any help much appreciated.

[IanMackenzie]

I was able to get something like this to work by passing a coordinate attribute in from the feature class from which my survey is launched... see custom attribute display screen shot below.

The coordinates in the feature class "Coordinates" text field look like this (minus the quotes):

"53.5386769 -113.2948011 ; 53.5346850 -113.2949250 ; 53.5373088 -113.2865969"

[Note i did not need the apostrophe that would be required when entering directly into the spreadsheet]

The Survey123 spreadsheet is formatted as per the second screenshot below. If you don't actually want to write those coordinates into the Survey feature class, i.e., field doesn't exist in the survey feature class, then need to set bind ESRI Field Type to null.

Ultimately I did not go with this approach as most of my polygons have too many vertices and exceed the maximum field size  (may revisit this with Blob type).