In a file geodatabase (GDB) to GDB translation, I am writing dynamically to a blank (unpopulated) template GBD that has relationship classes. From a source GDB I am reading features both from feature classes that participate in relationships and from the relationship feature classes themselves. I get the usual geodb_feature_has_relationships and geodb_oid format attributes on the participant features, and I get the usual geodb_type (= geodb_relationship in this case), geodb_rel_origin_oid, and geodb_rel_destination_oid format attributes on the relationship features; however, to keep the workspace generically dynamic and reusable, I need to determine--during translation--the names of the origin and destination feature classes for the relationship classes being read. Of course, I know what those feature classes are before runtime, but the dynamic, i.e., non-prescient, workspace does not. Is runtime determination of the origin and destination feature class names of an existing relationship class even possible in FME?
When reading a geodatabase relationship class, is there any way to determine what are the origin and destination feature classes?
+1- Contributor
Best answer by natalieatsafe
@tcrossman Hi, thanks for your question. I have not tested this out myself, however it seems like you should be able to use a scripted user parameter or two to extract the origin and destination class names via the arcpy Describe function. Have a look at this Esri document which outlines this Describe function. Here is our documentation on using scripted parameters. Scripted parameters do run before translation, so the returns from these scripted parameters should be available for the start of translation.
There is a small code sample of this Describe function provided at the bottom of that linked Esri document. The two properties which may be relevant to your use case would be the Destination Class Name and the Origin Class Name properties. In a scripted parameter, the key is to use the return () function, rather than print (), in order to push the acquired value to FME.
I think it might get a bit tricky if more than one feature class serves as origin or destination. Figuring out how these are treated in the return, and extracting the names as individual values would be next steps in that case.
Hopefully the above give you at least a starting point on extracting relationship class origin and destination feature class names. Please let us know here how this goes, I'm curious to see how this could be implemented.
+11- Safer
- Best Answer
@tcrossman Hi, thanks for your question. I have not tested this out myself, however it seems like you should be able to use a scripted user parameter or two to extract the origin and destination class names via the arcpy Describe function. Have a look at this Esri document which outlines this Describe function. Here is our documentation on using scripted parameters. Scripted parameters do run before translation, so the returns from these scripted parameters should be available for the start of translation.
There is a small code sample of this Describe function provided at the bottom of that linked Esri document. The two properties which may be relevant to your use case would be the Destination Class Name and the Origin Class Name properties. In a scripted parameter, the key is to use the return () function, rather than print (), in order to push the acquired value to FME.
I think it might get a bit tricky if more than one feature class serves as origin or destination. Figuring out how these are treated in the return, and extracting the names as individual values would be next steps in that case.
Hopefully the above give you at least a starting point on extracting relationship class origin and destination feature class names. Please let us know here how this goes, I'm curious to see how this could be implemented.
+1- Contributor
@tcrossman Hi, thanks for your question. I have not tested this out myself, however it seems like you should be able to use a scripted user parameter or two to extract the origin and destination class names via the arcpy Describe function. Have a look at this Esri document which outlines this Describe function. Here is our documentation on using scripted parameters. Scripted parameters do run before translation, so the returns from these scripted parameters should be available for the start of translation.
There is a small code sample of this Describe function provided at the bottom of that linked Esri document. The two properties which may be relevant to your use case would be the Destination Class Name and the Origin Class Name properties. In a scripted parameter, the key is to use the return () function, rather than print (), in order to push the acquired value to FME.
I think it might get a bit tricky if more than one feature class serves as origin or destination. Figuring out how these are treated in the return, and extracting the names as individual values would be next steps in that case.
Hopefully the above give you at least a starting point on extracting relationship class origin and destination feature class names. Please let us know here how this goes, I'm curious to see how this could be implemented.
@natalieatsafe Hello, and thanks for your answer. I have an ArcGIS script tool I wrote many years ago (since ported to Pro and included in a Python Toolbox) that scans a geodatabase (GDB) to document the schema, including using the Describe function to read all of the relationship properties. I will look at the Esri examples you link to, though, in case there is code efficiency or functionality to be gained and of which I am not aware. (No one ever accused me of being a good programmer.) I have actually used my relationship scanning code in a PythonCaller to determine the origin and destination feature class names. Works fine for its specific purpose in the workflow; however, because I am really just an intermediate level FME user at best, it never occurred to me to put the code in a scripted parameter. Brilliant! ... and that would allow me to do some other things in the workflow that are difficult when the code is in a PythonCaller. Originally, I had been hoping that someone would indicate how I could determine those feature class names with pure FME functionality (internal business reasons to avoid Esri functionality, if at all possible), but since I posted my question--and now with your answer--I have become certain that I have no choice but to go with Esri functionality (not a problem for me personally). Thank you so much for your answer, especially the suggestion of a scripted parameter. I shall certainly try that out.
Reply
Helpful Members This Week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.