Example gallery modern / classic

Hi,

I know, I know there’s already been some talk about the example gallery… still :slight_smile:

All the examples shown are written with the MODERN MODE, but -and I think I’m not the only one- I mostly use GMT within scripts which requires the CLASSIC MODE.

IMO, it could be nice to have both Modern and Classic scripts for each example.

What do you think?

I think we have no capacity to maintain two sets of documentations. There is always the link to 5.4.5 discussing scripts in classic mode. We do not want to highlight both classic and modern forms of a script since the classic is much longer, harder to learn, and much more prone to errors, Users who already know classic only (and there are many GMT 4 users out there as well) can always stick with the old docs if they do not want to change, but new users should be told as little as possible about classic…

But, can we do as much in classic mode ?

I thought there were some restrictions for scripts (especially for loops). If that’s the case, it can be difficult to find on its own some things without prior knowledge of the modules. (eg pscontour vs contour) … no?

Yes … another classic mode user and I support your case @PlanetGus.

I come to enjoy modern mode as well. As @pwessel said, most of the simpler things go quicker in modern mode compared to classic mode. But I see it more like MacOS. You have a simple, shiny, easy-to-use GUI (modern mode) which most people never leave. But you also have a fully fledged unixoid system beneath it (classic mode) where you can do anything you fancy including completely wrecking your system. Great power, but great responsibility.

I basically rely on the stuff that pushed Paul and the others to develop modern mode in the first place. As baking old and new layers together isn’t an option in modern mode most of my work depends on classic mode. I understand that Paul is reluctant to tell the world that classic mode still exists but it still is more powerful than modern mode and offers a flexibility not found in other GIS software. That’s why I disagree with Paul about hiding it from the world. I fear the plan is to abandon classic mode in the long run which would be a real shame as it is one of the major advantages over other software packages.

I think most users generate plots once for some kind of single time use and never touch them again. For them, modern mode is a big improvement. No worrying about -O and -K and other sources of constant questions in the forum anymore. The shiny MacOS GUI.

I have a use case in which plots are automatically generated daily with new data for some of the layers but most layers remain static. This runs every day. To cut down on generation time only the changed layers are generated and then baked together into the final plot with the already existing unchanged layers. Sure, I could generate all of my plots in modern mode with some trickery (loops …) but generation time would go through the roof. The baking of layers cuts the generation time from around six hours to less than one hour every night. The raw unixoid foundation of MacOS. Great power, but great responsibility.

My half-baked idea is to have the modern gallery as the default/base/standard one and add a small link at the end of the page which leads to the classic version of the example. Maybe even head every classic mode example page with a big red

– PROCEED WITH CAUTION –
BETTER USE MODERN MODE
SEE [LINK TO MODERN MODE]

but the info will still be there for people like @PlanetGus and me. Your thoughts?

Or just having under the already existing examples :

– the figure –
MODERN MODE code > few lines

CLASSIC MODE code > more lines that will eventually discourage people

@KristofKoch just curious. What is it that take one hour to calculate just some layers? Did you identify the bottleneck?

@Joaquim – the main bottleneck is not GMT-related but calling the database on a different server and calculating some things on the fly (outside GMT) for every chart. The calls could be made more efficient. Second time eater is rastering PNGs from the PS files (PS -> PDF -> PNG). I don’t see any optimization potential here. The charts cover the whole globe so the sheer number of charts amplifies the problem. My ventures into parallelization haven’t been successful so far. Less than one hour for the whole globe is acceptable for me.

@PlanetGus I have the feeling that users will try to mix modern with classic mode syntax if presented next to each other.

This will lead to @pwessel’s dentist bill soaring to unknown heights and him plotting to do harm to us. Luckily for us, he is confined to an island far, far away in the Pacific Ocean but never underestimate a man from the North …

Not to mention… he has connections all around the globe.

@PlanetGus you are right – I didn’t think of his faithful vassals …

1 Like

I feel that it may be useful to have a section in the cookbook (maybe as an appendix), explaining how the GMT modern mode works. For example:

  • the structure of Postscript file (Head + body1 + body2 +…+ bodyn + trailer, i.e., the -K and -O option)
  • the classic way to create a figure (via -K, -O and redirection)
  • the paper size (~11mX11m) and the plot origin (a few inches from the bottom left corner)
  • how GMT knows the option history (via gmt.history, but the file is invisible in modern mode)
  • what’s a GMT session, and session PPID
  • the concept of session, figure, subplot, and inset and the different levels of CPTs and gmt.conf
  • et al.

Most users don’t need to know how GMT modern mode works, but it’s useful for people to understanding some of the GMT’s behaviors.

I know that some of the points above are already documented in the cookbook or module manpage, but they’re in separated places and may make users difficult to follow.