I think only the last example, centered annotations, is of interest (that's what everybody would manually draw). If someone really wants the outside annotations, make a second call to basemap. Grid-lines is probably an exception. I can perfectly imagine the wish of centered annotations plus grid-lines

The last panel is definitely the best looking one (IMO).

But I'd keep the 0, especially foreseeing this remark :

but I can imagine some joker wanting to specify the desired x and y placements

After all, the "first" annotation is supposed to be easy to remove thanks to B+e option (it reminds me this BTW.

Annotating the center is asking for trouble. If one used a non 0/0 value then it double always overprint. Here is 0/0:

I think from all the other annotations there is no need to do something complicated at the center since those values, whatever they are, could be spelled out in a figure caption or text etc., or just inferred from the other annotations.

So, based on this limited feedback, the leading candidate is --MAP_FRAME_TYPE=graph-origin[,x/y] and it would only result in the last map as is.

What about slightly shifting the annotation ? That would solve the grid overlap too

What about slightly shifting the annotation ? That would solve the grid overlap too

This would need to involve font size, absolute values, spacing etc. It is not a fun thing to do. I think leaving it out is a good start. There is always text if people cannot figure out what those coordinates are.

There is always text if people cannot figure out what those coordinates are.

True. What about the B+el option ?

Well, -B+e has no knowledge of any center coordinate to skip. One can image a -B+ec but the point is that nobody would want an annotation that prints on top of the axis and the other annotation, which brings us back to the "can we just shift it a bit". There is real agony in determine "a bit".

agony

Alright alright. You're the one doing the work here 🥇

I'm curious about the result with this showcase :

#!/bin/bash

gmt begin test png

	vecsta=$(gmt math -Q -3 PI MUL =)
	vecsto=$(gmt math -Q 3 PI MUL =)
	vecste=$(gmt math -Q 1 32 DIV =)

        # x
	gmt math -T$vecsta/$vecsto/$vecste T -o0 = x.txt
       # y = sin(x)
	gmt math -Q x.txt SIN = y.txt 
        #y2 = A cos(x+B)
	gmt math -Q x.txt PI 3 DIV ADD COS 4 PI MUL 10 DIV MUL = y2.txt

        # Shading for red<blue
	gmt math -Q y.txt y2.txt LE 0 NAN y.txt MUL = y_c.txt
        # Shading for red>blue
	gmt math -Q y.txt y2.txt GE 0 NAN y2.txt MUL = y2_c.txt

        # All in one file (for -Sb+base option)
	paste x.txt y.txt y2.txt y_c.txt y2_c.txt > file.txt

        # Graph-paper
	gmt basemap -R-10/10/-2/2 -JX10c -Bxafpigpi -Byafg -BW+t"Relative anomaly" --MAP_FRAME_TYPE=graph-origin --MAP_GRID_PEN=lightgray
 
        # Plot sines
	gmt plot file.txt -i0,1 -Wfat,blue -l"@[\sin(x)@["
	gmt plot file.txt -i0,2 -Wfat,red -l"@[\frac{4\pi}{10}\cos(x+\frac{\pi}{3})@["

        # Plot shades
	gmt plot file.txt -i0,3,2 -Gred@90 -Sb${vecste}q+b -l"red > blue"
	gmt plot file.txt -i0,4,1 -Gblue@90 -Sb${vecste}q+b -l"red < blue"

gmt end show

Give it a try. I have updated the docs. For various reasons the syntax is

--MAP_FRAME_TYPE=graph-origin[+ox/y]

My complaints about unwanted ticks were silly since one can just select axis l and b to just get the vectors and w and s to add ticks.

Give it a try. I have updated the docs.

I don't see it in dev doc.

> gmt --version
6.5.0_8bbc44d_2022.06.25

> bash Untitled-1.sh
basemap [WARNING]: Bad fraction, error = 0.00128068

> > 
#!/bin/bash

gmt begin test png

	vecsta=$(gmt math -Q -3 PI MUL =)
	vecsto=$(gmt math -Q 3 PI MUL =)
	vecste=$(gmt math -Q 1 32 DIV =)

        # x
	gmt math -T$vecsta/$vecsto/$vecste T -o0 = x.txt
       # y = sin(x)
	gmt math -Q x.txt SIN = y.txt 
        #y2 = A cos(x+B)
	gmt math -Q x.txt PI 3 DIV ADD COS 4 PI MUL 10 DIV MUL = y2.txt

        # Shading for red<blue
	gmt math -Q y.txt y2.txt LE 0 NAN y.txt MUL = y_c.txt
        # Shading for red>blue
	gmt math -Q y.txt y2.txt GE 0 NAN y2.txt MUL = y2_c.txt

        # All in one file (for -Sb+base option)
	paste x.txt y.txt y2.txt y_c.txt y2_c.txt > file.txt

        # Graph-paper
	gmt basemap -R-10/10/-2/2 -JX10c -Bxafpigpi -Byafg -BWS+t"Relative anomaly" --MAP_FRAME_TYPE=graph-origin+o0/0 --MAP_GRID_PEN=lightgray
 
        # Plot sines
	gmt plot file.txt -i0,1 -Wthick,blue -l"@[\sin(x)@["
	gmt plot file.txt -i0,2 -Wthick,red -l"@[\frac{4\pi}{10}\cos(x+\frac{\pi}{3})@["

        # Plot shades
	gmt plot file.txt -i0,3,2 -Gred@90 -Sb${vecste}q+b -l"red > blue"
	gmt plot file.txt -i0,4,1 -Gblue@90 -Sb${vecste}q+b -l"red < blue"

gmt end show

Not merged - this is WIP branch only. - need to build that branch.

need to build that branch

I'm a simple man.

Your example looks like this:

Which tells me that if only one axis is selected we do not have to block the labeling of the origin since there is no overprint.

if only one axis is selected

Indeed. Do you throw an error if Joker asks for -BWSEN or similar ?

Not yet, but silently ignore anything but WwlSsb

Still need to update the example plot in gmt.conf of the various basemaps to include the graph-origin. @gd-a example with both axis looks like this:

I am unsure if we should automatically add to the title offset (the length of the extension) or if the user should use --MAP_TITLE_OFFSET.

silently ignore anything but WwlSsb

The secret to peace of mind.

It looks neat ! (Well, except for the ugly plot lines)
I'd add the offset, else users would have to declare it every time, which have a tendency to clutter the code.

Now with auto shift:

Documentation and code has been updated to use graph-origin and the figure and script in gmt.conf has been expanded to include the graph-origin basemap. I think this PR is now ready for final review:

Agree that graph-origin is better (a little shorter).

Another thing. Your example figure shows that the figures are small the fonts are still too big.

Agree the fonts are too big here. Maybe it is a subplot thing? Anyway, separate issue from graph-origin.

Given Joaquim's blind approval, it would be good if @seisman @Esteban82 and @meghanrjones give it a try first before I merge.

Do you think it makes more sense to have the default origin at the center of the x- and y-range. For example, for -R10/30/-20/-10, the default origin is +o20/-15.

gmt basemap -JX5c -R10/30/-20/-10 -Baf -BWS --MAP_FRAME_TYPE=graph-origin -png map

-Blb and -Bls don't work as expected:

gmt basemap -Baf -Blb -JX5c -R-10/10/-10/10 --MAP_FRAME_TYPE=graph-origin -png map
gmt basemap -Baf -BlS -JX5c -R-10/10/-10/10 --MAP_FRAME_TYPE=graph-origin -png map

Do you think it makes more sense to have the default origin at the center of the x- and y-range. For example, for -R10/30/-20/-10, the default origin is +o20/-15

No, I think that would be a problem. Lets say I use -R-10/20/-20/10. I would want the axes at the origin, but your default would place them at (5,-5) which is useless. So now I would have to add +o0/0 to make sure every time. I think it is better the other way, that you should have to do +o20/-15 instead.

Perhaps a getter solution would be an optional +oc for "Center the axes on the given domain", with the default still being the origin at (0,0)?

Do you think it makes more sense to have the default origin at the center of the x- and y-range. For example, for -R10/30/-20/-10, the default origin is +o20/-15

No, I think that would be a problem. Lets say I use -R-10/20/-20/10. I would want the axes at the origin, but your default would place them at (5,-5) which is useless. So now I would have to add +o0/0 to make sure every time. I think it is better the other way, that you should have to do +o20/-15 instead.

Perhaps a getter solution would be an optional +oc for "Center the axes on the given domain", with the default still being the origin at (0,0)?

Sounds good to me.

Please check again, @seisman. The +oc has been implemented and I fixed the lack of reset for unannotated axes.