Feature request #20665

patch: better documentation for inconsistent behaviour of x_at (and y_at)

Added by Alister Hood almost 2 years ago. Updated almost 2 years ago.

Status:Closed
Priority:Normal
Assignee:Yves Jacolin
Category:Documentation and Help
Pull Request or Patch supplied:Yes Resolution:
Easy fix?:Yes Copied to github as #:28485

Description

$x_at(i) and $y_at(i) return the coordinates of a vertex. The help in the expression dialog explains that i is the index of a point of a line, starting at 0; negative values applying from the last index.

I wanted to get the coordinates at the end of a line, so I tried using $x_at(-0), but it returned the coordinates at the start of the line, presumably because -0=0. I therefore assumed it is impossible to get the coordinates at the end of the line, so I reversed all the lines in my layer, extracted the coordinates of the start points to attribute fields, and then reversed them again. Someone else might instead get wrong results by trying to get coordinates of e.g. the second to last point by using -1.

I've now found that what I did was unnecessary, because the negative indices simply start at -1. In my opinion this is unnecessarily inconsistent (if it is not technically possible for negative indices to start at -0, then positive indices should start at 1 instead of 0). But I guess it is too late to change this behaviour, in which case I propose documenting it properly - see patch attached.

x_at_y_at.patch Magnifier (786 Bytes) Alister Hood, 2018-11-29 06:56 AM

History

#1 Updated by Nyall Dawson almost 2 years ago

  • Status changed from Open to Feedback

It's modelled off the approach Python uses -- they also use 0 based indices in the ascending direction, and -1 to refer to the last element in an array.

But the documentation improvement is very welcome. Can you file this as a PR on github so that we can merge?

#3 Updated by Luigi Pirelli almost 2 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF