grdview oddities

[Andy Jacobson-4]

Howdy,

Many, many thanks for making and continuing to support GMT.  This  
year, we're dropping previous R- and python-based mapping solutions  
and using GMT to make all the maps for our NOAA CarbonTracker web  
page.  This new version will go live in a week or so, and I'll make  
sure to prominently mention GMT's role on the site.

I have two questions about grdview.  Context:  I make the netCDF files  
that grdview is reading myself.  They are output from a global  
atmospheric transport model, with a 3 degree longitude by 2 degree  
latitude global grid.  Further:  we're using GMT 4.5.1, and on several  
differing unix platforms.  grdview calls are of the form:

${grdview} -Lg -T ${psstart} "${ncfile}?${ncvar}" -Ya${map_y}i -Xa$
{map_x}i   -R${region} -J${projspec} ${gridlines} -C${cpt} > ${epsfile}



Question 1:  If I don't put "actual_range" attributes on the lat and  
lon dimension variables, there's a reproducible (OS X and linux)  
freeing of an unallocated pointer.  With those attributes in the grid  
file, I still get "grdview: Warning: x_inc does not divide 180; g  
boundary condition ignored."  I don't understand that warning message,  
and would like to fix my code.

Question 2: With a global Hammer projection, the grid annotation  
argument "-Bg0/g0" to grdview does not produce the desired global  
outlines.  The program grdimage, however, does produce the outlines I  
want (but I need grid box polygons without interpolation, hence  
"grdview -T").  Further, I'm getting "-Bg0/g0" to work if I use a  
regional Lambert cc projection.  As a workaround, I've been following  
the call to grdview with a call psbasemap.   I presume this is not  
expected behavior of grdview...am I perhaps doing things wrong?

I'm willing to help track down and fix these bugs, but I don't know  
how to begin helping.


Best Regards,

Andy


--
Andy Jacobson
andy.jacobson@...

NOAA Earth System Research Lab
Global Monitoring Division
325 Broadway
Boulder, Colorado 80305

303/497-4916

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

[Joaquim Luis]

Andy Jacobson wrote:

> ${grdview} -Lg -T ${psstart} "${ncfile}?${ncvar}" -Ya${map_y}i
> -Xa${map_x}i   -R${region} -J${projspec} ${gridlines} -C${cpt} >
> ${epsfile}
>
> Question 1:  If I don't put "actual_range" attributes on the lat and
> lon dimension variables, there's a reproducible (OS X and linux)
> freeing of an unallocated pointer.  With those attributes in the grid
> file, I still get "grdview: Warning: x_inc does not divide 180; g
> boundary condition ignored."  I don't understand that warning message,
> and would like to fix my code.

Andy,

That makes think of the effect of a bug on GMT versions built with GDAL
support. Are you using one of such?
But even that would manifest only if you were actually using GDAL
through the =gd mechanism, which doesn't
seam to be the case of  -- "${ncfile}?${ncvar}".

Joaquim Luis

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

[Andy Jacobson-4]

Hi Joaquim,

Thanks for your response.  I don't know if my versions of GMT were  
compiled with GDAL, but I'm certainly not using that capability.  As  
you surmise, I'm getting my data from netCDF files.

Thanks,

Andy


On Fri 30 Oct , at 14:52 , Joaquim Luis wrote:

> Andy Jacobson wrote:
>> ${grdview} -Lg -T ${psstart} "${ncfile}?${ncvar}" -Ya${map_y}i -Xa$
>> {map_x}i   -R${region} -J${projspec} ${gridlines} -C${cpt} > $
>> {epsfile}
>>
>> Question 1:  If I don't put "actual_range" attributes on the lat  
>> and lon dimension variables, there's a reproducible (OS X and  
>> linux) freeing of an unallocated pointer.  With those attributes in  
>> the grid file, I still get "grdview: Warning: x_inc does not divide  
>> 180; g boundary condition ignored."  I don't understand that  
>> warning message, and would like to fix my code.
>
> Andy,
>
> That makes think of the effect of a bug on GMT versions built with  
> GDAL support. Are you using one of such?
> But even that would manifest only if you were actually using GDAL  
> through the =gd mechanism, which doesn't
> seam to be the case of  -- "${ncfile}?${ncvar}".
>
> Joaquim Luis
>
> To unsubscribe, send the message "signoff gmt-help" to listserv@...
>

