version5.4.3 PSXY could not plot vector arrows and pens in the desired colours

[JianboLong]

temp.txt
Description of the problem

In using the psxy from version 5.4.3 to plot a 2-D vector arrow map, the arrow and its pen (or tail) can not be set the desired colour at the same time using a CPT (colour) file. In my case, the arrows can be set the desired colours according to the CPT file, if using the plot command without additional colour specification in the flag -W

gmt psxy temp.txt -R-1.1/1.1/-1.5/1.5 -JX5c/7c -Sv0.15c+ea+p-+h0.4 -W0.85p -Ccolourbar.cpt -Baf -Bx+l"X / km" -By+l"Y / km" -BWSne -i0,1,2,3,4 -Vd -P > ${PS_FILE}

but the pens remain black, which is not what I want. If, however, the -W0.85p is modified as -W0.85p+cl, then the pens can be set the desired colours from the CPT file, but the arrows are missing in this case:

gmt psxy temp.txt -R-1.1/1.1/-1.5/1.5 -JX5c/7c -Sv0.15c+ea+p-+h0.4 -W0.85p+cl -Ccolourbar.cpt -Baf -Bx+l"X / km" -By+l"Y / km" -BWSne -i0,1,2,3,4 -Vd -P > ${PS_FILE}

This is not what I expect, according to the descriptions about -W for the programme psxy in the document http://gmt.soest.hawaii.edu/doc/5.4.4/psxy.html

Now I am not sure if there're some bugs in the psxy, or I misunderstood something. Any help would be useful !

Full script that generated the error

gmt makecpt -Crainbow -T-4.5/-1.4/0.2 -Z > colourbar.cpt

gmt psxy temp.txt -R-1.1/1.1/-1.5/1.5 -JX5c/7c  -Sv0.15c+ea+p-+h0.4 -W0.85p+cl -Ccolourbar.cpt  -Baf -Bx+l"X / km" -By+l"Y / km" -BWSne -i0,1,2,3,4 -Vd -P  > ${PS_FILE}

Full error message

psxy: History: Process -R-1.1/1.1/-1.5/1.5.
psxy: History: Process -JX5c/7c.
psxy: History: Process -Xa2.0c.
psxy: History: Process -Ya14.0c.
psxy: History: Process -Baf.
psxy: History: Process -Bx+lX / km.
psxy: History: Process -By+lY / km.
psxy: History: Process -BWSne.
psxy: Pen modifier found: cl
psxy: Processing input table data
psxy: GMT: 1. gmt_getsharepath trying current dir
psxy: Object ID 0 : Registered CPT File colourbar.cpt as an Input resource with geometry Non-Geographical [n_objects = 1]
psxy: api_begin_io: Input resource access is now enabled [container]
psxy: api_import_palette: Passed ID = 0 and mode = 0
psxy: Reading CPT from File colourbar.cpt
psxy: Reading CPT from colourbar.cpt
psxy: GMT_End_IO: Input resource access is now disabled
psxy: Operation will require 5 input columns [n_cols_start = 3]
psxy: Projected values in meters: -1.1 1.1 -1.5 1.5
psxy: Auto-frame interval for axis 0 item 0: d = 0.5  f = 0.1
psxy: Auto-frame interval for axis 1 item 0: d = 1  f = 0.2
psxy: Map scale is 0.00044 km per cm or 1:44.
psxy: GMT_Get_Family: Could not determine family
psxy: api_init_import: Passed family = Data Table and geometry = Point
psxy: Object ID 1 : Registered Data Table File temp.txt as an Input resource with geometry Point [n_objects = 2]
psxy (api_init_import): tried to free unallocated memory
psxy: api_init_import: Added 1 new sources
psxy: GMT_Init_IO: Returned first Input object ID = 1
psxy: GMT_Begin_IO: Initialize record-by-record access for Input
psxy: api_next_io_source: Selected object 1
psxy: Reading Data Table from file temp.txt
psxy: GMT_Begin_IO: Input resource access is now enabled [record-by-record]
psxy: GMT_End_IO: Input resource access is now disabled
psxy: Entering plot_map_gridlines
psxy: Exiting plot_map_gridlines
psxy (gmt_freepen): tried to free unallocated memory
psxy (gmt_freepen): tried to free unallocated memory
psxy: gmtapi_garbage_collection: Destroying object: C=0 A=0 ID=0 W=Input F=CPT M=File S=Used P=0 D=753da0 N=colourbar.cpt
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (support_free_range): tried to free unallocated memory
psxy (gmtlib_free_cpt_ptr): tried to free unallocated memory
psxy: GMTAPI_Garbage_Collection freed 1 memory objects
psxy: gmtapi_unregister_io: Unregistering object no 0 [n_objects = 1]
psxy: gmtapi_unregister_io: Unregistering object no 1 [n_objects = 0]
psxy (gmtlib_free_tmp_arrays): tried to free unallocated memory
gmt: Entering GMT_Destroy_Session

