Same functionality as -g, but for processing - exists?

Recently I became aware of (and tested) the -g option (Segment data by detecting gaps). This is, as far as I know, just for plotting data.

Is there a utility that implements this functionality for data processing? I.e., instead of using -g I would like to preprocess my lines/data so that -g is unnecessary.

I feel like I’ve seen this before, but looking through the docs where I would assume such functionality to be described, I didn’t find anything, e.g. gmtspatial, gmtselect and gmtconnect (this seems to do the opposite - connect segments).

Any kick in the right direction is appreciated!

How about gmtconvert?

Hmm, I’ve been through the gmtconvert docs, but not having any epiphanies yet. Maybe gmtconvert -F

Just no other options than -g

gmtconvert file -g... > ...

For example I use this to split in segments if there is a gap of 1 km.

gmt convert file -gd1000 > new_file

And example like this would be helpful in gmtconvert docs.

1 Like

Will -g in any way be affected by > (line segments) in the input file?
Or will -g only check coordinates?

Note to self: I see that my use of project cause > to end up after the last coordinate pair for each segment, instead of being on a line of its own;

[...]
6033377.82
4448000.39	6426562.71
-2533192.10	-2302101.72>
# @D38
3042532.74	5873471.96
[...]

Segment headers always great things into segments and have no influence on optils like -g. The -g may add more segment headers as it detects those gaps.

Thanks Paul.

  • Upper: unprocessed - wrapping occur
  • Middle-upper is plot with -g - splits ut line segments good
  • Middle-lower is an attempt to get the result of the middle-upper plot (with -g) into a file for later use. This does produces lines, but many(/all) of the line segments are reduced to contain only one point, hence no lines are drawn. This is illustrated by the lower figure.
gmt begin projected-graticules png
gmt plot -Wdarkgray -B0 -B+t"plotted as-is" projected-graticules.dat -Jx1:200000000
gmt plot -Wdarkgray -B0 -B+t"-gX1c" projected-graticules.dat -Y-11c -gX1c
gmt convert projected-graticules.dat -gd1000 | gmt plot -Wred -B0 -B+t"gmt convert -gd1000 -Wred (i.e. lines)" -Y-11c
gmt convert projected-graticules.dat -gd1000 | gmt plot -Sc0.1c -Gred -B0 -B+t"gmt convert -gd1000 -Sc0.1c -Gred (i.e. points)" -Y-11c
gmt end show

projected-graticules.dat (16.0 KB)

  • PS: s/-gd1000/-gD1000 cause crash (the command may not make sense, but a crash is a crash):
ERROR: Caught signal number 11 (Segmentation fault) at
[0x0]
[0x0]
Stack backtrace:
/home/anbj/gmt/build/lib/libgmt.so.6(sig_handler_unix+0x10a)[0x7fca63ce6071]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x13140)[0x7fca63b0a140]
plot [WARNING]: File <stdin> is empty!

I think your gmt convert -g stuff needs to be fed first vi mapproject -J etc since otherwise you are using the wrong units directly on the lon/lat data.

What if the file is already projected? In this case via proj.
The -g option should not care about where the data is coming from…?
Am I using wrong units in this case?

I think that you should use -gD (upper case for projected data). But I test it and I got a segmentation fault (as you I think).

PS: I think I sayd nonsense. Ignore this comment. I often confuse projected data in the figure (in cm or inches) and projected like in UTM.

What is the gap that you want? 1000 m?

Try a higher value for -gd

$ gmt convert projected-graticules.dat -gd10000000 
>
-10648864.61    -5873471.96
-13227645.12    -4906776.05
-15573644.14    -3664907.27
> Data gap detected via -g; Segment header inserted
17452594.04     -2251010.89
17084864.19     -742476.62
16239291.22     795722.76
14909467.2      2302101.72
13124503.25     3711426.03
10961938.36     4945662.41
8588916.34      5900499.3
6309316.42      6436524.33
4448000.39      6426562.71
3042532.74      5873471.96
-2533192.1      -2302101.72

No problem @Esteban82; don’t we all… Confusing stuff.
Everything I’m using here is already in projected units (with proj); just to keep it as simple as possible.

A higher value for gd does work; -gd5000000 gives the exact result as -gX1c:

gmt begin projected-graticules png
gmt plot -Wdarkgray -B0 -B+t"plotted as-is" projected-graticules.dat -Jx1:200000000
gmt plot -Wdarkgray -B0 -B+t"-gX1c" projected-graticules.dat -Y-11c -gX1c
g=-gd5000000
gmt convert projected-graticules.dat ${g} | gmt plot -Wred -B0 -B+t"gmt convert ${g} -Wred (i.e. lines)" -Y-11c
gmt convert projected-graticules.dat ${g} | gmt plot -Sc0.1c -Gred -B0 -B+t"gmt convert ${g} -Sc0.1c -Gred (i.e. points)" -Y-11c
gmt end show

From -g: d|D - define a gap when there is a large enough distance between coordinates (upper case to use projected coordinates).

This give to cases:

    1. gap is big enough → impose breal
    1. gap is not big enough → do not impose break

In my orignal plot, -gd was set too low, causing a ‘blank canvas’ (middle-lower); shouldn’t this just produce the same plot as the upper figure (‘plotted as-is’)?

Mmmm, with your previous values (-gd1000) you split all your data into single points and them ask GMT to plot lines (gmt plot -W). from them. I don’t think that makes sense. But, you could plot points as in the lowest figure.

Yes, you’re right. I get confused. Thanks!

1 Like

Mainly for the record, it is not the same thing.

  • -gd5000000; Gaps where the distance is 5.000 km (because the data is in m).
  • -gX1c: Gaps where the data ploted in the map is sepatated 1 cm in the X direction.

In your case, you have the same result due to your scale (-Jx1:200000000).

Thank you @Esteban82.