Skip to main content
Solved

Can you write to geodb relationships from any source data type?

  • February 3, 2022
  • 6 replies
  • 93 views
timboberoosky
Contributor
Forum|alt.badge.img+7

Hello there

I was wondering if it's possible to write to geodatabase relationship classes where the source is not a geodatabase, so you don't have the "OBJECTID" to set as the "geodb_oid". I'm reading in some CAD data and am inserting records into 1 feature class and 1 table in a defined File Geodatabase that already has the relationship class setup (non-attributed), and want those 2 objects related. All the examples I've seen of writing to geodatabase relationship classes seem to have a Geodatabase-type source with already-defined OBJECTID values as attributes. I may have missed some documentation, or have done some tests incorrectly, but is it possible to somehow create the "geodb_oid" at runtime or would this have to be a 2 step process (i.e. 1) write data to feature class and table and 2) write relationships)?

I know this is a bit vague but hopefully there's enough information that someone knows the answer!

Thanks

Best answer by markatsafe

@timboberoosky​ If you look at the feature counts, you're creating two relationship features, when you only should have one for each pair of origin/destination features. Normally, you have to merge the origin and destination features to create the relationship since they might be coming from two source features.

 

But...in your case, both the origin & destination feature originate from a single source Transformer feature. So, you can have your Counter transformers in series to generate the geodb_rel_origin_oid & geodb_rel_destination_oid - send that to the relation class. Then rename geodb_rel_origin_oid & geodb_rel_destination_oid as geodb_oid for the Transformer (origin) and TransformerUnit (destination)

This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.

6 replies

M
Forum|alt.badge.img+2
  • markatsafe
  • 1891 replies
  • February 17, 2022

@timboberoosky​ I don't think you need the actual OBJECTID. I think you can set temporary values for geodb_oid and FME should sort out the actual objectid's. You just need to ensure that the geodb_oid's values are the same on both sides of the relationship so they can be linked.

timboberoosky
Contributor
Forum|alt.badge.img+7
  • timboberooskyContributor
  • Author
  • Contributor
  • 50 replies
  • February 17, 2022

@timboberoosky​ I don't think you need the actual OBJECTID. I think you can set temporary values for geodb_oid and FME should sort out the actual objectid's. You just need to ensure that the geodb_oid's values are the same on both sides of the relationship so they can be linked.

Thanks @Mark Stoakes​ 

I must still be missing something then. I simplified my workspace just to see if I could get the relationships working, and I'm constantly getting the error "Missing required attribute 'geodb_rel_destination_oid' for writing relationship. Please specify this attribute on all relationship features to be written". However, I have both my geodb_rel_origin_oid and geodb_rel_destination_oid attributes set on appropriate features, as can be seen on the Table Preview of the features being written to the relationship class - see below. Note that I'm breaking up 1 source feature into 2 streams, writing 1 to the origin feature class and the other to the destination table, and I created IDs for each using Counter transformers. Is there something I'm obviously missing? The datasets are large so I didn't want to upload them, but could try to do so if that would help.

Thanks again.

 

2022-02-17_14-57-35 

M
Forum|alt.badge.img+2
  • markatsafe
  • 1891 replies
  • Best Answer
  • February 17, 2022

@timboberoosky​ If you look at the feature counts, you're creating two relationship features, when you only should have one for each pair of origin/destination features. Normally, you have to merge the origin and destination features to create the relationship since they might be coming from two source features.

 

But...in your case, both the origin & destination feature originate from a single source Transformer feature. So, you can have your Counter transformers in series to generate the geodb_rel_origin_oid & geodb_rel_destination_oid - send that to the relation class. Then rename geodb_rel_origin_oid & geodb_rel_destination_oid as geodb_oid for the Transformer (origin) and TransformerUnit (destination)

timboberoosky
Contributor
Forum|alt.badge.img+7
  • timboberooskyContributor
  • Author
  • Contributor
  • 50 replies
  • February 17, 2022

