[GPlates-discuss] Defining mid-ocean ridges

John Cannon john.cannon at sydney.edu.au
Sun Apr 29 16:15:48 AEST 2018 

Hi Bruce,


1)      Each ridge polyline segment can be in a different feature with the same name. Or can be a single feature containing multiple polyline segments with the same property name (eg, ‘gpml:centerLineOf’). Or it’s acceptable to join the ridge and transform segments into a single polyline.

2)      In general left/right indicates which side of the line you are on when following the order of points in the line (eg, if line goes South to North then left is West, and for North to South then left is East). This is how subduction polarity works – see (3). Ideally this should also be followed for mid-ocean ridges, but here the concept of left/right is also used for reconstruction. And it’s possible that the left/right plate IDs might, strictly speaking, be incorrect (ie, swapped such that the left plate ID corresponds to the right side, and right plate ID to left side) but you could still get the correct reconstruction provided the spreading asymmetry is also swapped (ie, negated). For symmetric spreading (ie, asymmetry is zero) this swapping won’t affect reconstruction.

3)      Subduction polarity indicates which side the over-riding plate is on (eg, if subduction zone line goes South to North and polarity is Left then over-riding plate is West and subducting plate is East).


There’s also a description of these features/properties at https://protect-au.mimecast.com/s/TfbBCBNZwLivZvQWizcWta?domain=gplates.org , for example the MidOceanRidge at https://protect-au.mimecast.com/s/f2_dCD1jy9tX6X2Ys55Aez?domain=gplates.org and subduction polarity at https://protect-au.mimecast.com/s/T1KYCE8kz9tBABr4cp5MTc?domain=gplates.org

Regards,
John

From: GPlates-discuss [mailto:gplates-discuss-bounces at mailman.sydney.edu.au] On Behalf Of Eglington, Bruce
Sent: Sunday, 29 April 2018 12:40 AM
To: GPlates general discussion mailing list
Subject: [GPlates-discuss] Defining mid-ocean ridges

Hi John
  Thanks for all the extra information and the warnings for what not to do.  A few more questions though:

1)      The polylineonsphere procedure expects a series of nodes. For present day mid-ocean ridges there are lots of offsets with ridge segments interspersed with transform faults so one needs lots of separate ridge polylines. Do these need to be named differently or can each ocean ridge polyline segment of what is geologically one ridge have the same name?

2)      How does one judge what is left and what is right? Does GPlates have some preferred frame of reference (convention) for this? When a ridge or subduction zone is oriented north-south, it is easy to say what is left (west) and what is right (east) if one follows standard map viewing conventions but what if the ridge or subduction zone is oriented east-west. Does one view the polyline from an eastern or western perspective? More generally, does one view from the perspective of the starting node or from the ending node?

3)      Separately, what is meant by subduction zone polarity? What is the convention for deciding what is left or right?
Thanks
   Bruce


Bruce Eglington (Ph.D.)
Murray Pyke Chair
Geological Sciences
University of Saskatchewan
114 Science Place
Saskatoon
SK
S7N 5E2
Canada

bruce.eglington at usask.ca<mailto:bruce.eglington at usask.ca>
+1-306-966-5732

From: GPlates-discuss [mailto:gplates-discuss-bounces at mailman.sydney.edu.au] On Behalf Of John Cannon
Sent: Saturday, April 28, 2018 01:54
To: GPlates general discussion mailing list <gplates-discuss at mailman.sydney.edu.au>
Subject: Re: [GPlates-discuss] GPlates and linking to databases

…I forgot to mention the reconstruction method maps to the RECON_METH shapefile attribute, and can be set to HalfStageRotationVersion3 (or HalfStageRotationVersion2 or HalfStageRotation). However note the issues below (better to use GPlates or pyGPlates to do all this)…


Version 3 of the half-stage rotation was introduced in GPlates 2.0 (and, as mentioned in my last post, current pyGPlates only supports version 2 and below). With version 3 the spreading starts at the digitization time (ie, the reconstruction time at which the mid-ocean ridge was digitized in GPlates) such that subsequent adjustments to the spreading asymmetry no longer change the position of the ridge at the digitization time. With version 2, the ridge position would offset quite substantially making it unfeasible to adjust the asymmetry. So now the digitization time needed to be recorded, and this introduced the new property ‘gpml:geometryImportTime’ (also used in the new ability to reconstruct geometries using deforming and non-deforming topologies in GPlates 2.0).

Oh, I just realized that gpml:geometryImportTime is not mapped in GPlates !  Which means it gets lost on saving to, or loading from, Shapefile and defaults to 0Ma. And this puts (version 3) mid-ocean ridges in the wrong location in GPlates 2.0 (when loaded from Shapefile). I’ll fix that for GPlates 2.1 (by mapping to a new attribute, say IMPORT_AGE).

Actually, even when that is fixed, it will still be quite difficult to create a mid-ocean ridge without using GPlates or pyGPlates. This is because you need to take your mid-ocean ridge geometry (at say 100Ma) and reverse reconstruct it back to present day, and then store that present day geometry in the feature (in GPML or Shapefile) – this is how all features are stored. And that (reverse) reconstruction differs between the half-stage rotation versions. I suppose you could emulate version 2 or version 3, and reverse reconstruct yourself, but that requires knowing exactly how these versions are implemented inside GPlates/pyGPlates. It’s better to just use pyGPlates to create a mid-ocean ridge (since it takes care of the reverse reconstruction for you).

So in general I would recommend creating features (especially mid-ocean ridges) using GPlates or pyGPlates.

This sample code shows how to create a mid-ocean ridge in pyGPlates:

https://protect-au.mimecast.com/s/EyZkCGvmB5iwywx3HQes6K?domain=gplates.org<https://protect-au.mimecast.com/s/EyZkCGvmB5iwywx3HQes6K?domain=gplates.org>

…and how to save it to a file (eg, GPML or Shapefile):

https://protect-au.mimecast.com/s/5EvwCJyp0qhx4xG9CvW1SE?domain=gplates.org<https://protect-au.mimecast.com/s/5EvwCJyp0qhx4xG9CvW1SE?domain=gplates.org>

Regards,
John


From: GPlates-discuss [mailto:gplates-discuss-bounces at mailman.sydney.edu.au] On Behalf Of John Cannon
Sent: Saturday, 28 April 2018 4:03 PM
To: GPlates general discussion mailing list
Subject: Re: [GPlates-discuss] GPlates and linking to databases

Hi Bruce,

If you’re digitizing a feature in GPlates then you don’t need to specify the Plate ID and Conjugate ID fields. When you switch to Half Stage Rotation (in Create Feature dialog) those fields disappear, and the Left Plate ID and Right Plate ID fields appear. And the feature type is taken care of when you selected MidOceanRidge. Saving to Shapefile will then map the feature type and spreading asymmetry to the GPGIM_TYPE and SPREAD_ASY shapefile attributes by default.

However if you’re creating a feature outside GPlates, and without using pyGPlates, then you can add the GPGIM_TYPE shapefile attribute as ‘gpml:MidOceanRidge’ (as you noted) and the SPREAD_ASY attribute as a value in the range [-1,1] where 0 is symmetric spreading. And add the left/right plate IDs as L_PLATE and R_PLATE. Note that when GPlates loads your shapefile it will also load plate/conjugate IDs of zero by default, but they won’t get used for a half stage rotation.

On a related note, the current public pyGPlates (revision 12) will not work with mid-ocean ridges created in GPlates 2.0 (ie, pyGPlates will not reconstruct them properly). To solve this there will be a simultaneous pyGPlates release alongside GPlates 2.1 (soon).

Regards,
John

From: GPlates-discuss [mailto:gplates-discuss-bounces at mailman.sydney.edu.au] On Behalf Of Eglington, Bruce
Sent: Saturday, 28 April 2018 10:53 AM
To: GPlates general discussion mailing list
Subject: Re: [GPlates-discuss] GPlates and linking to databases

Hi Sabin
  I need to be a bit more certain about what is needed so please excuse what will appear very evident as soon as I get things working. As I understand you, for a given OceanRidge, I need to specify the half-stage left plate plateid value and the half-stage right plate plate id. When I do this do I specify the normal PlateID field as none and the conjugate plateid field as none? Presumably I ought also to set the featuretype as having an appropriate GPGIM_TYPE value for ocean ridges (“gpml:MidOceanRidge” as I remember)? Do I need to have fields with something in my shapefile for reconstruction method and for spreading asymmetry?

Thanks
  Bruce


Bruce Eglington (Ph.D.)
Murray Pyke Chair
Geological Sciences
University of Saskatchewan
114 Science Place
Saskatoon
SK
S7N 5E2
Canada

bruce.eglington at usask.ca<mailto:bruce.eglington at usask.ca>
+1-306-966-5732

From: GPlates-discuss [mailto:gplates-discuss-bounces at mailman.sydney.edu.au] On Behalf Of Sabin Zahirovic
Sent: Friday, April 27, 2018 15:57
To: GPlates general discussion mailing list <gplates-discuss at mailman.sydney.edu.au<mailto:gplates-discuss at mailman.sydney.edu.au>>
Subject: Re: [GPlates-discuss] GPlates and linking to databases

Hi Bruce,

If you digitize a feature to be a MidOceanicRidge, you can specify the Reconstruction Method as “Half Stage Rotation” with a Left and Right PlateID. The ridge will then move with a half stage rotation, and will be equally spaced.

Regards,
Sabin

--
DR SABIN ZAHIROVIC | Postdoctoral Research Associate
School of Geosciences | Faculty of Science


THE UNIVERSITY OF SYDNEY
Rm 403, Madsen Building F09 | The University of Sydney | NSW | 2006
M +61 416 775 589 P +61 2 9351 3625
E sabin.zahirovic at sydney.edu.au<mailto:sabin.zahirovic at sydney.edu.au> | W https://protect-au.mimecast.com/s/Cvf0CK1qJZtLALg7iGLosE?domain=earthbyte.org<https://protect-au.mimecast.com/s/gABbCL7rK8tLoLxBirDjnV?domain=earthbyte.org> | R http://www.researchgate.net/profile/Sabin_Zahirovic
F https://protect-au.mimecast.com/s/fgnsCMwvLQTjojKBtPJG8T?domain=facebook.com<https://protect-au.mimecast.com/s/fgnsCMwvLQTjojKBtPJG8T?domain=facebook.com> | T https://protect-au.mimecast.com/s/TydSCNLwM9ionoKkiyHGcs?domain=twitter.com<https://protect-au.mimecast.com/s/TydSCNLwM9ionoKkiyHGcs?domain=twitter.com>

CRICOS 00026A
This email plus any attachments to it are confidential. Any unauthorised use is strictly prohibited. If you receive this email in error, please delete it and any attachments.

From: GPlates-discuss <gplates-discuss-bounces at mailman.sydney.edu.au<mailto:gplates-discuss-bounces at mailman.sydney.edu.au>> on behalf of "Eglington, Bruce" <bruce.eglington at usask.ca<mailto:bruce.eglington at usask.ca>>
Reply-To: GPlates general discussion mailing list <gplates-discuss at mailman.sydney.edu.au<mailto:gplates-discuss at mailman.sydney.edu.au>>
Date: Saturday, 28 April 2018 at 6:59 am
To: GPlates general discussion mailing list <gplates-discuss at mailman.sydney.edu.au<mailto:gplates-discuss at mailman.sydney.edu.au>>
Subject: Re: [GPlates-discuss] GPlates and linking to databases

Hi Christian
  Thanks for the suggestions.

Separate from the database issue, can you explain how to make a mid ocean ridge stay equally spaced between two continents or oceanic plates? I assumed that one would link the MOR line to one of the adjacent PlateID’s and specify the other adjacent PlateID as the conjugate plate but that does not seem to work. I have also tried to link the adjacent plates as LeftPlate and RightPlate but also no joy.

Any suggestions will be a great help as none of the tutorials seem to explain this, at least not in a way that makes sense to me.

Bruce


Bruce Eglington (Ph.D.)
Murray Pyke Chair
Geological Sciences
University of Saskatchewan
114 Science Place
Saskatoon
SK
S7N 5E2
Canada

bruce.eglington at usask.ca<mailto:bruce.eglington at usask.ca>
+1-306-966-5732

From: GPlates-discuss [mailto:gplates-discuss-bounces at mailman.sydney.edu.au] On Behalf Of Christian.Heine at shell.com<mailto:Christian.Heine at shell.com>
Sent: Wednesday, March 7, 2018 09:28
To: gplates-discuss at mailman.sydney.edu.au<mailto:gplates-discuss at mailman.sydney.edu.au>
Subject: Re: [GPlates-discuss] GPlates and linking to databases

Hi Bruce,

AFAIK there is no such capability, unless you’d count hooking up to a WFS server as one.

We had discussions a few years back of linking to PostGIS, but also we recently talked about the new OGC Geopackage standard (being sqlite-based I would also classify this as database, see geopackage.org) but so far this has not matured further (I think).  In theory the implementation should be relative straightforward as GPlates is already using the GDAL library (which reads PostGIS, sqlite, geopackage etc). However, the complications come in when turning relatively arbitrary database attributes/columns into the GPlates feature model (GPGIM).

I suppose some way you could go about this (thinking out loud)could be a crude combination of pyGPlates (or even using the built in Python shell) together with either the GDAL python library or something like psycopg2 to connect to your (geospatial) database (for some older project I used psycopg2+postgis/postgresql with GMT quite successfully). However, this will also require you to map the feature you import to the GPGIM. You could write some script to write out native GPML files from your DB as well to avoid the “lossy” shapefile format (ie col header truncation if > 12 chars, 255 char limits in attributes etc etc) which is the only way to bridge the ESRI world with GPlates currently.

I would very much support any effort to get GPlates and the GPGIM to read from DBs as this would also help a lot to improve the interface to commonly used GIS tools, especially in the corporate environment which somehow doesn’t like open formats.

Not sure if John & co will have some surprises in this direction in the upcoming 2.1 release.

Cheers,
Christian


From: GPlates-discuss [mailto:gplates-discuss-bounces at mailman.sydney.edu.au] On Behalf Of Eglington, Bruce
Sent: Wednesday, March 07, 2018 3:55 PM
To: 'gplates-discuss at mailman.sydney.edu.au' <gplates-discuss at mailman.sydney.edu.au<mailto:gplates-discuss at mailman.sydney.edu.au>>
Subject: [GPlates-discuss] GPlates and linking to databases

Good day
  Is there currently any design capability to link to tables or queries in any form of database already built in to GPlates or are the only data input options ROT, GPML, SHP, NETCDF and various raster formats? If not currently available, are there any plans to add database capabilities in the foreseeable  future?

Regards
   Bruce

Bruce Eglington (Ph.D.)
Murray Pyke Chair
Geological Sciences
University of Saskatchewan
114 Science Place
Saskatoon
SK
S7N 5E2
Canada

bruce.eglington at usask.ca<mailto:bruce.eglington at usask.ca>
+1-306-966-5732

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.sydney.edu.au/pipermail/gplates-discuss/attachments/20180429/e250d50a/attachment-0001.html>

More information about the GPlates-discuss mailing list