[GPlates-discuss] CPT file with colour ramp

Tue Jan 17 06:22:00 AEDT 2017

Hi Bruce,

quick shot - I have not seen cpts with leading zeroes before - that might be a problem. Once I remove those, the world looks good - see screenshot. Revised cpt attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.cpt
Type: application/octet-stream
Size: 162 bytes
Desc: not available
URL: <http://mailman.sydney.edu.au/pipermail/gplates-discuss/attachments/20170116/c2f78e81/attachment-0001.obj>
-------------- next part --------------

Cheers,
Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.png
Type: image/png
Size: 1434311 bytes
Desc: not available
URL: <http://mailman.sydney.edu.au/pipermail/gplates-discuss/attachments/20170116/c2f78e81/attachment-0001.png>
-------------- next part --------------

On 16 Jan 2017, at 7:34 pm, Eglington, Bruce <bruce.eglington at usask.ca> wrote:

> Hi
>  I am having trouble getting a cpt file to work with colour ramps for a series of data where values range from negative to positive. Hopefully somebody can spot what I am doing incorrectly. The definitions are set up as:
> 
> 
> 
> -035	204	000	000	-005	255	102	102
> -005	255	255	051	-001	204	204	000
> -001	102	255	102	+001	000	153	000
> +001	102	102	255	+015	000	000	204
> 
> B	170	204	255
> F	145	111	111
> N	128	128	128
> 
> 
> There should be four stages in the colour ramping (values from -35 to -5 (reds), -5 to -1 (yelloes), -1 to +1 (greens) and +1 to +15 (blues)) but none of the ramp values with positive values work i.e. I never see any blue symbols even though there are lots in the dataset. I have tried adding a leading + symbol (as shown above) and have also excluded it but neither has an impact.
> 
> Any suggestions?
> 
> 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
> +1-306-966-5732
> 
> 
> -----Original Message-----
> From: GPlates-discuss [mailto:gplates-discuss-bounces at mailman.sydney.edu.au] On Behalf Of John Cannon
> Sent: Wednesday, January 11, 2017 07:53
> To: GPlates general discussion mailing list <gplates-discuss at mailman.sydney.edu.au>
> Subject: Re: [GPlates-discuss] Colour by feature age: Keeping colour constant during reconstruction
> 
> Hi Christian,
> 
>> One other question - the pygplates pages say that pygplates doesn't yet work on the built-in GPlates Python console, is this still the case in GPlates 2.0.x?
> 
> Yes that's still the case with GPlates 2.0. In other words, the official pyGPlates is not currently supported "inside" GPlates (eg, in the GPlates Python console). But it will be in the future (since it will be needed when Python plugins are supported) - although we don't currently have a good estimate of when that will be.
> 
> 
> /detailMode on/
> 
> It's a bit confusing because...
> 
> 
> Firstly, there's the new official pyGPlates API (programming interface)...
> 
> http://www.gplates.org/docs/pygplates/index.html
> 
> ...which does not currently work in GPlates (ie, can only be used in external Python scripts - by external I mean not running inside GPlates).
> 
> 
> But there's also an old, lesser known API that is currently used "inside" GPlates for colouring (like you see in ColorByProperty.py and that AbsoluteAge code snippet below)...
> 
> http://www.gplates.org/user-manual/PythonAPIs.html
> 
> ...but it will mostly get replaced by the official pyGPlates API when it is later supported "inside" GPlates. And this will affect the colouring scripts since they make calls to pyGPlates (and hence will be affected by the changed API). But since the old API is quite small we will probably also silently support it for backward compatibility (ie, so old colouring scripts don't bail).
> 
> /detailMode off/
> 
> 
> Regards,
> John
> 
> ________________________________________
> From: GPlates-discuss [gplates-discuss-bounces at mailman.sydney.edu.au] on behalf of Christian.Heine at shell.com [Christian.Heine at shell.com]
> Sent: Wednesday, 11 January 2017 9:31 PM
> To: gplates-discuss at mailman.sydney.edu.au
> Subject: Re: [GPlates-discuss] Colour by feature age: Keeping colour constant during reconstruction
> 
> Hi John,
> 
>> That's correct - the colouring will always be relative to the
>> reconstruction time. And thanks for providing your colouring tutorial
>> :)
> 
> Most welcome!
> 
>>> I guess one could also just point the ColorByProperty script to the
>> "FROMAGE" here, thinking about it...
>> 
>> Yes that works also. And is probably the easiest solution if you
>> already have the ColorByProperty script.
> 
> OK
> 
>>> Is there a simpler way to do this?
>> 
>> This isn't the simplest, but another alternative is to provide the
>> following script (using a similar procedure, to add the script, as
>> covered in your tutorial)...
> 
> [snip]
> 
>> ...perhaps calling it "AbsoluteAge.py". And make sure not to mix tabs
>> and spaces... as I just did a few moments ago :-) ...
> 
> haha, beginner's mistake ;-)
> 
>> It's basically a minor modification to class FeatureAge in the
>> existing "draw_style_demo.py" script that you can see in GPlates 1.5
>> (it's now stored inside the executable in GPlates 2.0 - so no longer visible).
> 
> Great - can confirm that your script works (did check for the space/tabs though :-) ), the beauty is that now only needs the CPT to be loaded and not the age attribute specified.
> 
>> In the future we will take another look at this sort of thing when
>> symbology is implemented/improved to see investigate easier ways to do
>> this (ie, without having to write a Python script).
> 
> Yep, cool.
> 
> One other question - the pygplates pages say that pygplates doesn't yet work on the built-in GPlates Python console, is this still the case in GPlates 2.0.x? I was trying something out yesterday and couldn't get pygplates to work in the console.
> 
> Thanks again,
> Christian
> 
> 
> 
>> ________________________________________
>> From: GPlates-discuss [gplates-discuss-bounces at mailman.sydney.edu.au]
>> on behalf of Christian.Heine at shell.com [Christian.Heine at shell.com]
>> Sent: Tuesday, 10 January 2017 3:39 AM
>> To: gplates-discuss at mailman.sydney.edu.au
>> Subject: [GPlates-discuss] Colour by feature age: Keeping colour
>> constant during reconstruction
>> 
>> Hi list,
>> 
>> happy 2017 first!
>> 
>> I recently had a query from a colleague and just wanted to check with
>> the list whether my reasoning/workflow is correct:
>> 
>> When reconstructing features in GPlates which are coloured by
>> "FeatureAge" the colouring will always be relative to reconstruction age.
>> I am using my GTS2012 colourscale
>> (https://bitbucket.org/chhei/gmt-cpts)
>> but this equally applies to the default GPlates FeatureAge colouring.
>> This means that a 50 Ma old feature at 40 Ma recon time will be be
>> 'yellowish' (using the GTS2012 cpt) as it is only 10 Myr old, but grow
>> darker as reconstruction time progresses towards present day.
>> 
>> In order to keep the feature colour constant (e.g. keep a Jurassic
>> chron "blue" over the course of the reconstruction) I have reverted to
>> the following procedure described here:
>> 
>> https://wiki.paleoearthlabs.org/tectonicwaters:gplates_coloring_featur
>> es_
>> by_absolute_age
>> 
>> where I introduce a new attribute column for the "FROMAGE" but then
>> use the ColorByProperty python script to colour the features for an
>> absolute age (ie keep the colouring constant) using the age value from
>> the new column.
>> 
>> Is there a simpler way to do this? I guess one could also just point
>> the ColorByProperty script to the "FROMAGE" here, thinking about it...
>> 
>> 
>> Cheers,
>> Christian
>> 
>> --
>>  Christian Heine, Ph.D.
>>  Upstream | Shell Intl. Exploration and Production B.V.
>>  Carel van Bylandtlaan 5 | C05 0.D15
>>  2596 HP Den Haag, The Netherlands
>> 
>>  SIP +31 7 0377 4341
>>  W: http://www.shell.com
>>  G: http://goo.gl/7GfvPZ
>> 
>> _______________________________________________
>> GPlates-discuss mailing list
>> GPlates-discuss at mailman.sydney.edu.au
>> http://mailman.sydney.edu.au/mailman/listinfo/gplates-discuss
>> 
>> 
>> 
>> _______________________________________________
>> GPlates-discuss mailing list
>> GPlates-discuss at mailman.sydney.edu.au
>> http://mailman.sydney.edu.au/mailman/listinfo/gplates-discuss
> 
> _______________________________________________
> GPlates-discuss mailing list
> GPlates-discuss at mailman.sydney.edu.au
> http://mailman.sydney.edu.au/mailman/listinfo/gplates-discuss
> 
> 
> 
> _______________________________________________
> GPlates-discuss mailing list
> GPlates-discuss at mailman.sydney.edu.au
> http://mailman.sydney.edu.au/mailman/listinfo/gplates-discuss
> 
> _______________________________________________
> GPlates-discuss mailing list
> GPlates-discuss at mailman.sydney.edu.au
> http://mailman.sydney.edu.au/mailman/listinfo/gplates-discuss
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.sydney.edu.au/pipermail/gplates-discuss/attachments/20170116/c2f78e81/attachment-0001.sig>