I think the error reported in this question is caused by a defect in the NeighborFinder.
This workspace reproduces the same situation. Could you please check this?
(FME 2017.1.2)
This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
- 7843 replies
I don't know which option is the best for other users, but I personally think that "Use the value of the end point" seems to fit to "finding neighbor" conceptually, in both Continuous and Discrete.
The issue is the current behavior is different between the start node side and the end node side.In the example above, the leftmost point took Measure/Z from the first vertex of the candidate line, even though its perpendicular line apparently doesn't cross the candidate line. That is, the current NeighborFinder follows "Use the value of the end point" approach already for the start node side. If you reverse orientation of the candidate line, the "nan" appears in the leftmost point, but the rightmost point will take Measure/Z from the closest vertex of the candidate line.I think the behavior should be consistent between the both sides.
- 7843 replies
I don't know which option is the best for other users, but I personally think that "Use the value of the end point" seems to fit to "finding neighbor" conceptually, in both Continuous and Discrete.
The issue is the current behavior is different between the start node side and the end node side.In the example above, the leftmost point took Measure/Z from the first vertex of the candidate line, even though its perpendicular line apparently doesn't cross the candidate line. That is, the current NeighborFinder follows "Use the value of the end point" approach already for the start node side. If you reverse orientation of the candidate line, the "nan" appears in the leftmost point, but the rightmost point will take Measure/Z from the closest vertex of the candidate line.I think the behavior should be consistent between the both sides.
NeighborFinder: Try to get elevation but get this error: IFMELine was given an index beyond its current range