Select to view content in your preferred language

Join Feature Class to Standalone Table

176
2
3 weeks ago
JenniferTovar3
New Contributor

I have a feature class of cemetery headstones that I am trying to join to a standalone table which lists the information on the family members buried for that specific headstone. I need a one-to-many relationship that will ultimately be published out to a webapp for users to click on the single headstone and see the information on the family members buried in that plot. A join is one-to-one. How do I make this a one to many for end users in a webapp?

0 Kudos
2 Replies
BarryNorthey
Occasional Contributor III

Don't know about web apps, but joins in Pro can be one-to-many if the joined data have ObjectIds and reside in the same workspace such as a file geodatabase. 

0 Kudos
JonathanMcD
Occasional Contributor

Hi,

Suppose all depends on what you're looking for in terms of a user experience. Are you looking just for a large flat table of data listing Interment 1, 2, 3 etc., or are you looking for something along the lines of a relationship class experience where all related records are available in the pop-up?

I'm currently going through a programme of digitising our cemetery lairs and interments, along with enabling onsite safety inspections, and publishing to Open Data so families can view interments and headstones. I'll describe what I've done later.

Your options;

  • do a bit of ground work and calculate max number of possible interments then create a dataset to accommodate that, then all you'd do is construct your table and join one-to-one. Not great for updating tho' you could just republished and overwrite every release.
  • publish the headstone dataset along with the table, un-joined, but then use Arcade to list and return the matching records based on the headstone and interment unique IDs (not ObjectIDs) you have when the user clicks on the headstone. This would mean all you'll update/append is the table with every new data release.
  • Create in ArcPro a headstone database and create the interment table schema and import your data to both. In the headstone database ensure to use your headstone ID is the unique ID, in the interment table you'll have a GUID field and holding the common id too. Create a relationship class between the headstone and the interment table, selecting the right ID fields, and ensure the check box for Attributes is ticked. You'd just republish every data release. Use experience would allow for each individual interment to be looked at as a record.

What I've done - since I'm digitising the cemetery lairs, the parcels of land, these are created first with cemetery, section, and lair number details. Headstones are nothing more than blank dots. Once a layout is complete I run a process to update the lairs with the interment details. Those capturing the data click on the blank headstone point and Arcade in field maps populates all associated data and interments, all the person has to do is take the photo. Due to us using the headstone point for auditing and safety inspections, the relationship class is just for that, rather than interments, so all the interment details are a bit like option one. The families would only see the headstone point, interment details, and the picture.

 

0 Kudos