Bug #606

pscoast no plot/memory error

Added by Sheila about 3 years ago. Updated about 3 years ago.

Status:ClosedStart date:2014-08-15
Priority:NormalDue date:
Assignee:Paul% Done:

100%

Category:-
Target version:Candidate for next bugfix release
Affected version:5.1.1 Platform:

Description

My command invoking pscoast with an azimuthal projection
trying to plot a hemisphere centred on a point in Asia
fails in v. 5.1.1 but not in v. 4.5.12.
Here is a test command that I wrote to illustrate the problem.
pscoast -Ja30.0/30.0/90.0/1.4/100.0 -Rg -B30/30WESN -A5000 -Dc -G40/255/128 -S100/200/255 -W > jjpscoast.ps
gives this:
pscoast (gmt_radial_boundary_arc): Error: Could not reallocate memory [68719476736.00 Gb, 9223372036854775806 items of 8 bytes]
If I eliminate the -G and -S options then it runs to completion but all the co-ordinates in the postscript file are zero. In V. 4.5.12 it worked OK. Test script below also contains the error messages. I appreciate that the coastlines at the edge of this hemispherical projection are going to be very distorted.

jjpscoast.gmt (759 Bytes) Sheila, 2014-08-15 00:48

Associated revisions

Revision 13470
Added by Paul about 3 years ago

Added check to prevent colatitudes being entered as oblique latitude in azimuthal projections, in support of issue #606

History

#1 Updated by Paul about 3 years ago

  • Status changed from New to Feedback

I dont understand your -Ja option. -Ja expects scale and you are giving it 100? It does not seem to match the requirements:

       -Ja|A<lon0>/<lat0>[/<horizon>]/<scale (or radius/lat)|width> (Lambert Azimuthal Equal Area)


Yours is
-Ja30.0/30.0/90.0/1.4/100.0

so horizon is 90, radius is 1.4, and scale is 100? With 100 inches or cm per degree, this plot would be enormous, hence your memory messages, no?

#2 Updated by Sheila about 3 years ago

Thanks. I still can't get it to work with -Ja - I clearly don't understand the documentation ("man gmt") - but it works with JA30.0/30.0/90.0/14.0 so I will go with that. I thought that what I had put was correct, i.e. that the final 1.4/100 represented "radius/lat" i.e. radius of plot = 1.4 cm out to oblique latitude 100 deg.

#3 Updated by Paul about 3 years ago

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

AH. looks like GMT does not like a radius/lat with lat > 90. But you are right that this should be in the 0-180 range, not -90/90. Will look into fixing this.

#4 Updated by Paul about 3 years ago

Actually, the problem is that you are giving a colatitude (0-180) while we are requesting an oblique latitude (-90/90). If you instead give -10 instead of your 100 things work fine.

#5 Updated by Paul about 3 years ago

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

We bave decided to stick with the long-time practice of specifying radius/lat instead of scale, in which radius is the projected distance on the map from the projection center to a particular oblique latitude around that center. Hence, an oblique latitude is given in the -90 to +90 range, We have added a check that if anything > 90 is given (a colatitude) we now give an error. This should prevent cases like yours from crashing and give a meaningful error message. In r13470.

#6 Updated by Paul about 3 years ago

  • Status changed from Resolved to Closed

Closing this issue as no more feedback.

Also available in: Atom PDF