Time axis, issues with setting tick positions, tick label formatting and placement.

[mkononets]

I wanted to set X axis as time, set major ticks every 2 weeks (14 days), and format tick labels as "%b %d", aligned (centered) exactly at the axis tick positions. My example data range is a bit shorter than 2 months.

In short: I want to have time tick placement, labels format specs and label alignment as shown in my gnuplot example. I am not getting this with GMT. See more below.

My gnuplot code and figure is presented to demonstrate what I want and how it is specified. Further down I posted what I was able to get using GMT, the code and the results that I don't like at all - mostly erratic tick positions, misaligned tick labels, and label formats not respecting the requested specifications.

I want to get the same result I get with gnuplot. Gnuplot apparently (naively) counts 2-week intervals starting from the epoch. This way major ticks appear at 2019-02-21 etc. These major tick positions are a whole number of 2-week periods away from the epoch of 1970-01-01. I want to get the same tick positions and tick labels aligned the same way in GMT.

NB a standard way of specifying tick label format using C strftime format specifiers. A significant advantage for the user (me) that tick label of types Time and Date become essentially the same with this approach. Time/Date formatting seems two different things with GMT. It is not clear why it is so and what benefits it brings. The documentation and examples are scarce and scattered across several different places.

NB 1 Gnuplot's approach to the time interval/tick placement implies that regardless of the specified time interval all the time ticks and labels always remain at exactly the same positions.

My gnuplot code:

set term pngcairo enhanced size 800,80 font "Helvetica,14"
set output "gnuplot.png"
set xdata time
set timefmt "%Y-%m-%d"
set xrange ["2019-02-15" to "2019-04-08"]
set yrange [0 to 1]
unset ytics
set xtics 3600*24*14 nomirror out
set format x "%b %d"
set border 1
plot 0/0 notitle

Plot:

Now to my GMT trials and the results.

When I specify -Bxa14Rf7R the following --FORMAT_DATE_MAP="o dd" is not respected, label format is just the date of month, labels are misaligned and printed a bit away from the ticks:

gmt basemap -R2019-02-15T/2019-04-08T/-20/+20 -JX10c -BS -Bxa14Rf7R -png R --FORMAT_DATE_MAP="o dd" --FORMAT_TIME_PRIMARY_MAP=abbrev

When I specify -Bxa2Uf1U --FORMAT_DATE_MAP="o dd" --FORMAT_TIME_PRIMARY_MAP=abbrev label format is correct but the labels are misaligned and printed far away from the ticks:

gmt basemap -R2019-02-15T/2019-04-08T/-20/+20 -JX10c -BS -Bxa2Uf1U -png U --FORMAT_DATE_MAP="o dd" --FORMAT_TIME_PRIMARY_MAP=abbrev

When I specify -Bxa14Df7D --FORMAT_DATE_MAP="o dd" --FORMAT_TIME_PRIMARY_MAP=abbrev I get extra label at Apr 01 right on top of Mar 29, plus the labels are misaligned, that is, not centered exactly at the tick positions:

gmt basemap -R2019-02-15T/2019-04-08T/-20/+20 -JX10c -BS -Bxa14Df7D -png D --FORMAT_DATE_MAP="o dd" --FORMAT_TIME_PRIMARY_MAP=abbrev

With -Bxa14Df7D --FORMAT_DATE_MAP="o dd" --FORMAT_TIME_PRIMARY_MAP=abbrev i get essentially the same labels as before: only date is printed, aligned away from the tick positions. The requested abbreviated month name is just disregarded:

gmt basemap -R2019-02-15T/2019-04-08T/-20/+20 -JX10c -BS -Bxa14df7d -png d --FORMAT_DATE_MAP="o dd" --FORMAT_TIME_PRIMARY_MAP=abbrev

I want in principle to have time tick placement labels and formatting as in gnuplot. This implies tick labels centered exactly at the tick positions by default (interval labels centered at the center of the interval), standard label format specifiers and standard tick position evaluation as in gnuplot, that is, all tick positions relative to the epoch.

Congrats and thanks to all those who managed to read that far down.

[joa-quim]

mostly erratic tick positions, misaligned tick labels, and label formats not respecting the requested specifications.

This is more than one issue. I'll address here the non-constant annotations/ticks cadence and what Claude found about it.

● Bug Analysis

  With -Bxa14D and range 2019-02-15T to 2019-04-08T, here's the step-by-step execution through gmtlib_moment_interval() in
  gmt_calclock.c:665-695:

  1. Init (Feb 15): day_m=15, (15-1) % 14 = 0, no floor. First annotation: Feb 15
  2. Step: day_m + step = 15 + 14 = 29 > 28 (Feb has 28 days) → truncates to Mar 1
  3. Step: 1 + 14 = 15 ≤ 31 → Mar 15
  4. Step: 15 + 14 = 29 ≤ 31 → Mar 29
  5. Step: 29 + 14 = 43 > 31 → truncates to Apr 1 (BUG!)
  6. Step: 1 + 14 = 15 ≤ 30 → Apr 15 (beyond max, loop ends)

  The expected sequence should be: Feb 15 → Mar 1 → Mar 15 → Mar 29 → Apr 12.

  Root Cause

  Lines 680-688 of gmt_calclock.c: when day_m + step exceeds the month length, the code truncates to the 1st of the next month instead of
   simply advancing step days:

  if (p->cc[0].day_m + p->step > kml) {
      /* Truncate to 1st of next month  */
      p->rd[1] = gmt_rd_from_gymd (..., next_month, 1);  // resets to day 1
  }
  else
      p->rd[1] = p->rd[0] + p->step;  // this branch is correct

  Fix

  The simplest fix would be to always advance by step days:

  p->rd[1] = p->rd[0] + p->step;

  This would produce Mar 29 + 14 = Apr 12 (correct) instead of truncating to Apr 1.

  However, the truncation to day 1 may be intentional for small steps (e.g., a7D) where aligning to month boundaries makes sense. A safer
   fix would be to only truncate when step is small enough that month-boundary alignment is meaningful (e.g., step < ~15), or perhaps
  only when step evenly divides typical month lengths.

I did confirm that doing what Claude suggests as the simplest fix does indeed fix the issue. But on the other hand
https://github.com/GenericMappingTools/gmt/blob/master/src/gmt_calclock.c#L680-L691
was clearly written on purpose. Any idea what we would break if that code is removed?

[mkononets]

on the other hand
https://github.com/GenericMappingTools/gmt/blob/master/src/gmt_calclock.c#L680-L691
was clearly written on purpose. Any idea what we would break if that code is removed?

Does it worth asking that thing exactly this question?

[joa-quim]

I can try, but there is a little catch with that thing. Even the payed version consumes thousands of tokens (credits) and I have a hourly and weekly plafond. When consumed I must wait to next window.

[mkononets]

Is it very expensive? I literally have no idea.

[joa-quim]

Basic entry usage (the one I have) costs about 18 Euro a month. Next level starts to be (> 100). But it's duration (per time window) depends a lot on what one asks it to do.

But the free thing also let us do quite some things.

[mkononets]

Yeah right, now I remember seeing the numbers.
I also tried to persuade the free thing to run some errands, really dumb tasks like digitizing data tables from old pdf reports. The free thing has not been great at that, I had to double check literally everything. It didn't make me keen on paying. Good to see that thing seems better at coding (than me).

[joa-quim]

Claude is not good for images (though it can read them). Itself warns about that.

[mkononets]

No, that was a "normal" text pdf, not pure graphics or an OCR text layer "behind" the page images. But the table content could not be copy-pasted easily or processed by a script. Free Claude got quickly tired once the table contained many irregular empty cells.