--
Andy Jacobson
andy.jacobson@...

NOAA Earth System Research Lab
Global Monitoring Division
325 Broadway
Boulder, Colorado 80305

303/497-4916

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

[Joaquim Luis-2]

On Fri, Oct 30, 2009 at 10:29 PM, Andy Jacobson <Andy.Jacobson@...> wrote:

Hi Joaquim,

Thanks for your response.  I don't know if my versions of GMT were compiled with GDAL, but I'm certainly not using that capability.  As you surmise, I'm getting my data from netCDF files.

First part is very is to check. Just run grdreformat and see if last line printed on screen mention the GDAL driver

As for second partd, you could get netCDF trough gdal support but that is NOT RECOMMENDED, as the GDAL netCDF driver is bugged since several years.

 

Thanks,

Andy

On Fri 30 Oct , at 14:52 , Joaquim Luis wrote:

Andy Jacobson wrote:

${grdview} -Lg -T ${psstart} "${ncfile}?${ncvar}" -Ya${map_y}i -Xa${map_x}i   -R${region} -J${projspec} ${gridlines} -C${cpt} > ${epsfile}

Question 1:  If I don't put "actual_range" attributes on the lat and lon dimension variables, there's a reproducible (OS X and linux) freeing of an unallocated pointer.  With those attributes in the grid file, I still get "grdview: Warning: x_inc does not divide 180; g boundary condition ignored."  I don't understand that warning message, and would like to fix my code.

Andy,

That makes think of the effect of a bug on GMT versions built with GDAL support. Are you using one of such?
But even that would manifest only if you were actually using GDAL through the =gd mechanism, which doesn't
seam to be the case of  -- "${ncfile}?${ncvar}".

Joaquim Luis

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

--
Andy Jacobson
andy.jacobson@...

NOAA Earth System Research Lab
Global Monitoring Division
325 Broadway
Boulder, Colorado 80305

303/497-4916

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

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

[Andy Jacobson-4]

On Fri 30 Oct , at 16:42 , J Luis wrote:

> First part is very is to check. Just run grdreformat and see if last  
> line printed on screen mention the GDAL driver


Done.  GMT was not compiled with GDAL support on any of my platforms.

-Andy

--
Andy Jacobson
andy.jacobson@...

NOAA Earth System Research Lab
Global Monitoring Division
325 Broadway
Boulder, Colorado 80305

303/497-4916

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

[Joaquim Luis]

Andy Jacobson wrote:
> On Fri 30 Oct , at 16:42 , J Luis wrote:
>
>> First part is very is to check. Just run grdreformat and see if last
>> line printed on screen mention the GDAL driver
>
>
> Done.  GMT was not compiled with GDAL support on any of my platforms.

So, can you provide us a (preferably small) example of a netCDF grid and
the grdview command that raises
that free unallocated pointer error?

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

[Andy Jacobson-4]

On Fri 30 Oct , at 17:00 , Joaquim Luis wrote:
>
> So, can you provide us a (preferably small) example of a netCDF grid  
> and the grdview command that raises
> that free unallocated pointer error?


Yes.  Files are at ftp://ftp.cmdl.noaa.gov/pub/andy/for_gmt.  Two  
(small) netCDF files, a color palette file, and the output EPS files I  
generate are available for download.  The EPS files are large and  
probably you don't need to download them.

This is a 2x2 factorial experiment.

Condition A:  with or without "actual_range" attributes
Condition B:  Hammer or Lambert Conformal Conic projection

The freed pointer is combination A1B1 shown at the bottom of this  
message.  Mysterious warning message happens in A0B0.  No grid lines  
are produced in A0B0 or A1B0 (both Hammer).

Thanks,

Andy


[A0B0] ** With actual_range, projection Hammer **
Command:  grdview -Lg -T -K 'CT2009-range.nc?co2land' -Ya0.9i -Xa0.05i  
-R-180/180/-75/75 -JH0/5.5i -Bg0/g0 -Cflux.cpt > hammer-range.eps
Result:  warning message "grdview: Warning: x_inc does not divide 180;  
g boundary condition ignored.", produces map, but without desired  
gridlines


[A1B0] ** Without actual_range, projection Hammer **
Command:  grdview -Lg -T -K 'CT2009-norange.nc?co2land' -Ya0.9i -
Xa0.05i -R-180/180/-75/75 -JH0/5.5i -Bg0/g0 -Cflux.cpt > hammer-
norange.eps
Result:  no warning message, map produced, no desired grid lines