System information

• Operating system: Ubuntu LTS 16.04
• Version of GMT: 5.4.3

[welcome]

👋 Thanks for opening your first issue here! Please make sure you filled out the template with as much detail as possible. We appreciate that you took the time to contribute!

[joa-quim]

We may have a bug but can't check your case because you didn't provide the temp.txt file. Can you please reduce this to a one line command showing the problem (no need for the -X, fancy -B etc)

Also notice that your makecpt command says -T-4.5/-1.4/0.2 . This will be an error in GMT6

makecpt [ERROR]: Syntax error -T option: (max - min) is not a whole multiple of inc

[joa-quim]

We may have a bug but can't check your case because you didn't provide the temp.txt file. Can you please reduce this to a one line command showing the problem (no need for the -X, fancy -B etc)

Also notice that your makecpt command says -T-4.5/-1.4/0.2 . This will be an error in GMT6

makecpt [ERROR]: Syntax error -T option: (max - min) is not a whole multiple of inc

[JianboLong]

We may have a bug but can't check your case because you didn't provide the temp.txt file. Can you please reduce this to a one line command showing the problem (no need for the -X, fancy -B etc)

Also notice that your makecpt command says -T-4.5/-1.4/0.2 . This will be an error in GMT6

makecpt [ERROR]: Syntax error -T option: (max - min) is not a whole multiple of inc

The file has now been attached, and the descriptions updated. Thanks for the comments. Could you try it again to see if you can reproduce the pictures ?

[PaulWessel]

Thanks for posting the file. Your commands work fine once you fix your makecpt -T range to be a multiple of 0.2. E.g., -T-4.6/-1.4/0.2. As it is the command fails and no CPT is used in psxy.

[joa-quim]

Well, I can't really say its working. With the plot size given in the example I see only tiny squares, so I increased things and than found that heads are lost and need to really shrink the head size to colored lines

psxy temp.txt -R-1.1/1.1/-1.5/1.5 -JX15c/21c -Sv0.005c+ea+p-+h0.4 -W0.85p+cl -Ccolourbar.cpt -Baf -BWSne -P > lixo.ps

when I remove the +cl than we can see nice vector heads but no vector bodies

psxy temp.txt -R-1.1/1.1/-1.5/1.5 -JX15c/21c -Sv0.005c+ea+p-+h0.4 -W0.85p -Ccolourbar.cpt -Baf -BWSne -P > lixo.ps

But heads are still colored although we now are not asking for color.
And, BTW, the +g<fill> is ignored

psxy temp.txt -R-1.1/1.1/-1.5/1.5 -JX15c/21c -Sv0.5c+ea+h0.4+gred -W0.85p -Baf -BWSne -P > lixo.ps

[JianboLong]

Well, I can't really say its working. With the plot size given in the example I see only tiny squares, so I increased things and than found that heads are lost and need to really shrink the head size to colored lines

psxy temp.txt -R-1.1/1.1/-1.5/1.5 -JX15c/21c -Sv0.005c+ea+p-+h0.4 -W0.85p+cl -Ccolourbar.cpt -Baf -BWSne -P > lixo.ps

when I remove the +cl than we can see nice vector heads but no vector bodies

psxy temp.txt -R-1.1/1.1/-1.5/1.5 -JX15c/21c -Sv0.005c+ea+p-+h0.4 -W0.85p -Ccolourbar.cpt -Baf -BWSne -P > lixo.ps

But heads are still colored although we now are not asking for color.
And, BTW, the +g<fill> is ignored

psxy temp.txt -R-1.1/1.1/-1.5/1.5 -JX15c/21c -Sv0.5c+ea+h0.4+gred -W0.85p -Baf -BWSne -P > lixo.ps

In your enlarged version (by using -JX15c/21c, instead of the original -JX5c/7c), when testing with the second command (without +cl), I can still only see black pens, no colour. The vector arrows are too small to be visible because of -Sv0.005c. Is this what you're talking about in "we can see nice vector heads but no vector bodies" ?

Also, the length of the vector pens is set to be 0.15c, which is provided in the last column of the attached temp.txt file. So when the size of the vector arrows is set too large compared to 0.15c, you will not see the pens. Sorry for this inconvenience.

[joa-quim]

Sorry for delay, but there still things that I don't understand either. And I'm using GMT6dev so there might some other differences due to it. What I get with my updated version 2) is

psxy temp.txt -R-1.1/1.1/-1.5/1.5 -JX15c/21c -Sv0.5+ea+h0.4 -Ccolourbar.cpt -W0.85p  -Baf -BWSne -P > lixo.ps

But I puzzled with this too because:

1. It's painting the heads although that is not requested (no -W+cf)
2. Don't understand where it's getting the variable color info from. It should be from the 5th column otemp.txt but that is a cont value = 0.15
3. It's not drawing the vector bodies, or else it's drawing them but they are too small to be seen (5th column?)

[PaulWessel]

I can solve no. 2 for you: Since the dawn of man, GMT has used the z-column when -C is used. For psxy that means the 3rd column, i.e., x, y, z, .... For psxyz it means the 4th column, i.e., it is the column after the point coordinate.

[JianboLong]

