With the advent of GPlates 1.5 came the ability to read a new version of the rotation file format called *.grot. In analogy to JSON and OGR_GMT formats it allows for much more verbose and structured addition of metadata to rotation sequences.

Revision: 1793 Date: 2012-05-11

1. GROT format attribute names
2. Example files

GPlates and the GPlate Geological Information Model (GPGIM) and the GPlates markup language (GPML) have opened new ways of working with plate tectonic data. Whereas the feature-centric data model has been vastly improved, the way the rotation model data is handled has not changed since the early days of the PLATES software. There is, however, a need to enhance the “richness” of the rotation file in terms of metadata, bibliographic annotation, revision histories and integration of rotation uncertainty estimates. I propose to model this new standard on the currently implemented GMT OGR format and a Multimarkdown-type set of attributes which should allow for an easy, streamlined processing in tools such as awk, Python or simple shell scripts as well as integration of these enhanced features into the GPlates software.

The new GPlates rotation file format encapsulates important rotation metadata in a simple and logical way. It emulates various language syntaxes such as GMT OGR, MultiMarkDown, LATEX Python and XML to provide a clean, logical and easy-to-use metadata framework. The file suffix for the new rotation file format is *.grot for GPlates rotation file, pronounced g-rot (and not grot…).

How to cite: Qin, X., Müller, R. D., Cannon, J., Landgrebe, T. C. W., Heine, C., Watson, R. J., and Turner, M.: The GPlates Geological Information Model and Markup Language, Geosci. Instrum. Method. Data Syst., 1, 111–134, https://doi.org/10.5194/gi-1-111-2012, 2012.

qin.gimds.2012.bib

