Nabble - GMT

Re: some grdcontour bugs

2009-11-26T14:58:08Z

Hi Boris-

1. The -Q option is the cause of the missing lines that cross
Greenwhich. -Q was intended to only be applied to closed contours; we
will fix bug this in the next version.
2. Regarding the high in the upper right corner. Yes, this is wrong
and the cause has been found. The correct version now yields a low.

Thanx for pointing these out. All fixed in CVS.

Cheers,
Paul

On Nov 27, 2009, at 3:35 AM, Alexander Kukharsky wrote:

> Walter-
>
> The line(s) should cross zero more than once. I should be notice it
> earlier.
> There was stripped line in your 14.png near the North Pole (09 nov
> 09), see please euras.png
>
> grdcontour data14.grd -JS55/90/30c -bo -R0/35/182/67r -C4 -Q100 -A
> +a0+s22+kBrown+r.5 -T:LH -G3i/3 -S2 -W2p/Red -K>14.ps
> pscoast -Dc -R -bo -B20g20/10g10 -J -W0.5p -O>>14.ps
>
> And the same ones for data15.grd
>
> grdcontour data15.grd -JS55/90/30c -bo -R0/35/182/67r -C4 -Q100 -A
> +a0+s22+kBrown+r.5 -T:LH -G3i/3 -S2 -W2p/Red -K>15.ps
> pscoast -Dc -R -bo -B20g20/10g10 -J -W0.5p -O>>15.ps
>
> It is important to reproduce my -J/-R/-C/-Q parameters.
>
> But the more important thing for me is the wrong behavor of the high
> label (H) in 14.png upper-right corner. There must be (L) label for
> level 524.
>
>
>
>> Best Regards
>>
>> Alex
>>
>> -----Original Message-----
>>
>>> Alex-
>>>
>>> I got the data from your archived message and obtained the attached
>>> PNG; it looks nothing like your posted plots so you must have used
>>> another grid. I cannot debug problems that cannot be reproduced. I
>>> do note in my PNG that a contour line is missing in the lower plot
>>> so
>>> there is at least one bug somewhere. I see no "stripped lines".
>>>
>>> As for annotation placement you will need to learn how to use the -G
>>> option (see Appendix O as well). I suggest -Gl.
>>>
>>> Please send me directly a zip with (a) a grid and (b) a png based on
>>> that grid so I can reproduce it.
>>>
>>> Cheers,Paul
>>>
>>> ATTACHMENT: image/png (Euras.png)
>>>
>>>
>>>
>>> On Nov 8, 2009, at 8:31 PM, Alexander Kukharsky wrote:
>>>
>>>> Hi, Paul
>>>>
>>>> 1. It was unnecessary to add the surface string in my script. The
>>>> correct example should be produced using only grdcontour line (file
>>>> data2.grd loaded in my archive). Sorry for my confused message.
>>>>
>>>> Moreover, another image with script was posted for GMT mailing list
>>>> {27 Oct 2009} without possibility of notification.
>>>> https://listserv.hawaii.edu/cgi-bin/wa?A2=ind0910&L=GMT-HELP&D=1&T=0&O=D&P=108109
>>>>
>>>> 2. This stripped lines was drawn in any cases of gridding. The
>>>> lines
>>>> with -I1 produced more smooth lines and needed detalization level.
>>>>
>>>> Regards
>>>>
>>>> Alex Kukharsky
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>>
>>>>> Hi Alex-
>>>>>
>>>>> A few issues:
>>>>>
>>>>> 1. The command you sent me does not reproduce you PNG. Could you
>>>>> tell
>>>>> me which -R -J you used for that plot so I can reproduce. Also
>>>>> your
>>>>> script passed -R to surface but specified no values. I surmised
>>>>> from
>>>>> your grid it is -R0/360/0/90.
>>>>> 2. However, surface has NO knowledge of geographic boundary
>>>>> conditions, and furthermore cannot handle geographic poles.
>>>>> Looking
>>>>> at your data I see it is already gridded at 2.5 degrees, so the
>>>>> solution is to just put it into grd format with xyz2grd
>>>>> mean2.xyz -
>>>>> I2.5 -R0/360/0/90 -Gdata2.grd (this is just reformatting).
>>>>> 3. Once that is done the contours looks OK to me, but perhaps
>>>>> you can
>>>>> redo your exercise and send me a PNG and the exact commands used.
>>>>>
>>>>> Once the lines look OK we can discuss if there are font/color
>>>>> issues.
>>>>>
>>>>> Cheers,
>>>>> Paul
>>>>>
>>>>> On Nov 6, 2009, at 9:13 PM, Alexander Kukharsky wrote:
>>>>>
>>>>>> Dear colleagues,
>>>>>>
>>>>>> I've found a non accurate (splitted) lines as a result of the
>>>>>> grdcontour action.
>>>>>> (1) This wrong lines was drawn along the zero meridian when the
>>>>>> pole
>>>>>> is inside the boundaries (level 524). The correct line was
>>>>>> drawn in
>>>>>> case of North Pole was outside the boundaries with the same input
>>>>>> file.
>>>>>> (2) Wrong indication of lows/highs (maybe only along the zero
>>>>>> meridian too).
>>>>>>
>>>>>> Please, see my added picture and explain how so solve this
>>>>>> problems.
>>>>>>
>>>>>> I also have some troubles with
>>>>>>
>>>>>> (3) and with changing the color of ANNOTATION FONT (I see that -W
>>>>>> parameter controls the color of local lows/highs and the color of
>>>>>> the lines simultaneously).
>>>>>> (4) the elimination of the contour clipping at the boundaries
>>>>>>
>>>>>> May be is it possible to control this parameters?
>>>>>>
>>>>>> I am using GMT-4.5 on a 32-bit Windows system.
>>>>>>
>>>>>> surface mean2.xyz -I1 -R -Gdata2.grd
>>>>>> grdcontour data2.grd -JS55/90/16c -R0/30/150/85r -P -C4 -Q100 -A
>>>>>> +a0+s18+kBrown+n.1/.1 -T:LH -G5i/5i -S2 -Wa1.5p/Red -K -X0 -
>>>>>> Y0>02.ps
>>>>>> pscoast -Dc -R0/30/150/85r -bo -B20g20/10g10 -JS55/90/16c -P -
>>>>>> W0.5p
>>>>>> -O>>02.ps
>>>>>>
>>>>>>
>>>>>> Best Regards
>>>>>>
>>>>>> Alex Kukharsky
>>>>>>
>>>>>>
>>>>>> To unsubscribe, send the message "signoff gmt-help" to listserv@...
>>>>>> <LOW-HIGH.ZIP><low-high.png>
>>>>>
>>>>> To unsubscribe, send the message "signoff gmt-help" to listserv@...
>>>>>
>>>>
>>>> To unsubscribe, send the message "signoff gmt-help" to listserv@...
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
> To unsubscribe, send the message "signoff gmt-help" to listserv@...
> <14-15.ZIP><14.png><15.png><Euras.png>

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

Re: some grdcontour bugs

2009-11-26T08:35:23Z

Walter-

The line(s) should cross zero more than once. I should be notice it earlier.
There was stripped line in your 14.png near the North Pole (09 nov 09), see please euras.png

grdcontour data14.grd -JS55/90/30c -bo -R0/35/182/67r -C4 -Q100 -A+a0+s22+kBrown+r.5 -T:LH -G3i/3 -S2 -W2p/Red -K>14.ps
pscoast -Dc -R -bo -B20g20/10g10 -J -W0.5p -O>>14.ps

And the same ones for data15.grd

grdcontour data15.grd -JS55/90/30c -bo -R0/35/182/67r -C4 -Q100 -A+a0+s22+kBrown+r.5 -T:LH -G3i/3 -S2 -W2p/Red -K>15.ps
pscoast -Dc -R -bo -B20g20/10g10 -J -W0.5p -O>>15.ps

It is important to reproduce my -J/-R/-C/-Q parameters.

But the more important thing for me is the wrong behavor of the high label (H) in 14.png upper-right corner. There must be (L) label for level 524.

> Best Regards
>
> Alex
>
> -----Original Message-----
>
> > Alex-
> >
> > I got the data from your archived message and obtained the attached
> > PNG; it looks nothing like your posted plots so you must have used
> > another grid. I cannot debug problems that cannot be reproduced. I
> > do note in my PNG that a contour line is missing in the lower plot so
> > there is at least one bug somewhere. I see no "stripped lines".
> >
> > As for annotation placement you will need to learn how to use the -G
> > option (see Appendix O as well). I suggest -Gl.
> >
> > Please send me directly a zip with (a) a grid and (b) a png based on
> > that grid so I can reproduce it.
> >
> > Cheers,Paul
> >
> > ATTACHMENT: image/png (Euras.png)
> >
> >
> >
> > On Nov 8, 2009, at 8:31 PM, Alexander Kukharsky wrote:
> >
> > > Hi, Paul
> > >
> > > 1. It was unnecessary to add the surface string in my script. The
> > > correct example should be produced using only grdcontour line (file
> > > data2.grd loaded in my archive). Sorry for my confused message.
> > >
> > > Moreover, another image with script was posted for GMT mailing list
> > > {27 Oct 2009} without possibility of notification.
> > > https://listserv.hawaii.edu/cgi-bin/wa?A2=ind0910&L=GMT-HELP&D=1&T=0&O=D&P=108109
> > >
> > > 2. This stripped lines was drawn in any cases of gridding. The lines
> > > with -I1 produced more smooth lines and needed detalization level.
> > >
> > > Regards
> > >
> > > Alex Kukharsky
> > >
> > >
> > >
> > > -----Original Message-----
> > >
> > >> Hi Alex-
> > >>
> > >> A few issues:
> > >>
> > >> 1. The command you sent me does not reproduce you PNG. Could you
> > >> tell
> > >> me which -R -J you used for that plot so I can reproduce. Also your
> > >> script passed -R to surface but specified no values. I surmised from
> > >> your grid it is -R0/360/0/90.
> > >> 2. However, surface has NO knowledge of geographic boundary
> > >> conditions, and furthermore cannot handle geographic poles. Looking
> > >> at your data I see it is already gridded at 2.5 degrees, so the
> > >> solution is to just put it into grd format with xyz2grd mean2.xyz -
> > >> I2.5 -R0/360/0/90 -Gdata2.grd (this is just reformatting).
> > >> 3. Once that is done the contours looks OK to me, but perhaps you can
> > >> redo your exercise and send me a PNG and the exact commands used.
> > >>
> > >> Once the lines look OK we can discuss if there are font/color issues.
> > >>
> > >> Cheers,
> > >> Paul
> > >>
> > >> On Nov 6, 2009, at 9:13 PM, Alexander Kukharsky wrote:
> > >>
> > >>> Dear colleagues,
> > >>>
> > >>> I've found a non accurate (splitted) lines as a result of the
> > >>> grdcontour action.
> > >>> (1) This wrong lines was drawn along the zero meridian when the pole
> > >>> is inside the boundaries (level 524). The correct line was drawn in
> > >>> case of North Pole was outside the boundaries with the same input
> > >>> file.
> > >>> (2) Wrong indication of lows/highs (maybe only along the zero
> > >>> meridian too).
> > >>>
> > >>> Please, see my added picture and explain how so solve this problems.
> > >>>
> > >>> I also have some troubles with
> > >>>
> > >>> (3) and with changing the color of ANNOTATION FONT (I see that -W
> > >>> parameter controls the color of local lows/highs and the color of
> > >>> the lines simultaneously).
> > >>> (4) the elimination of the contour clipping at the boundaries
> > >>>
> > >>> May be is it possible to control this parameters?
> > >>>
> > >>> I am using GMT-4.5 on a 32-bit Windows system.
> > >>>
> > >>> surface mean2.xyz -I1 -R -Gdata2.grd
> > >>> grdcontour data2.grd -JS55/90/16c -R0/30/150/85r -P -C4 -Q100 -A
> > >>> +a0+s18+kBrown+n.1/.1 -T:LH -G5i/5i -S2 -Wa1.5p/Red -K -X0 -
> > >>> Y0>02.ps
> > >>> pscoast -Dc -R0/30/150/85r -bo -B20g20/10g10 -JS55/90/16c -P -W0.5p
> > >>> -O>>02.ps
> > >>>
> > >>>
> > >>> Best Regards
> > >>>
> > >>> Alex Kukharsky
> > >>>
> > >>>
> > >>> To unsubscribe, send the message "signoff gmt-help" to listserv@...
> > >>> <LOW-HIGH.ZIP><low-high.png>
> > >>
> > >> To unsubscribe, send the message "signoff gmt-help" to listserv@...
> > >>
> > >
> > > To unsubscribe, send the message "signoff gmt-help" to listserv@...
> >
> >
> >
>
>
>
>
>
>

To unsubscribe, send the message "signoff gmt-help" to listserv@...

14-15.ZIP (264K) Download Attachment
14.png (61K) Download Attachment
15.png (63K) Download Attachment
Euras.png (147K) Download Attachment

From forum: GMT - User

Re: [GMT-HELP}Crash while using time language file for some modes

2009-11-26T06:58:43Z

Walter,

Thank you for the quick answer.
It is necessary to wait for the new GMT version.
Maybe you will use the attached time language files in the future GMT versions. One for Win (console variant cp866 ru.d) and one for Unix (KOI8r ruk.d). The existing one may not be encoded due to another Windows codepage.
What your relation to adding the angle parameter for the annotation labels. I think it will be useful. The best example for this improvement is the long labels such as month names or something else.

Best Regards

Alex

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

Re: Text outside my drawing region

2009-11-26T05:16:45Z

Thanks for the answer and directions.

Gery

Date: Thu, 26 Nov 2009 07:50:30 +1100
From: p.wessel@...
Subject: Re: [GMT-HELP] Text outside my drawing region
To: GMT-HELP@...

Ue pstext with a new -R -J that uses cm positioning on the paper (e.g., -R0/20/0/20 -Jx1c) , or use your actual -R -J with -N to position something outside the region.

-p

On Nov 26, 2009, at 7:15 AM, Gery Herbozo Jimenez wrote:

Hi,

I have to put some texts (attached figure) outside my drawing region (CMP vs TWT: -R0/4000/0/2.5 or Distance vs Depth: -R0/50/0/5.5) but don't know how to do it exactly. I used pstext but it asked me to use the current region (e.g. -R0/4000/0/2.5), so it'll yield the text below the CMP (or X) axis (i.e. inside the box). In the attached figure I wrote the red text (using Paint), is it possible to put them in this way in GMT? I want this in my ps file.

Thanks in advance,

Gery

¡Windows Phone ya está aquí! Mucho más que un teléfono. ¡Hazte con uno! To unsubscribe, send the message "signoff gmt-help" tolistserv@...

To unsubscribe, send the message "signoff gmt-help" to listserv@...

¡Nuevo Canal Mujer! Moda, belleza, sexo, dietas, embarazo. más fácil y a tu alcance. Si quieres estar a la última, no puedes perdértelo. To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

Re: Text outside my drawing region

2009-11-25T12:50:30Z

Ue pstext with a new -R -J that uses cm positioning on the paper (e.g., -R0/20/0/20 -Jx1c) , or use your actual -R -J with -N to position something outside the region.

-p

On Nov 26, 2009, at 7:15 AM, Gery Herbozo Jimenez wrote:

Hi,

I have to put some texts (attached figure) outside my drawing region (CMP vs TWT: -R0/4000/0/2.5 or Distance vs Depth: -R0/50/0/5.5) but don't know how to do it exactly. I used pstext but it asked me to use the current region (e.g. -R0/4000/0/2.5), so it'll yield the text below the CMP (or X) axis (i.e. inside the box). In the attached figure I wrote the red text (using Paint), is it possible to put them in this way in GMT? I want this in my ps file.

Thanks in advance,

Gery

¡Windows Phone ya está aquí! Mucho más que un teléfono. ¡Hazte con uno! To unsubscribe, send the message "signoff gmt-help" tolistserv@...

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

Text outside my drawing region

2009-11-25T12:17:04Z

Hi,

I have to put some texts (attached figure) outside my drawing region (CMP vs TWT: -R0/4000/0/2.5 or Distance vs Depth: -R0/50/0/5.5) but don't know how to do it exactly. I used pstext but it asked me to use the current region (e.g. -R0/4000/0/2.5), so it'll yield the text below the CMP (or X) axis (i.e. inside the box). In the attached figure I wrote the red text (using Paint), is it possible to put them in this way in GMT? I want this in my ps file.

Thanks in advance,

Gery

¡Windows Phone ya está aquí! Mucho más que un teléfono. ¡Hazte con uno! To unsubscribe, send the message "signoff gmt-help" to listserv@...

example.jpg (47K) Download Attachment

From forum: GMT - User

Text outside my drawing region

2009-11-25T12:15:46Z

Hi,

Thanks in advance,

Gery

¡Windows Phone ya está aquí! Mucho más que un teléfono. ¡Hazte con uno! To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

Re: [GMT-HELP}Crash while using time language file for some modes

2009-11-25T01:01:44Z

Hi Alex-

We use a hash function to quickly find certain internal strings (e.g.,
month names) and when it was fed the strange control codes in ru.d it
returned a negative value which is not good to use as array entries.
I suppose it is because the extended characters were negative ascii
values. I have modified the code so this cannot happen.
Committed to GMT cvs. I am unable to test under Windows since we dont
have a Windows CVS version but the OSX version also crashed with your
example but now runs fine (well, I dont have the encodings so cannot
see the cyrillic) without crashing.

Cheers,
Paul

On Nov 25, 2009, at 7:39 PM, Alexander Kukharsky wrote:

> Hello,
> Windows system, last GMT version.
> psbasemap was crushed after reading ru.d file in function
> GMT_hash_init. The same case was repeated with jp/gr/il modes.
> This reaction can be reproduced with Example21.
> I have changed the encoding table to cp1251 because the existing
> ones (ISO-8859-5 for Russian language) not used in Windows. This
> table runs perfectly for DOS/OEM (cp866) console mode in any cases
> for existing GS fonts.
>
> What can be wrong in this situation?
>
> Best Regards
>
> Alex
>
>
> To unsubscribe, send the message "signoff gmt-help" to listserv@...
> <drwtsn32.log><cp1251.ps>

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

[GMT-HELP}Crash while using time language file for some modes

2009-11-25T00:39:54Z

Hello,
Windows system, last GMT version.
psbasemap was crushed after reading ru.d file in function GMT_hash_init. The same case was repeated with jp/gr/il modes.
This reaction can be reproduced with Example21.
I have changed the encoding table to cp1251 because the existing ones (ISO-8859-5 for Russian language) not used in Windows. This table runs perfectly for DOS/OEM (cp866) console mode in any cases for existing GS fonts.

What can be wrong in this situation?

Best Regards

Alex

To unsubscribe, send the message "signoff gmt-help" to listserv@...

drwtsn32.log (2K) Download Attachment
cp1251.ps (3K) Download Attachment

From forum: GMT - User

Re: pscoupe in version 4.5.1

2009-11-24T09:53:33Z

Gavin Hayes wrote:
> Hi Joaquim,
>
> I use version 4.2.0 on a Mac OSX 10.5.8. My results using the test
> script are attached; they reproduce the V3 behavior. Cheers,
>
> Gavin

Thanks Gavin.

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

Re: pscoupe in version 4.5.1

2009-11-24T09:43:10Z

Hi Joaquim,

I use version 4.2.0 on a Mac OSX 10.5.8. My results using the test script are attached; they reproduce the V3 behavior. Cheers,

Gavin

To unsubscribe, send the message "signoff gmt-help" to listserv@...

On Nov 24, 2009, at 10:33 AM, Joaquim Luis wrote:

Victoria Miller wrote:
Hello Joaquim,

The problem I am having is with the pscoupe command. Pscoupe should show a cross sectional view of what psmeca shows on a map e.g. a thrust fault fault in psmeca might look like a strike slip in cross section. If you could run the same pscoupe command in the two versions then it would be useful to see if you can reproduce the same results as me. When I do it, the 3.4.5 version produced a cross section view consistent with the map plot of psmeca, but the 4.5.1 version does not produce a consistent mechanism.

Victoria,

Yes, I can reproduce your results. I would not expect that the pscoupe behavior is the one you describe as I find very hard to interpret a focal mechanism that depends on the viewing perspective, but it wasn't me who wrote it and as I said I'm not an user.

At 4.4.0 version we fixed a couple bugs in util_meca.c so maybe than something was broken in pscoupe. Can someone with a pre 4.4.0 GMT version check if it gives the V3 or V4 behavior?

Joaquim

To unsubscribe, send the message "signoff gmt-help" to listserv@...

-----------------------

Gavin P Hayes

Post-doc Researcher

USGS National Earthquake Information Center

(Contracted by Synergetics, Inc.)

ghayes@...

303-273-8421

To unsubscribe, send the message "signoff gmt-help" to listserv@...

test.pdf (22K) Download Attachment

From forum: GMT - User

Re: pscoupe in version 4.5.1

2009-11-24T09:33:24Z

Victoria Miller wrote:

> Hello Joaquim,
>
> The problem I am having is with the pscoupe command. Pscoupe should
> show a cross sectional view of what psmeca shows on a map e.g. a
> thrust fault fault in psmeca might look like a strike slip in cross
> section. If you could run the same pscoupe command in the two versions
> then it would be useful to see if you can reproduce the same results
> as me. When I do it, the 3.4.5 version produced a cross section view
> consistent with the map plot of psmeca, but the 4.5.1 version does not
> produce a consistent mechanism.

Victoria,

Yes, I can reproduce your results. I would not expect that the pscoupe
behavior is the one you describe as I find very hard to interpret a
focal mechanism that depends on the viewing perspective, but it wasn't
me who wrote it and as I said I'm not an user.

At 4.4.0 version we fixed a couple bugs in util_meca.c so maybe than
something was broken in pscoupe. Can someone with a pre 4.4.0 GMT
version check if it gives the V3 or V4 behavior?

Joaquim

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

Re: another odd linear feature

2009-11-24T03:05:28Z

Hi again Dan-

Now fixed in the CVS version. Bug affected the easternmost nodes in
global, pixel-registered grids which fell in GSHHS bins with no
coastlines in them.

-p

On Nov 24, 2009, at 9:30 PM, Paul Wessel wrote:

> Hi Dan-
>
> I have reproduced the problem, so we should be able to fix this soon.
>
> Cheers,
> Paul
>
> On Nov 24, 2009, at 4:16 AM, Dan Kokron wrote:
>
>> GMT_version = "4.5.1 [64-bit] on Linux (RedHat 2.6.16.53-0.16-smp)
>> netcdf-4.0.1_20090326 (downloaded using the 'Unitdata netCDF library'
>> link on the GMT download page)
>> HDF5-1.8.2
>> GDAL-1.6.2, released 2009/07/31
>> all compiled with ifort--11.0.083
>>
>> The following commands produce a wet/dry mask that has water in the
>> wrong place. Specifically along the east side of the date-line over
>> Antarctica and Russia.
>>
>> grdlandmask -Rd -I7200+/3600+ -N0/1/0/1/1 -Df -A10+l -
>> Gglobal_slmask_7200x3600_pixelreg_f_gt10kmsq_byte.grd=nb -F
>>
>> grdimage global_slmask_7200x3600_pixelreg_f_gt10kmsq_byte.grd=nb -
>> R175/185/-90/-65 -C../slmask.cpt -Sn -JX8id -P > SL.ps
>> display SL.ps
>> --
>> Dan Kokron
>> Global Modeling and Assimilation Office
>> NASA Goddard Space Flight Center
>> Greenbelt, MD 20771
>> Daniel.S.Kokron@...
>> Phone: (301) 614-5192
>> Fax: (301) 614-5304
>>
>> To unsubscribe, send the message "signoff gmt-help" to listserv@...
>> <SL.ps><slmask.cpt>
>

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

Re: another odd linear feature

2009-11-24T02:30:28Z

Hi Dan-

I have reproduced the problem, so we should be able to fix this soon.

Cheers,
Paul

On Nov 24, 2009, at 4:16 AM, Dan Kokron wrote:

> GMT_version = "4.5.1 [64-bit] on Linux (RedHat 2.6.16.53-0.16-smp)
> netcdf-4.0.1_20090326 (downloaded using the 'Unitdata netCDF library'
> link on the GMT download page)
> HDF5-1.8.2
> GDAL-1.6.2, released 2009/07/31
> all compiled with ifort--11.0.083
>
> The following commands produce a wet/dry mask that has water in the
> wrong place. Specifically along the east side of the date-line over
> Antarctica and Russia.
>
> grdlandmask -Rd -I7200+/3600+ -N0/1/0/1/1 -Df -A10+l -
> Gglobal_slmask_7200x3600_pixelreg_f_gt10kmsq_byte.grd=nb -F
>
> grdimage global_slmask_7200x3600_pixelreg_f_gt10kmsq_byte.grd=nb -
> R175/185/-90/-65 -C../slmask.cpt -Sn -JX8id -P > SL.ps
> display SL.ps
> --
> Dan Kokron
> Global Modeling and Assimilation Office
> NASA Goddard Space Flight Center
> Greenbelt, MD 20771
> Daniel.S.Kokron@...
> Phone: (301) 614-5192
> Fax: (301) 614-5304
>
> To unsubscribe, send the message "signoff gmt-help" to listserv@...
> <SL.ps><slmask.cpt>

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

Re: grdproject coordinate innacuracies

2009-11-23T12:42:41Z

John Robbins wrote:

>
> This behavior (internal resetting of spacing) is not clearly described
> in the man pages. Intuitively, when one requests a set spacing (-D),
> one should get exactly that spacing, even if the -R needs trimming (or
> expanding) to get an integral number of cells.
>
> I might suggest to the GMT coding team that if a user specifies a set
> -D value for grdproject, that GMT adjust the -R boundaries to
> accommodate that spacing. If the user uses -N to specify the number of
> grid nodes then the resulting grid spacing should be adjusted to the
> "fixed" -R requested.

John,

You have a point that grdproject -D man is very short, but it uses the
same syntax as, for example, -I on surface. And there, the explanation
is extent