[A0B1] ** With actual_range, projection Lambert CC **
Command:  grdview -Lg -T -K 'CT2009-range.nc?co2land' -Ya0.9i -Xa0.05i  
-R-170/-50/10/75 -JL-90/24.5/51.5/45/6i -Bg0/g0 -Cflux.cpt > lambert-
range.eps
Result: map produced, grid lines present

[A1B1] ** Without actual_range, projection Lambert CC **
Command:  grdview -Lg -T -K 'CT2009-norange.nc?co2land' -Ya0.9i -
Xa0.05i -R-170/-50/10/75 -JL-90/24.5/51.5/45/6i -Bg0/g0 -Cflux.cpt >  
lambert-norange.eps
Result:  unallocated pointer messages (below), map produced with grid  
lines on OSX; empty EPS file on Linux.

OS X:
grdview(76823) malloc: *** error for object 0x17011e: Non-aligned  
pointer being freed
*** set a breakpoint in malloc_error_break to debug
grdview(76823) malloc: *** error for object 0xa7000: pointer being  
freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Linux:
*** glibc detected *** grdview: munmap_chunk(): invalid pointer:  
0xffa6e6f8 ***
======= Backtrace: =========
/lib/libc.so.6(cfree+0x1bb)[0x58cceb]
grdview[0x80b4671]
grdview(GMT_wesn_clip+0xa80)[0x808c540]
grdview[0x8088548]
grdview[0x80e0731]
grdview[0x8052505]
/lib/libc.so.6(__libc_start_main+0xdc)[0x535e8c]
grdview[0x804df71]
======= Memory map: ========
00502000-0051c000 r-xp 00000000 08:03  
4190269                            /lib/ld-2.5.so
0051c000-0051d000 r--p 00019000 08:03  
4190269                            /lib/ld-2.5.so
0051d000-0051e000 rw-p 0001a000 08:03  
4190269                            /lib/ld-2.5.so
00520000-0065e000 r-xp 00000000 08:03  
4190221                            /lib/libc-2.5.so
0065e000-00660000 r--p 0013e000 08:03  
4190221                            /lib/libc-2.5.so
00660000-00661000 rw-p 00140000 08:03  
4190221                            /lib/libc-2.5.so
00661000-00664000 rw-p 00661000 00:00 0
006d1000-006f6000 r-xp 00000000 08:03  
4190277                            /lib/libm-2.5.so
006f6000-006f7000 r--p 00024000 08:03  
4190277                            /lib/libm-2.5.so
006f7000-006f8000 rw-p 00025000 08:03  
4190277                            /lib/libm-2.5.so
08048000-0813e000 r-xp 00000000 00:19  
1319559494                         /nfs/ccg/sw/gmt/bin/grdview
0813e000-08162000 rw-p 000f5000 00:19  
1319559494                         /nfs/ccg/sw/gmt/bin/grdview
08162000-081ac000 rw-p 08162000 00:00 0
09889000-09907000 rw-p 09889000 00:00  
0                                  [heap]
f7f42000-f7f77000 r--s 00000000 08:03  
8185101                            /var/db/nscd/passwd
f7f77000-f7f78000 rw-p f7f77000 00:00 0
f7f80000-f7f8b000 r-xp 00000000 08:03  
4190348                            /lib/libgcc_s-4.1.2-20080825.so.1
f7f8b000-f7f8c000 rw-p 0000a000 08:03  
4190348                            /lib/libgcc_s-4.1.2-20080825.so.1
f7f8c000-f7f8e000 rw-p f7f8c000 00:00 0
ffa60000-ffa75000 rw-p 7ffffffea000 00:00  
0                              [stack]
ffffe000-fffff000 r-xp ffffe000 00:00 0
Abort


--
Andy Jacobson
andy.jacobson@...

NOAA Earth System Research Lab
Global Monitoring Division
325 Broadway
Boulder, Colorado 80305

303/497-4916

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

[Paul Wessel-2]

Andy-

I am sure Remko, our netCDF guru, will have a look when he can.  I  
suspect your files are only partly conforming to the COARDS convention  
but something we expect to be in there is not.  Pls check if you are  
following it to the letter.

-p

On Oct 30, 2009, at 2:30 PM, Andy Jacobson wrote:

> On Fri 30 Oct , at 17:00 , Joaquim Luis wrote:
>>
>> So, can you provide us a (preferably small) example of a netCDF  
>> grid and the grdview command that raises
>> that free unallocated pointer error?
>
>
> Yes.  Files are at ftp://ftp.cmdl.noaa.gov/pub/andy/for_gmt.  Two  
> (small) netCDF files, a color palette file, and the output EPS files  
> I generate are available for download.  The EPS files are large and  
> probably you don't need to download them.
>
> This is a 2x2 factorial experiment.
>
> Condition A:  with or without "actual_range" attributes
> Condition B:  Hammer or Lambert Conformal Conic projection
>
> The freed pointer is combination A1B1 shown at the bottom of this  
> message.  Mysterious warning message happens in A0B0.  No grid lines  
> are produced in A0B0 or A1B0 (both Hammer).
>
> Thanks,
>
> Andy
>
>
> [A0B0] ** With actual_range, projection Hammer **
> Command:  grdview -Lg -T -K 'CT2009-range.nc?co2land' -Ya0.9i -
> Xa0.05i -R-180/180/-75/75 -JH0/5.5i -Bg0/g0 -Cflux.cpt > hammer-
> range.eps
> Result:  warning message "grdview: Warning: x_inc does not divide  
> 180; g boundary condition ignored.", produces map, but without  
> desired gridlines
>
>
> [A1B0] ** Without actual_range, projection Hammer **
> Command:  grdview -Lg -T -K 'CT2009-norange.nc?co2land' -Ya0.9i -
> Xa0.05i -R-180/180/-75/75 -JH0/5.5i -Bg0/g0 -Cflux.cpt > hammer-
> norange.eps
> Result:  no warning message, map produced, no desired grid lines
>
> [A0B1] ** With actual_range, projection Lambert CC **
> Command:  grdview -Lg -T -K 'CT2009-range.nc?co2land' -Ya0.9i -
> Xa0.05i -R-170/-50/10/75 -JL-90/24.5/51.5/45/6i -Bg0/g0 -Cflux.cpt >  
> lambert-range.eps
> Result: map produced, grid lines present
>
> [A1B1] ** Without actual_range, projection Lambert CC **
> Command:  grdview -Lg -T -K 'CT2009-norange.nc?co2land' -Ya0.9i -
> Xa0.05i -R-170/-50/10/75 -JL-90/24.5/51.5/45/6i -Bg0/g0 -Cflux.cpt >  
> lambert-norange.eps
> Result:  unallocated pointer messages (below), map produced with  
> grid lines on OSX; empty EPS file on Linux.
>
> OS X:
> grdview(76823) malloc: *** error for object 0x17011e: Non-aligned  
> pointer being freed
> *** set a breakpoint in malloc_error_break to debug
> grdview(76823) malloc: *** error for object 0xa7000: pointer being  
> freed was not allocated
> *** set a breakpoint in malloc_error_break to debug
>
> Linux:
> *** glibc detected *** grdview: munmap_chunk(): invalid pointer:  
> 0xffa6e6f8 ***
> ======= Backtrace: =========
> /lib/libc.so.6(cfree+0x1bb)[0x58cceb]
> grdview[0x80b4671]
> grdview(GMT_wesn_clip+0xa80)[0x808c540]
> grdview[0x8088548]
> grdview[0x80e0731]
> grdview[0x8052505]
> /lib/libc.so.6(__libc_start_main+0xdc)[0x535e8c]
> grdview[0x804df71]
> ======= Memory map: ========
> 00502000-0051c000 r-xp 00000000 08:03  
> 4190269                            /lib/ld-2.5.so
> 0051c000-0051d000 r--p 00019000 08:03  
> 4190269                            /lib/ld-2.5.so
> 0051d000-0051e000 rw-p 0001a000 08:03  
> 4190269                            /lib/ld-2.5.so
> 00520000-0065e000 r-xp 00000000 08:03  
> 4190221                            /lib/libc-2.5.so
> 0065e000-00660000 r--p 0013e000 08:03  
> 4190221                            /lib/libc-2.5.so
> 00660000-00661000 rw-p 00140000 08:03  
> 4190221                            /lib/libc-2.5.so
> 00661000-00664000 rw-p 00661000 00:00 0
> 006d1000-006f6000 r-xp 00000000 08:03  
> 4190277                            /lib/libm-2.5.so
> 006f6000-006f7000 r--p 00024000 08:03  
> 4190277                            /lib/libm-2.5.so
> 006f7000-006f8000 rw-p 00025000 08:03  
> 4190277                            /lib/libm-2.5.so
> 08048000-0813e000 r-xp 00000000 00:19  
> 1319559494                         /nfs/ccg/sw/gmt/bin/grdview
> 0813e000-08162000 rw-p 000f5000 00:19  
> 1319559494                         /nfs/ccg/sw/gmt/bin/grdview
> 08162000-081ac000 rw-p 08162000 00:00 0
> 09889000-09907000 rw-p 09889000 00:00  
> 0                                  [heap]
> f7f42000-f7f77000 r--s 00000000 08:03  
> 8185101                            /var/db/nscd/passwd
> f7f77000-f7f78000 rw-p f7f77000 00:00 0
> f7f80000-f7f8b000 r-xp 00000000 08:03  
> 4190348                            /lib/libgcc_s-4.1.2-20080825.so.1
> f7f8b000-f7f8c000 rw-p 0000a000 08:03  
> 4190348                            /lib/libgcc_s-4.1.2-20080825.so.1
> f7f8c000-f7f8e000 rw-p f7f8c000 00:00 0
> ffa60000-ffa75000 rw-p 7ffffffea000 00:00  
> 0                              [stack]
> ffffe000-fffff000 r-xp ffffe000 00:00 0
> Abort
>
>
> --
> Andy Jacobson
> andy.jacobson@...
>
> NOAA Earth System Research Lab
> Global Monitoring Division
> 325 Broadway
> Boulder, Colorado 80305
>
> 303/497-4916
>
> To unsubscribe, send the message "signoff gmt-help" to listserv@...

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

[Remko Scharroo]

Hi Andy,

Your grid is definitely COARDS compliant, and it should plot. There  
have been bugs in the past figuring out if a grid was truly global,  
but I think in 4.5.1 that is done correctly.
However, grdview is old an basically obsolete. Stay away from it. Try  
grdimage instead. It works for me with your example.

Remko

On 30 Oct 2009, at 20:30, Andy Jacobson wrote:

> On Fri 30 Oct , at 17:00 , Joaquim Luis wrote:
>>
>> So, can you provide us a (preferably small) example of a netCDF  
>> grid and the grdview command that raises
>> that free unallocated pointer error?
>
>
> Yes.  Files are at ftp://ftp.cmdl.noaa.gov/pub/andy/for_gmt.  Two  
> (small) netCDF files, a color palette file, and the output EPS files  
> I generate are available for download.  The EPS files are large and  
> probably you don't need to download them.
>
> This is a 2x2 factorial experiment.
>
> Condition A:  with or without "actual_range" attributes
> Condition B:  Hammer or Lambert Conformal Conic projection
>
> The freed pointer is combination A1B1 shown at the bottom of this  
> message.  Mysterious warning message happens in A0B0.  No grid lines  
> are produced in A0B0 or A1B0 (both Hammer).
>
> Thanks,
>
> Andy
>
>
> [A0B0] ** With actual_range, projection Hammer **
> Command:  grdview -Lg -T -K 'CT2009-range.nc?co2land' -Ya0.9i -
> Xa0.05i -R-180/180/-75/75 -JH0/5.5i -Bg0/g0 -Cflux.cpt > hammer-
> range.eps
> Result:  warning message "grdview: Warning: x_inc does not divide  
> 180; g boundary condition ignored.", produces map, but without  
> desired gridlines
>
>
> [A1B0] ** Without actual_range, projection Hammer **
> Command:  grdview -Lg -T -K 'CT2009-norange.nc?co2land' -Ya0.9i -
> Xa0.05i -R-180/180/-75/75 -JH0/5.5i -Bg0/g0 -Cflux.cpt > hammer-
> norange.eps
> Result:  no warning message, map produced, no desired grid lines
>
> [A0B1] ** With actual_range, projection Lambert CC **
> Command:  grdview -Lg -T -K 'CT2009-range.nc?co2land' -Ya0.9i -
> Xa0.05i -R-170/-50/10/75 -JL-90/24.5/51.5/45/6i -Bg0/g0 -Cflux.cpt >  
> lambert-range.eps
> Result: map produced, grid lines present
>
> [A1B1] ** Without actual_range, projection Lambert CC **
> Command:  grdview -Lg -T -K 'CT2009-norange.nc?co2land' -Ya0.9i -
> Xa0.05i -R-170/-50/10/75 -JL-90/24.5/51.5/45/6i -Bg0/g0 -Cflux.cpt >  
> lambert-norange.eps
> Result:  unallocated pointer messages (below), map produced with  
> grid lines on OSX; empty EPS file on Linux.
>
> OS X:
> grdview(76823) malloc: *** error for object 0x17011e: Non-aligned  
> pointer being freed
> *** set a breakpoint in malloc_error_break to debug
> grdview(76823) malloc: *** error for object 0xa7000: pointer being  
> freed was not allocated
> *** set a breakpoint in malloc_error_break to debug
>
> Linux:
> *** glibc detected *** grdview: munmap_chunk(): invalid pointer:  
> 0xffa6e6f8 ***
> ======= Backtrace: =========
> /lib/libc.so.6(cfree+0x1bb)[0x58cceb]
> grdview[0x80b4671]
> grdview(GMT_wesn_clip+0xa80)[0x808c540]
> grdview[0x8088548]
> grdview[0x80e0731]
> grdview[0x8052505]
> /lib/libc.so.6(__libc_start_main+0xdc)[0x535e8c]
> grdview[0x804df71]
> ======= Memory map: ========
> 00502000-0051c000 r-xp 00000000 08:03  
> 4190269                            /lib/ld-2.5.so
> 0051c000-0051d000 r--p 00019000 08:03  
> 4190269                            /lib/ld-2.5.so
> 0051d000-0051e000 rw-p 0001a000 08:03  
> 4190269                            /lib/ld-2.5.so
> 00520000-0065e000 r-xp 00000000 08:03  
> 4190221                            /lib/libc-2.5.so
> 0065e000-00660000 r--p 0013e000 08:03  
> 4190221                            /lib/libc-2.5.so
> 00660000-00661000 rw-p 00140000 08:03  
> 4190221                            /lib/libc-2.5.so
> 00661000-00664000 rw-p 00661000 00:00 0
> 006d1000-006f6000 r-xp 00000000 08:03  
> 4190277                            /lib/libm-2.5.so
> 006f6000-006f7000 r--p 00024000 08:03  
> 4190277                            /lib/libm-2.5.so
> 006f7000-006f8000 rw-p 00025000 08:03  
> 4190277                            /lib/libm-2.5.so
> 08048000-0813e000 r-xp 00000000 00:19  
> 1319559494                         /nfs/ccg/sw/gmt/bin/grdview
> 0813e000-08162000 rw-p 000f5000 00:19  
> 1319559494                         /nfs/ccg/sw/gmt/bin/grdview
> 08162000-081ac000 rw-p 08162000 00:00 0
> 09889000-09907000 rw-p 09889000 00:00  
> 0                                  [heap]
> f7f42000-f7f77000 r--s 00000000 08:03  
> 8185101                            /var/db/nscd/passwd
> f7f77000-f7f78000 rw-p f7f77000 00:00 0
> f7f80000-f7f8b000 r-xp 00000000 08:03  
> 4190348                            /lib/libgcc_s-4.1.2-20080825.so.1
> f7f8b000-f7f8c000 rw-p 0000a000 08:03  
> 4190348                            /lib/libgcc_s-4.1.2-20080825.so.1
> f7f8c000-f7f8e000 rw-p f7f8c000 00:00 0
> ffa60000-ffa75000 rw-p 7ffffffea000 00:00  
> 0                              [stack]
> ffffe000-fffff000 r-xp ffffe000 00:00 0
> Abort
>
>
> --
> Andy Jacobson
> andy.jacobson@...
>
> NOAA Earth System Research Lab
> Global Monitoring Division
> 325 Broadway
> Boulder, Colorado 80305
>
> 303/497-4916
>
> To unsubscribe, send the message "signoff gmt-help" to listserv@...

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

[Andy Jacobson-4]

On Sat 31 Oct , at 06:58 , Remko Scharroo wrote:
>
> Your grid is definitely COARDS compliant, and it should plot. There  
> have been bugs in the past figuring out if a grid was truly global,  
> but I think in 4.5.1 that is done correctly.
> However, grdview is old an basically obsolete. Stay away from it.  
> Try grdimage instead. It works for me with your example.


Thanks for looking at those netCDF files, Remko.

I like grdview because I can easily paint the actual shape of the 1x1  
degree grid boxes in our model product, projection and all.  Yes, I  
can use grdimage, but as far as I can tell, there's no practical way  
to convey the information about the limited resolution of the source  
data.  See attached samples.  Is there an alternative to grdview that  
can produce projected polygons?

Thanks,

Andy


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




--
Andy Jacobson
andy.jacobson@...

NOAA Earth System Research Lab
Global Monitoring Division
325 Broadway
Boulder, Colorado 80305

303/497-4916




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

[Remko Scharroo]

Hi again Alan,

Actually, I just checked that in grdview, it works file as well. I  
don't get the errors you get when using GMT 4.5.1.
So with GMT 4.5.1 you should be all set to go, which you apparently  
have used, looking at the plots you attached.

I do appreciate you want to keep being able to see the 1x1 degree  
tiles. Indeed grdview will give you that with the -T option.
You may have noticed that this kind of plotting is fairly inefficient  
as it prints out the PostScript code for each tile individually. With  
curved edges to each tile, this adds up. Depending on which way you  
convert the result to PNG, you might even see thin lines between those  
tiles (we, of course, recommend you use ps2raster that comes with GMT,  
which doesn't do that).

But you rightly asked for an alternative, and there is: grdimage. You  
are right that grdimage by default makes cells of similar size as your  
original grid, but lined up on a horizontal/vertical grid. But you can  
"fake" your original cells by oversampling the grid (-E option to set  
the number of dots per inch: I'd say 600), and preventing grdimage  
from interpolating, but taking the nearest neighbour number instead (-
Sn option). Additionally you can leave the NaN values transparent (-Q  
option). Then you basically have what grdview -T does, with a bonus:
grdview -T result for your Lambert example: 1 MB
grdimage -E600 -Sn -Q: 330 kB
You'd think that with all the pixels a 600 DPI image is producing, the  
grdimage result would be huge, but it isn't because of the built-in  
colour LZW compression that is applied. And when only using a few  
colours with much of it the same for long runs, this compresses quite  
well. If you limit the number of colour intervals (you have 400  
currently) to a lower number, say 40 (makecpt -D -T-200/200/10) you go  
even down to 218 kB with grdimage. And I don't think you will notice  
the difference!

Success trying this!

Remko

On 31 Oct 2009, at 13:41, Andy Jacobson wrote:

>
> On Sat 31 Oct , at 06:58 , Remko Scharroo wrote:
>>
>> Your grid is definitely COARDS compliant, and it should plot. There  
>> have been bugs in the past figuring out if a grid was truly global,  
>> but I think in 4.5.1 that is done correctly.
>> However, grdview is old an basically obsolete. Stay away from it.  
>> Try grdimage instead. It works for me with your example.
>
>
> Thanks for looking at those netCDF files, Remko.
>
> I like grdview because I can easily paint the actual shape of the  
> 1x1 degree grid boxes in our model product, projection and all.  
> Yes, I can use grdimage, but as far as I can tell, there's no  
> practical way to convey the information about the limited resolution  
> of the source data.  See attached samples.  Is there an alternative  
> to grdview that can produce projected polygons?
>
> Thanks,
>
> Andy
>
>
> To unsubscribe, send the message "signoff gmt-help" to listserv@...
> <grdview.png><grdimage.png>
> --
> Andy Jacobson
> andy.jacobson@...
>
> NOAA Earth System Research Lab
> Global Monitoring Division
> 325 Broadway
> Boulder, Colorado 80305
>
> 303/497-4916
>
>
>
>
> To unsubscribe, send the message "signoff gmt-help" to listserv@...

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

[Remko Scharroo]

Sorry Andy, not Alan.
Remko

On 31 Oct 2009, at 14:20, Remko Scharroo wrote:

> Hi again Alan,

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

[Andy Jacobson-4]

Remko,

Thanks very much for the pointer.  This is great advice about  
oversampling in grdimage.  I would never have guessed that the  
postscript output would be smaller doing it this way.

Best Regards,

Andy

--
Andy Jacobson
andy.jacobson@...

NOAA Earth System Research Lab
Global Monitoring Division
325 Broadway
Boulder, Colorado 80305

303/497-4916

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