using
gmt 6.2dev8on linux, the most up-to-date version currently available fromconda-forge.
Hi,
This post is more of a comment than a software issue per se. I don’t know if it really has its place here or on the forum. At any rate…
I spent quite some time yesterday trying to “properly” scale arrows for wind maps using grdvector.
The conclusion from the screed to come is :
A. The back and forth between units is too tedious (cm on paper, km as well as degrees on map, data units, …)
B. There should be an option to scale -Q+n in data units
C. The legend for arrows is too tedious (maybe an automatic something with +n too?)
D. Need of a more concrete gallery example using grdvector (glacier flow in greenland?).
My goals were :
- plot two distincts regions on two different plots but where 1cm on paper equals the same distance on both maps
- map 1 : +/- 30N over 80 degrees longitude
- map 2 : +/- 30N over 170 degrees longitude
- scale the arrows so 1 data unit corresponds roughly to the data resolution (ie wind of 1 m/s ~= 0.25 degrees)
- further scale the arrows so values smaller than 10 m/s are scaled down (for aesthetic)
- plot a legend with a 10m/s reference
First difficulty : pen sizes
The arrow’s pen and head (-W and -Q) are scales with the map.
In my case as one map is wider than the other (see point (1)),-W0.1c and -Q0.01c have two different aspect on each map.
resolution : calculate the aspect ratio between the two maps and apply the resulting values.
# basin_rat = 170/80
# map_cm = paper height in cm
# 2, 0.25 and 18 result from tuning for aesthetic.
v_pen=$(echo "scale=3;$basin_rat * 2/(($lonE-$lonW)/$map_cm/0.25) ;"|bc) # Arrow pen thickness (in cm)
v_head=$(echo "scale=3;$basin_rat * 360/($lonE-$lonW)/18;"|bc) # Arrow head size (in cm)
Second difficulty : scaling
After working around the -S option for a while (see point (2)), I finally scaled correctly my arrow with:
v_scale=$(echo "scale=3; 0.25 * 111.132954 ;"|bc) # Wind vector scaling (1m/s = 0.25deg = 27.783km)
-Si${v_scale}k
My real problem resides in point (3), when I wanted to scale down the arrows smaller than 10m/s using the -Q+n option. At first I had scaled my arrow with -S instead of -Si, so it was not obvious to me that I needed to give -Q+n in the same unit as the latter (km).
In my opinion, even if explicitly mentioned by the documentation, more examples should be provided (in the gallery maybe?).
# here I want a scaling under 10 m/s
gmt grdvector tmp_u.nc tmp_v.nc -Gblack -W${v_pen}c,black -Si${v_scale}k -Q${v_head}c+e+a45+jc+n$(echo "scale=3; $v_scale * 10;"|bc)k
- Subsequent question 1 : If I understand the documentation correctly, using -Q+n1 has no effect ? What happens when dealing with small regions ?
- Subsequent question 2 : the
-Q+n<value in km>option scales down arrows smaller than . Shouldn’t it scales up arrows greater ?
Last difficulty (bug?) : legend
Dealing with legends and scaled arrow is a headache. There must be a simpler way.
Potential bug? : If I plot the head of the arrow, the tail partially disappears (there seems to be an overlap). The resulting aspect thus differs greatly from the arrows plotted on the map.
gmt legend -DjTR+w2c+o-5p/2p -F+r4p+pthinnest,gray+gwhite --FONT_ANNOT_PRIMARY=8p <<- END
S - - $(echo "scale=3; $basin_rat * 10 * ${v_scale}/111.132954 * ${map_cm}/(${lonE}-${lonW});"|bc)c black ${v_pen}c - 10m.s@+-1@+
END
Note on block width: I don’t really remember why I resorted to give a manual value. I guess I was just tired at some point… but automatic width exists right?*
The result :
