Category Archives: GPlates

Global Paleoshoreline data

Together with former Ph.D. student Logan Yeo, we’ve reverse-engineered a set of global paleoshoreline compilations by Golonka et al. (2006) [1] and Smith et al. (1994) [2] and taken them back from the age of “dark data” being only published in analogue form, to fully digital versions. The paleoshoreline models are made available publicly in different formats, ready to be reconstructed with GPlates using different plate models. The data is published on the web alongside the paper (in press) in the Australian Journal of Earth Sciences (Heine, Yeo & Muller: Evaluating global paleoshoreline models for the Cretaceous and Cenozoic, Aust. J. Earth Sciences, in press) and they show the evolution of land area over time from ~150 Ma to the present according to the two different paleoshoreline estimates.

The files are available on my GitHub page here in *.gpml, *.geojson and *.shp format and can be viewed online. Unfortunately it doesn’t seem to be possible to embed the map on wordpress.com – I originally envisaged some funky webX.X embedded mapping here, but no. Instead web1.0 style links to follow for a sneak peek and some screenshots below:

  1. Golonka et al. (2006) models (examples):
  2. Smith et al. (1994) models:

The rendering through GitHub is fast and allows a quick overview about the global and regional paleoshoreline locations, allowing zooming in and panning.

Paleoshorelines in the Golonka model for the 139-123 Ma time slice rendered from a geojson file live on GitHub.

Paleoshorelines in the Golonka model for the 139-123 Ma time slice rendered from a geojson file live on GitHub. The colored area inside the polygon is equivalent to interpreted land (above sealevel) in the given time interval.

Another option to access the data is to use the version on CartoDB and interactively query and alter the data.

References:

[1] GOLONKA J., KROBICKI M., PAJAK J., VAN GIANG N. & ZUCHIEWICZ W. 2006. Global Plate Tectonics and Paleogeography of Southeast Asia. Faculty of Geology, Geophysics and Environmental Protection, AGH University of Science and Technology, Arkadia, Krakow, Poland.

[2] SMITH A., SMITH D. G. & FURNELL B. M.1994. Atlas of Mesozoic and Cenozoic coastlines. Cambridge University Press, 112 p. Cambridge, United Kingdom.

Advertisements

Working with plate velocities in GPlates

GPlates v1.3 can display and extract plate velocities. Depending on your work, you might have different requirements for these domains, plus there are a few pitfalls on the way. Currently, there are two three  ways to create velocity domains in GPlates:

  1. Create a global set of points at regular spacing which stay fixed absolute and the plates move across them. This method will report velocities of whatever plate will be on top of these points. This method is generally used when working with global models and when one wants to export boundary conditions for global geodynamic modelling (the CitcomS and Terra mesh generation options). Use  Features → Generate Velocity Point Domains to create a velocity domain setup according to your needs. Note that this also allows to create a regular spaced lon/lat grid of distributed points. The features are gpml:MeshNode features in the GPlates Geological Information Model.

    Adding a global layer of velocity domain points using GPlates' built-in function

    Adding a global layer of velocity domain points using GPlates’ built-in function

  2. Alternatively, you can just go and create a set of points wherever you require them – you might have a few small plates which fall through the cracks when creating the global velocity domains. So here, you just go and create a few point features, assigning them the right properties in the ‘Create Feature’ dialogue. Create and save the layer after you are done. You can automatically assign PlateIDs using GPlates’ cookie-cutting tool afterwards which saves you typing in PlateIDs manually.

    Manually creating a point feature collection where velocities are to be extraced

    Manually creating a point feature collection where velocities are to be extracted

  3. Use QGIS and the Vector toolbox to create a regular spaced point grid in OGR Vector format (ESRI Shapefile, OGR GMT etc) and load that into GPlates, cookie-cut – or rather – assign plate ids and there is a regional, regular-spaced point set which you can use as velocity domains.

    Creating a regular spaced point grid to be used as velocity domain, using QGIS.

    Creating a regular spaced point grid to be used as velocity domain, using QGIS.

One important thing to know is that GPlates utilises layers for different types of data, so here’s a little digression and some background info. This layer business is much like GIS software has vector and raster layers, and other layers which are the result of some computations/combination of other layers – or like image manipulation applications like GIMP or Photoshop. The following layer types exist in GPlates (n.b. ideally a detailed overview of the layers with examples should follow here but currently there is no time, I suppose this might be found in the GPlates documentation somewhere):

  • ReconstructionTree: Rotation files/models are automagically assigned to the yellow layer.
  • ReconstructedGeometries: Essentially all feature data one works with gets stuffed into the green layer type. Shapefiles, standard GPML files (not topologies), OGR GMT files all belong to this layer type.
  • Co-registration: Features related to data mining and association checks are combined in this layer type. This is one example where a layer does not correspond directly to a feature collection (ie a single file on disk). Instead, the user selects a set of seed points (a feature collection) and target geometries/rasters (another feature collection/raster) to generate a new data type.
  • Calculated velocity fields: Another one of of those layers where the layer=feature collection equation breaks down. Here we load a point feature collection and combine it with other data such as topological polygons or static polygons to compute velocities.
  • Resolved topologial networks:   This (brown) layer type is similar to the topological geometries but creates triangulated networks used for deformation.
  • Resolved topological geometries: Topologically closed polygons are created from the combination of a rotation file (ReconstructionTree) and a feature layer (ReconstructedGeometries).
  • Reconstructed Raster: Raster data gets loaded into the red layer type.
  • 3D scalar field: Volume-rendering of scalar fields as, for example, from seismic tomography

Now that this is sorted, let’s generate some velocity fields.

After completing either of those steps above you should have a point layer from which you can now extract velocities. Depending on the way you created these points, the steps to display velocities might differ a bit.

