Problem with plotting polygons using PSXY and also problem with GMTSPATIAL

Discussion:

Kara Matthews

2014-07-21 01:59:38 UTC

Hello All,

I am using GMT 5.1.1 (r12972) on OSX Mavericks and am having a problem with plotting polygons (Im using the Mercator projection). Specifically I am getting banding across my map in instances when a polygon is being cropped by the map border. It seems that the polygon is wrapping the wrong way around the world. Compare test_0-360.pdf (artefact in bottom right) with test_required_plotting.pdf (this is what I want the map to look like). A couple of my other colleagues at work are having the same problem.

To try and get around this issue I used gmtspatial and the C option to close the polygons at the map border using my -R. This sometimes works, but not all the time. In some cases it seems to be inventing some strange polygons that I cant account for. See "test_0-360_gmtspatial.pdf"

So when gmtspatial wasnt working I used gmtconvert to separate my polygons out into separate files to then isolate the problem polygons. It seems that gmtspatial was making up some polygons with strange coordinates, coordinates that werent in the original polygon file. See prob_poly.txt that coincidentally has the same longitudes as my map region.

I was able to get around my problem by working out which polygons werent working (a bit of trial and error with awk and bash if statements) and then not plotting these but my clunky work-around is not ideal for making lots of figures, or plotting lots of polygon files.

I have also attached a test script and the input files in problem_with_psxy.zip. I have currently uncommented the set of lines I needed to make my ideal figure. You should be able to run this script from the folder if needed.

Thanks kindly for any help you can offer!!

Kind regards,
Kara

---

Dr Kara J. Matthews | Postdoctoral Researcher
School of Geosciences | Faculty of Science

THE UNIVERSITY OF SYDNEY
Rm 403 | Madsen Building (F09) | The University of Sydney | NSW | 2006
E: ***@sydney.edu.au
T: +61 2 9351 3625
W: www.earthbyte.org

Mailing list for GMT discussions of all kinds. If you are not sure you have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to ***@lists.hawaii.edu
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on gmt.soest.hawaii.edu instead.

Christian Heine

2014-07-23 21:40:16 UTC

Permalink

Hi Kara,

Post by Kara Matthews
I am using GMT 5.1.1 (r12972) on OSX Mavericks and am having a problem with plotting polygons (Im using the Mercator projection). Specifically I am getting banding across my map in instances when a polygon is being cropped by the map border. It seems that the polygon is wrapping the wrong way around the world. Compare test_0-360.pdf (artefact in bottom right) with test_required_plotting.pdf (this is what I want the map to look like). A couple of my other colleagues at work are having the same problem.

I just ran your test.sh script using Version 5.1.2_r13178 [64-bit] on OS 10.9.4 and get the attached result (test_0-360_chhei_crop.pdf). It is quite similar to the look of your 'desired' map. The only difference between your desired map and the one I generated using your script is the central part where there are white/unfilled patches (missing polygons?) as opposed to filled space in your required map.

Plotting COBreconstructed_${age}.00Ma.xy (2.pdf) and WARSreconstructed_${age}.00Ma.xy (1.pdf) independently results in the attached maps.

For what it's worth it might be helpful to dump the reconstructed data as *.shp file and throw this into QGIS and do basic geometry checking: In QGIS there's the menu Vector -> Check Geometry Validity (btw this should also work on OGR GMT files). But I suspect that this is more something related to dateline crossings.

Also, I ran your polygons through gmtspatial -Q+ for a handedness check - some few of your polygons are CW whereas the others are CCW handed. Not sure whether this causes GMT to misbehave (wouldn't assume so).

When exporting from GPlates, I can highly recommend to use the GMT OGR format (*.gmt) as this also exports the GPlates Feature ID which lets you search and identify a single rogue feature much much easier.

Possible workaround: ogr2ogr from the GDAL library has a "[-clipsrc [xmin ymin xmax ymax]" option which you can also use to clip the data.

Sorry for not being able to help with specific debugging info with your setup. Maybe an update to the recent SVN versions will fix some of the problems?

Greetings from NL,
Christian

Mailing list for GMT discussions of all kinds. If you are not sure you have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to ***@lists.hawaii.edu
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on gmt.soest.hawaii.edu instead.

Kara Matthews

2014-08-01 04:52:33 UTC

Permalink

Hi Christian, and hi everyone,

Thanks very much for your reply. The script I previously sent also
included my work-around in it so I could show what steps I had to take to
overcome the problem. Sorry, I should have said which lines needed
commenting out. Sabin downloaded the developer version 5.1.2 (r13381, 64
bit) and it didn¹t work for him.

I did some more testing and this is what I have concluded:
Using v5.1.1 (r12968, 64 bit) and 5.1.2 (r13381, 64 bit) I cannot use psxy
to make a mercator map that contains 180deg longitude and contains
polygons that are truncated by both the left and right map margins - I get
banding across the map. Depending on whether you specify your region in
the form 0-360 or 180/180 you can get a map with polygons that are
truncated by one of the margins without banding, but not both.

In the attached scripts I plot 8 rectangles (10 degrees wide) in each map.
4 are cut in half by the right margin and 4 are cut in half by the left
margin. The 4 rectangles at each margin differ as follows:
- 1 is digitised clockwise and coordinates are 180/180
- 1 is digitised counterclockwise and coordinates are 180/180
- 1 is digitised clockwise and coordinates are 0/360
- 1 is digitised counterclockwise and coordinates are 0/360

I ran tests in 3 locations (three directories within
polygon_fill_problem.zip): eastern US, Pacific, Australia

For each location, the top two maps have the same R region but are
specified either in the form 180/180 or 0/360, and the bottom two maps
have the same location but the R¹s are specified differently. I have
annotated this.

You will see that as long as the map doesn¹t include 180 degrees
longitude, see attached gmt_poly_plotting_test_E-US.pdf (from test1_E-US
example), then it is possible to make the map without banding, you just
have to choose the right R format. However, if the map includes 180
degrees longitude, see gmt_poly_plotting_test_AUS_2.pdf and
gmt_poly_plotting_test_PAC_2.pdf (from test2_PAC top two maps, and
test3_AUS bottom two maps), then it is not possible to have polygons
truncated on each side of the map without banding.

In the attached directories contained within polygon_fill_problem.zip all
the files are in place and you just have to run the scripts as they are. I
am using 5.1.1 (r12972) 64-bit.

Interestingly, I did some further testing and this problem does not occur
using v4.5.8 (64-bit)!!

I¹m sorry to be a bother, but I had a bunch of plotting scripts that I
made late last year using an older developer version of GMT5 (I can¹t
remember which version sorry but I can find out tonight if needed) that
work and now they don¹t. Plus I know a couple of others in the group
having this problem.

Does anyone have any recommendations? To the developers, is there a way to
change the GMT thing responsible for this back to the way it was in v4.5.8?

Thank you very very much for your help Christian and to anyone else who
can offer any suggestions.

Cheers,
Kara

Post by Christian Heine
Hi Kara,

Post by Kara Matthews
I am using GMT 5.1.1 (r12972) on OSX Mavericks and am having a problem
with plotting polygons (I¹m using the Mercator projection). Specifically
I am getting banding across my map in instances when a polygon is being
cropped by the map border. It seems that the polygon is wrapping the
wrong way around the world. Compare ³test_0-360.pdf² (artefact in bottom
right) with ³test_required_plotting.pdf² (this is what I want the map to
look like). A couple of my other colleagues at work are having the same
problem.

I just ran your test.sh script using Version 5.1.2_r13178 [64-bit] on OS
10.9.4 and get the attached result (test_0-360_chhei_crop.pdf). It is
quite similar to the look of your 'desired' map. The only difference
between your desired map and the one I generated using your script is the
central part where there are white/unfilled patches (missing polygons?)
as opposed to filled space in your required map.
Plotting COBreconstructed_${age}.00Ma.xy (2.pdf) and
WARSreconstructed_${age}.00Ma.xy (1.pdf) independently results in the
attached maps.
For what it's worth it might be helpful to dump the reconstructed data as
*.shp file and throw this into QGIS and do basic geometry checking: In
QGIS there's the menu Vector -> Check Geometry Validity (btw this should
also work on OGR GMT files). But I suspect that this is more something
related to dateline crossings.
Also, I ran your polygons through gmtspatial -Q+ for a handedness check -
some few of your polygons are CW whereas the others are CCW handed. Not
sure whether this causes GMT to misbehave (wouldn't assume so).
When exporting from GPlates, I can highly recommend to use the GMT OGR
format (*.gmt) as this also exports the GPlates Feature ID which lets you
search and identify a single rogue feature much much easier.
Possible workaround: ogr2ogr from the GDAL library has a "[-clipsrc [xmin
ymin xmax ymax]" option which you can also use to clip the data.
Sorry for not being able to help with specific debugging info with your
setup. Maybe an update to the recent SVN versions will fix some of the
problems?
Greetings from NL,
Christian
Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New
Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on
gmt.soest.hawaii.edu instead.

Post by Kara Matthews
To try and get around this issue I used gmtspatial and the C option to
close the polygons at the map border using my -R. This sometimes works,
but not all the time. In some cases it seems to be inventing some
strange polygons that I can¹t account for. See
"test_0-360_gmtspatial.pdf"
So when gmtspatial wasn¹t working I used gmtconvert to separate my
polygons out into separate files to then isolate the problem polygons.
It seems that gmtspatial was making up some polygons with strange
coordinates, coordinates that weren¹t in the original polygon file. See
prob_poly.txt that coincidentally has the same longitudes as my map
region.
I was able to get around my problem by working out which polygons
weren¹t working (a bit of trial and error with awk and bash if
statements) and then not plotting these but my clunky work-around is
not ideal for making lots of figures, or plotting lots of polygon files.
I have also attached a test script and the input files in
problem_with_psxy.zip. I have currently uncommented the set of lines I
needed to make my ideal figure. You should be able to run this script
from the folder if needed.
Thanks kindly for any help you can offer!!
Kind regards,
Kara
---
Dr Kara J. Matthews | Postdoctoral Researcher
School of Geosciences | Faculty of Science
THE UNIVERSITY OF SYDNEY
Rm 403 | Madsen Building (F09) | The University of Sydney | NSW | 2006
T: +61 2 9351 3625
W: www.earthbyte.org
Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first. To formally report bugs or
request features, please register and add New Issue on
gmt.soest.hawaii.edu To unsubscribe, send the message "signoff gmt-help"
1, 2014 - please use forum on gmt.soest.hawaii.edu instead.
<test_0-360.pdf><test_0-360_gmtspatial.pdf><test_required_plotting.pdf><p
rob_poly.txt><problem_with_psxy.zip>

Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New
Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on
gmt.soest.hawaii.edu instead.

Mailing list for GMT discussions of all kinds. If you are not sure you have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to ***@lists.hawaii.edu
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on gmt.soest.hawaii.edu instead.

Sabin Zahirovic

2014-08-02 05:07:24 UTC

Permalink

Hi all,

Kara, thanks so much for putting this together, itâs a great summary of
the problem.

Just a few things to add from my own experience with the problem:

* Using .gmt files makes no difference and still causes the horizontal
banding artefacts
* Last year I generated a bunch of GMT-files last year and had run a
plotting script successfully last year - I re-ran the same script recently
and it plotted with the artefacts
* Using GPlates 1.3 and 1.4 output causes the same problems in the new
versions of GMT - so it definitely seems that something has changed in GMT
* I tried using the GMT flags to force PSXY to understand that itâs
plotting geographic data, and that didnât help either

I can also confirm all of Karaâs observations. If this is a problem that
is unlikely to be fixed in the near term, is it relatively straightforward
to extract GMT 4.5.8 (or similar) from the GMT SVN? Otherwise Iâll have to
try dig up an old compiled folderâŠ

Thanks for the help and time in advance!

Cheers,
Sabin

PS: I attach a sample of my own problem, the grey polygons (LIPs) that
cross the east map boundary cause the artefact. However, as Kara
demonstrated, often the west boundary is also affected.
--
MR SABIN ZAHIROVIC | PhD Candidate
School of Geosciences | Faculty of Science

THE UNIVERSITY OF SYDNEY
Rm 414, Madsen Building F09 | The University of Sydney | NSW | 2006
M +61 416 775 589
E ***@sydney.edu.au | W http://www.earthbyte.org
<http://www.earthbyte.org/>

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.

Post by Kara Matthews
Hi Christian, and hi everyone,
Thanks very much for your reply. The script I previously sent also
included my work-around in it so I could show what steps I had to take to
overcome the problem. Sorry, I should have said which lines needed
commenting out. Sabin downloaded the developer version 5.1.2 (r13381, 64
bit) and it didnÂ¹t work for him.
Using v5.1.1 (r12968, 64 bit) and 5.1.2 (r13381, 64 bit) I cannot use psxy
to make a mercator map that contains 180deg longitude and contains
polygons that are truncated by both the left and right map margins - I get
banding across the map. Depending on whether you specify your region in
the form 0-360 or Â180/Â180 you can get a map with polygons that are
truncated by one of the margins without banding, but not both.
In the attached scripts I plot 8 rectangles (10 degrees wide) in each map.
4 are cut in half by the right margin and 4 are cut in half by the left
- 1 is digitised clockwise and coordinates are Â180/180
- 1 is digitised counterclockwise and coordinates are Â180/180
- 1 is digitised clockwise and coordinates are 0/360
- 1 is digitised counterclockwise and coordinates are 0/360
I ran tests in 3 locations (three directories within
polygon_fill_problem.zip): eastern US, Pacific, Australia
For each location, the top two maps have the same ÂR region but are
specified either in the form Â180/180 or 0/360, and the bottom two maps
have the same location but the ÂRÂ¹s are specified differently. I have
annotated this.
You will see that as long as the map doesnÂ¹t include 180 degrees
longitude, see attached gmt_poly_plotting_test_E-US.pdf (from test1_E-US
example), then it is possible to make the map without banding, you just
have to choose the right ÂR format. However, if the map includes 180
degrees longitude, see gmt_poly_plotting_test_AUS_2.pdf and
gmt_poly_plotting_test_PAC_2.pdf (from test2_PAC top two maps, and
test3_AUS bottom two maps), then it is not possible to have polygons
truncated on each side of the map without banding.
In the attached directories contained within polygon_fill_problem.zip all
the files are in place and you just have to run the scripts as they are. I
am using 5.1.1 (r12972) 64-bit.
Interestingly, I did some further testing and this problem does not occur
using v4.5.8 (64-bit)!!
IÂ¹m sorry to be a bother, but I had a bunch of plotting scripts that I
made late last year using an older developer version of GMT5 (I canÂ¹t
remember which version sorry Â but I can find out tonight if needed) that
work and now they donÂ¹t. Plus I know a couple of others in the group
having this problem.
Does anyone have any recommendations? To the developers, is there a way to
change the GMT thing responsible for this back to the way it was in v4.5.8?
Thank you very very much for your help Christian and to anyone else who
can offer any suggestions.
Cheers,
Kara

Post by Christian Heine
Hi Kara,

Post by Kara Matthews
I am using GMT 5.1.1 (r12972) on OSX Mavericks and am having a problem
with plotting polygons (IÂ¹m using the Mercator projection). Specifically
I am getting banding across my map in instances when a polygon is being
cropped by the map border. It seems that the polygon is wrapping the
wrong way around the world. Compare Â³test_0-360.pdfÂ² (artefact in bottom
right) with Â³test_required_plotting.pdfÂ² (this is what I want the map to
look like). A couple of my other colleagues at work are having the same
problem.

I just ran your test.sh script using Version 5.1.2_r13178 [64-bit] on OS
10.9.4 and get the attached result (test_0-360_chhei_crop.pdf). It is
quite similar to the look of your 'desired' map. The only difference
between your desired map and the one I generated using your script is the
central part where there are white/unfilled patches (missing polygons?)
as opposed to filled space in your required map.
Plotting COBreconstructed_${age}.00Ma.xy (2.pdf) and
WARSreconstructed_${age}.00Ma.xy (1.pdf) independently results in the
attached maps.
For what it's worth it might be helpful to dump the reconstructed data as
*.shp file and throw this into QGIS and do basic geometry checking: In
QGIS there's the menu Vector -> Check Geometry Validity (btw this should
also work on OGR GMT files). But I suspect that this is more something
related to dateline crossings.
Also, I ran your polygons through gmtspatial -Q+ for a handedness check -
some few of your polygons are CW whereas the others are CCW handed. Not
sure whether this causes GMT to misbehave (wouldn't assume so).
When exporting from GPlates, I can highly recommend to use the GMT OGR
format (*.gmt) as this also exports the GPlates Feature ID which lets you
search and identify a single rogue feature much much easier.
Possible workaround: ogr2ogr from the GDAL library has a "[-clipsrc [xmin
ymin xmax ymax]" option which you can also use to clip the data.
Sorry for not being able to help with specific debugging info with your
setup. Maybe an update to the recent SVN versions will fix some of the
problems?
Greetings from NL,
Christian
Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New
Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on
gmt.soest.hawaii.edu instead.

Post by Kara Matthews
To try and get around this issue I used gmtspatial and the ÂC option to
close the polygons at the map border using my -R. This sometimes works,
but not all the time. In some cases it seems to be inventing some
strange polygons that I canÂ¹t account for. See
"test_0-360_gmtspatial.pdf"
So when gmtspatial wasnÂ¹t working I used gmtconvert to separate my
polygons out into separate files to then isolate the problem polygons.
It seems that gmtspatial was making up some polygons with strange
coordinates, coordinates that werenÂ¹t in the original polygon file. See
prob_poly.txt that coincidentally has the same longitudes as my map
region.
I was able to get around my problem by working out which polygons
werenÂ¹t working (a bit of trial and error with awk and bash if
statements) and then not plotting theseÅ but my clunky work-around is
not ideal for making lots of figures, or plotting lots of polygon files.
I have also attached a test script and the input files in
problem_with_psxy.zip. I have currently uncommented the set of lines I
needed to make my ideal figure. You should be able to run this script
from the folder if needed.
Thanks kindly for any help you can offer!!
Kind regards,
Kara
---
Dr Kara J. Matthews | Postdoctoral Researcher
School of Geosciences | Faculty of Science
THE UNIVERSITY OF SYDNEY
Rm 403 | Madsen Building (F09) | The University of Sydney | NSW | 2006
T: +61 2 9351 3625
W: www.earthbyte.org
Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first. To formally report bugs or
request features, please register and add New Issue on
gmt.soest.hawaii.edu To unsubscribe, send the message "signoff gmt-help"
1, 2014 - please use forum on gmt.soest.hawaii.edu instead.
<test_0-360.pdf><test_0-360_gmtspatial.pdf><test_required_plotting.pdf><
p
rob_poly.txt><problem_with_psxy.zip>

Mailing list for GMT discussions of all kinds. If you are not sure you have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to ***@lists.hawaii.edu
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on gmt.soest.hawaii.edu instead.

Joaquim Luis

2014-08-02 05:37:03 UTC

Permalink

I can also confirm all of Kara’s observations. If this is a problem that
is unlikely to be fixed in the near term, is it relatively straightforward
to extract GMT 4.5.8 (or similar) from the GMT SVN? Otherwise I’ll have to
try dig up an old compiled folder…

This is a known issue. For those of you that need it badly, the simplest solution is to have installed both GMT4 and GMT5. See the cookbook for how to have both running side by side.

Joaquim

Thanks for the help and time in advance!
Cheers,
Sabin
PS: I attach a sample of my own problem, the grey polygons (LIPs) that
cross the east map boundary cause the artefact. However, as Kara
demonstrated, often the west boundary is also affected.
--
MR SABIN ZAHIROVIC | PhD Candidate
School of Geosciences | Faculty of Science
THE UNIVERSITY OF SYDNEY
Rm 414, Madsen Building F09 | The University of Sydney | NSW | 2006
M +61 416 775 589
<http://www.earthbyte.org/>
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.

Post by Kara Matthews
Hi Christian, and hi everyone,
Thanks very much for your reply. The script I previously sent also
included my work-around in it so I could show what steps I had to take to
overcome the problem. Sorry, I should have said which lines needed
commenting out. Sabin downloaded the developer version 5.1.2 (r13381, 64
bit) and it didn¹t work for him.
Using v5.1.1 (r12968, 64 bit) and 5.1.2 (r13381, 64 bit) I cannot use psxy
to make a mercator map that contains 180deg longitude and contains
polygons that are truncated by both the left and right map margins - I get
banding across the map. Depending on whether you specify your region in
the form 0-360 or 180/180 you can get a map with polygons that are
truncated by one of the margins without banding, but not both.
In the attached scripts I plot 8 rectangles (10 degrees wide) in each map.
4 are cut in half by the right margin and 4 are cut in half by the left
- 1 is digitised clockwise and coordinates are 180/180
- 1 is digitised counterclockwise and coordinates are 180/180
- 1 is digitised clockwise and coordinates are 0/360
- 1 is digitised counterclockwise and coordinates are 0/360
I ran tests in 3 locations (three directories within
polygon_fill_problem.zip): eastern US, Pacific, Australia
For each location, the top two maps have the same R region but are
specified either in the form 180/180 or 0/360, and the bottom two maps
have the same location but the R¹s are specified differently. I have
annotated this.
You will see that as long as the map doesn¹t include 180 degrees
longitude, see attached gmt_poly_plotting_test_E-US.pdf (from test1_E-US
example), then it is possible to make the map without banding, you just
have to choose the right R format. However, if the map includes 180
degrees longitude, see gmt_poly_plotting_test_AUS_2.pdf and
gmt_poly_plotting_test_PAC_2.pdf (from test2_PAC top two maps, and
test3_AUS bottom two maps), then it is not possible to have polygons
truncated on each side of the map without banding.
In the attached directories contained within polygon_fill_problem.zip all
the files are in place and you just have to run the scripts as they are. I
am using 5.1.1 (r12972) 64-bit.
Interestingly, I did some further testing and this problem does not occur
using v4.5.8 (64-bit)!!
I¹m sorry to be a bother, but I had a bunch of plotting scripts that I
made late last year using an older developer version of GMT5 (I can¹t
remember which version sorry but I can find out tonight if needed) that
work and now they don¹t. Plus I know a couple of others in the group
having this problem.
Does anyone have any recommendations? To the developers, is there a way to
change the GMT thing responsible for this back to the way it was in v4.5.8?
Thank you very very much for your help Christian and to anyone else who
can offer any suggestions.
Cheers,
Kara

Post by Christian Heine
Hi Kara,

I just ran your test.sh script using Version 5.1.2_r13178 [64-bit] on OS
10.9.4 and get the attached result (test_0-360_chhei_crop.pdf). It is
quite similar to the look of your 'desired' map. The only difference
between your desired map and the one I generated using your script is the
central part where there are white/unfilled patches (missing polygons?)
as opposed to filled space in your required map.
Plotting COBreconstructed_${age}.00Ma.xy (2.pdf) and
WARSreconstructed_${age}.00Ma.xy (1.pdf) independently results in the
attached maps.
For what it's worth it might be helpful to dump the reconstructed data as
*.shp file and throw this into QGIS and do basic geometry checking: In
QGIS there's the menu Vector -> Check Geometry Validity (btw this should
also work on OGR GMT files). But I suspect that this is more something
related to dateline crossings.
Also, I ran your polygons through gmtspatial -Q+ for a handedness check -
some few of your polygons are CW whereas the others are CCW handed. Not
sure whether this causes GMT to misbehave (wouldn't assume so).
When exporting from GPlates, I can highly recommend to use the GMT OGR
format (*.gmt) as this also exports the GPlates Feature ID which lets you
search and identify a single rogue feature much much easier.
Possible workaround: ogr2ogr from the GDAL library has a "[-clipsrc [xmin
ymin xmax ymax]" option which you can also use to clip the data.
Sorry for not being able to help with specific debugging info with your
setup. Maybe an update to the recent SVN versions will fix some of the
problems?
Greetings from NL,
Christian
Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New
Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on
gmt.soest.hawaii.edu instead.

Post by Kara Matthews
To try and get around this issue I used gmtspatial and the C option to
close the polygons at the map border using my -R. This sometimes works,
but not all the time. In some cases it seems to be inventing some
strange polygons that I can¹t account for. See
"test_0-360_gmtspatial.pdf"
So when gmtspatial wasn¹t working I used gmtconvert to separate my
polygons out into separate files to then isolate the problem polygons.
It seems that gmtspatial was making up some polygons with strange
coordinates, coordinates that weren¹t in the original polygon file. See
prob_poly.txt that coincidentally has the same longitudes as my map
region.
I was able to get around my problem by working out which polygons
weren¹t working (a bit of trial and error with awk and bash if
statements) and then not plotting theseŠ but my clunky work-around is
not ideal for making lots of figures, or plotting lots of polygon files.
I have also attached a test script and the input files in
problem_with_psxy.zip. I have currently uncommented the set of lines I
needed to make my ideal figure. You should be able to run this script
from the folder if needed.
Thanks kindly for any help you can offer!!
Kind regards,
Kara
---
Dr Kara J. Matthews | Postdoctoral Researcher
School of Geosciences | Faculty of Science
THE UNIVERSITY OF SYDNEY
Rm 403 | Madsen Building (F09) | The University of Sydney | NSW | 2006
T: +61 2 9351 3625
W: www.earthbyte.org
Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first. To formally report bugs or
request features, please register and add New Issue on
gmt.soest.hawaii.edu To unsubscribe, send the message "signoff gmt-help"
1, 2014 - please use forum on gmt.soest.hawaii.edu instead.
<test_0-360.pdf><test_0-360_gmtspatial.pdf><test_required_plotting.pdf><
p
rob_poly.txt><problem_with_psxy.zip>

Mailing list for GMT discussions of all kinds. If you are not sure you have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New Issue on gmt.soest.hawaii.edu
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on gmt.soest.hawaii.edu instead.
<new_gmt_0025.png>

Mailing list for GMT discussions of all kinds. If you are not sure you have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to ***@lists.hawaii.edu
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on gmt.soest.hawaii.edu instead.

Paul Wessel

2014-08-02 05:57:46 UTC

Permalink

Kara, Sabin-

To help me debug this issue asap, please provide just ONE polygon and a psxy command that demonstrates the problem - that way I don't have to spend time trimming down the more complicated examples. I am on a short leash time-wise and could need the help!

-p

Post by Joaquim Luis

This is a known issue. For those of you that need it badly, the simplest solution is to have installed both GMT4 and GMT5. See the cookbook for how to have both running side by side.
Joaquim

Post by Kara Matthews
Hi Christian, and hi everyone,
Thanks very much for your reply. The script I previously sent also
included my work-around in it so I could show what steps I had to take to
overcome the problem. Sorry, I should have said which lines needed
commenting out. Sabin downloaded the developer version 5.1.2 (r13381, 64
bit) and it didn¹t work for him.
Using v5.1.1 (r12968, 64 bit) and 5.1.2 (r13381, 64 bit) I cannot use psxy
to make a mercator map that contains 180deg longitude and contains
polygons that are truncated by both the left and right map margins - I get
banding across the map. Depending on whether you specify your region in
the form 0-360 or 180/180 you can get a map with polygons that are
truncated by one of the margins without banding, but not both.
In the attached scripts I plot 8 rectangles (10 degrees wide) in each map.
4 are cut in half by the right margin and 4 are cut in half by the left
- 1 is digitised clockwise and coordinates are 180/180
- 1 is digitised counterclockwise and coordinates are 180/180
- 1 is digitised clockwise and coordinates are 0/360
- 1 is digitised counterclockwise and coordinates are 0/360
I ran tests in 3 locations (three directories within
polygon_fill_problem.zip): eastern US, Pacific, Australia
For each location, the top two maps have the same R region but are
specified either in the form 180/180 or 0/360, and the bottom two maps
have the same location but the R¹s are specified differently. I have
annotated this.
You will see that as long as the map doesn¹t include 180 degrees
longitude, see attached gmt_poly_plotting_test_E-US.pdf (from test1_E-US
example), then it is possible to make the map without banding, you just
have to choose the right R format. However, if the map includes 180
degrees longitude, see gmt_poly_plotting_test_AUS_2.pdf and
gmt_poly_plotting_test_PAC_2.pdf (from test2_PAC top two maps, and
test3_AUS bottom two maps), then it is not possible to have polygons
truncated on each side of the map without banding.
In the attached directories contained within polygon_fill_problem.zip all
the files are in place and you just have to run the scripts as they are. I
am using 5.1.1 (r12972) 64-bit.
Interestingly, I did some further testing and this problem does not occur
using v4.5.8 (64-bit)!!
I¹m sorry to be a bother, but I had a bunch of plotting scripts that I
made late last year using an older developer version of GMT5 (I can¹t
remember which version sorry but I can find out tonight if needed) that
work and now they don¹t. Plus I know a couple of others in the group
having this problem.
Does anyone have any recommendations? To the developers, is there a way to
change the GMT thing responsible for this back to the way it was in v4.5.8?
Thank you very very much for your help Christian and to anyone else who
can offer any suggestions.
Cheers,
Kara

Post by Christian Heine
Hi Kara,

I just ran your test.sh script using Version 5.1.2_r13178 [64-bit] on OS
10.9.4 and get the attached result (test_0-360_chhei_crop.pdf). It is
quite similar to the look of your 'desired' map. The only difference
between your desired map and the one I generated using your script is the
central part where there are white/unfilled patches (missing polygons?)
as opposed to filled space in your required map.
Plotting COBreconstructed_${age}.00Ma.xy (2.pdf) and
WARSreconstructed_${age}.00Ma.xy (1.pdf) independently results in the
attached maps.
For what it's worth it might be helpful to dump the reconstructed data as
*.shp file and throw this into QGIS and do basic geometry checking: In
QGIS there's the menu Vector -> Check Geometry Validity (btw this should
also work on OGR GMT files). But I suspect that this is more something
related to dateline crossings.
Also, I ran your polygons through gmtspatial -Q+ for a handedness check -
some few of your polygons are CW whereas the others are CCW handed. Not
sure whether this causes GMT to misbehave (wouldn't assume so).
When exporting from GPlates, I can highly recommend to use the GMT OGR
format (*.gmt) as this also exports the GPlates Feature ID which lets you
search and identify a single rogue feature much much easier.
Possible workaround: ogr2ogr from the GDAL library has a "[-clipsrc [xmin
ymin xmax ymax]" option which you can also use to clip the data.
Sorry for not being able to help with specific debugging info with your
setup. Maybe an update to the recent SVN versions will fix some of the
problems?
Greetings from NL,
Christian
Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New
Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on
gmt.soest.hawaii.edu instead.

Post by Kara Matthews
To try and get around this issue I used gmtspatial and the C option to
close the polygons at the map border using my -R. This sometimes works,
but not all the time. In some cases it seems to be inventing some
strange polygons that I can¹t account for. See
"test_0-360_gmtspatial.pdf"
So when gmtspatial wasn¹t working I used gmtconvert to separate my
polygons out into separate files to then isolate the problem polygons.
It seems that gmtspatial was making up some polygons with strange
coordinates, coordinates that weren¹t in the original polygon file. See
prob_poly.txt that coincidentally has the same longitudes as my map
region.
I was able to get around my problem by working out which polygons
weren¹t working (a bit of trial and error with awk and bash if
statements) and then not plotting theseŠ but my clunky work-around is
not ideal for making lots of figures, or plotting lots of polygon files.
I have also attached a test script and the input files in
problem_with_psxy.zip. I have currently uncommented the set of lines I
needed to make my ideal figure. You should be able to run this script
from the folder if needed.
Thanks kindly for any help you can offer!!
Kind regards,
Kara
---
Dr Kara J. Matthews | Postdoctoral Researcher
School of Geosciences | Faculty of Science
THE UNIVERSITY OF SYDNEY
Rm 403 | Madsen Building (F09) | The University of Sydney | NSW | 2006
T: +61 2 9351 3625
W: www.earthbyte.org
Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first. To formally report bugs or
request features, please register and add New Issue on
gmt.soest.hawaii.edu To unsubscribe, send the message "signoff gmt-help"
1, 2014 - please use forum on gmt.soest.hawaii.edu instead.
<test_0-360.pdf><test_0-360_gmtspatial.pdf><test_required_plotting.pdf><
p
rob_poly.txt><problem_with_psxy.zip>

Mailing list for GMT discussions of all kinds. If you are not sure you have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New Issue on gmt.soest.hawaii.edu
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on gmt.soest.hawaii.edu instead.
<new_gmt_0025.png>

Mailing list for GMT discussions of all kinds. If you are not sure you have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New Issue on gmt.soest.hawaii.edu
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on gmt.soest.hawaii.edu instead.

Mailing list for GMT discussions of all kinds. If you are not sure you have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to ***@lists.hawaii.edu
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on gmt.soest.hawaii.edu instead.

Kara Matthews

2014-08-03 04:28:10 UTC

Permalink

Hi Paul,

We can use GMT4 for now, and of course we can easily wait til after your
deadlines! :-)

Here is the line:

gmt psxy Pacific_polygons.txt -R170/205/-60/-20 -JM8 -Ba30NSWE -V
-Wthick,black -Gred > test.ps

In the above case the outlines plot fine, itâs the -G that is the problem.

Thanks for looking into this for us, we really appreciate it!

Cheers,
Kara

Post by Paul Wessel
Kara, Sabin-
To help me debug this issue asap, please provide just ONE polygon and a
psxy command that demonstrates the problem - that way I don't have to
spend time trimming down the more complicated examples. I am on a short
leash time-wise and could need the help!
-p

Post by Joaquim Luis

Post by Sabin Zahirovic
I can also confirm all of Karaâs observations. If this is a problem that
is unlikely to be fixed in the near term, is it relatively
straightforward
to extract GMT 4.5.8 (or similar) from the GMT SVN? Otherwise Iâll have to
try dig up an old compiled folderâŠ

This is a known issue. For those of you that need it badly, the
simplest solution is to have installed both GMT4 and GMT5. See the
cookbook for how to have both running side by side.
Joaquim

Post by Sabin Zahirovic
Thanks for the help and time in advance!
Cheers,
Sabin
PS: I attach a sample of my own problem, the grey polygons (LIPs) that
cross the east map boundary cause the artefact. However, as Kara
demonstrated, often the west boundary is also affected.
--
MR SABIN ZAHIROVIC | PhD Candidate
School of Geosciences | Faculty of Science
THE UNIVERSITY OF SYDNEY
Rm 414, Madsen Building F09 | The University of Sydney | NSW | 2006
M +61 416 775 589
<http://www.earthbyte.org/>
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.

Post by Christian Heine
Hi Kara,

I just ran your test.sh script using Version 5.1.2_r13178 [64-bit] on OS
10.9.4 and get the attached result (test_0-360_chhei_crop.pdf). It is
quite similar to the look of your 'desired' map. The only difference
between your desired map and the one I generated using your script is the
central part where there are white/unfilled patches (missing polygons?)
as opposed to filled space in your required map.
Plotting COBreconstructed_${age}.00Ma.xy (2.pdf) and
WARSreconstructed_${age}.00Ma.xy (1.pdf) independently results in the
attached maps.
For what it's worth it might be helpful to dump the reconstructed data as
*.shp file and throw this into QGIS and do basic geometry checking: In
QGIS there's the menu Vector -> Check Geometry Validity (btw this should
also work on OGR GMT files). But I suspect that this is more something
related to dateline crossings.
Also, I ran your polygons through gmtspatial -Q+ for a handedness check -
some few of your polygons are CW whereas the others are CCW handed. Not
sure whether this causes GMT to misbehave (wouldn't assume so).
When exporting from GPlates, I can highly recommend to use the GMT OGR
format (*.gmt) as this also exports the GPlates Feature ID which lets you
search and identify a single rogue feature much much easier.
Possible workaround: ogr2ogr from the GDAL library has a "[-clipsrc [xmin
ymin xmax ymax]" option which you can also use to clip the data.
Sorry for not being able to help with specific debugging info with your
setup. Maybe an update to the recent SVN versions will fix some of the
problems?
Greetings from NL,
Christian
Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New
Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on
gmt.soest.hawaii.edu instead.

Mailing list for GMT discussions of all kinds. If you are not sure
you have found a bug, discuss it here first.
To formally report bugs or request features, please register and add
New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum
on gmt.soest.hawaii.edu instead.
<new_gmt_0025.png>

Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add
New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum
on gmt.soest.hawaii.edu instead.

Mailing list for GMT discussions of all kinds. If you are not sure you have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to ***@lists.hawaii.edu
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on gmt.soest.hawaii.edu instead.

Kara Matthews

2014-08-03 04:37:28 UTC

Permalink

Sorry Paul, here is the line and one polygon (also attached):

gmt psxy Pacific_polygon.txt -R170/205/-60/-20 -JM8 -Ba30NSWE -V
-Wthick,black -Gred > test1.ps

PAC CW

210 -46
210 -51
200 -51
200 -46
210 -46

Thanks again!

Kara, Sabin-
To help me debug this issue asap, please provide just ONE polygon and a
psxy command that demonstrates the problem - that way I don't have to
spend time trimming down the more complicated examples. I am on a short
leash time-wise and could need the help!
-p

Post by Joaquim Luis

This is a known issue. For those of you that need it badly, the
simplest solution is to have installed both GMT4 and GMT5. See the
cookbook for how to have both running side by side.
Joaquim

Post by Christian Heine
Hi Kara,

I just ran your test.sh script using Version 5.1.2_r13178 [64-bit] on OS
10.9.4 and get the attached result (test_0-360_chhei_crop.pdf). It is
quite similar to the look of your 'desired' map. The only difference
between your desired map and the one I generated using your script is the
central part where there are white/unfilled patches (missing polygons?)
as opposed to filled space in your required map.
Plotting COBreconstructed_${age}.00Ma.xy (2.pdf) and
WARSreconstructed_${age}.00Ma.xy (1.pdf) independently results in the
attached maps.
For what it's worth it might be helpful to dump the reconstructed data as
*.shp file and throw this into QGIS and do basic geometry checking: In
QGIS there's the menu Vector -> Check Geometry Validity (btw this should
also work on OGR GMT files). But I suspect that this is more something
related to dateline crossings.
Also, I ran your polygons through gmtspatial -Q+ for a handedness check -
some few of your polygons are CW whereas the others are CCW handed. Not
sure whether this causes GMT to misbehave (wouldn't assume so).
When exporting from GPlates, I can highly recommend to use the GMT OGR
format (*.gmt) as this also exports the GPlates Feature ID which lets you
search and identify a single rogue feature much much easier.
Possible workaround: ogr2ogr from the GDAL library has a "[-clipsrc [xmin
ymin xmax ymax]" option which you can also use to clip the data.
Sorry for not being able to help with specific debugging info with your
setup. Maybe an update to the recent SVN versions will fix some of the
problems?
Greetings from NL,
Christian
Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New
Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on
gmt.soest.hawaii.edu instead.

Mailing list for GMT discussions of all kinds. If you are not sure
you have found a bug, discuss it here first.
To formally report bugs or request features, please register and add
New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum
on gmt.soest.hawaii.edu instead.
<new_gmt_0025.png>

Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add
New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum
on gmt.soest.hawaii.edu instead.

Mailing list for GMT discussions of all kinds. If you are not sure you have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to ***@lists.hawaii.edu
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on gmt.soest.hawaii.edu instead.

Sabin Zahirovic

2014-08-03 05:49:07 UTC

Permalink

Hi Joaquim,

I do have GMT4 and GMT5 running side by side. However, the bug is in both
GMT4 and GMT5. The workaround is to install an older version of GMT4, such
as GMT 4.5.8.

Paul, thanks for offering to look at this. Your time and help is much
appreciated!

Cheers,
Sabin
--
MR SABIN ZAHIROVIC | PhD Candidate
School of Geosciences | Faculty of Science

THE UNIVERSITY OF SYDNEY
Rm 414, Madsen Building F09 | The University of Sydney | NSW | 2006
M +61 416 775 589
E ***@sydney.edu.au | W http://www.earthbyte.org
<http://www.earthbyte.org/>

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.

Post by Joaquim Luis

I can also confirm all of Kara’s observations. If this is a problem that
is unlikely to be fixed in the near term, is it relatively
straightforward
to extract GMT 4.5.8 (or similar) from the GMT SVN? Otherwise I’ll have to
try dig up an old compiled folder…

This is a known issue. For those of you that need it badly, the simplest
solution is to have installed both GMT4 and GMT5. See the cookbook for
how to have both running side by side.
Joaquim

Post by Kara Matthews
Hi Christian, and hi everyone,
Thanks very much for your reply. The script I previously sent also
included my work-around in it so I could show what steps I had to take to
overcome the problem. Sorry, I should have said which lines needed
commenting out. Sabin downloaded the developer version 5.1.2 (r13381, 64
bit) and it didn¹t work for him.
Using v5.1.1 (r12968, 64 bit) and 5.1.2 (r13381, 64 bit) I cannot use psxy
to make a mercator map that contains 180deg longitude and contains
polygons that are truncated by both the left and right map margins - I get
banding across the map. Depending on whether you specify your region in
the form 0-360 or 180/180 you can get a map with polygons that are
truncated by one of the margins without banding, but not both.
In the attached scripts I plot 8 rectangles (10 degrees wide) in each map.
4 are cut in half by the right margin and 4 are cut in half by the left
- 1 is digitised clockwise and coordinates are 180/180
- 1 is digitised counterclockwise and coordinates are 180/180
- 1 is digitised clockwise and coordinates are 0/360
- 1 is digitised counterclockwise and coordinates are 0/360
I ran tests in 3 locations (three directories within
polygon_fill_problem.zip): eastern US, Pacific, Australia
For each location, the top two maps have the same R region but are
specified either in the form 180/180 or 0/360, and the bottom two maps
have the same location but the R¹s are specified differently. I have
annotated this.
You will see that as long as the map doesn¹t include 180 degrees
longitude, see attached gmt_poly_plotting_test_E-US.pdf (from test1_E-US
example), then it is possible to make the map without banding, you just
have to choose the right R format. However, if the map includes 180
degrees longitude, see gmt_poly_plotting_test_AUS_2.pdf and
gmt_poly_plotting_test_PAC_2.pdf (from test2_PAC top two maps, and
test3_AUS bottom two maps), then it is not possible to have polygons
truncated on each side of the map without banding.
In the attached directories contained within polygon_fill_problem.zip all
the files are in place and you just have to run the scripts as they are. I
am using 5.1.1 (r12972) 64-bit.
Interestingly, I did some further testing and this problem does not occur
using v4.5.8 (64-bit)!!
I¹m sorry to be a bother, but I had a bunch of plotting scripts that I
made late last year using an older developer version of GMT5 (I can¹t
remember which version sorry but I can find out tonight if needed) that
work and now they don¹t. Plus I know a couple of others in the group
having this problem.
Does anyone have any recommendations? To the developers, is there a way to
change the GMT thing responsible for this back to the way it was in v4.5.8?
Thank you very very much for your help Christian and to anyone else who
can offer any suggestions.
Cheers,
Kara

Post by Christian Heine
Hi Kara,

I just ran your test.sh script using Version 5.1.2_r13178 [64-bit] on OS
10.9.4 and get the attached result (test_0-360_chhei_crop.pdf). It is
quite similar to the look of your 'desired' map. The only difference
between your desired map and the one I generated using your script is the
central part where there are white/unfilled patches (missing polygons?)
as opposed to filled space in your required map.
Plotting COBreconstructed_${age}.00Ma.xy (2.pdf) and
WARSreconstructed_${age}.00Ma.xy (1.pdf) independently results in the
attached maps.
For what it's worth it might be helpful to dump the reconstructed data as
*.shp file and throw this into QGIS and do basic geometry checking: In
QGIS there's the menu Vector -> Check Geometry Validity (btw this should
also work on OGR GMT files). But I suspect that this is more something
related to dateline crossings.
Also, I ran your polygons through gmtspatial -Q+ for a handedness check -
some few of your polygons are CW whereas the others are CCW handed. Not
sure whether this causes GMT to misbehave (wouldn't assume so).
When exporting from GPlates, I can highly recommend to use the GMT OGR
format (*.gmt) as this also exports the GPlates Feature ID which lets you
search and identify a single rogue feature much much easier.
Possible workaround: ogr2ogr from the GDAL library has a "[-clipsrc [xmin
ymin xmax ymax]" option which you can also use to clip the data.
Sorry for not being able to help with specific debugging info with your
setup. Maybe an update to the recent SVN versions will fix some of the
problems?
Greetings from NL,
Christian
Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New
Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on
gmt.soest.hawaii.edu instead.

Post by Kara Matthews
To try and get around this issue I used gmtspatial and the C option to
close the polygons at the map border using my -R. This sometimes works,
but not all the time. In some cases it seems to be inventing some
strange polygons that I can¹t account for. See
"test_0-360_gmtspatial.pdf"
So when gmtspatial wasn¹t working I used gmtconvert to separate my
polygons out into separate files to then isolate the problem polygons.
It seems that gmtspatial was making up some polygons with strange
coordinates, coordinates that weren¹t in the original polygon file. See
prob_poly.txt that coincidentally has the same longitudes as my map
region.
I was able to get around my problem by working out which polygons
weren¹t working (a bit of trial and error with awk and bash if
statements) and then not plotting theseŠ but my clunky work-around is
not ideal for making lots of figures, or plotting lots of polygon files.
I have also attached a test script and the input files in
problem_with_psxy.zip. I have currently uncommented the set of lines I
needed to make my ideal figure. You should be able to run this script
from the folder if needed.
Thanks kindly for any help you can offer!!
Kind regards,
Kara
---
Dr Kara J. Matthews | Postdoctoral Researcher
School of Geosciences | Faculty of Science
THE UNIVERSITY OF SYDNEY
Rm 403 | Madsen Building (F09) | The University of Sydney | NSW | 2006
T: +61 2 9351 3625
W: www.earthbyte.org
Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first. To formally report bugs or
request features, please register and add New Issue on
gmt.soest.hawaii.edu To unsubscribe, send the message "signoff gmt-help"
1, 2014 - please use forum on gmt.soest.hawaii.edu instead.
<test_0-360.pdf><test_0-360_gmtspatial.pdf><test_required_plotting.pdf

p
rob_poly.txt><problem_with_psxy.zip>

Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add
New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum
on gmt.soest.hawaii.edu instead.
<new_gmt_0025.png>

Mailing list for GMT discussions of all kinds. If you are not sure you have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to ***@lists.hawaii.edu
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on g

Paul Wessel

2014-08-05 23:54:19 UTC

Permalink

Hi guys-

I think I have fixed this in r13414 (GMT5) and r10251 (GMT4). I do not have time to test things thoroughly today though. Could you please give it a shot and if you still find clipping issue then please add a new issue on the tracker with a small example showing failure.

Cheers, Paul

Post by Sabin Zahirovic
Hi Joaquim,
I do have GMT4 and GMT5 running side by side. However, the bug is in both
GMT4 and GMT5. The workaround is to install an older version of GMT4, such
as GMT 4.5.8.
Paul, thanks for offering to look at this. Your time and help is much
appreciated!
Cheers,
Sabin
--
MR SABIN ZAHIROVIC | PhD Candidate
School of Geosciences | Faculty of Science
THE UNIVERSITY OF SYDNEY
Rm 414, Madsen Building F09 | The University of Sydney | NSW | 2006
M +61 416 775 589
<http://www.earthbyte.org/>
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.

Post by Joaquim Luis

I can also confirm all of Kara’s observations. If this is a problem that
is unlikely to be fixed in the near term, is it relatively
straightforward
to extract GMT 4.5.8 (or similar) from the GMT SVN? Otherwise I’ll have to
try dig up an old compiled folder…

This is a known issue. For those of you that need it badly, the simplest
solution is to have installed both GMT4 and GMT5. See the cookbook for
how to have both running side by side.
Joaquim

Post by Kara Matthews
Hi Christian, and hi everyone,
Thanks very much for your reply. The script I previously sent also
included my work-around in it so I could show what steps I had to take to
overcome the problem. Sorry, I should have said which lines needed
commenting out. Sabin downloaded the developer version 5.1.2 (r13381, 64
bit) and it didn¹t work for him.
Using v5.1.1 (r12968, 64 bit) and 5.1.2 (r13381, 64 bit) I cannot use psxy
to make a mercator map that contains 180deg longitude and contains
polygons that are truncated by both the left and right map margins - I get
banding across the map. Depending on whether you specify your region in
the form 0-360 or 180/180 you can get a map with polygons that are
truncated by one of the margins without banding, but not both.
In the attached scripts I plot 8 rectangles (10 degrees wide) in each map.
4 are cut in half by the right margin and 4 are cut in half by the left
- 1 is digitised clockwise and coordinates are 180/180
- 1 is digitised counterclockwise and coordinates are 180/180
- 1 is digitised clockwise and coordinates are 0/360
- 1 is digitised counterclockwise and coordinates are 0/360
I ran tests in 3 locations (three directories within
polygon_fill_problem.zip): eastern US, Pacific, Australia
For each location, the top two maps have the same R region but are
specified either in the form 180/180 or 0/360, and the bottom two maps
have the same location but the R¹s are specified differently. I have
annotated this.
You will see that as long as the map doesn¹t include 180 degrees
longitude, see attached gmt_poly_plotting_test_E-US.pdf (from test1_E-US
example), then it is possible to make the map without banding, you just
have to choose the right R format. However, if the map includes 180
degrees longitude, see gmt_poly_plotting_test_AUS_2.pdf and
gmt_poly_plotting_test_PAC_2.pdf (from test2_PAC top two maps, and
test3_AUS bottom two maps), then it is not possible to have polygons
truncated on each side of the map without banding.
In the attached directories contained within polygon_fill_problem.zip all
the files are in place and you just have to run the scripts as they are. I
am using 5.1.1 (r12972) 64-bit.
Interestingly, I did some further testing and this problem does not occur
using v4.5.8 (64-bit)!!
I¹m sorry to be a bother, but I had a bunch of plotting scripts that I
made late last year using an older developer version of GMT5 (I can¹t
remember which version sorry but I can find out tonight if needed) that
work and now they don¹t. Plus I know a couple of others in the group
having this problem.
Does anyone have any recommendations? To the developers, is there a way to
change the GMT thing responsible for this back to the way it was in v4.5.8?
Thank you very very much for your help Christian and to anyone else who
can offer any suggestions.
Cheers,
Kara

Post by Christian Heine
Hi Kara,

I just ran your test.sh script using Version 5.1.2_r13178 [64-bit] on OS
10.9.4 and get the attached result (test_0-360_chhei_crop.pdf). It is
quite similar to the look of your 'desired' map. The only difference
between your desired map and the one I generated using your script is the
central part where there are white/unfilled patches (missing polygons?)
as opposed to filled space in your required map.
Plotting COBreconstructed_${age}.00Ma.xy (2.pdf) and
WARSreconstructed_${age}.00Ma.xy (1.pdf) independently results in the
attached maps.
For what it's worth it might be helpful to dump the reconstructed data as
*.shp file and throw this into QGIS and do basic geometry checking: In
QGIS there's the menu Vector -> Check Geometry Validity (btw this should
also work on OGR GMT files). But I suspect that this is more something
related to dateline crossings.
Also, I ran your polygons through gmtspatial -Q+ for a handedness check -
some few of your polygons are CW whereas the others are CCW handed. Not
sure whether this causes GMT to misbehave (wouldn't assume so).
When exporting from GPlates, I can highly recommend to use the GMT OGR
format (*.gmt) as this also exports the GPlates Feature ID which lets you
search and identify a single rogue feature much much easier.
Possible workaround: ogr2ogr from the GDAL library has a "[-clipsrc [xmin
ymin xmax ymax]" option which you can also use to clip the data.
Sorry for not being able to help with specific debugging info with your
setup. Maybe an update to the recent SVN versions will fix some of the
problems?
Greetings from NL,
Christian
Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New
Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on
gmt.soest.hawaii.edu instead.

Post by Kara Matthews
To try and get around this issue I used gmtspatial and the C option to
close the polygons at the map border using my -R. This sometimes works,
but not all the time. In some cases it seems to be inventing some
strange polygons that I can¹t account for. See
"test_0-360_gmtspatial.pdf"
So when gmtspatial wasn¹t working I used gmtconvert to separate my
polygons out into separate files to then isolate the problem polygons.
It seems that gmtspatial was making up some polygons with strange
coordinates, coordinates that weren¹t in the original polygon file. See
prob_poly.txt that coincidentally has the same longitudes as my map
region.
I was able to get around my problem by working out which polygons
weren¹t working (a bit of trial and error with awk and bash if
statements) and then not plotting theseŠ but my clunky work-around is
not ideal for making lots of figures, or plotting lots of polygon files.
I have also attached a test script and the input files in
problem_with_psxy.zip. I have currently uncommented the set of lines I
needed to make my ideal figure. You should be able to run this script
from the folder if needed.
Thanks kindly for any help you can offer!!
Kind regards,
Kara
---
Dr Kara J. Matthews | Postdoctoral Researcher
School of Geosciences | Faculty of Science
THE UNIVERSITY OF SYDNEY
Rm 403 | Madsen Building (F09) | The University of Sydney | NSW | 2006
T: +61 2 9351 3625
W: www.earthbyte.org
Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first. To formally report bugs or
request features, please register and add New Issue on
gmt.soest.hawaii.edu To unsubscribe, send the message "signoff gmt-help"
1, 2014 - please use forum on gmt.soest.hawaii.edu instead.
<test_0-360.pdf><test_0-360_gmtspatial.pdf><test_required_plotting.pdf

p
rob_poly.txt><problem_with_psxy.zip>

Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add
New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum
on gmt.soest.hawaii.edu instead.
<new_gmt_0025.png>

Mailing list for GMT discussions of all kinds. If you are not sure you have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New Issue on gmt.soest.hawaii.edu
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on gmt.soest.hawaii.edu instead.

Mailing list for GMT discussions of all kinds. If you are not sure you have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to ***@lists.hawaii.edu
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on gmt.soest.hawaii.edu instead.

Kara Matthews

2014-08-06 23:49:47 UTC

Permalink

Hi Paul,

I installed r13414 and my test cases and real world cases all appear to be
working! Thank you very much! :-)

Cheers,
Kara

Post by Paul Wessel
Hi guys-
I think I have fixed this in r13414 (GMT5) and r10251 (GMT4). I do not
have time to test things thoroughly today though. Could you please give
it a shot and if you still find clipping issue then please add a new
issue on the tracker with a small example showing failure.
Cheers, Paul
On Aug 2, 2014, at 7:49 PM, Sabin Zahirovic

Post by Joaquim Luis

I can also confirm all of Kara’s observations. If this is a problem that
is unlikely to be fixed in the near term, is it relatively
straightforward
to extract GMT 4.5.8 (or similar) from the GMT SVN? Otherwise I’ll
have
to
try dig up an old compiled folder…

This is a known issue. For those of you that need it badly, the simplest
solution is to have installed both GMT4 and GMT5. See the cookbook for
how to have both running side by side.
Joaquim

Thanks for the help and time in advance!
Cheers,
Sabin
PS: I attach a sample of my own problem, the grey polygons (LIPs) that
cross the east map boundary cause the artefact. However, as Kara
demonstrated, often the west boundary is also affected.
--
MR SABIN ZAHIROVIC | PhD Candidate
School of Geosciences | Faculty of Science
THE UNIVERSITY OF SYDNEY
Rm 414, Madsen Building F09 | The University of Sydney | NSW | 2006
M +61 416 775 589
<http://www.earthbyte.org/>
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.

Post by Kara Matthews
Hi Christian, and hi everyone,
Thanks very much for your reply. The script I previously sent also
included my work-around in it so I could show what steps I had to
take
to
overcome the problem. Sorry, I should have said which lines needed
commenting out. Sabin downloaded the developer version 5.1.2 (r13381, 64
bit) and it didn¹t work for him.
Using v5.1.1 (r12968, 64 bit) and 5.1.2 (r13381, 64 bit) I cannot use psxy
to make a mercator map that contains 180deg longitude and contains
polygons that are truncated by both the left and right map margins -
I
get
banding across the map. Depending on whether you specify your region in
the form 0-360 or 180/180 you can get a map with polygons that are
truncated by one of the margins without banding, but not both.
In the attached scripts I plot 8 rectangles (10 degrees wide) in each map.
4 are cut in half by the right margin and 4 are cut in half by the left
- 1 is digitised clockwise and coordinates are 180/180
- 1 is digitised counterclockwise and coordinates are 180/180
- 1 is digitised clockwise and coordinates are 0/360
- 1 is digitised counterclockwise and coordinates are 0/360
I ran tests in 3 locations (three directories within
polygon_fill_problem.zip): eastern US, Pacific, Australia
For each location, the top two maps have the same R region but are
specified either in the form 180/180 or 0/360, and the bottom two maps
have the same location but the R¹s are specified differently. I have
annotated this.
You will see that as long as the map doesn¹t include 180 degrees
longitude, see attached gmt_poly_plotting_test_E-US.pdf (from test1_E-US
example), then it is possible to make the map without banding, you just
have to choose the right R format. However, if the map includes 180
degrees longitude, see gmt_poly_plotting_test_AUS_2.pdf and
gmt_poly_plotting_test_PAC_2.pdf (from test2_PAC top two maps, and
test3_AUS bottom two maps), then it is not possible to have polygons
truncated on each side of the map without banding.
In the attached directories contained within polygon_fill_problem.zip all
the files are in place and you just have to run the scripts as they are. I
am using 5.1.1 (r12972) 64-bit.
Interestingly, I did some further testing and this problem does not occur
using v4.5.8 (64-bit)!!
I¹m sorry to be a bother, but I had a bunch of plotting scripts that I
made late last year using an older developer version of GMT5 (I can¹t
remember which version sorry but I can find out tonight if needed) that
work and now they don¹t. Plus I know a couple of others in the group
having this problem.
Does anyone have any recommendations? To the developers, is there a way to
change the GMT thing responsible for this back to the way it was in v4.5.8?
Thank you very very much for your help Christian and to anyone else who
can offer any suggestions.
Cheers,
Kara

Post by Christian Heine
Hi Kara,

I just ran your test.sh script using Version 5.1.2_r13178 [64-bit]
on
OS
10.9.4 and get the attached result (test_0-360_chhei_crop.pdf). It is
quite similar to the look of your 'desired' map. The only difference
between your desired map and the one I generated using your script
is
the
central part where there are white/unfilled patches (missing polygons?)
as opposed to filled space in your required map.
Plotting COBreconstructed_${age}.00Ma.xy (2.pdf) and
WARSreconstructed_${age}.00Ma.xy (1.pdf) independently results in the
attached maps.
For what it's worth it might be helpful to dump the reconstructed data as
*.shp file and throw this into QGIS and do basic geometry checking: In
QGIS there's the menu Vector -> Check Geometry Validity (btw this should
also work on OGR GMT files). But I suspect that this is more something
related to dateline crossings.
Also, I ran your polygons through gmtspatial -Q+ for a handedness check -
some few of your polygons are CW whereas the others are CCW handed. Not
sure whether this causes GMT to misbehave (wouldn't assume so).
When exporting from GPlates, I can highly recommend to use the GMT OGR
format (*.gmt) as this also exports the GPlates Feature ID which
lets
you
search and identify a single rogue feature much much easier.
Possible workaround: ogr2ogr from the GDAL library has a "[-clipsrc [xmin
ymin xmax ymax]" option which you can also use to clip the data.
Sorry for not being able to help with specific debugging info with your
setup. Maybe an update to the recent SVN versions will fix some of the
problems?
Greetings from NL,
Christian
Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New
Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on
gmt.soest.hawaii.edu instead.

Post by Kara Matthews
To try and get around this issue I used gmtspatial and the C
option
to
close the polygons at the map border using my -R. This sometimes works,
but not all the time. In some cases it seems to be inventing some
strange polygons that I can¹t account for. See
"test_0-360_gmtspatial.pdf"
So when gmtspatial wasn¹t working I used gmtconvert to separate my
polygons out into separate files to then isolate the problem polygons.
It seems that gmtspatial was making up some polygons with strange
coordinates, coordinates that weren¹t in the original polygon file. See
prob_poly.txt that coincidentally has the same longitudes as my map
region.
I was able to get around my problem by working out which polygons
weren¹t working (a bit of trial and error with awk and bash if
statements) and then not plotting theseŠ but my clunky work-around is
not ideal for making lots of figures, or plotting lots of polygon files.
I have also attached a test script and the input files in
problem_with_psxy.zip. I have currently uncommented the set of
lines
I
needed to make my ideal figure. You should be able to run this script
from the folder if needed.
Thanks kindly for any help you can offer!!
Kind regards,
Kara
---
Dr Kara J. Matthews | Postdoctoral Researcher
School of Geosciences | Faculty of Science
THE UNIVERSITY OF SYDNEY
Rm 403 | Madsen Building (F09) | The University of Sydney | NSW | 2006
T: +61 2 9351 3625
W: www.earthbyte.org
Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first. To formally report bugs or
request features, please register and add New Issue on
gmt.soest.hawaii.edu To unsubscribe, send the message "signoff gmt-help"
1, 2014 - please use forum on gmt.soest.hawaii.edu instead.
<test_0-360.pdf><test_0-360_gmtspatial.pdf><test_required_plotting.p
df

p
rob_poly.txt><problem_with_psxy.zip>

Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add
New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum
on gmt.soest.hawaii.edu instead.
<new_gmt_0025.png>

Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add
New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum
on gmt.soest.hawaii.edu instead.

Mailing list for GMT discussions of all kinds. If you are not sure you have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to ***@lists.hawaii.edu
Note: gmt-help will become obsolete on Sept 1, 2014 - ple

Sabin Zahirovic

2014-08-07 00:46:48 UTC

Permalink

Hi Paul,

It worked for me too in gmt5-dev (havenât tried gmt4-dev). It took me a
few goes - initial compiles still had the same problem. I updated cmake
through macports, and make sure the directory locations were OK in the
ConfigUser.cmake file, and it finally worked.

For anyone who is unsure how to do get the latest developer version, the
instructions are here:
http://gmt.soest.hawaii.edu/projects/gmt/wiki/BuildingGMT

I attach my working cmake/ConfigUser.cmake file in case it helps anyone
get started. Just a note, my gmt5-dev folder is in
/Users/sabinz/Documents/GMT_Dev/gmt5-dev and the compile process with
create the /Users/sabinz/Documents/GMT_Dev/gmt5-dev/bin folder with the
executables. I keep my GSHHG and DCW unzipped files in
/Users/sabinz/Documents/GMT_Dev/AccessoryFiles

If you have gmt5 from macports, youâll need to uninstall it if you need to
psxy polygon clipping fix. I first had to uninstall inactive ports using
"sudo port uninstall inactiveâ, then "sudo port uninstall gmt5â. Make sure
to modify your shell path to include the gmt5-dev bin folder. Do this also
for TextMate if youâre using it to run scripts (Preferences > Advanced >
Shell Variables).

Thanks again for the help!

Cheers,
Sabin
--
MR SABIN ZAHIROVIC | PhD Candidate
School of Geosciences | Faculty of Science

THE UNIVERSITY OF SYDNEY
Rm 414, Madsen Building F09 | The University of Sydney | NSW | 2006
M +61 416 775 589
E ***@sydney.edu.au | W http://www.earthbyte.org
<http://www.earthbyte.org/>

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.

Post by Kara Matthews
Hi Paul,
I installed r13414 and my test cases and real world cases all appear to be
working! Thank you very much! :-)
Cheers,
Kara

Post by Sabin Zahirovic
Hi Joaquim,
I do have GMT4 and GMT5 running side by side. However, the bug is in both
GMT4 and GMT5. The workaround is to install an older version of GMT4, such
as GMT 4.5.8.
Paul, thanks for offering to look at this. Your time and help is much
appreciated!
Cheers,
Sabin
--
MR SABIN ZAHIROVIC | PhD Candidate
School of Geosciences | Faculty of Science
THE UNIVERSITY OF SYDNEY
Rm 414, Madsen Building F09 | The University of Sydney | NSW | 2006
M +61 416 775 589
<http://www.earthbyte.org/>
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.

Post by Joaquim Luis

This is a known issue. For those of you that need it badly, the simplest
solution is to have installed both GMT4 and GMT5. See the cookbook for
how to have both running side by side.
Joaquim

Post by Sabin Zahirovic
Thanks for the help and time in advance!
Cheers,
Sabin
PS: I attach a sample of my own problem, the grey polygons (LIPs) that
cross the east map boundary cause the artefact. However, as Kara
demonstrated, often the west boundary is also affected.
--
MR SABIN ZAHIROVIC | PhD Candidate
School of Geosciences | Faculty of Science
THE UNIVERSITY OF SYDNEY
Rm 414, Madsen Building F09 | The University of Sydney | NSW | 2006
M +61 416 775 589
<http://www.earthbyte.org/>
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.

Post by Kara Matthews
Hi Christian, and hi everyone,
Thanks very much for your reply. The script I previously sent also
included my work-around in it so I could show what steps I had to
take
to
overcome the problem. Sorry, I should have said which lines needed
commenting out. Sabin downloaded the developer version 5.1.2
(r13381,
64
bit) and it didnÂ¹t work for him.
Using v5.1.1 (r12968, 64 bit) and 5.1.2 (r13381, 64 bit) I cannot
use
psxy
to make a mercator map that contains 180deg longitude and contains
polygons that are truncated by both the left and right map margins -
I
get
banding across the map. Depending on whether you specify your region in
the form 0-360 or Â180/Â180 you can get a map with polygons that are
truncated by one of the margins without banding, but not both.
In the attached scripts I plot 8 rectangles (10 degrees wide) in
each
map.
4 are cut in half by the right margin and 4 are cut in half by the left
- 1 is digitised clockwise and coordinates are Â180/180
- 1 is digitised counterclockwise and coordinates are Â180/180
- 1 is digitised clockwise and coordinates are 0/360
- 1 is digitised counterclockwise and coordinates are 0/360
I ran tests in 3 locations (three directories within
polygon_fill_problem.zip): eastern US, Pacific, Australia
For each location, the top two maps have the same ÂR region but are
specified either in the form Â180/180 or 0/360, and the bottom two maps
have the same location but the ÂRÂ¹s are specified differently. I have
annotated this.
You will see that as long as the map doesnÂ¹t include 180 degrees
longitude, see attached gmt_poly_plotting_test_E-US.pdf (from test1_E-US
example), then it is possible to make the map without banding, you just
have to choose the right ÂR format. However, if the map includes 180
degrees longitude, see gmt_poly_plotting_test_AUS_2.pdf and
gmt_poly_plotting_test_PAC_2.pdf (from test2_PAC top two maps, and
test3_AUS bottom two maps), then it is not possible to have polygons
truncated on each side of the map without banding.
In the attached directories contained within
polygon_fill_problem.zip
all
the files are in place and you just have to run the scripts as they are. I
am using 5.1.1 (r12972) 64-bit.
Interestingly, I did some further testing and this problem does not occur
using v4.5.8 (64-bit)!!
IÂ¹m sorry to be a bother, but I had a bunch of plotting scripts that I
made late last year using an older developer version of GMT5 (I canÂ¹t
remember which version sorry Â but I can find out tonight if needed) that
work and now they donÂ¹t. Plus I know a couple of others in the group
having this problem.
Does anyone have any recommendations? To the developers, is there a way to
change the GMT thing responsible for this back to the way it was in v4.5.8?
Thank you very very much for your help Christian and to anyone else who
can offer any suggestions.
Cheers,
Kara

Post by Christian Heine
Hi Kara,

Post by Kara Matthews
I am using GMT 5.1.1 (r12972) on OSX Mavericks and am having a problem
with plotting polygons (IÂ¹m using the Mercator projection). Specifically
I am getting banding across my map in instances when a polygon is being
cropped by the map border. It seems that the polygon is wrapping the
wrong way around the world. Compare Â³test_0-360.pdfÂ² (artefact in
bottom
right) with Â³test_required_plotting.pdfÂ² (this is what I want the
map to
look like). A couple of my other colleagues at work are having the same
problem.

I just ran your test.sh script using Version 5.1.2_r13178 [64-bit]
on
OS
10.9.4 and get the attached result (test_0-360_chhei_crop.pdf). It is
quite similar to the look of your 'desired' map. The only difference
between your desired map and the one I generated using your script
is
the
central part where there are white/unfilled patches (missing polygons?)
as opposed to filled space in your required map.
Plotting COBreconstructed_${age}.00Ma.xy (2.pdf) and
WARSreconstructed_${age}.00Ma.xy (1.pdf) independently results in the
attached maps.
For what it's worth it might be helpful to dump the reconstructed data as
*.shp file and throw this into QGIS and do basic geometry checking: In
QGIS there's the menu Vector -> Check Geometry Validity (btw this should
also work on OGR GMT files). But I suspect that this is more something
related to dateline crossings.
Also, I ran your polygons through gmtspatial -Q+ for a handedness check -
some few of your polygons are CW whereas the others are CCW handed. Not
sure whether this causes GMT to misbehave (wouldn't assume so).
When exporting from GPlates, I can highly recommend to use the GMT OGR
format (*.gmt) as this also exports the GPlates Feature ID which
lets
you
search and identify a single rogue feature much much easier.
Possible workaround: ogr2ogr from the GDAL library has a "[-clipsrc [xmin
ymin xmax ymax]" option which you can also use to clip the data.
Sorry for not being able to help with specific debugging info with your
setup. Maybe an update to the recent SVN versions will fix some of the
problems?
Greetings from NL,
Christian
Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add
New
Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on
gmt.soest.hawaii.edu instead.

Post by Kara Matthews
To try and get around this issue I used gmtspatial and the ÂC
option
to
close the polygons at the map border using my -R. This sometimes works,
but not all the time. In some cases it seems to be inventing some
strange polygons that I canÂ¹t account for. See
"test_0-360_gmtspatial.pdf"
So when gmtspatial wasnÂ¹t working I used gmtconvert to separate my
polygons out into separate files to then isolate the problem polygons.
It seems that gmtspatial was making up some polygons with strange
coordinates, coordinates that werenÂ¹t in the original polygon
file.
See
prob_poly.txt that coincidentally has the same longitudes as my map
region.
I was able to get around my problem by working out which polygons
werenÂ¹t working (a bit of trial and error with awk and bash if
statements) and then not plotting theseÅ but my clunky work-around is
not ideal for making lots of figures, or plotting lots of polygon files.
I have also attached a test script and the input files in
problem_with_psxy.zip. I have currently uncommented the set of
lines
I
needed to make my ideal figure. You should be able to run this script
from the folder if needed.
Thanks kindly for any help you can offer!!
Kind regards,
Kara
---
Dr Kara J. Matthews | Postdoctoral Researcher
School of Geosciences | Faculty of Science
THE UNIVERSITY OF SYDNEY
Rm 403 | Madsen Building (F09) | The University of Sydney | NSW | 2006
T: +61 2 9351 3625
W: www.earthbyte.org
Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first. To formally report bugs or
request features, please register and add New Issue on
gmt.soest.hawaii.edu To unsubscribe, send the message "signoff gmt-help"
on
Sept
1, 2014 - please use forum on gmt.soest.hawaii.edu instead.
<test_0-360.pdf><test_0-360_gmtspatial.pdf><test_required_plotting.
p
df

p
rob_poly.txt><problem_with_psxy.zip>

Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add
New
Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on
gmt.soest.hawaii.edu instead.

Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add
New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum
on gmt.soest.hawaii.edu instead.
<new_gmt_0025.png>

Mailing list for GMT discussions of all kinds. If you are not sure you
have found a bug, discuss it here first.
To formally report bugs or request features, please register and add
New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum
on gmt.soest.hawaii.edu instead.

Mailing list for GMT discussions of all kinds. If you are not sure you have found a bug, discuss it here first.
To formally report bugs or request features, please register and add New Issue on gmt.soest.hawaii.edu
To unsubscribe, send the message "signoff gmt-help" to ***@lists.hawaii.edu
Note: gmt-help will become obsolete on Sept 1, 2014 - please use forum on gmt.soest.hawaii.edu instead.