x2sys_cross¶

Calculate crossovers between track data files

Synopsis¶

gmt x2sys_cross track(s) -TTAG [ -Acombitable ] [ -C[runtimes] ] [ -D[S|N] ] [ -Il|a|c ] [ -Qe|i ] [ -Sl|u|hspeed ] [ -V[level] ] [ -Wsize ] [ -Z ] [ -bobinary ] [ -donodata ] [ --PAR=value ]

Note: No space is allowed between the option flag and the associated arguments.

Description¶

x2sys_cross is used to determine all intersections between (“external cross-overs”) or within (“internal cross-overs”) tracks (Cartesian or geographic), and report the time, position, distance along track, heading and speed along each track segment, and the crossover error (COE) and mean values for all observables. The names of the tracks are passed on the command line. By default, x2sys_cross will look for both external and internal COEs. As an option, you may choose to project all data using one of the map-projections prior to calculating the COE.

Required Arguments¶

tracks: Can be one or more ASCII, native binary, or COARDS netCDF 1-D data files. To supply the data files via a text file with a list of tracks (one per record), specify the name of the track list after a leading equal-sign (e.g., =tracks.lis). If the names are missing their file extension we will append the suffix specified for this TAG. Track files will be searched for first in the current directory and second in all directories listed in $X2SYS_HOME/TAG/TAG_paths.txt (if it exists). [If $X2SYS_HOME is not set it will default to $GMT_SHAREDIR/x2sys]. (Note: MGD77 files will also be looked for via MGD77_HOME/mgd77_paths.txt and *.gmt files will be searched for via $GMT_SHAREDIR/mgg/gmtfile_paths).

-TTAG: Specify the x2sys TAG which identifies the attributes of this data type.

Optional Arguments¶

-Acombitable: Only process the pair-combinations found in the file combitable [Default process all possible combinations among the specified files]. The file combitable created by x2sys_get -L option

-C[runtimes]: Compute and append the processing run-time for each pair to the progress message. Append a filename to save these run-times to file. The idea here is to use the knowledge of run-times to split the main process in a number of sub-processes that can each be launched in a different processor of your multi-core machine. See the MATLAB function split_file4coes.m that lives in the x2sys supplement source code.

-D[S|N]: Control how geographic coordinates are handled (Cartesian data are unaffected). By default, we determine if the data are closer to one pole than the other, and then we use a cylindrical polar conversion to avoid problems with longitude jumps. You can turn this off entirely with -D and then the calculations uses the original data (we have protections against longitude jumps). However, you can force the selection of the pole for the projection by appending S or N for the south or north pole, respectively. The conversion is used because the algorithm used to find crossovers are inherently a Cartesian algorithm that can run into trouble with data that has large longitudinal range at higher latitudes.

-Il|a|c

Sets the interpolation mode for estimating values at the crossover. Choose among:

l Linear interpolation [Default].

a Akima spline interpolation.

c Cubic spline interpolation.

-Qe|i: Append e for external COEs only, and i for internal COEs only [Default is all COEs].

-Rwest/east/south/north[/zmin/zmax][+r][+uunit]

Specify the region of interest. For Cartesian data just give xmin/xmax/ymin/ymax. This option limits the COEs to those that fall inside the specified domain. The region may be specified in one of six ways:

-Rwest/east/south/north[+uunit]. This is the standard way to specify geographic regions when using map projections where meridians and parallels are rectilinear. The coordinates may be specified in decimal degrees or in [±]dd:mm[:ss.xxx][W|E|S|N] format. Optionally, append +uunit to specify a region in projected units (e.g., UTM meters) where west/east/south/north are Cartesian projected coordinates compatible with the chosen projection (-J) and unit is an allowable distance unit; we inversely project to determine the actual rectangular geographic region.

-Rwest/south/east/north+r. This form is useful for map projections that are oblique, making meridians and parallels poor choices for map boundaries. Here, we instead specify the lower left corner and upper right corner geographic coordinates, followed by the modifier +r. This form guarantees a rectangular map even though lines of equal longitude and latitude are not straight lines.

-Rg or -Rd. These forms can be used to quickly specify the global domain (0/360 for -Rg and -180/+180 for -Rd in longitude, with -90/+90 in latitude).

-Rcode1,code2,…[+e|r|Rincs]. This indirectly supplies the region by consulting the DCW (Digital Chart of the World) database and derives the bounding regions for one or more countries given by the codes. Simply append one or more comma-separated countries using the two-character ISO 3166-1 alpha-2 convention. To select a state within a country (if available), append .state, e.g, US.TX for Texas. To specify a whole continent, prepend = to any of the continent codes AF (Africa), AN (Antarctica), AS (Asia), EU (Europe), OC (Oceania), NA (North America), or SA (South America). The following modifiers can be appended:

