[GPlates-discuss] Saving global settings to project files

Eglington, Bruce bruce.eglington at usask.ca
Sun Apr 29 18:14:49 AEST 2018


Hi John
  Thanks

Bruce
________________________________
From: GPlates-discuss <gplates-discuss-bounces at mailman.sydney.edu.au> on behalf of John Cannon <john.cannon at sydney.edu.au>
Sent: Sunday, April 29, 2018 12:16:37 AM
To: GPlates general discussion mailing list
Subject: [GPlates-discuss] Saving global settings to project files

Hi Bruce,

> it would be very useful if the alpha value for the graticule could also be stored in the GPlates project file so that we don’t have to adjust it every time GPlates gets started.

Adding graticule alpha to project files is an interesting one. I can definitely see why you’d want that in your situation (where you load your own rotating graticules from a gpml file, and want the default graticule to disappear).

Normally we only save state relevant to the individual layers, and not “global” state (for reasons noted below), but I think it’s probably OK in some cases.


/detalMode on/

Currently we don’t save global state such anchor plate ID, or camera location/view/zoom, or whether view is currently in 3D globe or 2D map view. This is mainly so that if you load someone else’s project file it doesn’t change your global settings (such that when you’re finished with their project – maybe you’ve unloaded all their data files - then you have to manually change your global settings back, such as making the graticule reappear). However there is “File > Clear Session” which resets all project/session state, and this would reset these global settings back to their default (such as making the graticule reappear) as well as unload all files/layers. This is better, and easier, than manually unloading all the data files (which doesn’t make the graticule reappear). And loading a new project/session has essentially the same reset effect (but resets with loaded state instead of default state). So if you use projects (and recent sessions) to swap back and forth between work sessions then I don’t think saving some global state would be a problem. There is probably some other global state that falls under this category too, perhaps visual state such as background colour (I think you noted in the past) and maybe the text overlay. Though I’m not sure about things like camera and projection settings. Anchor plate ID should probably be left out since it’s not really a ‘visual’ state, although it’s not clear to me. Then there’s other things like the animation settings and current reconstruction time which are also unclear. Where to draw the line :)

As a side note, there are already some cases where global state is saved, such as the settings under “View > Geometry Visibility” such as “Show lines”, because those settings should have been individual layer settings (rather than applied globally to all layers).

/detailMode off/

Regards,
John

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

Hi John
  I have just had another look at one of the EarthByte group’s published plateboundary gpml files as I try to better understand how to implement mid-ocean ridges and subduction zones. In some cases I note that the PlateID field in the gpml file has a value 0 (zero) when half stage rotation is going to occur (since in this situation left and right plate ID fields are defined and take precedence over PlateID). I just want to check that, within GPlates you don’t assume that PlateID is zero and ALSO assume that zero is the spin axis. To deal more easily with true polar wander, Dave Evans and I now assume that plate id zero is the absolute reference frame and the spin axis is a different number, the value of which is likely to vary in different versions of our models as we add TPW complexity.

As an aside, for our models to be visually correct, we have to provide latitude/longitude graticules tied to the spin axis PlateID we use as separate gpml files and switch off the default GPlates graticule but that allows everything to look right, no matter what plate is considered to be fixed during reconstruction and visualization. As noted in a previous email, it would be very useful if the alpha value for the graticule could also be stored in the GPlates project file so that we don’t have to adjust it every time GPlates gets started.

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 00:03
To: GPlates general discussion mailing list <gplates-discuss at mailman.sydney.edu.au>
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/bTdACq7BKYt94mRPFZBB6M?domain=earthbyte.org<https://protect-au.mimecast.com/s/NiFaCr8DLRtxNL60tz5xl3?domain=earthbyte.org> | R http://www.researchgate.net/profile/Sabin_Zahirovic
F https://protect-au.mimecast.com/s/-gghCvl0PoCvBM4jhzk9hH?domain=facebook.com | T https://protect-au.mimecast.com/s/G2-dCwVLQmioOYPzhKGFrP?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/50b2b2ef/attachment-0001.html>


More information about the GPlates-discuss mailing list