Have you looked at the snipper transformer? You can use the measures within this
Thank you @egomm! I have just found the Snipper and from what I see it's the perfect transformer for this. I'm just not quite sure which setting would be more suitable: Measure (Relative to Start Point) or Measure (Value). My measures which I created with the MeasureGenerator were multiplied by a factor to get the appropriate length (if thats of any help).
If you send your line features to the Inspector you can see the measure values next to the coordinates, which I personally find very helpful when debugging LRS features. If you have applied a factor to your measures, you will of course also have to take that into account in your start and end location values (publicWFS_vst / publicWFS_bst).
You should probably use "Measure (value)" in your case. The different modes are explained in the help.
Thank you @david_r! I was wondering because the number of lines
was smaller in the output port of the Snipper than before. Aren't
there supposed be more or at least the same number of lines in the output compared to the input, when they are
"snipped"?
Thank you @david_r! I was wondering because the number of lines
was smaller in the output port of the Snipper than before. Aren't
there supposed be more or at least the same number of lines in the output compared to the input, when they are
"snipped"?
It's difficult to tell without knowing the details of your data and your workspace. Do you by any chance have aggregate features entering the Snipper? They will not be processed and will exit the <Rejected> port.
I would suggest isolating a single input object where this happens and sending the before and after to the Inspector for analysis.
It's difficult to tell without knowing the details of your data and your workspace. Do you by any chance have aggregate features entering the Snipper? They will not be processed and will exit the <Rejected> port.
I would suggest isolating a single input object where this happens and sending the before and after to the Inspector for analysis.
I'm trying to figure it out with a subset of the data. In the log file it says for example:
@Snip (or FMELine::snip) was given Measures of 1468 and 1974, which are out of range for a line with min/max measures of 0 and 1974. Snapping params to closest valid value.
The first measure for this line at coordinate zero is:
Coordinate 0: 333098.47953629337, 5623070.8301944714
Measures:
<default_measure> = 0.0
And the last one:
Coordinate 135: 334772.80646645062, 5624034.9839437641
Measures:
<default_measure> = 1973.9999999999952
Although these are only little difference, perhaps one could round the measures, so that it fully matches with the values in the attribute? Anyone know if that's possible?
I'm trying to figure it out with a subset of the data. In the log file it says for example:
@Snip (or FMELine::snip) was given Measures of 1468 and 1974, which are out of range for a line with min/max measures of 0 and 1974. Snapping params to closest valid value.
The first measure for this line at coordinate zero is:
Coordinate 0: 333098.47953629337, 5623070.8301944714
Measures:
<default_measure> = 0.0
And the last one:
Coordinate 135: 334772.80646645062, 5624034.9839437641
Measures:
<default_measure> = 1973.9999999999952
Although these are only little difference, perhaps one could round the measures, so that it fully matches with the values in the attribute? Anyone know if that's possible?
Rounding errors can be a bit pesky, but it shouldn't really matter in this case. The Snipper will "snap" to the closest valid value by default. So in the example above you should get the line from 0 to 1973.9999999999952 when you ask to snip from 0 to 1974.
Or do you get something else?
Rounding errors can be a bit pesky, but it shouldn't really matter in this case. The Snipper will "snap" to the closest valid value by default. So in the example above you should get the line from 0 to 1973.9999999999952 when you ask to snip from 0 to 1974.
Or do you get something else?
Yes, the line goes to 1974. So the result is correct. I was just wondering because of the numerous warnings regarding this rounding thing in the log file. But I will look further into the data and report back when I find anything.
Hey guys, just to let you know in case someone has a similar problem: the proposed solution with the snipper transformer works perfectly. The rounding messages were just a warning, the result is correct.
