Bug #963

plotting OGR_GMT polygons with psxy

Added by Jed about 2 years ago. Updated almost 2 years ago.

Status:ClosedStart date:2016-08-29
Priority:NormalDue date:
Assignee:Paul% Done:


Target version:Candidate for next bugfix release
Affected version:5.x-svn Platform:Mac OS X


Dear GMT gurus,

I have noticed an error in newer versions of GMT > 5.1.x when attempting to plot OGR_GMT format polygon files. As a test of the different GMT versions, I made a very simple plotting script:



# -----------------------------

psbasemap -R-25/-34/55/25r -JA20/0/20 -D-25/-34/55/25r -B0 -P -K > $output

psxy potveg_biomes.gmt -R -J -A -fg -aG=gmtrgb -L -O -P >> $output

ps2raster -A -Tf $output

rm $output

Both the correct (with GMT 5.1.2) and incorrect (with GMT 5.3.0_r17024) versions of the output are attached to this bug report, along with the OGR_GMT polygon file I am using for plotting. Basically, the older version of GMT recognizes the OGR_GMT polygon file correctly and plots each polygon in the correct color. The newer version of GMT somehow thinks that all of the polygons should be painted the same color.

I recompiled both versions of GMT today, so they are linked to exactly the same libraries, including, e.g., GDAL.

Thank you very much for your help resolving this!

Best regard,


potveg_biomes.gmt - OGR_GMT polygon file (9.73 MB) Jed, 2016-08-29 07:30

africa_vegmap_gmt5.1.2.pdf - correct version of gmt output: map plotted using gmt 5.1.2 (274 KB) Jed, 2016-08-29 07:34

africa_vegmap_gmt5.3.0_r17024.pdf - incorrect version of gmt output: map plotted using gmt 5.3 devel (272 KB) Jed, 2016-08-29 07:34


#1 Updated by Paul almost 2 years ago

  • Status changed from New to In Progress
  • Assignee set to Paul
  • Target version set to Candidate for next bugfix release

I can confirm the problem. The color is not reset after all the holes in the first polygon with holes are painted. Will look for a solution.

#2 Updated by Paul almost 2 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

In a fix to deal with a related problem we ended failing to parse the @P and @H properly so that once a hole was detected everything else was flagged as holes; hence everything became blue after the last hole. Fixed in r17150 - give it a try.

#3 Updated by Joaquim almost 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF