Bug #595

grdpaste incorrectly reports empty grdi

Added by Joseph about 3 years ago. Updated almost 3 years ago.

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

100%

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

Description

Summary: when pasting two grids together, if the first one is empty, then grdpaste will complain that the second is also empty. But the second is not empty.

The real problem is that it appears that paste result is intermittent; sometimes the results are valid , other times I get output grids that are incorrectly empty...

Since I'm an "gluing" the word together for SRTM15, this is a show stopper. One could write a lot of spaghetti code to avoid empty tiles, and some how expand the intermediate results to include the empty boundary, but since I can't be sure if the result is correct ...

-jj

Here is a case where the output is correct even if the messages are not. The random checker board I get for the global result shows that in other cases, the paste outputs an empty grid when there was input...

daintree:srtm15 jbecker$ grdpaste unmaskedGrd/w150n45.grd unmaskedGrd/w135n45.grd -Gcrap.grd

grdpaste: Warning: No valid values in grid [unmaskedGrd/w150n45.grd]
grdpaste: Warning: No valid values in grid [unmaskedGrd/w135n45.grd]

daintree:srtm15 jbecker$ grdinfo crap.grd

crap.grd: Title: /Volumes/RAID/doNotBackup/srtm15//unmaskedGrd/w150n45.grd
crap.grd: Command: grdpaste unmaskedGrd/w150n45.grd unmaskedGrd/w135n45.grd -Gcrap.grd
crap.grd: Remark:
crap.grd: Gridline node registration used [Cartesian grid]
crap.grd: Grid file format: nf = GMT netCDF format (32-bit float), COARDS, CF-1.5
crap.grd: x_min: -150 x_max: -120 x_inc: 0.00416666666667 name: x nx: 7201
crap.grd: y_min: 30 y_max: 45 y_inc: 0.00416666666667 name: y ny: 3601
crap.grd: z_min: -9.25 z_max: 4255.5 name: z
crap.grd: scale_factor: 1 add_offset: 0
crap.grd: format: netCDF-4 chunk_size: 129,129 shuffle: on deflation_level: 3

daintree:srtm15 jbecker$ grdinfo unmaskedGrd/w150n45.grd unmaskedGrd/w135n45.grd

unmaskedGrd/w150n45.grd: Title: /Volumes/RAID/doNotBackup/srtm15//unmaskedGrd/w150n45.grd
unmaskedGrd/w150n45.grd: Command: xyz2grd -bi3 -R/-150/-135/30/45 -I15c -G/Volumes/RAID/doNotBackup/srtm15//unmaskedGrd/w150n45.grd
unmaskedGrd/w150n45.grd: Remark:
unmaskedGrd/w150n45.grd: Gridline node registration used [Cartesian grid]
unmaskedGrd/w150n45.grd: Grid file format: nf = GMT netCDF format (32-bit float), COARDS, CF-1.5
unmaskedGrd/w150n45.grd: x_min: -150 x_max: -135 x_inc: 0.00416666666667 name: x nx: 3601
unmaskedGrd/w150n45.grd: y_min: 30 y_max: 45 y_inc: 0.00416666666667 name: y ny: 3601
unmaskedGrd/w150n45.grd: z_min: NaN z_max: NaN name: z
unmaskedGrd/w150n45.grd: scale_factor: 1 add_offset: 0
unmaskedGrd/w150n45.grd: format: netCDF-4 chunk_size: 129,129 shuffle: on deflation_level: 3

unmaskedGrd/w135n45.grd: Title: /Volumes/RAID/doNotBackup/srtm15//unmaskedGrd/w135n45.grd
unmaskedGrd/w135n45.grd: Command: xyz2grd -bi3 -R/-135/-120/30/45 -I15c -G/Volumes/RAID/doNotBackup/srtm15//unmaskedGrd/w135n45.grd
unmaskedGrd/w135n45.grd: Remark:
unmaskedGrd/w135n45.grd: Gridline node registration used [Cartesian grid]
unmaskedGrd/w135n45.grd: Grid file format: nf = GMT netCDF format (32-bit float), COARDS, CF-1.5
unmaskedGrd/w135n45.grd: x_min: -135 x_max: -120 x_inc: 0.00416666666667 name: x nx: 3601
unmaskedGrd/w135n45.grd: y_min: 30 y_max: 45 y_inc: 0.00416666666667 name: y ny: 3601
unmaskedGrd/w135n45.grd: z_min: -9.25 z_max: 4255.5 name: z
unmaskedGrd/w135n45.grd: scale_factor: 1 add_offset: 0
unmaskedGrd/w135n45.grd: format: netCDF-4 chunk_size: 129,129 shuffle: on deflation_level: 3

History

#1 Updated by Joseph about 3 years ago

So I fiddled with this some more. Turning off compression appears to make the intermittent empty output file problem go away.

compression_level=`gmt get IO_NC4_DEFLATION_LEVEL`
gmtset IO_NC4_DEFLATION_LEVEL = 0

It doesn't solve the spurious empty input grid problem. And my initial debugging was that if the first file was empty the second would get called; that's not true. The second file is the result of a xyz2grd, and some get flagged by grdpaste, some do not.

grdinfo can read all of them... Not sure you want a 1.3 GB debug file or two...

#2 Updated by Joseph about 3 years ago

Make that

And my initial debugging was that if the first file was empty the second would get flagged; that's not true.

#3 Updated by Paul about 3 years ago

  • Status changed from New to Feedback

Can you please revisit this report to see if it still gives incorrect messages after updating to r13421 ?

#4 Updated by Joseph almost 3 years ago

fixed

#5 Updated by Paul almost 3 years ago

  • Status changed from Feedback to Closed
  • Assignee set to Paul
  • Target version set to Candidate for next bugfix release
  • % Done changed from 0 to 100

Great, closing this issue as fixed.

Also available in: Atom PDF