Generating plate velocity vectors:

  1. Create a global velocity domain layer using (1) from above or create your velocity points using method 2 or 3 from above.
  2. Once you have created the velocity domain layer using option (1), GPlates will automatically load a new feature layer with the name of velocity point layer as you specified. If you have  used the “Latitude Longitude” option in GPlates, your default layer name will be something like lat_lon_velocity_domain_SomeIntegervalue and have a green color in the layer window (the ReconstructedGeometry layer). In addition, GPlates will create a aqua turquoise colored layer (the “Calculated Velocity Fields” layer) with the same name. That is where ze aktion happens.
  3. Creating a global velocity domain layer will automagically create a "ReconstructableFeature" layer (green) and a "Calculated Velocity Fields" layer (turquoise) - see arrows. Above, the different layer types are displayed from the drop-down menu.

    Creating a global velocity domain layer will automagically create a “ReconstructableFeature” layer (green) and a “Calculated Velocity Fields” layer (turquoise) – see arrows. Above, the different layer types are displayed from the drop-down menu.

  4. The next thing you need is either a static polygon feature collection set or a topologically closed polygon feature collection and of course a rotation model loaded. The next steps will illustrate why.
  5. Only if you have created your point velocity domain layer manually): Add a new blank “Calculated Velocity Fields” layer throug clicking the big at the top of the layer window.
  6. The key now is to connect the Velocity layer with other feature data. This can be a global polygon data set or a set of static polygons. Open the aqua-colored layer by clicking the little triangle on the left and  under the “Inputs” category you see the headings “Velocity domains” (and your generated velocity domain reconstructable geometry layer is already connected to this. If it is not connected, you need to add it here. This is  the case where you created it manually. Under the “Velocity surfaces” heading, click on the “Add new connection”  field and select the polygon data. If one is set to export velocity boundary conditions for geodynamic modelling this of course requires continuously closed polygons, covering the surface of the Earth at any reconstruction time. Such topologically closed polygon data is provided on the EarthByte website. If you are working regionally, just select whatever polygon feature collection you are working with.
    The "Calculated Velocity Fields" layer unfolded.

    The “Calculated Velocity Fields” layer unfolded.

    Adding regional polygons as surfaces for the velocity calculations

    Adding regional polygons as surfaces for the velocity calculations

  7. In the case that you are using global velocity domain points and polygons, make sure that in the “Velocity and Interpolation options” section,  Calculate velocities is set to “of surfaces” . If you have a set of points that are assigned plate ids, one would want to set this to “of domain points”.
  8. Once you have connected your surface domains with your velocity domains, you should see velocity vectors displayed in the main window. The settings for the vector display can be altered in the layer dialogue.

    Screenshot showing calculated velocities at a set of global domain points. Note that velocities are only displayed where surface polygons overlap with the points.

    Screenshot showing calculated velocities at a set of global domain points. Note that velocities are only displayed where surface polygons overlap with the points.

  9. If needed these vectors can be exported using the “Export…” function under the “Reconstruction” menu in a wide flavour of formats.

The world in (geological) colors

The color palettes I described in my recent post can also be used with GPlates to color loaded features. Here are three examples which use the static polygon dataset which comes with GPlates. The first is using the GTS2012 chronostratigraphic time scale to color the static polygons by epoch and fill the polygons:

The world colored by geological epoch.

The world colored by geological epoch, filling the static polygons.

The second is just using the same data set and color the line features by geological era:

Coloring the polygons by era in GTS2012 colors.

Coloring the polygons by era in GTS2012 colors.

And the last is a bit Bauhaus-y by coloring everything in black and white according to the Gee & Kent geomagnetic polarity time scale (not that this would make a lot of sense, but as we can do it…):

The world in normal polarity and reverse polarity according to the Gee & Kent geomagnetic polarity timescale.

The world in normal polarity and reverse polarity according to the Gee & Kent geomagnetic polarity timescale (using the filled static polygons).

That planet looks way to boring -  hemispherical view of the Earth colored according to a normal (white) and reverse (black) geomagnetic polarity. Again using the Gee & Kent 2007 timescale.

That planet looks way to boring – hemispherical view of the Earth with the static polygons colored according to a normal (white) and reverse (black) geomagnetic polarity. Again using the Gee & Kent 2007 timescale.

In order to color loaded features by age (and timescale) just add the colorpalettes to the “Draw style” settings (Features -> Manage colouring) like this:

The geological age color palettes can be added to the Draw style (Manage colouring).

The geological age color palettes can be added to the Draw style (Manage colouring).

Once the new colour palettes are available, they can be assigned to the individual layers either through the layer window or through “Features -> “Manage colouring” .

Shapefile of reconstructable graticule lines for GPlates

5-Degree spaced graticule lines using the Seton et al plate polygons, reconstructed to 100 Ma.

I have generated a shapefile with reconstructable, global graticule lines (5 degree spacing) for the Seton et al. plate model continental polygons. Download the file here. This file is released under a Creative Commons Attribution Share-Alike 3.0 license and was created with CreateGraticuleLines.py (Link to BitBucket site).

Graticules for plate tectonic reconstructions

Plate tectonic reconstructions require to have some present-day markers so that any person reading or looking at the results can correlate the paleo plate positions and continents with present day. Things did indeed look quite a bit different back then… Usually the present-day coastlines are used a such a marker, but as sealevel has varied extensively over the geological history, displaying an Early Cretaceous reconstruction at, say 110 Million years, with present-day shorelines might be a bit misleading. In fact one could probably say that it is plainly wrong.

So what’s the big deal about this you might ask. One key aspect of graticules is usually that they are not “features” in the sense of tangible geospatial data, but rather a “decorative” overlay. GPlates also displays a fixed graticule (the thin gray lines spaced at 30 degrees) on the globe. However, in plate tectonics, if we go back in time, we require that such lines and decorations become ‘reconstructable’ back through geological history. So we need data, not decorations. During the 1980’s in the famous PLATES project at UTIG, a special data type called ‘Gridmarks’ was invented which was pretty much a set of crosshairs, centered at equally spaced increments, mimicking a graticule which could be reconstructed. Take these individual crosshairs, assign them a lifespan and a PlateID and one could simply reconstruct them as continental outlines and other geospatial features were. All worked quite happily with this concept and this old file.

When I started to work on South Atlantic plate kinematics, I realised that, albeit being quite useful, some smaller plates would simply be missed by the grid marks. Also, one would also have to reassign plate ids for any new set of polygons one is working with and sometimes a bit of an update to the way things are being done is also refreshing. The routines which were used to generate these gridmark files (in the old PLATES *.dat format) were written in Fortran and I don’t have a compiled version for my OS at hand and knowing the pain associated with this exercise I opted for a writing a new routine from scratch in Python tailored for use with GPlates.

The result of this is  a short script called “CreateGraticuleLines.py” in my gptools repository on Atlassian’s BitBucket which borrows command line options from GMT. I’ll give a brief overview about the usage. First,  either clone the toolbox using

git clone https://bitbucket.org/chhei/gptools.git

or simply download a zipped archive (either from the overview or from the Downloads page under ‘branches’). Open the terminal, cd to the place where you have downloaded the archive, unzip and type:

cd gptools
chmod u+x CreateGraticuleLines.py
./CreateGraticuleLines.py --help

So now you can create regular spaced graticule lines either for a global coverage at 5 degree line spacing (the default settings, equivalent to -Rd -I5) or for any other bounding box and line increment you require. For example

./CreateGraticuleLine.py -R-10/40/40/70 -I1

will create the following file for GPlates (by default the output name for the file is “Graticule.gpml”):

Graticule lines feature collection showing a 1-degree graticule covering most of Europe. Note that all lines are individual features.

Graticule lines feature collection showing a 1-degree graticule covering most of Europe. Note that all lines are individual features.

Once you load plate polygons into GPlates along with the graticule lines, you can use the cookie-cutting functionality in GPlates to cut the lines and assign individual plate IDs along with an “age of appearance” (set to 0 Ma by the script). It should then somehow look like this:

A global graticule (using the default settings) cookie-cut and age-assigned along with plate polygons.

A global graticule (using the default settings) cookie-cut and age-assigned along with plate polygons.

Once you have cookie-cut and age-assigned the graticule lines, you can reconstruct them like any other feature in GPlates. Note that areas without plate ID and changed ages of appearance will not display once you step back beyond 0 Ma (present day). Here’s another screenshot:

Graticule lines as reconstructable features - cookie cut to plate polygons and rotated back to 100 Ma.

Graticule lines as reconstructable features – cookie cut to plate polygons and rotated back to 100 Ma.

If you now export your reconstruction as set of GMT files, you can now use GMT’s psxy to plot a graticule mesh on top of your reconstruction maps using various line styles. A last example from my South Atlantic maps:

An example of the application of the reconstructed graticules here as thin gray dashed lines (Heine et al., 2013)

An example of the application of the reconstructed graticules here as thin gray dashed lines (Heine et al., 2013)

Similarly, this will also work when using GPlates’ SVG export. You can of course also export your graticule file in GPlates to different formats – such as ESRI Shapefile or OGR GMT plain text format (“Save as” functionality in GPlates’ feature manager).

Happy map making. For bug reports and improvement suggestions please use the BitBucket issue tracker or the commenting functionality here.

The “GROT” – A new rotation file format for GPlates

I had written earlier about the new file format (“GROT” – pronounced g-rot) for GPlates rotation files. After probably 3 decades of plain text rotation files with freeform comments, things like direct links to DOIs and bibliographies, structured document metadata and the option to include Hellinger style rotation statistics in the rotation files finally arrive in the plate tectonic reconstruction world 2.0. The technical details of the new format are described in a supplementary PDF to the GPGIM Paper by Michael Chin. Now, the next release of GPlates will be able to read and write those files natively, below are a few screenshots (the release of GPlates v1.3 is pending). But first – what is metadata and why could it potentially be useful in the context of plate tectonic rotation models? Here’s a little description from the Dublin Core website:

The word “metadata” means “data about data”. Metadata articulates a context for objects of interest — “resources” such as MP3 files, library books, or satellite images — in the form of “resource descriptions”. As a tradition, resource description dates back to the earliest archives and library catalogs. The modern “metadata” field that gave rise to Dublin Core and other recent standards emerged with the Web revolution of the mid-1990s.

Now, such information is important when it comes to the ‘semantic web’ and having machines to process such files – something Matt Hall from Agile recently commented on “Machines can read, too“). This means there is information about the author, access rights, description of the content and coverage (spatial and temporal) and contributors (where there is no publication for a rotation sequence yet), plus some info on how to programmatically process the data, encoded. The GROT format is naturally not as engineered as GPlates’ GPML files or GeoSciML, but I think it strikes a good balance between easy enough to edit by hand in a text editor while maintaining some structure in order to automatically process the file content.

