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.

---

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.

Hi @MarkAtSafe, thanks for filing the PR. Could you please post a comment or an answer to the original thread?

 

NeighborFinder: Try to get elevation but get this error: IFMELine was given an index beyond its current range

 

---