/
"x_inc/ [and optionally /y_inc/] is the grid spacing. Optionally, append
a suffix modifier. *Geographical (degrees) coordinates*: Append *m* to
indicate arc minutes or *c* to indicate arc seconds. If one of the units
*e*, *k*, *i*, or *n* is appended instead, the increment is assumed to
be given in meter, km, miles, or nautical miles, respectively, and will
be converted to the equivalent degrees longitude at the middle latitude
of the region (the conversion depends on *ELLIPSOID
<gmtdefaults.html#ELLIPSOID>*). If //y_inc/ is given but set to 0 it
will be reset equal to /x_inc/; otherwise it will be converted to
degrees latitude. *All coordinates*: If *=* is appended then the
corresponding max /x/ (/east/) or /y/ (/north/) may be slightly adjusted
to fit exactly the given increment [by default the increment may be
adjusted slightly to fit the given domain]. Finally, instead of giving
an increment you may specify the /number of nodes/ desired by appending
*+* to the supplied integer argument; the increment is then recalculated
from the number of nodes and the domain. The resulting increment value
depends on whether you have selected a gridline-registered or
pixel-registered grid; see Appendix B for details. Note: if
*-R*/grdfile/ is used then grid spacing has already been initialized;
use *-I* to override the values."

Joaquim

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

Re: grdproject coordinate innacuracies

2009-11-23T12:29:17Z

Thanks Marta, I've hit this snag before and should have remembered that GMT works to fit things into the -R parameters. You have solved the issue I was having.

When I reset the -39 upper latitude limit to an integral number of projected cells (-38.9528588207, in my case), it all works fine.

This behavior (internal resetting of spacing) is not clearly described in the man pages. Intuitively, when one requests a set spacing (-D), one should get exactly that spacing, even if the -R needs trimming (or expanding) to get an integral number of cells.

I might suggest to the GMT coding team that if a user specifies a set -D value for grdproject, that GMT adjust the -R boundaries to accommodate that spacing. If the user uses -N to specify the number of grid nodes then the resulting grid spacing should be adjusted to the "fixed" -R requested.

Thanks again Marta - case closed!

John Robbins

Marta Ghidella wrote:

Cryospheric Branch, Code 614
Hello John:

Thank you for your message.

I know it is not an ellipsoid issue. I wanted to make clear that we were
using different ellipsoids because if it wasn't so then we had an extra
problem (at least I had one).

I understand that the spacing issue is as follows:

Your geographical region -R0/360/-90/-39 maps
into -5906.15/5906.15/-5906.15/5906.15 using WGS-84.

Now:
(xmax-xmin)/dx = (5906.15 - (-5906.15))/12.5 = 944.984

So the result is not an integer. You have two possibilities for the
projected grid if you want to fix the spacing: to make it a little shorter,
944 cells, or a little longer, 945 cells. For the first case the boundaries
are xmin=-5906.00, xmax=5906.00; for the second, xmin=-5906.25,
xmax=5906.25. For both cases your region is a little smaller or larger than
the mapped region.

An alternative can be to use exactly the same region with a slightly
different spacing, choosing the nearest integer, in this case 945. In this
case:
(5906.15 - (-5906.15))/dx_new = 945, so dx_new = 12.4998

And I think that this is what grdproject did. One problem is that it doesn't
allow you to make the choice yourself.

About grdmath: as I didn't have your grid, I created one just to test what
happened if I used the geographic region specified in the "////r" way.

Cheers,

Marta

----- Original Message -----
From: John.W.Robbins@...

To: GMT-HELP@...

Sent: Monday, November 23, 2009 1:28 PM

Subject: Re: [GMT-HELP] grdproject coordinate innacuracies

[Marta, my reply did not get posted to the group. Resending... slightly re-worded]

Marta,

Thank you for investigating the nature of the issue I'm trying to work through. Using the WGS-84 ellipsoid, I am able to replicate your x_min and x_max values. What you neglected to mention was the fact that the resulting grid is not spaced at exactly 12.5km. I get something like 12.4998km.

For my grids, I'm using the Hughes-1980 ellipsoid. But this is not an ellipsoid issue, since all my grids are self-consistent. I thought grdproject should be able to take practically any geographic grid on any ellipsoid and project it onto a plane with exactly 12.5km spacing.

I am unable to utilize (via grdmath) a grdproject-created grid with another that is defined exactly on 12.5km spacing. I must be missing something here... but thanks for running a few simple tests!

Sincerely,

John Robbins (NASA/GSFC)

Marta Ghidella wrote:
I don't see anything wrong.

It seems to me that your given spacing was slightly adjusted (by the
program) to match the projected coordinates exactly, in a way that the -39
degree circle is tangent to the sides of the square determined by the
projected region.

Using:
grdproject
test.grd -Gtr.grd -Js0/-90/-70/1:1 -R-135/-21.9058/45/-21.9058r -F -Ak -C -D12.5

I get a similar result as that generated by:
grdproject
test.grd -Gt125.grd -Js0/-90/-70/1:1 -R0/360/-90/-39 -F -Ak -C -D12.5

(test.grd was created using: grdmath -R0/360/-90/-39 -I1 0 1 ADD = test.grd)

I am using GMT version 4.5.0

In all cases I get rather different projected coordinates. You got:
x_min: -5906.27115 x_max: 5906.27115

And I get:
x_min: -5906.15 x_max: 5906.15

I am using ellipsoid WGS-84. Different ellipsoids are the only cause that I
can think of to account for the difference. Which one are you using?


Cheers,

Marta

----- Original Message ----- 
From: John Robbins
To: GMT-HELP@...
Sent: Friday, November 20, 2009 1:59 PM
Subject: [GMT-HELP] grdproject coordinate innacuracies


I seem to have run into a strange bit of grdproject behavior. The
coordinates resulting from a grdproject command are not exact. I am using
GMT 4.4 on an intel Mac using OS 10.5.8.

Starting with a simple 1 deg by 1 deg global grid (gridline registration),
the desire is to project this grid onto a (south) polar stereographic plane,
with pixel registration, having a spacing 12.5km. I have used a command like
this:

grdproject
test.grd -Gt125.grd -Js0/-90/-70/1:1 -R0/360/-90/-39 -Ak -F -C -D12.5

When I issue a grdinfo on t125.grd I get the following (using
a --D_FORMAT=%.5f):

t125.grd: Title: t125.grd
t125.grd: Command: grdproject -Js0/-90/-70/1:1 -R0/360/-90/-39
test.grd -Gt125.grd -Ak -F -C -D12.5
t125.grd: Remark:
t125.grd: Pixel node registration used
t125.grd: Grid file format: nf (# 18)
t125.grd: x_min: -5906.27115 x_max: 5906.27115 x_inc: 12.50004 name: x nx:
945
t125.grd: y_min: -5906.27115 y_max: 5906.27115 y_inc: 12.50004 name: y ny:
945
t125.grd: z_min: -2.31822 z_max: 17.63076 name: z
t125.grd: scale_factor: 1.00000 add_offset: 0.00000

Why are the x and y min and max values non integral to the requested 12.5km
spacing? The increment comes back as 12.50004. Any ideas?

Additionally, I seem unable to specify -R parameters as lower left and upper
right coordinates (appending "r"). grdproject runs endlessly under such a
request. Perhaps these were issues ironed out with the release of GMT 4.5?

John R.

    

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

Re: grdproject coordinate innacuracies

2009-11-23T11:54:18Z

Cryospheric Branch, Code 614

Hello John:

Thank you for your message.

I know it is not an ellipsoid issue. I wanted to make clear that we were
using different ellipsoids because if it wasn't so then we had an extra
problem (at least I had one).

I understand that the spacing issue is as follows:

Your geographical region -R0/360/-90/-39 maps
into -5906.15/5906.15/-5906.15/5906.15 using WGS-84.

Now:
(xmax-xmin)/dx = (5906.15 - (-5906.15))/12.5 = 944.984

So the result is not an integer. You have two possibilities for the
projected grid if you want to fix the spacing: to make it a little shorter,
944 cells, or a little longer, 945 cells. For the first case the boundaries
are xmin=-5906.00, xmax=5906.00; for the second, xmin=-5906.25,
xmax=5906.25. For both cases your region is a little smaller or larger than
the mapped region.

An alternative can be to use exactly the same region with a slightly
different spacing, choosing the nearest integer, in this case 945. In this
case:
(5906.15 - (-5906.15))/dx_new = 945, so dx_new = 12.4998

And I think that this is what grdproject did. One problem is that it doesn't
allow you to make the choice yourself.

About grdmath: as I didn't have your grid, I created one just to test what
happened if I used the geographic region specified in the "////r" way.

Cheers,

Marta

----- Original Message -----

From: John.W.Robbins@...

To: GMT-HELP@...

Sent: Monday, November 23, 2009 1:28 PM

Subject: Re: [GMT-HELP] grdproject coordinate innacuracies

[Marta, my reply did not get posted to the group. Resending... slightly re-worded]

Marta,

Thank you for investigating the nature of the issue I'm trying to work through. Using the WGS-84 ellipsoid, I am able to replicate your x_min and x_max values. What you neglected to mention was the fact that the resulting grid is not spaced at exactly 12.5km. I get something like 12.4998km.

For my grids, I'm using the Hughes-1980 ellipsoid. But this is not an ellipsoid issue, since all my grids are self-consistent. I thought grdproject should be able to take practically any geographic grid on any ellipsoid and project it onto a plane with exactly 12.5km spacing.

I am unable to utilize (via grdmath) a grdproject-created grid with another that is defined exactly on 12.5km spacing. I must be missing something here... but thanks for running a few simple tests!

Sincerely,

John Robbins (NASA/GSFC)

Marta Ghidella wrote:

I don't see anything wrong.

It seems to me that your given spacing was slightly adjusted (by the
program) to match the projected coordinates exactly, in a way that the -39
degree circle is tangent to the sides of the square determined by the
projected region.

Using:
grdproject
test.grd -Gtr.grd -Js0/-90/-70/1:1 -R-135/-21.9058/45/-21.9058r -F -Ak -C -D12.5

I get a similar result as that generated by:
grdproject
test.grd -Gt125.grd -Js0/-90/-70/1:1 -R0/360/-90/-39 -F -Ak -C -D12.5

(test.grd was created using: grdmath -R0/360/-90/-39 -I1 0 1 ADD = test.grd)

I am using GMT version 4.5.0

In all cases I get rather different projected coordinates. You got:
x_min: -5906.27115 x_max: 5906.27115

And I get:
x_min: -5906.15 x_max: 5906.15

I am using ellipsoid WGS-84. Different ellipsoids are the only cause that I
can think of to account for the difference. Which one are you using?


Cheers,

Marta

----- Original Message ----- 
From: John Robbins
To: GMT-HELP@...
Sent: Friday, November 20, 2009 1:59 PM
Subject: [GMT-HELP] grdproject coordinate innacuracies


I seem to have run into a strange bit of grdproject behavior. The
coordinates resulting from a grdproject command are not exact. I am using
GMT 4.4 on an intel Mac using OS 10.5.8.

Starting with a simple 1 deg by 1 deg global grid (gridline registration),
the desire is to project this grid onto a (south) polar stereographic plane,
with pixel registration, having a spacing 12.5km. I have used a command like
this:

grdproject
test.grd -Gt125.grd -Js0/-90/-70/1:1 -R0/360/-90/-39 -Ak -F -C -D12.5

When I issue a grdinfo on t125.grd I get the following (using
a --D_FORMAT=%.5f):

t125.grd: Title: t125.grd
t125.grd: Command: grdproject -Js0/-90/-70/1:1 -R0/360/-90/-39
test.grd -Gt125.grd -Ak -F -C -D12.5
t125.grd: Remark:
t125.grd: Pixel node registration used
t125.grd: Grid file format: nf (# 18)
t125.grd: x_min: -5906.27115 x_max: 5906.27115 x_inc: 12.50004 name: x nx:
945
t125.grd: y_min: -5906.27115 y_max: 5906.27115 y_inc: 12.50004 name: y ny:
945
t125.grd: z_min: -2.31822 z_max: 17.63076 name: z
t125.grd: scale_factor: 1.00000 add_offset: 0.00000

Why are the x and y min and max values non integral to the requested 12.5km
spacing? The increment comes back as 12.50004. Any ideas?

Additionally, I seem unable to specify -R parameters as lower left and upper
right coordinates (appending "r"). grdproject runs endlessly under such a
request. Perhaps these were issues ironed out with the release of GMT 4.5?

John R.

Email: John.Robbins@...

Web: ICESat Home Page

Cryospheric Branch, Code 614.1

NASA Goddard Space Flight Center

Greenbelt, Maryland 20771

To unsubscribe, send the message "signoff gmt-help" to listserv@... To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

another odd linear feature

2009-11-23T09:16:57Z

GMT_version = "4.5.1 [64-bit] on Linux (RedHat 2.6.16.53-0.16-smp)
netcdf-4.0.1_20090326 (downloaded using the 'Unitdata netCDF library'
link on the GMT download page)
HDF5-1.8.2
GDAL-1.6.2, released 2009/07/31
all compiled with ifort--11.0.083

The following commands produce a wet/dry mask that has water in the
wrong place. Specifically along the east side of the date-line over
Antarctica and Russia.

grdlandmask -Rd -I7200+/3600+ -N0/1/0/1/1 -Df -A10+l -Gglobal_slmask_7200x3600_pixelreg_f_gt10kmsq_byte.grd=nb -F

grdimage global_slmask_7200x3600_pixelreg_f_gt10kmsq_byte.grd=nb -R175/185/-90/-65 -C../slmask.cpt -Sn -JX8id -P > SL.ps
display SL.ps
--
Dan Kokron
Global Modeling and Assimilation Office
NASA Goddard Space Flight Center
Greenbelt, MD 20771
Daniel.S.Kokron@...
Phone: (301) 614-5192
Fax: (301) 614-5304

To unsubscribe, send the message "signoff gmt-help" to listserv@...

# cpt file created by: grd2cpt global_slmask_1152x721_gt600kmsq.grd -Crainbow -E3
#COLOR_MODEL = +HSV
#
0 225 1 1 0.5 225 1 1
0.5 75 1 1 1 75 1 1
B 0 0 0
F 0 0 1
N 0 0 0.501960784314

To unsubscribe, send the message "signoff gmt-help" to listserv@...

SL.ps (16K) Download Attachment

From forum: GMT - User

Re: grdproject coordinate innacuracies

2009-11-23T08:28:44Z

I don't see anything wrong.

It seems to me that your given spacing was slightly adjusted (by the
program) to match the projected coordinates exactly, in a way that the -39
degree circle is tangent to the sides of the square determined by the
projected region.

Using:
grdproject
test.grd -Gtr.grd -Js0/-90/-70/1:1 -R-135/-21.9058/45/-21.9058r -F -Ak -C -D12.5

I get a similar result as that generated by:
grdproject
test.grd -Gt125.grd -Js0/-90/-70/1:1 -R0/360/-90/-39 -F -Ak -C -D12.5

(test.grd was created using: grdmath -R0/360/-90/-39 -I1 0 1 ADD = test.grd)

I am using GMT version 4.5.0

In all cases I get rather different projected coordinates. You got:
x_min: -5906.27115 x_max: 5906.27115

And I get:
x_min: -5906.15 x_max: 5906.15

I am using ellipsoid WGS-84. Different ellipsoids are the only cause that I
can think of to account for the difference. Which one are you using?


Cheers,

Marta

----- Original Message ----- 
From: John Robbins
To: GMT-HELP@...
Sent: Friday, November 20, 2009 1:59 PM
Subject: [GMT-HELP] grdproject coordinate innacuracies


I seem to have run into a strange bit of grdproject behavior. The
coordinates resulting from a grdproject command are not exact. I am using
GMT 4.4 on an intel Mac using OS 10.5.8.

Starting with a simple 1 deg by 1 deg global grid (gridline registration),
the desire is to project this grid onto a (south) polar stereographic plane,
with pixel registration, having a spacing 12.5km. I have used a command like
this:

grdproject
test.grd -Gt125.grd -Js0/-90/-70/1:1 -R0/360/-90/-39 -Ak -F -C -D12.5

When I issue a grdinfo on t125.grd I get the following (using
a --D_FORMAT=%.5f):

t125.grd: Title: t125.grd
t125.grd: Command: grdproject -Js0/-90/-70/1:1 -R0/360/-90/-39
test.grd -Gt125.grd -Ak -F -C -D12.5
t125.grd: Remark:
t125.grd: Pixel node registration used
t125.grd: Grid file format: nf (# 18)
t125.grd: x_min: -5906.27115 x_max: 5906.27115 x_inc: 12.50004 name: x nx:
945
t125.grd: y_min: -5906.27115 y_max: 5906.27115 y_inc: 12.50004 name: y ny:
945
t125.grd: z_min: -2.31822 z_max: 17.63076 name: z
t125.grd: scale_factor: 1.00000 add_offset: 0.00000

Why are the x and y min and max values non integral to the requested 12.5km
spacing? The increment comes back as 12.50004. Any ideas?

Additionally, I seem unable to specify -R parameters as lower left and upper
right coordinates (appending "r"). grdproject runs endlessly under such a
request. Perhaps these were issues ironed out with the release of GMT 4.5?

John R.

--
Cryospheric Branch, Code 614

Email: John.Robbins@...

Web: ICESat Home Page

Cryospheric Branch, Code 614.1

NASA Goddard Space Flight Center

Greenbelt, Maryland 20771

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

Re: pscoupe in version 4.5.1

2009-11-23T08:19:01Z

Hello Joaquim,

The problem I am having is with the pscoupe command. Pscoupe should show a cross sectional view of what psmeca shows on a map e.g. a thrust fault fault in psmeca might look like a strike slip in cross section. If you could run the same pscoupe command in the two versions then it would be useful to see if you can reproduce the same results as me. When I do it, the 3.4.5 version produced a cross section view consistent with the map plot of psmeca, but the 4.5.1 version does not produce a consistent mechanism.

Thanks

Victoria

On Nov 22, 2009, at 8:02 PM, Joaquim Luis wrote:

Victoria Miller wrote:

Hi,

I recently switched from GMT version 3.4.5 to 4.5.1 and am trying to plot focal mechanisms in cross section using pscoupe.
However the focal mechanisms (using version 4.5.1) I get in the cross section are rotated 90 degrees from what they should be.
I ran my test script on another computer with version 4.2 and it worked fine...is this perhaps something that changed in the 4.4.0 version update?

Attached are a v3 figure which has the correct mechanisms, and a v4 figure which has the wrong mechanisms.

Thanks

Victoria,

Why do you say the V3 is correct and V4 is wrong?
Taking as example the first mechanism of your example file

-62.17967 16.71317 -3.83 180 18 -88 0 72 -90 4.90

and plotting it with psmeca

echo 0.0 0.0 0.0 180 18 -88 5 0 0 | psmeca -Sa2.5c -Gblack -R-1/1/-1/1 -JM8c -P -B0 > this_meca.ps

shows "vertical" balls, similar to the V4 example. And I say similar because it looks like your example seen from "behind".
That is, like this

echo 0.0 0.0 0.0 0 18 -88 5 0 0 | psmeca -Sa2.5c -Gblack -R-1/1/-1/1 -JM8c -P -B0 > this_meca.ps

Anyway, I'm not a psvelo user and confess that I don't understand a bit of the man description when it says:

"A /new file/ is created with the new coordinates (*x*, *y*) and the mechanism (from lower focal half-sphere for horizontal plane, to half-sphere behind a vertical plane). When the plane is not horizontal, - north direction becomes upwards steepest descent direction of the plane (u) - east direction becomes strike direction of the plane (s) - down direction (= north^east) becomes u^s Axis angles are defined in the same way as in horizontal plane in the new system. Moment tensor (initially in r, t, f system that is up, south, east) is defined in (-u^s, -u, s) system. A /file/ is created with extracted events."

Joaquim Luis

To unsubscribe, send the message "signoff gmt-help" to listserv@...

Victoria Miller

victoriamiller0@...

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

Re: pscoupe in version 4.5.1

2009-11-22T17:02:32Z

Victoria Miller wrote:

> Hi,
>
> I recently switched from GMT version 3.4.5 to 4.5.1 and am trying to
> plot focal mechanisms in cross section using pscoupe.
> However the focal mechanisms (using version 4.5.1) I get in the cross
> section are rotated 90 degrees from what they should be.
>
> I ran my test script on another computer with version 4.2 and it
> worked fine...is this perhaps something that changed in the 4.4.0
> version update?
>
> Attached are a v3 figure which has the correct mechanisms, and a v4
> figure which has the wrong mechanisms.
>
> Thanks

Victoria,

Why do you say the V3 is correct and V4 is wrong?
Taking as example the first mechanism of your example file

-62.17967 16.71317 -3.83 180 18 -88 0 72 -90 4.90

and plotting it with psmeca

echo 0.0 0.0 0.0 180 18 -88 5 0 0 | psmeca -Sa2.5c -Gblack -R-1/1/-1/1
-JM8c -P -B0 > this_meca.ps

shows "vertical" balls, similar to the V4 example. And I say similar
because it looks like your example seen from "behind".
That is, like this

echo 0.0 0.0 0.0 0 18 -88 5 0 0 | psmeca -Sa2.5c -Gblack -R-1/1/-1/1
-JM8c -P -B0 > this_meca.ps

Anyway, I'm not a psvelo user and confess that I don't understand a bit
of the man description when it says:

"A /new file/ is created with the new coordinates (*x*, *y*) and the
mechanism (from lower focal half-sphere for horizontal plane, to
half-sphere behind a vertical plane). When the plane is not horizontal,
- north direction becomes upwards steepest descent direction of the
plane (u) - east direction becomes strike direction of the plane (s) -
down direction (= north^east) becomes u^s
Axis angles are defined in the same way as in horizontal plane in the
new system.
Moment tensor (initially in r, t, f system that is up, south, east) is
defined in (-u^s, -u, s) system. A /file/ is created with extracted events."

Joaquim Luis

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

Re: gmt map to geotif

2009-11-22T11:28:15Z

Hi,

Some recent work with ps2raster allows you to do this (or to an image with world file which works just as well). Make sure you are using at least GMT v 4.4.0

There are some quirks/gotchas with this, particularly around the image extent not exceeding the map extent (with annotations).

From the ps2raster help:

-W Write a ESRI type world file suitable to make (e.g) .tif files be recognized as geotiff by softwares that know how to do it. Be aware,
however, that different results are obtained depending on the image
contents and if the -B option has been used or not. The trouble with
-B is that it creates a frame and very likely its annotations and that
introduces pixels outside the map data extent. As a consequence, the
map extents estimation will be wrong. To avoid this problem, use the
--BASEMAP_TYPE=inside option which plots all annotations related stuff
inside the image and does not compromise the coordinate computations.
The world file naming follows the convention of jamming a 'w' in the
file extension. So, if the output is tif (-Tt) the world file is a .tfw,
for jpeg a .jgw, and so on.
Use -W+ to do a system call to gdal_translate and produce a true geoTIFF
image right away. The output file will have the extension .tiff
See the man page for other 'gotchas'. Automatically sets -A -P.

Cheers

Brent Wood

--- On Sun, 11/22/09, Ahmet Temiz <temiz@...> wrote:

> From: Ahmet Temiz <temiz@...>
> Subject: [GMT-HELP] gmt map to geotif
> To: GMT-HELP@...
> Date: Sunday, November 22, 2009, 11:38 PM
> hello
>
> I was wondering how I could convert my gmt map to geotif
> to use in
> UMN-Mapserver environment ?
>
> regards
>
> Ahmet Temiz
> --
> Open WebMail Project (http://openwebmail.org)
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> To unsubscribe, send the message "signoff gmt-help" to listserv@...
>

To unsubscribe, send the message "signoff gmt-help" to listserv@...

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

gmt map to geotif

2009-11-22T02:38:52Z

hello

I was wondering how I could convert my gmt map to geotif to use in
UMN-Mapserver environment ?

regards

Ahmet Temiz
--
Open WebMail Project (http://openwebmail.org)

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

Re: physical GMT globe

2009-11-20T15:20:59Z

On Monday 16 November 2009 12:00:52 Kelsey Jordahl wrote:
> I will use this as an opportunity to ask a few questions I have had for a
> while:
>
> 1. Is there a good commercially available globe of Earth topography,
> particularly from Smith & Sandwell data? (I haven't had any luck finding
> them.)
>
I haven't seen one.

> 2. Is there a standard map projection for creating the gores for a globe?
> Obviously it would be great to have GMT scripts.

I would imagine a very suitable approach would be to plot each UTM zone,
making sure you plot the bounding meridians, then trim along the meridians.
That would give you sixty pieces of paper for each hemisphere: is that too
much?
>
> 3. Are there any good sources for the practical aspects of printing &
> gluing a globe (paper type, glue, width of the gores, etc.)?
>
I've never done this myself, but I can imagine getting the gores in the right
place the first time is fairly difficult: so some way of actually building the
globe from the printed material might be worth trying. You could assemble a
montage of gores (either by using an X shift in the origin within GMT or using
ps2raster to convert the Postscript output into something you can assemble in
a graphics editor like Gimp) to give a set of gores to be printed on a single
page. How many would depend on the scale you are working at. If you could use
a scale such that fifteen gores are printed on one page (using UTM zones), you
would have eight approximately square images, each covering 90 degrees of
latitude and 90 degrees of longitude.

If you printed this on cardstock, you could trim each page along the equator
and its boundaries, and cut out the blanks between the gores, leaving them
connected for a short distance from the equator.

Then for each quadrant of each hemisphere, tape the gores together on the
inside.

Assembling each hemisphere would then be fairly easy (some kind of reinforcing
would be needed if you want to make it durable) and joining the two
hemispheres would also be easy. You would probably need a disc at each pole
to overlay all the joined gores. This could be plotted using polar
stereographic projection.
--
Les Denham
-------------------
http://www.hal-pc.org/~ldenham
-----------------------------------------------------------------------------------------------
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

grdproject coordinate innacuracies

2009-11-20T08:59:00Z

I seem to have run into a strange bit of grdproject behavior. The coordinates resulting from a grdproject command are not exact. I am using GMT 4.4 on an intel Mac using OS 10.5.8.

Starting with a simple 1 deg by 1 deg global grid (gridline registration), the desire is to project this grid onto a (south) polar stereographic plane, with pixel registration, having a spacing 12.5km. I have used a command like this:

grdproject test.grd -Gt125.grd -Js0/-90/-70/1:1 -R0/360/-90/-39 -Ak -F -C -D12.5

When I issue a grdinfo on t125.grd I get the following (using a --D_FORMAT=%.5f):

t125.grd: Title: t125.grd t125.grd: Command: grdproject -Js0/-90/-70/1:1 -R0/360/-90/-39 test.grd -Gt125.grd -Ak -F -C -D12.5 t125.grd: Remark: t125.grd: Pixel node registration used t125.grd: Grid file format: nf (# 18) t125.grd: x_min: -5906.27115 x_max: 5906.27115 x_inc: 12.50004 name: x nx: 945 t125.grd: y_min: -5906.27115 y_max: 5906.27115 y_inc: 12.50004 name: y ny: 945 t125.grd: z_min: -2.31822 z_max: 17.63076 name: z t125.grd: scale_factor: 1.00000 add_offset: 0.00000

Why are the x and y min and max values non integral to the requested 12.5km spacing? The increment comes back as 12.50004. Any ideas?

Additionally, I seem unable to specify -R parameters as lower left and upper right coordinates (appending "r"). grdproject runs endlessly under such a request. Perhaps these were issues ironed out with the release of GMT 4.5?

John R.

--
Cryospheric Branch, Code 614

Email: John.Robbins@...

Web: ICESat Home Page

Cryospheric Branch, Code 614.1

NASA Goddard Space Flight Center

Greenbelt, Maryland 20771

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

Re: GMT gsview

2009-11-19T20:47:47Z

Because gv and gsview are different programs.

You can install gv or make an alias with gsview (e.g. ln -s /usr/bin/gsview /usr/bin/gv).

With the latter case, calling gv will execute gsview.

Cheers,

-s

On Nov 19, 2009, at 6:39 PM, woxin5295 wrote:

Dear sir

I have installed GMT,and ESP Ghostscript 815.04 (2007-03-14),gsview-4.8-1.i386.rpm.But when I run the GMT example,I os show:

gv : command not find?why?
Yours

Liu Junqing

"雪见"杨幂邀你共品3D国韵网游《天下贰》，海报免费领

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

GMT gsview

2009-11-19T20:39:27Z

Dear sir

I have installed GMT,and ESP Ghostscript 815.04 (2007-03-14),gsview-4.8-1.i386.rpm.But when I run the GMT example,I os show:

gv : command not find?why?
Yours

Liu Junqing

"雪见"杨幂邀你共品3D国韵网游《天下贰》，海报免费领

From forum: GMT - User

Stereographic projection usage (-Js) issues

2009-11-19T11:58:50Z

Greetings,

Some nuts and bolts questions regarding the General
Stereographic projection. I'm actually able to
accomplish what I want to accomplish with GMT (namely
MAPPROJECT), but investigating this projection highlighted
to me some places where the GMT documentation could be
improved and where the projection algorithm becomes suspect
without any GMT warnings/errors.

Any feedback on my questions would be welcome.

Thanks,
Dan

I am puzzling over the usage of the General Stereographic
projection...in my case centered on the North Pole (thus a
polar stereographic projection). In particular, I have
questions about -Js; some of these questions are related
but not identical to what was initiated on GMTHELP earlier this year
by John Robbins regarding -JS usage; see:
https://listserv.hawaii.edu/cgi-bin/wa?A2=ind0901&L=GMT-HELP&D=0&P=35121
I am working with a Polar Stereographic grid of the International
Bathymetry Chart of the Arctic Ocean (IBCAO), which has a standard
latitude of 75degN.

The attached C-shell script, and a log of its stdout/stderr, illustrates
some of the behavior addressed below. These examples are for
inverse-projections, but I see the same results with forward-projections.
My goal for working with the IBCAO grid is to use
MAPPROJECT to go between lat-lon and X-Y values properly. I get
the same behavior with GMT on recent versions of Linux and Solaris.

First: the usage message for the -Js/-JS option is confusing to me;
for example, see:
http://gmt.soest.hawaii.edu/gmt/doc/gmt/html/man/psbasemap.html
Below, I propose a more-accurate and less-confusing (to me) description,
but I'm not sure that my description is 100% accurate.

Existing:
-Jslon0/lat0[/horizon]/scale or -JSlon0/lat0[/horizon]/width (General Stereographic [C]).
lon0/lat0 specifies the projection center. horizon
specifies the max distance from projection center (in degrees, < 180,
default 90). Give scale as 1:xxxx (true at pole)
or lat0/1:xxxx (true at standard parallel lat0) or radius/lat (radius
in UNIT from origin to the oblique latitude lat).
Note if 1:xxxx is used then to specify horizon you must also specify
the lat0 as +-90 to avoid ambiguity.

Less(?)-confusing:
-Jslon0/lat0[/horizon]/scale or -JSlon0/lat0[/horizon]/width (General Stereographic [C]).
lon0/lat0 specifies the projection center. horizon
specifies the max distance from projection center (in degrees, < 180,
default 90). Give scale as 1:xxxx (true at projection center)
or lats/1:xxxx (true at standard parallel lats) or radius/lato (radius
in UNIT from projection center to the oblique latitude lato).
Note if 1:xxxx is used, then to specify horizon you must also specify
the lat0(??) as +-90 to avoid ambiguity.

My suggested changes are:
I replaced "pole" with "projection center"
I replaced "lat0" referring to standard latitude with "lats"
I replaced "lat" referring to oblique latitude with "lato"
I don't know what the final lat0 means...truly lat0, or lats, or lato...
in the description above.
Can anyone confirm my changes or refine my suggested wording to more
accurately make this description less confusing?

Second: I'm uncertain about the reliability of the projection when
the standard parallel (I call it the latitude of true-scale, LAT_TS)
approaches or equals the central latitude. In
the north polar stereographic example, "Part 1)" of the example
C-shell script compares the inverse-projection results from PROJ.4
and MAPPROJECT. For all cases where LAT_TS is away from the pole,
I get identical results. When LAT_TS equals 90deg, I get NaN's for
MAPPROJECT, whereas PROJ gives me inverse-projection values in-line with
those of near-by LAT_TS's. I see a (small) divergence of MAPPROJECT's
results from PROJ's when LAT_TS is 89.999deg, suggesting to me that
GMT's algorithm is approaching a numerical singularity towards the
latitude of origin. When I omit LAT_TS, MAPPROJECT yields a
result very close to the result obtained when LAT_TS is set to
88deg...not the result at the projection center (90deg) as suggested to
me by the existing -Js|S description and the value obtained from PROJ.

Third: Like John Robbins in the above GMTHELP link, I'm confused
about the meaning of "horizon". I don't see this term in the
John Snyder, USGS Professional Paper 1395; a WWW-search of "horizon"
and "stereographic" gets a lot of hits to the "stereographic horizon
map projection", which appears to have been popularized for meteorological
uses. The first few figures of Shenk et al., 1971, J. Appl. Meteor.,
illustrate the geometry of this projection:
http://ams.allenpress.com/perlserv/?request=get-abstract&doi=10.1175%2F1520-0450(1971)010%3C0582%3AMUOTSH%3E2.0.CO%3B2&ct=1
After scanning the paper, it seems that the stereographic horizon projection
is simply a stereographic projection not at the north or south pole
of the earth (i.e. LAT0 != +/-90., see Fig. 4 of that paper), which -Js|S
seem to provide without any reference to the "horizon" parameter. This
parameter is described as:
"horizon specifies the max distance from projection center (in degrees, <180, default 90)"
Thus, "horizon" seems to be most similar to "d" in Figures 3,4 and Eqn. 6+
in the Shenk et al. paper, but I think that "d" is a linear measure
whereas "horizon" is an angular measure. Maybe "horizon" is simply the
maximum pseudo-co-latitude of P (Fig. 2) relative to the projection's
center; that would be most consistent with its stated limits (<180; default=90).
Does this parameter only have relevance for map-making (and not for
coordinate transforms via MAPPROJECT)?

When I omit a horizon value or when I specify the default 90deg, I get
identical results between MAPPROJECT and PROJ; this is good. However,
in "Part 2)" of my C-shell script, I don't see any effect of changing the
HORIZON value from 0.1deg to 179.9deg. This makes me question whether
HORIZON has any relevance to -Js in MAPPROJECT. Minor note: because
mapproject generates an error message when HORIZON=0deg, the limits for
HORIZON should be stated as: "(>0, <180, default 90)" and not "(<180,
default 90)". I'd probably state "arc-distance" rather than "distance" since
"horizon" seems to be only an angular quantity, different from
the maximum-distance "d" parameter that I think it most closely
resembles in the development of the stereographic horizon projection.

I'd be happy to iterate with the GMT developers on a better wording
for the "horizon" concept in this projection...off the top of my head,
I can't think of any easy changes other than probably re-naming
"horizon" (maxcolat?) and sticking a reference to the Shenk paper.
The wording of last sentence of the -Js|S description could be improved,
too.

Finally: a minor documentation glitch:
In manual page descriptions for psbasmap and similar, -Jm/-JM and
-Jt/-JT do not have the projection name in parentheses following
the projection parameters. This can be seen at:
http://gmt.soest.hawaii.edu/gmt/doc/gmt/html/man/psbasemap.html

I believe that the correct parenthetical descriptions would be:

-Jm[lon0/[lat0/]]scale or -JM[lon0/[lat0/]]width (Mercator [C]).

-Jtlon0/[lat0/]scale or -JTlon0/[lat0/]width (Transverse Mercator [C])

It may be worth noting in the -Jm|M case, the default lat0=0
yields Equatorial Mercator (similar to the special cases listed
under -J{cyl_stere|Cyl_stere|q|Q|y|Y})

To unsubscribe, send the message "signoff gmt-help" to listserv@...

[polar_stereographic_examples.csh.log]

Experiments with GMT's stereographic projection -- inverse projection ===================================================================== Result of typing: mapproject |& head -1 mapproject 4.4.0 - Forward and Inverse map transformations and geodesy Result of typing: proj |& head -1 Rel. 4.6.1, 21 August 2008 Test point is lower-left corner, in meters, of IBCAO (version 2) polar-stereographic grid: -2904000 -2904000 Part 1) Compare results from inverse-projections by PROJ and MAPPROJECT at different standard latitudes: For LAT_TS=00.000, result via PROJ is: -45.0000000000 24.5903833779 For LAT_TS=00.000, result via MAPPROJECT (-Js) is: -45.0000000000 24.5903833778 For LAT_TS=50.000, result via PROJ is: -45.0000000000 50.0088819691 For LAT_TS=50.000, result via MAPPROJECT (-Js) is: -45.0000000000 50.0088819691 This is the IBCAO standard latitude... For LAT_TS=75.000, result via PROJ is: -45.0000000000 53.7995535809 For LAT_TS=75.000, result via MAPPROJECT (-Js) is: -45.0000000000 53.7995535809 For LAT_TS=88.000, result via PROJ is: -45.0000000000 54.3680344049 For LAT_TS=88.000, result via MAPPROJECT (-Js) is: -45.0000000000 54.3680344049 For LAT_TS=89.000, result via PROJ is: -45.0000000000 54.3756774881 For LAT_TS=89.000, result via MAPPROJECT (-Js) is: -45.0000000000 54.3756774881 For LAT_TS=89.999, result via PROJ is: -45.0000000000 54.3782247436 For LAT_TS=89.999, result via MAPPROJECT (-Js) is: -45.0000000000 54.3782235026 For LAT_TS=90.000, result via PROJ is: -45.0000000000 54.3782247460 For LAT_TS=90.000, result via MAPPROJECT (-Js) is: NaN NaN Avoid any/all LAT_TS in MAPPROJECT (-Js) is: -45.0000000000 54.3648410043 Part 2) Compare results from inverse-projections by MAPPROJECT (-Js) with different horizon values: (with LAT_TS=75.000) For HORIZON=00.0, result via MAPPROJECT (-Js) is: mapproject: GMT SYNTAX ERROR -J option. Correct syntax: -Js<lon0>/<lat0>[/<horizon>]/<scale> OR -JS<lon0>/<lat0>[/<horizon>]/<width> <horizon> is distance from center to perimeter (< 180, default 90) <scale> is <1:xxxx>, <lat>/<1:xxxx>, or <radius> (in inch)/<lat>, or use <width> in inch For HORIZON=00.1, result via MAPPROJECT (-Js) is: -45.0000000000 53.7995535809 For HORIZON=01.0, result via MAPPROJECT (-Js) is: -45.0000000000 53.7995535809 For HORIZON=10.0, result via MAPPROJECT (-Js) is: -45.0000000000 53.7995535809 For HORIZON=40.0, result via MAPPROJECT (-Js) is: -45.0000000000 53.7995535809 For HORIZON=50.0, result via MAPPROJECT (-Js) is: -45.0000000000 53.7995535809 For HORIZON=90.0, result via MAPPROJECT (-Js) is: -45.0000000000 53.7995535809 For HORIZON=179.0, result via MAPPROJECT (-Js) is: -45.0000000000 53.7995535809 For HORIZON=179.9, result via MAPPROJECT (-Js) is: -45.0000000000 53.7995535809 For HORIZON=180.0, result via MAPPROJECT (-Js) is: mapproject: GMT SYNTAX ERROR -J option. Correct syntax: -Js<lon0>/<lat0>[/<horizon>]/<scale> OR -JS<lon0>/<lat0>[/<horizon>]/<width> <horizon> is distance from center to perimeter (< 180, default 90) <scale> is <1:xxxx>, <lat>/<1:xxxx>, or <radius> (in inch)/<lat>, or use <width> in inch

polar_stereographic_examples.csh (7K) Download Attachment

From forum: GMT - User

Re: pscoupe in version 4.5.1

2009-11-19T08:12:05Z

Here is the test script I was using and 4 data points.

Thanks

To unsubscribe, send the message "signoff gmt-help" to listserv@...

On Nov 19, 2009, at 6:32 AM, Paul Wessel wrote:

Could you send us some data points and your command so we can reproduce the problem.
Thanx,
-p

On Nov 19, 2009, at 5:14 AM, Victoria Miller wrote:

Hi,

I recently switched from GMT version 3.4.5 to 4.5.1 and am trying to plot focal mechanisms in cross section using pscoupe.
However the focal mechanisms (using version 4.5.1) I get in the cross section are rotated 90 degrees from what they should be.

I ran my test script on another computer with version 4.2 and it worked fine...is this perhaps something that changed in the 4.4.0 version update?

Attached are a v3 figure which has the correct mechanisms, and a v4 figure which has the wrong mechanisms.

Thanks

Victoria (using powerPC mac OS 10.4.11)

To unsubscribe, send the message "signoff gmt-help" to listserv@... <testV3.pdf>
To unsubscribe, send the message "signoff gmt-help" to listserv@... <testV4.pdf>
To unsubscribe, send the message "signoff gmt-help" to listserv@...

To unsubscribe, send the message "signoff gmt-help" to listserv@...

Victoria Miller

victoriamiller0@...

To unsubscribe, send the message "signoff gmt-help" to listserv@...

test.sh (388 bytes) Download Attachment
testfm.temp (244 bytes) Download Attachment

From forum: GMT - User

Re: pscoupe in version 4.5.1

2009-11-19T03:32:23Z

Could you send us some data points and your command so we can reproduce the problem.

Thanx,

-p

On Nov 19, 2009, at 5:14 AM, Victoria Miller wrote:

Hi,

I recently switched from GMT version 3.4.5 to 4.5.1 and am trying to plot focal mechanisms in cross section using pscoupe.
However the focal mechanisms (using version 4.5.1) I get in the cross section are rotated 90 degrees from what they should be.

I ran my test script on another computer with version 4.2 and it worked fine...is this perhaps something that changed in the 4.4.0 version update?

Attached are a v3 figure which has the correct mechanisms, and a v4 figure which has the wrong mechanisms.

Thanks

Victoria (using powerPC mac OS 10.4.11)

To unsubscribe, send the message "signoff gmt-help" to listserv@... <testV3.pdf>
To unsubscribe, send the message "signoff gmt-help" to listserv@... <testV4.pdf>
To unsubscribe, send the message "signoff gmt-help" to listserv@...

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

Re: Transparent contour Labels on PS printer.

2009-11-18T10:14:39Z

Thank you for the response. You gave me a good option to try making a plot file but I suspect it would be good and print just like I was using the non-PS print driver. We have a couple of HP printers, one 15yo and one 1yo and they do the same thing. I preferred the print using the PS driver verses the HPGL or non-PS driver on the older printer. They are very similar on the new printer except of course the line through the contour labels. As long as I print using the non-PS driver everything is fine.

It seemed pretty consistent with the –R option and was wondering how GMT breaks the contour. It does not appear to affect the display in gsview, just the printing using the PS driver. I guess I was just more curious about the way the labels break the contour. My fear is that I will get to a certain map or certain setup that will not print the labels correctly regardless of the driver.

Regards,

Darrel Landis
EDCON-PRJ, Inc.

303-980-6556
Fax: 303-989-3480
dlandis@...

-----Original Message-----
From: World-Wide GMT Usage and Help Mailing List [mailto:GMT-HELP@...] On Behalf Of Kelsey Jordahl
Sent: Tuesday, November 17, 2009 10:08 AM
To: GMT-HELP@...
Subject: Re: [GMT-HELP] Transparent contour Labels on PS printer.

Different postscript interpreters render things in different ways (often [but not always?] due to bugs in implementation). If you like the way that ghostscript renders your PS file, you could use gs to generate a native printer file for you, or a bitmap (going through PDF is an extra step that may make things worse). I used to do this fairly often (usually because of memory limitations on a printer or to save processing time), but haven't had to for a long time. You didn't say what HP model, but for a LaserJet 4 series I have done this:

gs -q -dNOPAUSE -sDEVICE=ljet4 -sOutputFile=out.hp file.ps -c quit

and send the file out.hp (which if I recall correctly is PCL) to the printer. You may have to make sure that your printer driver doesn't get in the way and try to print the PCL as text or something.

I think the CUPS drivers hide all this from users in OS X and Linux these days, but may do something similar internally so the postscript interpreting is handled by ghostscript rather than the printer. I have no idea how this works in the Windows world.

On Fri, Nov 13, 2009 at 1:22 PM, Darrel landis <dlandis@...> wrote:

Hello

I'm having trouble with the transparent contour labels when printing maps on
a HP postscript printer. The PS file looks good in gsview but when I send
the plot to our postscript printer the contour line goes through the label.
I have found that if I give a -R range within my grid the line does not go
through the labels and the contour breaks correctly. When the -R is outside
the grid all contour labels have the contour line running through it and it
appears to only do this when it is plotted.

Has anyone had trouble printing contour labels on a Postscript printer?
Obviously I could generate a PDF or plot not using the plotter's PS driver
but I like the look of the plot better. How is the contour broken for the
labels? I'm using GMT version 4.5.0 on Win XP.

Regards,
Darrel Landis
EDCON-PRJ, Inc.
303-980-6556
Fax: 303-989-3480
dlandis@...

To unsubscribe, send the message "signoff gmt-help" to listserv@...

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

pscoupe in version 4.5.1

2009-11-18T10:14:00Z

Hi,

I recently switched from GMT version 3.4.5 to 4.5.1 and am trying to plot focal mechanisms in cross section using pscoupe.

However the focal mechanisms (using version 4.5.1) I get in the cross section are rotated 90 degrees from what they should be.

I ran my test script on another computer with version 4.2 and it worked fine...is this perhaps something that changed in the 4.4.0 version update?

Attached are a v3 figure which has the correct mechanisms, and a v4 figure which has the wrong mechanisms.

Thanks

Victoria (using powerPC mac OS 10.4.11)

To unsubscribe, send the message "signoff gmt-help" to listserv@...

To unsubscribe, send the message "signoff gmt-help" to listserv@...

To unsubscribe, send the message "signoff gmt-help" to listserv@...

testV3.pdf (14K) Download Attachment
testV4.pdf (13K) Download Attachment

From forum: GMT - User

Re: [Off topic] Gridding a polygon?

2009-11-18T02:54:26Z

Hi Russ

> Pscoast combines a series of cells into a polygon (the coastline). I want to
> convert a polygon into a series of cells. Cells totally within the polygon would
> be rectangles. Cells covering the edge of the polygon may be anything -
> triangles, quadrilaterals - depending on how many vertices of the polygon fell
> within that cell.

Have a look at GPC

http://www.cs.manchester.ac.uk/~toby/alan/software/

which allows arbitrary and robust intersection of
polygons. The library is is free for non-commercial
use (but not for commercial use).

I hope this helps!

Jim
--
J.J. Green
http://soliton.vm.bytemark.co.uk/pub/jjg/

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

Viewer matters

2009-11-18T02:31:09Z

Hi,

I was trying to get discrete colors for psscale but I always gets continuous color. I was using evince as the viewer. When I viewed it in gv, I got it as discrete. Surprise to me. So viewer sometimes matters.

Saji

The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User

[Off topic] Gridding a polygon?

2009-11-17T18:18:04Z

Thought someone on this list may have some brilliant insights into my problem -
or better still have already solved it! Conceptually I am wanting to do the
inverse of pscoast.

Pscoast combines a series of cells into a polygon (the coastline). I want to
convert a polygon into a series of cells. Cells totally within the polygon would
be rectangles. Cells covering the edge of the polygon may be anything -
triangles, quadrilaterals - depending on how many vertices of the polygon fell
within that cell.

The original polygon can be re-entrant but there will not be any nesting. The
grid size of the cells would be user specified.

Ideally there would need to be some ability to combine small cells that are not
entirely within the polygon with adjacent rectangular cells. This would be based
on some criteria - perhaps, area of cell less than some percentage of full cell
size.

Hope I have explained the problem sufficiently. Any bright ideas?

RussC
Brisbane

To unsubscribe, send the message "signoff gmt-help" to listserv@...

From forum: GMT - User