Hi Joaquim, for your 'puzzles', this is my understanding when using version 5.4.3 (there might be some difference if using version 6-dev, but that's beyond my test knowledge at the moment...)

It's painting the heads although that is not requested (no -W+cf)

I think the default option is to paint (fill) the symbol if a CPT is provided. the -W is more about changing the pens (lines). But according to the doc about PSXY, -W+cf also does the symbol fill job, however, it does not necessarily conflict with the default painting option, I guess.

Don't understand where it's getting the variable color info from. It should be from the 5th column otemp.txt but that is a cont value = 0.15

I just saw Paul's comment as writing this, yes, the variable colour is from CPT file as there is a -C. The 0.15 value as the 5th column in the data file is to control the length of the pen of the vector (as I tested)

It's not drawing the vector bodies, or else it's drawing them but they are too small to be seen (5th column?)

The pen of vector is just too small (0.15c) compared to your -Sv0.5c for the vector arrows (heads).

[PaulWessel]

Correct, if -C is given then the heads are filled. However, you can use the +c modifier to -W to tell it to use the color for the stem instead. And, if you also want both stem and head to be colored that way then you need to use +c or +clf.

[JianboLong]

Correct, if -C is given then the heads are filled. However, you can use the +c modifier to -W to tell it to use the color for the stem instead. And, if you also want both stem and head to be colored that way then you need to use +c or +clf.

This is actually what I wanted, to put both the stem and head be coloured using CPT file. The problem is when using +c for -W, I got the error (version 5.4.3 PSXY):

psxy: Pen modifier found: c psxy: Syntax error: Conflicting -E and -W options regarding -C option application

And when using +cf or +clf for -W, I only got the stems of the vectors, the heads are missing somehow, although in this case, the stems are coloured properly

[joa-quim]

I can solve no. 2 for you: Since the dawn of man, GMT has used the z-column when -C is used. For psxy that means the 3rd column, i.e., x, y, z, .... For psxyz it means the 4th column, i.e., it is the column after the point coordinate.

Than that means vectors are always colored by azimuth, which is a redundant info with respect to the heads direction. And if -C always fill the head then there is no need for a -W+cf (BTW, there is no +clf in the docs, only +c to do both).

I just saw Paul's comment as writing this, yes, the variable colour is from CPT file as there is a -C. The 0.15 value as the 5th column in the data file is to control the length of the pen of the vector (as I tested)

No, as per the manual 5th column is the header length when ... Direction (in degrees counter-clockwise from horizontal) and length must be found in columns 3 and 4, and size, if not specified on the command-line, should be present in column 5. But since the size was given (-Sv0.5c) my question is what was the 5th column used for.

[PaulWessel]

No, you are free to place whatever you want in col 3. If your "z" value is kept in some other column then you are expected to use -i to say so. Giving x y az length with -C will give an error (not enough cols) but in your case there are more cols and everything is shifted over by one, as per the way -C works. If you give x y az length value and -C then you are saying "I want az to be used for color, my azimuth to be length and length to be value. You get what you ask for.

[joa-quim]

So the manual clearly needs to provide that information because now it only says (no mention to shuffling the z column around)

-Sv
    vector. Direction (in degrees counter-clockwise from horizontal) and length must be found in
    columns 3 and 4, and size, if not specified on the command-line, should be present in column 5.
    The size is the length of the vector head. Vector width is set by -W.

[PaulWessel]

Well, it is already spelled out in detailed:

-Ccpt
Give a CPT or specify -Ccolor1,color2[,color3,...] to build a linear continuous CPT from those colors automatically, where z starts at 0 and is incremented by one for each color. In this case colorn can be a r/g/b triplet, a color name, or an HTML hexadecimal color (e.g. #aabbcc ). If -S is set, let symbol fill color be determined by the z-value in the third column. Additional fields are shifted over by one column (optional size would be 4th rather than 3rd field, etc.). If -S is not set, then plot expects the user to supply a multisegment file where each segment header contains a -Zval string. The val will control the color of the line or polygon (if -L is set) via the CPT.

[JianboLong]

So the manual clearly needs to provide that information because now it only says (no mention to shuffling the z column around)

-Sv
    vector. Direction (in degrees counter-clockwise from horizontal) and length must be found in
    columns 3 and 4, and size, if not specified on the command-line, should be present in column 5.
    The size is the length of the vector head. Vector width is set by -W.

For the Length that is after Direction, I think it's the length of the stem, right ?

[JianboLong]

Well, it is already spelled out in detailed:

-Ccpt
Give a CPT or specify -Ccolor1,color2[,color3,...] to build a linear continuous CPT from those colors automatically, where z starts at 0 and is incremented by one for each color. In this case colorn can be a r/g/b triplet, a color name, or an HTML hexadecimal color (e.g. #aabbcc ). If -S is set, let symbol fill color be determined by the z-value in the third column. Additional fields are shifted over by one column (optional size would be 4th rather than 3rd field, etc.). If -S is not set, then plot expects the user to supply a multisegment file where each segment header contains a -Zval string. The val will control the color of the line or polygon (if -L is set) via the CPT.

So my question now is, when -S is set, how can we let both the stem and head of the vector be coloured via the z-value in the third column ?

[PaulWessel]

echo "0 red 10 blue" > t.cpt
echo 0 0 5 0 1i | gmt psxy -R-1/1/-1/1 -JX4i -P -Sv0.2i+e -Ct.cpt -W2p+c > t.ps

seems to work find (gives you a purple vector stem and head.

[JianboLong]

echo "0 red 10 blue" > t.cpt
echo 0 0 5 0 1i | gmt psxy -R-1/1/-1/1 -JX4i -P -Sv0.2i+e -Ct.cpt -W2p+c > t.ps

seems to work find (gives you a purple vector stem and head.

Thank you for the comment, Paul. I tested your suggestion with GMT version 5.4.3, but still got the error

psxy: Syntax error: Conflicting -E and -W options regarding -C option application

Any idea of this ?

[PaulWessel]

I cannot fix bugs in 5.4.3 but they are fixed in 6.

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions.