Wrong scale in vector attributes +z[scale]

[joa-quim]

This plots a vector with the correct length

echo 0 0 5 5 | gmt plot -Sv0.5+e+z -R0/5/0/5 -Jx1 -Bpa0.5f0.25g0.5 -BWSen -png lixo

but this not (seems divided by 2.54). Note the +z1 instead of +z

echo 0 0 5 5 | gmt plot -Sv0.5+e+z1 -R0/5/0/5 -Jx1 -Bpa0.5f0.25g0.5 -BWSen -png lixo

[joa-quim]

Also don't understand why I have to apply a scale factor when the fig scale is not 1:1
Again, this is correct (after compensating for the bug effect)

echo 0 0 5 5 | gmt plot -Sv0.5+e+z2i -R0/5/0/7 -Jx2 -Bpa0.5f0.25g0.5 -BWSen -png lixo

but when the x,y scales are not the same, the result is wrong again and here I don't see anything that can be done since +z takes only one scale

echo 0 0 5 5 | gmt plot -Sv0.5+e+z2i -R0/5/0/7 -JX10 -Bpa0.5f0.25g0.5 -BWSen -png lixo

[joa-quim]

In fact, the workaround for now is to use +s instead of +z (no need to change the input because it starts at 0,0)

echo 0 0 5 5 | gmt plot -Sv0.5+e+s -R0/5/0/7 -JX10 -Bpa0.5f0.25g0.5 -BWSen -png lixo

[PaulWessel]

Your first case gives a correct 5,5 vector for me. If I use +z1 then I get a short vector, and I have to use +z1i to get the correct answer. So clearly there is some unit mischief here.

[joa-quim]

Yes, but not only that. Why in second plot I had to use -Sv0.5+e+z2i -Jx2?

[PaulWessel]

Do you intend to mean that the input is in cm or x and y units? If the latter then you need to use the q unit, else they should be seen as cm (barring any unit bug).

[joa-quim]

BTW, I find that q in docs very confusing

Append unit q if input components are given in user quantity units and we will scale to current plot unit for Cartesian vectors

Wat is q? The actual q char or does it mean any of the c, i, etc?

The the last example?

echo 0 0 5 5 | gmt plot -Sv0.5+e+z2i -R0/5/0/7 -JX10 -Bpa0.5f0.25g0.5 -BWSen -png lixo

It's hopelessly wrong when x & y are not isometric.

[PaulWessel]

What is the confusing part? You use q if these are data in km, kg, seconds, Hz, etc and should be scaled given the -J -R to yield cm. If you have vector components given in cm (or inches) then you append that unit to +z.

[joa-quim]

Append unit q

q is no unit so after this, it's confusing. You mean Append character **q**?

[PaulWessel]

yes, so should be bold. We do the same for bars with a width given in data units.

[PaulWessel]

Looking again it says:

Append unit q if input components are given in user quantity units and we will scale to current plot unit for Cartesian vectors...

So already in bold and at least to me, readable. We could bold the q in quantity if you think that helps.

[PaulWessel]

Following up. If you, as in your first examples, use +z1 etc., then you are saying that the input dx, dy are already in plot units (default would be cm, which then is converted internally to inches). You then scale those by 1, which internally was already converted to inches (0.39). That bug is why things are off by 2.54. Seems to me we need to add some checks here:

1. If +z uses q as unit, indicating that dx, dy are in user units (km, kg, plate motion rate in mm/yr, etc.) then +z expects a length scale in current plot units per user unit, with default cm but under the control of PROJ_LENGTH_UNIT. Internally, the product of user data components and this adjusted scale gives length units in inches.
2. If +z does not use q then it means the dx, dy are already in plot units (default is cm unless PROJ_LENGTH_UNIT is set) and we simply scale those by the unit-less scale. Since dx, dy are automatically converted from PROJ_LENGTH_UNIT to inches upon reading, these are further scaled by the dimensionless scale to still yield internal inches.

It seems in no circumstance should a unit be appended to +z other than q. If q is used then the scale is changed from scale per PROJ_LENGTH_UNIT to scale per inch internally, while without q the scale should be left as is since it is dimensionless. The current bug is that without q the dimensionless scale is actually assumed to have dimension cm and thus divides down to 0.39.

[PaulWessel]

Agree with this, @joa-quim ?

[joa-quim]

Yes, seems simpler to explain. Meanwhile I found that the 2.54 factor happens only when data is passed via MATRIX (Julia/MEX speaking). If I pass it via a GMTdataset multi-segment file, then no 2.54 stray scale is taking place.

[joa-quim]

And, we can set a scale with +z[scale] but not if direction and magnitude are passed in?