Creating a related feature that retains target layer location

[CourtneyWatson]

Hello! I'm just wondering if this is possible.

In Field Maps  I would like a user to be able to click on a tree to create a new feature called 'Asset Risk' with the same location as the tree and to enter risk attributes. When the 'Asset Risk' feature is created its symbolised on the map based on the input of the inspection,  Eg 'Asset Risk' has fields like Human Risk and Property Risk.  If Human Risk is 'High' and Property Risk is 'High', then there is a field called 'Score; which has a value of 5 and is symbolised in Red or something similar.

This is the issue I am facing, I have a relationship between the Tree and Asset Risk in Field Maps, so when I select a Tree I have the option to create an Asset Risk feature, however, the user is being asked to move the point on the device screen to the location they want the 'Asset Risk' feature to be created which I don't want.  I want the location of 'Asset Risk' to be automatically generated based on the location of the tree.

[ajevans429 · Accepted solution]

I did this with our tree data at one time. We had a related "tree activity" point feature class that I wanted to have the same geometry as the parent tree/location.

If you are using enterprise, you can set up an attribute rule to calculate on insert and update that pulls the parent tree's geometry and overwrites whatever geometry was assigned during collection. It's not a smooth solution, because it still allows the user to think that they can assign a separate location, but it worked.

For simplicity, I ended up transferring all of our data to being hosted in AGO, and converted the "tree activity" fc back into a geometry-less table. If I want to visualize the table data, I can create a join view that is always up to date. The only problem with that is that you can't edit your schema when a join view is active. Adding/editing domains/fields is impossible.

[RobertBorchert]

Why not just make Asset Risk an attribute of the tree itself rather than creating a new feature

[CourtneyWatson]

I need to retain the history of the inspections so I cannot have the field overwritten at each inspection.   Sorry, I should have mentioned that.

[ArmstKP]

You may want to just create a related table of inspections.

[ajevans429]

@CourtneyWatson , this is somewhat tangential to your original question, but would you be willing to share your organization's data collection workflow (or just the data structure) for collecting tree risk information? The categorization of "human risk" versus "property risk" is intriguing to me!

We currently have a 3 table deep setup (Tree/Sites->Tree Activity->Tree Risk Assessments). Our current workflows involve manually updating the latest "overall risk" value from the Tree Risk Assessment table to the parent Tree/Site asset, although I hope to include more automation in the future. 

Any additional info would super helpful!