Here’s a little talk through the new features of the GROT files – nothing seems to have changed in the Total Reconstruction Sequence View in GPlates apart from an additional ‘Show metadata’ button at the right hand side of the window (the column names you see in the window are from an earlier development version and will not show up in the pending release version):

So far nothing seems to have changed in the "View Total Reconstruction Sequences" window

So far nothing seems to have changed in the “View Total Reconstruction Sequences” window (the column names shown were only in a development version and will not be in the release candidate of GPlates)

Now, if the individual sequences are expanded, the metadata is revealed and the individual columns populated:

However, when expanding the individual sequences you are now exposing chunky parts of metadata for each moving plate rotation sequence or the individual rotation.

However, when expanding the individual sequences you are now exposing chunky parts of metadata for each moving plate rotation sequence or the individual rotation – again this was only in an earlier development version and will not be in release 1.3.

That little “Show metadata” can be used at various locations, depending where you have focused the view. Here we click on a single pole:

Individual moving plate rotation sequence metadata

Individual moving plate rotation sequence metadata

Now, note the structured fields in the right window – Here the user can specify geological timescales used for the rotation sequences, magnetic anomaly chron IDs, the reference(links to a local BibTeX database/ and DOI of the publication. In addition author names (AU), modification time (T) and plate pair (PP) can be added as valuable comments. In future incarnations there will hopefully be a hyperlink so that one can just click on the DOI in GPlates and  get automagically taken to the publication.

There is one other interesting part to the GROT format, namely the file metadata – this is a whole chunk of structured text at the top of the file (similar to what one uses in LaTeX or in a well-written script header). This metadata encapsules global information for the GROT file which GPlates can understand, namely:

  • The GROT version (for future-proofing updates to the format)
  • a Dublin Core metadata section as discussed above
  • Data relevant for the revision history of a rotation file
  • Data to connect the rotation file with a bibliographic database
  • Information about the geological time scales used to convert magnetic anomaly chrons and stratigraphic ranges to absolute ages

Here’s a screenshot of the metadata from the GROT file header:

GROT File header metadata

GROT File header metadata

Now a closer look at the contributors:

Details about contributors to a rotation file as part of the Dublin core metadata set

Details about contributors to a rotation file as part of the Dublin core metadata set

Now that all sounds probably quite complicated, but here’s a raw vision of how this looks like in a text editor with syntax coloring (using TextMate and my GROT bundle, see also this post here):

A raw vision of a part of the DublinCore file description

A raw vision of a part of the DublinCore file description

Raw vision of the moving plate rotation sequence

Raw vision of the moving plate rotation sequence

With the new GROT file format, the possibility also now exists to link certain features into the rotation file. In the following screenshot, the rotation of South America (201) relative to Africa (701) is specified based on picks of magnetic anomaly chrons (@CHRONID”…”). This structured format now allows to (theoretically) extrat all magnetic picks of e.g. CHRONID=”CAn18″ from a geospatial pick database with a simple where the plate id = 201 and the conjugate plate ID = 701.

Detailed annotations of stage poles allow linking to geospatial features, such as magnetic anomaly picks expressed through a CHRONID tag.

Detailed annotations of stage poles allow linking to geospatial features, such as magnetic anomaly picks expressed through a CHRONID tag.

So with the upcoming release of GPlates v1.3, finally structured, meta-data rich rotation files have arrived. More examples and some updated on the final release features should follow later.