-
Notifications
You must be signed in to change notification settings - Fork 346
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong scale in vector attributes +z[scale] #7039
Comments
Also don't understand why I have to apply a scale factor when the fig scale is not 1:1
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
|
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. |
Yes, but not only that. Why in second plot I had to use |
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). |
BTW, I find that q in docs very confusing
Wat is q? The actual q char or does it mean any of the c, i, etc? The the last example?
It's hopelessly wrong when x & y are not isometric. |
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. |
q is no unit so after this, it's confusing. You mean |
yes, so should be bold. We do the same for bars with a width given in data units. |
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. |
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:
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. |
Agree with this, @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. |
And, we can set a scale with +z[scale] but not if direction and magnitude are passed in? |
On a second thought, q should really be the default and hence no need to specify it. I have not much experience with |
See #7039 for discussion. The coding of modifier +z was expecting plot units but that makes no sense. This PR checks that either no unit or q is applied and errors otherwise.
This plots a vector with the correct length
but this not (seems divided by 2.54). Note the +z1 instead of +z
The text was updated successfully, but these errors were encountered: