Skip to main content

Dear expert of Dynamic Segmentation:

I was using LineOnLineOverlayer for Dynamic Segmentation purpose, but it was giving me wrong attribute information. I've got 2 segments or event layers here, all with geometry:

The ideal result I was looking for is:

But the result generated by LineOnLineOverlayer is:

Looking at the result in FME Inspector, the geometries of the 3 segments are at the right place, just the attributes are all messed up, specifically 1st and 2nd row. I didn't find too much information about using FME for linear referencing stuff, so I have to turn to this forum.

I hope gio and takashi or anybody with previous experience could provide some insights on this. Much appreciated. Thanks!

@gio

@takashi aand

 

The reason is that the LineonLineOverlayer does not overwrite existing attributes.

I would prefix attributes from both sources and the combine the two (maximum from and minimum to) to get the right values.

If the attribute exists on both sources one of the two (kind of random) will be used.


Hi @jonathanchiang0, I think this workflow works for you if the values of "from" and "to" are consistent with (i.e. equal to or in proportion to) the actual measure values of the line vertices.

  1. MeasureSetter x 2: Set the "from" and "to" values to measures of start/end vertex for each line.
  2. MeasureInterpolator (from FME Hub): Generate measures of other vertices.
  3. LineOnLineOverlayer: Perform segmentation.
  4. MeasureExtractor x 2: Extract the measure values of start/end vertex as new "from" and "to" for each segment.


As mentioned above the transformer does not overwrite attributes by default, see the image below for the attribute accumulation settings and List generation (list elements cannot be viewed in the table view of the Data Inspector, but only in the Feature Information Window)


The reason is that the LineonLineOverlayer does not overwrite existing attributes.

I would prefix attributes from both sources and the combine the two (maximum from and minimum to) to get the right values.

If the attribute exists on both sources one of the two (kind of random) will be used.

Thank you for the reply. LineonLineOverlayer worked, after a little tweaking with parameters and other transformers. But what about scalability? I was testing with 3 event layers containing half a million records. The process ran for 18 hours before I stopped it this morning. And I have 36 layers ...

 

 


Hi @jonathanchiang0, I think this workflow works for you if the values of "from" and "to" are consistent with (i.e. equal to or in proportion to) the actual measure values of the line vertices.

  1. MeasureSetter x 2: Set the "from" and "to" values to measures of start/end vertex for each line.
  2. MeasureInterpolator (from FME Hub): Generate measures of other vertices.
  3. LineOnLineOverlayer: Perform segmentation.
  4. MeasureExtractor x 2: Extract the measure values of start/end vertex as new "from" and "to" for each segment.

Thank you for the reply. LineonLineOverlayer worked, after a little tweaking with parameters and other transformers. But what about scalability? I was testing with 3 event layers containing half a million records. The process ran for 18 hours before I stopped it this morning. And I have 36 layers ...

 

 


As mentioned above the transformer does not overwrite attributes by default, see the image below for the attribute accumulation settings and List generation (list elements cannot be viewed in the table view of the Data Inspector, but only in the Feature Information Window)

Thank you for the reply. LineonLineOverlayer worked, after a little tweaking with parameters and other transformers. But what about scalability? I was testing with 3 event layers containing half a million records. The process ran for 18 hours before I stopped it this morning. And I have 36 layers ...

 


Thank you for the reply. LineonLineOverlayer worked, after a little tweaking with parameters and other transformers. But what about scalability? I was testing with 3 event layers containing half a million records. The process ran for 18 hours before I stopped it this morning. And I have 36 layers ...

 

 

If "id" and/or "streetname" can be used to group the segments for the same road, try setting the attribute(s) to the Group By parameter of the LineOnLineOverlayer.

 


Thank you for the reply. LineonLineOverlayer worked, after a little tweaking with parameters and other transformers. But what about scalability? I was testing with 3 event layers containing half a million records. The process ran for 18 hours before I stopped it this morning. And I have 36 layers ...

 

I would segment the data by tiling it and use the parallel processing capabilities of the transformer, dont forget to set the group by setting (otherwise the parallel processing wont work)

 

 


Thank you for the reply. LineonLineOverlayer worked, after a little tweaking with parameters and other transformers. But what about scalability? I was testing with 3 event layers containing half a million records. The process ran for 18 hours before I stopped it this morning. And I have 36 layers ...

 

 

Could you use the Group by on the LineomLineOverlayer and for example set it to the streetname?

 

That way you could use the parallel processing and get a faster result.

 

You will find transformer information here

 

 


As mentioned above the transformer does not overwrite attributes by default, see the image below for the attribute accumulation settings and List generation (list elements cannot be viewed in the table view of the Data Inspector, but only in the Feature Information Window)

@jonathanchiang0 Did you ever find a scalable method?

 


As mentioned above the transformer does not overwrite attributes by default, see the image below for the attribute accumulation settings and List generation (list elements cannot be viewed in the table view of the Data Inspector, but only in the Feature Information Window)

if you have different width (I suppose that the width of street), did you recalculate the width between 33.33 and 66.67? Or how we can recalculte the width?

 

 


Reply