@timboberoosky​ If you look at the feature counts, you're creating two relationship features, when you only should have one for each pair of origin/destination features. Normally, you have to merge the origin and destination features to create the relationship since they might be coming from two source features.

 

But...in your case, both the origin & destination feature originate from a single source Transformer feature. So, you can have your Counter transformers in series to generate the geodb_rel_origin_oid & geodb_rel_destination_oid - send that to the relation class. Then rename geodb_rel_origin_oid & geodb_rel_destination_oid as geodb_oid for the Transformer (origin) and TransformerUnit (destination)

Thanks @Mark Stoakes​ . Re-routed the workflow and wrote only one record to the relationship class and everything worked perfectly. Attaching screenshot below for reference. Thanks again!

2022-02-17_16-32-34

timboberoosky
Contributor
Forum|alt.badge.img+7
  • timboberooskyContributor
  • Author
  • Contributor
  • 50 replies
  • February 18, 2022

@timboberoosky​ If you look at the feature counts, you're creating two relationship features, when you only should have one for each pair of origin/destination features. Normally, you have to merge the origin and destination features to create the relationship since they might be coming from two source features.

 

But...in your case, both the origin & destination feature originate from a single source Transformer feature. So, you can have your Counter transformers in series to generate the geodb_rel_origin_oid & geodb_rel_destination_oid - send that to the relation class. Then rename geodb_rel_origin_oid & geodb_rel_destination_oid as geodb_oid for the Transformer (origin) and TransformerUnit (destination)

Hi again @Mark Stoakes​ 

I'm not sure if this deserves a new thread, and sorry for the lengthy explanation but it's a related a follow up where I'm adding some complexity to this relationship workflow. So, I'm wondering if it's possible to write to multiple relationship classes using the same feature as both primary and foreign keys for one and the other. So, the 1 Transformer source feature is creating 3 destination features: 1 Transformer feature, 1 TransformerUnit feature and 1 SurfaceStructure feature. The transformer feature in the example above is the primary key (geodb_rel_origin_oid) for one relationship (Transformer_TransformUnit that we already solved) as well as the foreign key (geodb_rel_destination_oid) for another relationship I've introduced (SurfStruct_Transformer). I could duplicate the stream to create the geodb_rel_origin_oid for the SurfaceStructure side of the SurfStruct_Transformer relationship, but the Transformer feature is already the geodb_rel_origin_oid for the other Transformer_TransformUnit relationship and needs to be the geodb_rel_destination_oid for the SurfStruct_Transformer relationship.

Does this make sense? I've tried to build what I mean in the screenshot below, but unsurprisingly it throws an error not being able to find the relationship feature from Transformer for the SurfStruct_Transformer relationship (I tried to exemplify this by making the geodb_rel_origin_oid and geodb_rel_destination_oid - both set by the count transformer not be the same number, i.e. starting 1 counter at 1 and the other counter at 2).

 

2022-02-18_15-20-16Also unsurprisingly, if I rename the geodb_rel_origin_oid and geodb_rel_destination_oid BOTH to geodb_oid on the Transformer feature being written, I get an "invalid foreign key value" error.

 

2022-02-18_15-25-50Any thoughts or help on this type of intermingled relationship writing would be greatly appreciated!

Thanks

M
Forum|alt.badge.img+2
  • markatsafe
  • 1891 replies
  • February 24, 2022

@timboberoosky​ I thin I was successful in creating two related tables for a single feature class. I've attached my workspace - FME 2021.2.

But... in your image, it looks like you have reversed your relationship to that SurfaceStructure is the origin (parent). That would mean you'd have to have a origin (foreign key on the Transformer feature class for the SurfaceStructure. I think that might be harder to do.

If you want to modify the attached File geodb template to match the relationships you have then I can take another look.

Community Stats

32,070
Posts
121,770
Replies
39,694
Members

Latest FME

Terms & ConditionsCookie settingsAccessibility statement
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.