Skip to main content

Hi,

I've tried to facilitate using the SpatialRelator with the "Input Ordered" set to "By group". And set the "Group By" value to a common attribute.

I sorted both my Requester and Supplier inputs by the same value. But even though the log file shows the expected groups, all groups have no matches (typically "0 BASE(s)").

Please advise as to how this functionality is supposed to work.

I got the process running by setting "Input Ordered" to "no" (keeping the "Group By"), but I think that this is not as efficient.

Cheers.

group by will only relate objects with common group value. (as you prob know)

Ordered for spatial relaling requires some work i believe. Sorting is not always sufficient to do so.

Maybe use a tiler to create groups based on tile id.

Then postproces boundary objects.


In my quick test, the SpatialRelator with the Input Ordered By Group option worked fine in FME 2017.1.

The option is available only when it's guaranteed that both Requestor and Supplier features would be input in the order by the value of attribute(s) set to the Group By parameter. Firstly make sure that the order of input features is correct.

If you still couldn't get expected result even though the order of the features was correct, post your workspace and minimal dataset that reproduce the issue, or contact Safe support.


In my quick test, the SpatialRelator with the Input Ordered By Group option worked fine in FME 2017.1.

The option is available only when it's guaranteed that both Requestor and Supplier features would be input in the order by the value of attribute(s) set to the Group By parameter. Firstly make sure that the order of input features is correct.

If you still couldn't get expected result even though the order of the features was correct, post your workspace and minimal dataset that reproduce the issue, or contact Safe support.

I've made a trimmed down workspace, and saved it as a template, with input data and a BAT I use to run the (edited) FME file (see my other post about a bug in FMW-to-FME).

 

I've added a user parameter to enable switching the "Input Ordered" setting on and off at the command line. Notice the difference between the two runs, the former produces no final output.

 

Unfortunately there's a limit of 3 Mb for attachments, and the template file is 4.2 Mb, so here's a link to it in my personal Dropbox: get the file

In my quick test, the SpatialRelator with the Input Ordered By Group option worked fine in FME 2017.1.

The option is available only when it's guaranteed that both Requestor and Supplier features would be input in the order by the value of attribute(s) set to the Group By parameter. Firstly make sure that the order of input features is correct.

If you still couldn't get expected result even though the order of the features was correct, post your workspace and minimal dataset that reproduce the issue, or contact Safe support.

Here's a screen dump of running the BAT:

 


group by will only relate objects with common group value. (as you prob know)

Ordered for spatial relaling requires some work i believe. Sorting is not always sufficient to do so.

Maybe use a tiler to create groups based on tile id.

Then postproces boundary objects.

Hi gio.

 

It's of course the same workspace I'm struggling with, and as I said in my other post about performance, tiling is really not a viable option here. Except maybe as aggregating the smaller polygons (municipalities) into larger ones (regions). Unfortunately, this doesn't seem to help much without the "Input Ordered" working properly.

 

Yes, I am aware that both data sources needs to be sorted identically, but they _are_. Please see my response to Takashi's reply above, and verify the template that data are being sorted, but still doesn't work.

 

 


In my quick test, the SpatialRelator with the Input Ordered By Group option worked fine in FME 2017.1.

The option is available only when it's guaranteed that both Requestor and Supplier features would be input in the order by the value of attribute(s) set to the Group By parameter. Firstly make sure that the order of input features is correct.

If you still couldn't get expected result even though the order of the features was correct, post your workspace and minimal dataset that reproduce the issue, or contact Safe support.

Probably you have to input Requestor features and Supplier features belonging to the same group consecutively to the SpatialRelator if you use the Input Ordered By Group option.

 

I modified your workspace. See the attached workspace (without the source datasets).

 

spatialrelator-with-input-ordered.fmw (FME 2017.1.0.0)

 


group by will only relate objects with common group value. (as you prob know)

Ordered for spatial relaling requires some work i believe. Sorting is not always sufficient to do so.

Maybe use a tiler to create groups based on tile id.

Then postproces boundary objects.

Hi gio.

 

Well, I reconsidered your grid suggestion, and found a way to utilize it. I first created a grid of 1 km cells, and sorted out all cells uniquely within a single municipality. I then preemptively matched my features with these grid cells, only performing the "expensive" matching on municipality polygons with the features not entirely within these grid cells. It seems that about 2/3 can be sorted this way.

 

I'm running my two 5 million+ feature sets with this improved workflow (which crashed before), hoping it'll speed up things. I'll let y'all know how it went.

 

Cheers

 


Probably you have to input Requestor features and Supplier features belonging to the same group consecutively to the SpatialRelator if you use the Input Ordered By Group option.

 

I modified your workspace. See the attached workspace (without the source datasets).

 

spatialrelator-with-input-ordered.fmw (FME 2017.1.0.0)

 

@takashi is correct -- the INPUT IS ORDERED requires that ALL features with the same group come in order. So you need to sort them in one stream, then separate out into the base/candidate thereafter (as he did in the workspace he attached above). This is a good observation that I'll alert our doc team to.

 


@takashi is correct -- the INPUT IS ORDERED requires that ALL features with the same group come in order. So you need to sort them in one stream, then separate out into the base/candidate thereafter (as he did in the workspace he attached above). This is a good observation that I'll alert our doc team to.

 

See PR#73951 - I think we've already looked at this (at least for the PointOnAreaOverlayer)

 

 


Reply