Hi,

 

 

you can use the AttributeCreator to access the altitude of the previous point, that way you won't have to use the FeatureMerger. That ought to help with performances:

 

 

 

 

(The above assumes the altitude is stored as an attribute, but you can extract it from your 3D point into an attribute using a CoordinateExtractor, if necessary)

 

 

David

---

if you sort by heigth, then it is dependent on the merging you do.

 

 

On what are you merging these points? What is the ordering, if height is the only ordering and you merge on your counter, then does it not calculate slopes all over the place? Or is it orderd by some area conatinig a constant slope?

---

Hi D,

 

 

I agree that the AttributeCreator is effective.

 

 

If your final goal is to get the inclination angle between adjoining 2 points, this expression may be helpful. Assuming that (x, y, z) have been extracted with a CoordinateExtractor beforehand.

 

-----

 

@atan2(@Value(_z)-@Value(featuree-1]._z),@hypot(@Value(_x)-@Value(featuree-1]._x),@Value(_y)-@Value(featuree-1]._y)))

 

-----

 

 

Unit of the result is radians. If you need to convert the unit to degrees, you can use @radToDeg function in FME 2015. If you are using FME 2014, multiply the result by "180/3.141592653598793".

 

 

The result for the first point is invalid since it has no previous point, and FME maybe log warnings. So, I would set "Use Attribute Value of Closest Feature" to the "If Attribute is Missing, Null, or Empty" parameter, so that the result for the first point will always be 0 (@atan2(0/0) = 0), and the warnings disappear.

 

 

Takashi

---

correction for a type:

 

@atan2(0,0)=0

---

I assumed from the post that not the actual basicschool math of calculating a slope between points is the problem.

 

More the linking of points to do so.

 

 

I fail see the use of ordering the points based on height, would that not mess up the intent? They would not nescessarily be neighbours after sorting unless the slope is constant.

 

Or is the intent to actualy find the slope between all points? (then ordering does not mater, but you stil owuld have to find neighbors).

 

 

I would assume that finding every 1st neighbour in every direction of every point is what needs to be done first. Or if u have profile lines and need to it only do it in one direction.

 

 

The calculation itself is very simple.

 

 

---

Thanks for all the great answers

 

 

@David R

 

I think this is exactly what I was looking for, as my process takes the count, and subtracts 1 from the count, than uses feature merger to get previous attribute based on the new count joined to the old count. I was unaware I could set it to a previous attribute, so this is perfect

 

 

@Gio

 

I sort by pipeline segment key, than sort by distance along which the points fall on that segment. than I use count minus 1 and join it back to get previous attribute

 

 

@Takashi

 

Attribute Creator looks to be the best way to do this, I am currently using 2014 on the client machine and 2015 on my local, I am just converting rad to degress via 180*pi (It would be nice if FME had a symbol for pi), good call on the first attribute, as for the start of every segment, the inclination will be zero.

 

 

@Gio

 

Agreed, calculating angles is very elementary, and the question was to see if there was a better way to get the previous attribute rather than my current process. In TSQL I use the LAG function, but here I will just use PreviousElevation = 

 

@Value(feature@-1]._z)

---

Thanks Again Everyone!! this was the solution for getting previous and next elevation.

 

 

 

---

@pi() function has been added in FME 2015. It returns the pi. FYI

---