Hello @jennychu, are you able to share a copy of your workspace and the FME Form vesion it was created in? It might aslo be helpful if you’re able to share the source/input dataset. Happy to help, Kailin.

Hello @kailinatsafe Thank you very much for your reply.

Yes, in the attachment, you can find the workspace, demo dataset, and citygml 3 schemas. I want to insert some new generics attributes in the trafficArea with function =7. But after the transformations, the geometry disappears, and the gml_parent_id setting seems incorrect either. I must have missed something, but I don’t know where.

the FME workbench version is v2023.1, I checked with v2022.2 as well.

best regards,

Jenny

Hello @kailinatsafe I wish you all good. Could you have a look at the demo workspace and give me some advice?

I assume the reason might be that I didn’t match the gml_id and gml_oarent_id in a correct way.

I just use the FeatureMerge with 1 -1. But I found it couldn’t map them. Do you know how to connect the various gml and gml_parent? 

Thank you very much for the assistance!

Best regards,

Jenny

Hello @jennychu, many apologies, I was away last week. I’ll download the sample today and try my best to reach out in the next few days. I appreciate your patience, Kailin.

hello @kailinatsafe thank you for following up! it means a lot.

Jenny

Hello @jennychu, thanks again for your patience! The 6 orphaned (TrafficArea) features in the output gml allude to missing parent features.

The missing parent features belong to the TrafficSpace reader feature type, which are being filtered out at AttributeFilter_2. To resolve the orphaned features in the output, we need to re-route these 6 parent features to the appropriate writer feature type! Hope this helps, Kailin.

hello @kailinatsafe I thought I re-create the new TrafficSpace gml_id in “AttributeFIlter”. Cause I re-organized geometry of the TrafficArea with function =7, and they need the new parent features (in TrafficSpace).

Another 2 further questions:

1. How could I map the gml_id with gml_parent_id correctly? since I tried to use the FeatureMerge with 1 -1. But I found it couldn’t map them. 
2. why is there no geometry in TrafficArea? Is the reason still relevant to the orphaned issues?

Jenny

@kailinatsafe I don’t know if I missed some points or understood wrong in some places.

I am very new to CItyGML 3.0

Thank you very much for the help! (sorry my last message was sent before I finished editing it.)

Hello @jennychu, no worries at all, more than happy to help out! You are correct, you will not see any geometries for the orphaned features until they are mapped properly.

Are you expecting the FeatureMerger_6 to assign / join the parent_gml_id from the Section reader feature type? If so you might want to change the ‘Conflict Resolution’ parameter in FeatureMerger to favor the Supplier (eg. Section). If this is not the goal, can you explain why we merge Section with TrafficSpace?

Ultimately we have 2 options:

1. route the missing parents from the AttributeFilter_2 to the TrafficSpace writer feature type, or
2. remap the orphaned child TrafficArea features to a valid parent feature that is being written to TrafficSpace

For a very basic example / explanation, I was able to resolve the orphaned features by connecting the <7> output port of the AttributeFilter_2 to the following junction. This writes valid parent features and produces the TrafficArea geometry correctly in the output. Note - this does send extra features to the writer so you might want to refine what's being routed (eg. there may be more optimal solutions).

I know this is a bit tricky to understand so please take your time! All the best, Kailin.

Hello @jennychu, no worries at all, more than happy to help out! You are correct, you will not see any geometries for the orphaned features until they are mapped properly.

Are you expecting the FeatureMerger_6 to assign / join the parent_gml_id from the Section reader feature type? If so you might want to change the ‘Conflict Resolution’ parameter in FeatureMerger to favor the Supplier (eg. Section). If this is not the goal, can you explain why we merge Section with TrafficSpace?

Ultimately we have 2 options:

1. route the missing parents from the AttributeFilter_2 to the TrafficSpace writer feature type, or
2. remap the orphaned child TrafficArea features to a valid parent feature that is being written to TrafficSpace

For a very basic example / explanation, I was able to resolve the orphaned features by connecting the <7> output port of the AttributeFilter_2 to the following junction. This writes valid parent features and produces the TrafficArea geometry correctly in the output. Note - this does send extra features to the writer so you might want to refine what's being routed (eg. there may be more optimal solutions).

I know this is a bit tricky to understand so please take your time! All the best, Kailin.

 

 

 

hello @kailinatsafe thank you so much for the further explanation. 

Yes, I expect 1. the merge between Section and TrafficSpace (parent&child relation) in FeautureMerge_6 and 2. the merge between TrafficSpace and TrafficArea (parent&child relation) in FeautureMerge_1. 

And I actually tried to use the option 2 to solve this. So after I did some operations with TrafficArea with function=7, I tried to use these new TrafficArea features to create the new TrafficSpace (see the bookmark named “parking slot trafficSpace”). But might my way was not correct?

Do you have any suggestions regarding the creation of valid parent features in TrafficSpace?

Thanks again for your time.

Jenny