Skip to main content
Solved

Aggregation nightmare

  • December 12, 2017
  • 6 replies
  • 41 views

oscard
Influencer
Forum|alt.badge.img+21

Good morning!

I've been given a sample of data to create aggregates from them (I have attached that data)

The only attribute of the features is type. I have to build aggregates using features of the same "type".

For example, these lines and point must be an aggregate:

Or these lines and polygon:

I've been messing around with the transformer NeighborhoodAggregator, but I'm incapable of adding the proper settings to make it work for all the types. Looking at the data, I'm not really sure if it is even possible to make it work for all of them.

I've been trying with spatial relationships, but I can't make it work either.

I'm out of ideas. I'm starting to think that I will have to treat every type on its own. In the data sample there are only 4 or 5 types, but in the real deal there will be more than 60.

I need to create the aggregates, because in the database the aggregate will be stored as a point feature.

I'm in need of another point of view, so thanks for any help provided.

FME version: 2017.1.1

Best answer by takashi

In some cases, buffering and dissolving could be effective to group geometries according to their spatial proximity. See also the attached demo.

bufferer-dissolver-spatialfilter.fmwt (FME 2017.1.1.1)

 

View original
Did this help you find an answer to your question?

6 replies

david_r
Celebrity
  • December 12, 2017

Could you not simply use the Aggregator with a Group By on "type"?

Or doesn't that fit with your data?


oscard
Influencer
Forum|alt.badge.img+21
  • Author
  • Influencer
  • December 12, 2017
david_r wrote:

Could you not simply use the Aggregator with a Group By on "type"?

Or doesn't that fit with your data?

Hi!

 

 

No, that doesn't work for us. For example, in that data sample there are 6 features of type 3. Those 6 should be 2 aggregates. Aggreagator only builds one from the six.

 

 


david_r
Celebrity
  • December 12, 2017
oscard wrote:
Hi!

 

 

No, that doesn't work for us. For example, in that data sample there are 6 features of type 3. Those 6 should be 2 aggregates. Aggreagator only builds one from the six.

 

 

What is the criteria for deciding if a feature with type "3" should be part of either aggregate one or two?

oscard
Influencer
Forum|alt.badge.img+21
  • Author
  • Influencer
  • December 12, 2017
david_r wrote:
What is the criteria for deciding if a feature with type "3" should be part of either aggregate one or two?
There is the big problem. The criteria is pure visual.

 

 

Those aggregates will be a point over a map. I have to aggregate the elements that are close to each other or, in some cases, the ones that share vertex points (type 2, for example).

 

 

The real origin are DGN. Those elements should have been cells, but for some reason, they are not and I've been told they are not going to be. But the client wants them to be treated as cells in FME... So I have to aggregate them somehow.

 

 


david_r
Celebrity
  • December 12, 2017

Sounds like you were on the right track with the NeighborhoodAggregator, but you may need to do it in several steps. Perhaps you could take a more iterative approach, first using a small-ish search size and then gently incrementing until you run out of objects.

Maybe look into using a looping custom transformer for this, see e.g. https://knowledge.safe.com/articles/1273/looping-with-blocking-transformers.html


takashi
Evangelist
  • Best Answer
  • December 12, 2017

In some cases, buffering and dissolving could be effective to group geometries according to their spatial proximity. See also the attached demo.

bufferer-dissolver-spatialfilter.fmwt (FME 2017.1.1.1)

 


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings