Question

conditional execution of densifying

  • 10 December 2013
  • 4 replies
  • 1 view
jelle
Rank
Badge +11
Hi FME'ers, 

 

 

I have some base features, and candidate features from another data set, sent through the SpatialRelator (Equal, Within). 

 

 

For the base features that failed these spatial relations, I do a Densification. Together with a densification of the candidate features, I send the features through the anchored snapper, with which I can improve my results with a second SpatialRelator.

 

 

However, sometimes the first SpatialRelator has no features in the failed port (all the objects have been found). In this case, I don't want to carry out the Densification because there won't be any candidate feature for the AnchoredSnapper. This extra processing time is not necessary.

 

 

How can I start the densification ONLY if there are features in the Failed Output port of the SpatialRelator? I tried to solve this with a variable, but it didn't work out. Or should I try harder? The only use case I found, was http://fmepedia.safe.com/articles/How_To/Get-the-Start-Count-for-the-Counter-from-a-different-dataset It is stressed that the order of reading the data sets is important. I tried with Feature Holders, but to no avail. Any suggestions?

 

 

 

best regards, 

 

Jelle

 

 

4 replies

david_r
Rank
Userlevel 4
Hi,

 

 

I think the order of the reading of the datasets refer to the order of the readers in the Navigator pane, not the FeatureHolder. Did you try to re-arrange them there?

 

 

Another option could be to set an attribute, e.g. SOURCE that indicates whether a feature is a base or candidate feature. You can then merge all the data into one flow and process them collectively. You can then either do a Group By on the SOURCE or a Tester to separate them into base and candidate features again.

 

 

David

 

 

jelle
Rank
Badge +11
Hi David, 

 

 

thank you for the answer.

 

 

Yes, the base features are being read first. The second reader is a CSV file, which provides information for the SQLExecutor to read the Candidates. The feature holder was just a long shot.

 

 

Your suggestion crossed my mind, but I thought it was cumbersome and that there must be a way through variables.

 

However, it would solve my problem indeed. Pragmatic as I am, I'll build it in. Thanks for the tip!

 

 

 

best regards, 

 

Jelle

 

 

takashi
Rank
Userlevel 2
Badge +17
Hi Jelle,

 

 

Just an idea. Try using a FeatureMerger for unconditional merging. Send the candidate features to REQUESTOR, send the failed base features to SUPPLIER port. Specify a constant value (e.g. "1") to "Join On" for both Requestor and Supplier. MERGED features (i.e. candidates) will be output only when there is one or more failed base features.

 

 

Takashi
jelle
Rank
Badge +11
Hi Takashi, 

 

 

that is another good option indeed. It avoids having to separate afterwards with a tester. Because of visualisation reasons, I use a cloner. For the first time in my FME career (I think), I have used the CopyNumberAttribute (as join attributes for the FeatureMerger).

 

 

Thank you! It looks good like this.

 

 

 

best regards, 

 

Jelle

Reply


Community Stats

28,716
Posts
109,495
Replies
36,561
Members
Terms & ConditionsCookie settings
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.