bind::esri:fieldName

[AnthonyJonesRSK]

I've recently come across the situation where I would like to have multiple repeats all use the same nested repeat in my survey. So we have parent layer with many child layers which would all make use of one child layer. The use case for this is that we would like each repeat to have a nested repeat to record actions but we would like those actions to be recorded in one table, not multiple separate tables, for the purpose of reporting.

I built a layer in ArcGIS Pro with the relationships as above but find that if I try and then build a S123 form on top of this in Connect it won't work as Connect doesn't like that they all have nested repeats with the same name. My thinking was that a bind::esri:fieldName option could be used which would mean you could give each repeat a different name in the name column (Actions1, Actions 2 etc.) so that any S123 calculations could reference the repeat but the underlying feature service would have just one table simply called Actions, added in this extra column.

This may also be a solution for the issue described here where Doug outlines the need to have fields with the same name across different repeats. Connect flags these as problematic even though the same field names in a feature service across different layers is perfectly fine. This additional bind field could possibly be a solution for that whilst still allowing users to reference the correct fields in their calculations.

I am sure there are reasons I'm unfamiliar with that may prevent this working but it would be great to know if it could be possible.

Thanks

Anthony

[DougBrowning]

From my talks with them the form uses field names and repeat names internally to figure out what to do where.  Since it is all name based I do not think it will ever be able to change.

What I do, and you probably will, is post process it into the format you want. The schema that makes the forms work well for the user is often not the schema that is good for long term storage and use.  We just take this as a given now really.  I have some forms that do exactly what you describe and my scripts are basically just Append tools a few times with some field manipulation.  All my projects have "ingest" scripts that process the data into a better schema for analysis and use.  Also AGOL is not a great place for long term data storage anyway (no backups, no SQL, no replication, etc).  Since we work on yearly field cycles each year I download, process into a schema that can have dup names and such, then store long term in SDE/SQL.

Not sure your workflows but I hope this helps.

[AnthonyJonesRSK]

Hi Doug,

Thanks for the response. I'm sure I'm over simplifying this and there are things under the hood that would prevent this being a reality, would be nice to have though. It would just be good to see S123 work better with relationship classes. In another instance I wanted to use a feature service with multiple cross relationships in S123 (so parent to child relationships with child to child relationships too) but I seem to remember it just broke the report template functionality.

We currently don't do much automated post processing to get what we need as we are a consultancy so don't tend to work on the same datasets for very long. We are however trying to create some data schemas and survey processes that can be used across projects no matter the client and I suspect this is where this type of functionality will be needed. Think I'll need to scrub up on my python and ArcGIS API knowledge though!

Cheers

Anthony

[DougBrowning]

In your case I could see you collecting the form data, then post processing into a nice clean schema for client delivery.  With QA steps along the way of course!  We use Python to kick out QA reports and it works well.

To help here is my basic ingest outline.  Its not too bad really.

Step 1 Load the AGOL data into memory so its fast and can edit it without affecting original data.  Can load directly from AGOL or download to GDB and process.

arcpy.FeatureClassToFeatureClass_conversion(surveyGDB + "\\" + tableList[table], "memory", "tempFC")
inTable = "memory\\tempFC"

Step 2 Manipulate the fields and copy them to new names that match.  Example here of renaming a key field as you described.  Since inTable is all in memory we can add fields without affecting the original at all.  I more complicated example if turning select multiple into rows in a related table.

arcpy.AddField_management(inTable, "RecKey", "TEXT", field_length=255)
arcpy.CalculateField_management(inTable, "RecKey", "!BasalRecKey!", "PYTHON_9.3")

Step 3 Run Append tool from Form Schema to Final Schema blank template.

arcpy.Append_management(inTable, outDB + "\\" + table, "NO_TEST")

So basically make old schema look like new schema in memory then Append into a blank new schema template.

In almost all cases the schema that works good for the forms and crews is almost never a good schema for long term use.

Hope that makes sense.