@article{Qin.GIMDS.2012,
	Author = {Qin, X. and M{\"u}ller, R. D. and Cannon, J. and Landgrebe, T. C. W. and Heine, C. and Watson, R. J. and Turner, M.},
	Date-Added = {2012-11-20 14:43:33 +1100},
	Date-Modified = {2020-06-01 22:37:22 +0200},
	Doi = {10.5194/gi-1-111-2012},
	Journal = {Geoscientific Instrumentation, Methods and Data Systems},
	Journaltitle = {Geoscientific Instrumentation, Methods and Data Systems},
	Number = {2},
	Pages = {111--134},
	Title = {{The GPlates Geological Information Model and Markup Language}},
	Url = {http://www.geosci-instrum-method-data-syst.net/1/111/2012/},
	Volume = {1},
	Year = {2012}

The following section outlines the proposed new standard for encoding metadata (essentially everything beyond the mandatory rotation parameters) which is backward-compatible, and machine-digestible. Please comment or send feedback to Christian Heine

Previously rotation files only allowed comments if they were denoted as 999 rotations. 999 rotations to comment out lines This is error prone as already pointed out during the early phases of the GPlates development and cumbersome when directly working with rotation files in a text editor.

An example of a commented line using the current practice of replacing the Plate ID of the moving plate with a 999 to disable it. The inactive rotation sequence data looks like this:

  999   200.00 -55.810  -41.520  101.880 802 ! FLI-ANT Norton & Sclater 1979 fit

This methods has the severe disadvantage, that the original plate ID (PlateID1, moving plate) is lost when inserting a comment. Secondly the comment area is not structured well enough for automatic processing, e.g. extracting bibliographic references related to individual rotations or groups of rotations. It is quite easy to conceive that simple file exchange in PICT PICT collaborations or the omission of metadata can lead to a significant loss of important information contained in the rotation file. In addition, the introduction of novel methods, such as deformation, or Hellinger-style rotation uncertainty parameters requires a much larger set of rotations to be dealt with.

Two new flags are introduced in the new *.grot rotation file format: Flags: # for comments and > for denoting moving plate rotation sequences

Lines starting with # and followed by text are ignored by GPlates unless they contain marked @ATTRIBUTE data. Lines starting with # and followed by text are ignored by GPlates If the # is followed by a valid rotation pole specification, the line will be read by GPlates but the rotation pole itself will be disabled (inactive). In the new file format commented lines and comments would appear as: Lines starting with # and followed by a valid rotation pole specification are regarded disabled/inactive by GPlates

  # Comment which is ignored by GPlates 
  @C"Comment which is read by GPlates and associated with the next rotation pole below" 
  288  200.00 -55.81 -41.52  101.88 802 
  #288  200.00 -55.81 -41.52  101.88 802 @C"Comment read by GPlates but DISABLED rotation"

For legacy applications using rotation files a simple awk one-liner using RegExp can be used strip off all commented lines or simply preceed them by a 999 0.0 0.0 0.0 0.0 999 # rotation line.

A new Moving Plate Rotation Sequence (MPRS) is introduced in this version of the rotation file. The MPRS serves as header or “segment” and follows the idea of “bookmarking” individual blocks of rotation sequences in various text editors as well as in GPlates as well as the concept of multi line segments in GMT. Detailed info on the syntax of the MPRS in Sec. .

  > @MPRS:pid"002" @MPRS:code"PHS" @MPRS:name"Pacific Hotspots" 
  002     0.780  49.3000  -49.500   -1.020  901
  002     2.580  53.7200  -56.880   -2.660  901 
  002     5.890  59.6500  -66.050   -5.390  901
  002     8.860  62.8700  -70.870   -8.230  901

Metadata attributes recognised by GPlates in the new format have a specific format. They are prefixed by an @ symbol followed by a text string which is the name of the attribute. The attribute value is enclosed in a pair of double quotes “. The allowed set of keywords is listed completely in Sec. “”.

  @ATTRIBUTE"VALUE"
  @AU"CHHEI"

The syntax allows to have multiple fields for the Value. These fields must be separated by vertical bars/pipes without whitespace before or after the attribute (akin to GMT OGR): Attribute Values can have multiple fields

  @ATTRIBUTE"Value 1 | Value 2 | Value 3"

  
  @MPRS"101|NAM|North America"

The following variations for the different attribute:value pairs are allowed, depending on the complexity of the original attribute: Attributes can have (nested) child attributes

  @ATTRIBUTE:subattribute"Value"
  
  @MPRS:name"North America"
  @MPRS:pid"101"
  @MPRS:code"NAM"

Attribute and subattributes allow nesting at deeper levels. Consider the following example: Nested attributes can be written in compact or verbose forms

Template

  @ATTRIBUTE:subattribute:subsubattribute"Value"

Compact version

  @DC:contributor"JODO|John Doe|john.doe@example.com"

Extended version

  @DC:contributor:name"John Doe"
  @DC:contributor:id"JODO" 
  @DC:contributor:email"john.doe@example.com"

Here, one complex set of subattribute and subsubattributes can be combined in one line or listed separately in sequence on individual lines.

This method also allows the creation of aliases which can be created by referencing certain fields to reduce complexity of nested parent:children attributes. Nested attributes can be aliased In the current version the use ofuser-defined aliases is not supported. Example: User-defined aliases are notsupported at present

Template

  @ATTRIBUTE:subattribute"ID | Name | Email"

Header info

  @DC:contributor"JODO | John Doe | john.doe@example.com" 
  @DC:contributor"FOBA | Foo Bar | foo.bar@example.com" 
  @DC:contributor"FOBOO | Foo Boo | foo.boo@example.com"

This creates an alias

 
 alias @AU = @DC:contributor:id 

Use alias in rotation sequence

  @AU"JODO"
  @AU"FOBOO"
  @AU"FOBA"

In this example, an attribute and subattribute (DC:contributor) contains a list of values, all separated by a vertical bar/pipe. These attribute values conform to a standardised list where the first element is a unique Author ID, the second specifies the real world name of this author and the third his email. The attribute alias can now be created by assigning the @AU attribute a list of possible values which are all derived from all available DC:contributor”ID“ fields.

This setup allows even to fetch complex structures from external files. Attributes can reference external sources Say we keep a BibTeX bibliographic database along with our rotation file. In this file, bibliographic data is collected, with each entry having a unique identifier (the so-called citekey). Using nested attributes and aliases we are able to create the following setup:

  # Header
  @BIBINFO:bibliographyfile"file://rotationfile.bib"
  
  # Alias 
  alias @REF = @BIBINFO:bibliographyfile:citekey
  
  # Actual rotation metadata
  @REF"Heine.AGU-GM.04"

This creates the possiblity to relatively link unique elements from one source into the rotation file by direct mapping of this unique identifier. A possibly query would yield the BibTeX record for the citation key Heine.SE.2013 in the associated bibliographic data file which was specified in the header record using the @BIBINFO:bibliographyfile attribute.

Another application is the possiblity of spatial queries by referencing certain feature types in an associated GPML file or a remote data source. Attributes can be used to generate spatial queries Consider the followingexample:

  # Header
  @GPML:namespace"http://www.earthbyte.org/Resources/GPGIM/public/"
   
  # Alias
  alias @CHRONID = @GPML:MagneticAnomalyIdentification:polarityChronID
   
  # Rotation
  101    33.100  75.9900    5.9800    9.770  714 @CHRONID"C13"

With the available information, GPlates can go and run a spatial query to extract all the relevant features from a source file (e.g. a GPML file with all magnetic anomaly picks). The query would look like:

Find all C13 picks on plate ID 101 which have a conjugate plate id 714

Naturally, a magnetic anomaly picking scheme has to be agreed upon or explicity stated in the CHRONID (e.g. the young end of C13– C13y). As the GPGIM specification states, this information should be included in the value part of this attribute. Refer to the GPGIM for details. Such a geospatial query can be run for all applicable features.

The file body contains all data outside the file header. These are Moving Plate Rotation Sequences (MPRS) which are in turn composed of individual lines listing rotation parameters.

The moving plate rotation sequence (MPRS) specifies a block of rotations which all have the same moving plate id. It is denoted by a > flag at the start of each line and allows multi-line headers.

The introduction of a header for any moving plate rotation sequence follows the idea that most metadata is applied to a whole sequence of rotations and allows for better “bookmarking” in GPlates' rotation file editor or other external text editors. The rotation header sequence denominator is modelled as follows:

Template:

  > @MPRS:pid"PID1" @MPRS:code"XXX" @MPRS:name"Moving Plate name"

Compact version

   
  > @MPRS"288 | FLI | Falkland Islands"

Extended version

  > @MPRS:pid"288" @MPRS:code"FLI" @MPRS:name"Falkland Islands" @C"optional comment"

Multiline version

  > @MPRS:pid"288"
  > @MPRS:code"FLI"
  > @MPRS:name"Falkland Islands" 
  > @C"Optional comment" @AU"CHHEI"

Oftentimes the full moving plate rotation sequence is taken from a single author/publication. In that case, adding metadata to each rotation line would increase the possibility for mistakes.

The new rotation file format allows the user to specify metadata for a whole MPRS in the header which then applies to all rotations in that sequence:

  > @MPRS:pid"002" @MPRS:code"PHS" @MPRS:name"Pacific Hotspots" 
  002     2.580  53.7200  -56.880   -2.660  901 @PP"PHS-PAC" @REF"Wessel.JGR.08" @C"Model WK08-A" @GTS"GeeK07" 
  002     5.890  59.6500  -66.050   -5.390  901 @PP"PHS-PAC" @REF"Wessel.JGR.08" @C"Model WK08-A" @GTS"GeeK07" 
  002     8.860  62.8700  -70.870   -8.230  901 @PP"PHS-PAC" @REF"Wessel.JGR.08" @C"Model WK08-A" @GTS"GeeK07" 
  002    12.290  65.3700  -68.680  -10.300  901 @PP"PHS-PAC" @REF"Wessel.JGR.08" @C"Model WK08-A" @GTS"GeeK07" 
  002    17.470  68.2500  -61.530  -15.500  901 @PP"PHS-PAC" @REF"Wessel.JGR.08" @C"Model WK08-A" @GTS"GeeK07" 
  002    24.060  68.7800  -69.830  -20.400  901 @PP"PHS-PAC" @REF"Wessel.JGR.08" @C"Model WK08-A" @GTS"GeeK07" 
  002    28.280  67.7200  -70.800  -23.600  901 @PP"PHS-PAC" @REF"Wessel.JGR.08" @C"Model WK08-A" @GTS"GeeK07" 
  002    33.540  66.5700  -68.730  -27.700  901 @PP"PHS-PAC" @REF"Wessel.JGR.08" @C"Model WK08-A" @GTS"GeeK07" 
  002    40.100  65.4300  -64.250  -31.600  901 @PP"PHS-PAC" @REF"Wessel.JGR.08" @C"Model WK08-A" @GTS"GeeK07"

can now be replaced with

  > @MPRS:pid"002" @MPRS:code"PHS" @MPRS:name"Pacific Hotspots" 
  > @PP"PHS-PAC" @REF"Wessel.JGR.08" @C"Model WK08-A" @GTS"GeeK07" 
  002     2.580  53.7200  -56.880   -2.660  901
  002     5.890  59.6500  -66.050   -5.390  901 
  002     8.860  62.8700  -70.870   -8.230  901
  002    12.290  65.3700  -68.680  -10.300  901 
  002    17.470  68.2500  -61.530  -15.500  901
  002    24.060  68.7800  -69.830  -20.400  901 
  002    28.280  67.7200  -70.800  -23.600  901
  002    33.540  66.5700  -68.730  -27.700  901 
  002    40.100  65.4300  -64.250  -31.600  901

In case there are changes to individual rotations in the MPRS these can be done on line/rotation pole level and will overide the MPRS header data: Multiline comment metadata in @MPRS header

  > @MPRS:pid"002" @MPRS:code"PHS" @MPRS:name"Pacific Hotspots" 
  > @PP"PHS-PAC" @REF"Wessel.JGR.08" @C"Model WK08-A" @GTS"GeeK07" 
  002     2.580  53.7200  -56.880   -2.660  901
  002     5.890  59.6500  -66.050   -5.390  901 
  002     9.0    62.8700  -70.870   -8.230  901 @AU"CHHEI" @T"2012-05-03" @C"Changed time from 8.860" 
  002    12.290  65.3700  -68.680  -10.300  901
  002    17.470  68.2500  -61.530  -15.500  901 
  002    24.060  68.7800  -69.830  -20.400  901
  002    28.280  67.7200  -70.800  -23.600  901 
  002    33.540  66.5700  -68.730  -27.700  901
  002    40.100  65.4300  -64.250  -31.600  901

Given the above, the new 9.0 Ma rotation will carry the metadata specified on for the individual pole and only the specified pole metadata overrides the MPRS metadata (non-overridden metadata is still inherited from the MPRS).

We adopt the legacy PLATES rotation format which consists of 6 mandatory parameters specifying the stage pole of any given rotation. Backwards compatibility with PLATES rotation data The format has not changed andis fully compatible with legacy applications.

   PID1 FROMAGE POLELAT POLELON ANGLE PID2

New optional meta data attributes from the dictionary can be added to the individual lines. Rotation metadata attributes The optional attributes follow the structure layed out in Sec. and can consist of the following elements:

Attribute	Description
@PP	Abbreviated description of the relative plate motions, e.g. Africa-South America to @PP”SAM-AFR“, the abbreviated names have to adhere to the @MPRS:code from the MPRS.
@C	Free form comment
@GTS:id	Unique ID of the geological time scale used in identifying the magnetic anomaly picks. References the @GEOTIMESCALE:id in the file header
@AU	Abbreviation/ID of modification author. Alias which references @DC:contributor:id in the file header.
@DOI	Digitial object identifier for reference related to that individual rotation. Alias to @BIBINFO:doibase:doi. Citation key for reference related to that individual rotation.
@REF	Alias for @BIBINFO:bibliographyfile:citekey
@HELL	Set of attribute:value pairs for uncertainty parameters for this rotation. For details see Sec. .
@T	Modification date/time. Adhere to ISO standard (ie [YYYY]-[MM]-[DD]T[hh]:[mm]:[ss]).
@CHRONID	Magnetic anomaly chron ID. Alias to @GPML:MagneticAnomalyIdentification:polarityChronID and adheres to strict naming convention. The identifier used for magnetic picks evolved to be a combination of letters and numbers, of the form of (C/M)<number><combination of letters>. See the GPGIM for details.

For a complete list of attributes see GPlates GROT Format attribute list

Example:

  833    53.300 -14.1900  130.4100   -0.7200  801 @PP"LHR-AUS"  @DOI"10.1029/98JB00386" @CHRONID"C24o"

The Hellinger method allows to compute statistical uncertainties for rotations, representing them as a series of parameters and a 3D-covariance matrix. Hellinger Statistics attributes for individual rotations

These parameters are:

• total misfit (sum of squares of the weighted distances of data points to great circle segment) in [km]
• number of data points
• number of great circle segments
• number of degrees of freedom
• kappahat: quality factor which relates the uncertainties assigned to the data to their true estimates
• a 3 × 3 covariance matrix which needs to be divided by the factor kappahat to convert in square radians

An example matrix is given here obtained from the file satl.34 and running the hellinger1 program:

(                                    )
  8.71113084   - 4.33230877  -4.97091355
|| -4.33230877   4.01436998   3.23033819|| × 10-7
|( -4.97091355   3.23033819    3.6493551 |)
(1)

So far, Hellinger-fit criteria have not been explicity expressed in the rotation file. For the new standard, the Hellinger statistics need to be included explicity in the format expressed below. The complete Hellinger values can either be represented as coherent string with the some matrix values omitted due to the rotational symmetry of the matrix:

@HELL"r|(N,s)|dF|kappahat|(($x_1$,$x_2$,$x_3$)($y_2$,$y_3$)($z_3$))"

or as a separate set of arguments using the @HELL Parent:Children attributes:

• total misfit
• number of data points and segment length
• number of degrees of freedom
• Quality factor ^κ
• Covariance matrix, here we ONLY USE ¹⁾ due to the rotational symmetry of the matrix used.

Example:

Multi line version:

  @HELL:r"41.1911338"
  @HELL:Ns"75,16"
  @HELL:dF"40." 
  @HELL:kappahat"0.971082763"
  @HELL:cov"(8.71113084E-07,-4.33230877E-07,-4.97091355E-07) \ 
              (4.01436998E-07,3.23033819E-07)(3.6493551E-07)"

Compact single line:

  @HELL"""41.1911338 |75,16 | 40.| 0.971082763|\
   (8.71113084E-07,-4.33230877E-07,-4.97091355E-07) \ 
   (4.01436998E-07,3.23033819E-07)(3.6493551E-07)"""

Each rotation file should come with a companion bibliographic reference database in the ascii-based BibTeX format, see GROT: A new rotation file format for GPlates. The choice for BibTeX is driven by the fact that the format is text-based, accepted as one of the bibliographic data standards and many software tools allow to either directly use this format (BibDesk, JabREF) or import/export it (e.g. Endnote). At a future data the bibliographic information can possibly be incorporated consistently into the rotation file format without the need for two separate files.

Online resources:

• GPlates web site
• BibTeX resources
• Info about Dublin Core