+r to adjust the region boundaries to be multiples of the steps indicated by inc, xinc/yinc, or winc/einc/sinc/ninc [default is no adjustment]. For example, -RFR+r1 will select the national bounding box of France rounded to nearest integer degree.

+R to extend the region outward by adding the amounts specified by inc, xinc/yinc, or winc/einc/sinc/ninc [default is no extension].

+e to adjust the region boundaries to be multiples of the steps indicated by inc, xinc/yinc, or winc/einc/sinc/ninc, while ensuring that the bounding box extends by at least 0.25 times the increment [default is no adjustment].

-Rjustifylon0/lat0/nx/ny, where justify is a 2-character combination of L|C|R (for left, center, or right) and T|M|B (for top, middle, or bottom) (e.g., BL for lower left). The two character code justify indicates which point on a rectangular region region the lon0/lat0 coordinates refer to and the grid dimensions nx and ny are used with grid spacings given via -I to create the corresponding region. This method can be used when creating grids. For example, -RCM25/25/50/50 specifies a 50x50 grid centered on 25,25.

-Rgridfile. This will copy the domain settings found for the grid in specified file. Note that depending on the nature of the calling module, this mechanism will also set grid spacing and possibly the grid registration (see Grid registration: The -r option).

-Sl|u|hspeed

Defines window of track speeds. If speeds are outside this window we do not calculate a COE. Specify

-Sl sets lower speed [Default is 0].

-Su sets upper speed [Default is Infinity].

-Sh does not limit the speed but sets a lower speed below which headings will not be computed (i.e., set to NaN) [Default calculates headings regardless of speed].

-V[level]: Select verbosity level [w]. (See full description) (See cookbook information).

-Wsize: Give the maximum number of data points on either side of the crossover to use in the spline interpolation [3].

-Z: Report the values of each track at the crossover [Default reports the crossover value and the mean value].

-bo[ncols][type] (more …): Select native binary output.

-donodata (more …): Replace output columns that equal NaN with nodata.

-^ or just -: Print a short message about the syntax of the command, then exit (NOTE: on Windows just use -).
-+ or just +: Print an extensive usage (help) message, including the explanation of any module-specific option (but not the GMT common options), then exit.
-? or no arguments: Print a complete usage (help) message, including the explanation of all options, then exit.
--PAR=value: Temporarily override a GMT default setting; repeatable. See gmt.conf for parameters.

Remarks¶

The COEs found are printed out to standard output in ASCII format (unless -bo is set). When ASCII is chosen, the output format depends on whether or not old-style XOVER output (-L) has been selected [See the GMT4 x_over man page for more details]. If ASCII, then the first record contains the name of the tag used, the second records specifies the exact command line used for this run, and the third record contains the names of each column. These three records are encoded as table headers and start with #. For each track pair, there will be a segment header record containing the two file names and their start/stop/dist information (start/stop is absolute time or NaN if unavailable while dist is the total track length), whereas subsequent records have the data for each COE encountered. The fields written out are x, y, time along track #1 and #2, distance along track #1 and #2, heading along track #1 and #2, velocity along track #1 and #2, and then pairs of columns for each selected observable. These are either pairs of (COE, average value) for each data type (or track-values #1 and #2; see -Z). It is recommended that the Akima spline is used instead of the natural cubic spline, since it is less sensitive to outliers that tend to introduce wild oscillations in the interpolation.

Sign Convention¶

If track_a and track_b are passed on the command line, then the COE value is Value (track_a) - Value (track_b).

Precision And Format¶

The output format of individual columns are controlled by FORMAT_FLOAT_OUT except for geographic coordinates (FORMAT_GEO_OUT) and absolute calendar time (FORMAT_DATE_OUT, FORMAT_CLOCK_OUT). Make sure these are set to give you enough significant digits to achieve the desired precision.

Examples¶

To compute all internal crossovers in the gmt-formatted file c2104.gmt, and using the tag GMT, try

gmt x2sys_cross c2104.gmt -TGMT > c2104.txt

To find the crossover locations with bathymetry between the two MGD77 files A13232.mgd77 and A99938.mgd77, using the MGD77 tag, try

gmt x2sys_cross A13232.mgd77 A99938.mgd77 -Qe -TMGD77 > crossovers.txt

References¶

Wessel, P. (2010), Tools for analyzing intersecting tracks: the x2sys package. Computers and Geosciences, 36, 348-354.

Wessel, P. (1989), XOVER: A cross-over error detector for track data, Computers and Geosciences, 15(3), 333-346.