Bug #577
gmtinfo doesn't accept binary input or cmtconvert outputs broken binary
| Status: | Closed | Start date: | 2014-06-09 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Paul | % Done: | 100% | |
| Category: | - | |||
| Target version: | Candidate for next bugfix release | |||
| Affected version: | 5.1.1 | Platform: |
Description
This works
grdtrack ridge.txt -Gspac.nc -C3000k/1k/1k -V -sa | gmt gmtconvert -o0,1,4 -T | gmt gmtinfo
<Standard Input>: N = 641428 ←44.3080784824/-11.6484643785> <37.7272855139/48.0782906623> <8.56908138662/13001.9969274>
This does NOT work
grdtrack ridge.txt -Gspac.nc -C3000k/1k/1k -V -sa | gmt gmtconvert -o0,1,4 -T -bo3f | gmt gmtinfo -bi3f
<Standard Input>: N = 1282856 ←3.40019101244e+38/3.40103841152e+38> ←3.40268858836e+38/3.40157366431e+38> ←3.40108303282e+38/3.40068164393e+38>
The number of lines read in the second case is 2x expected so it seems like gmtconvert might be giving double out when single is requested. I tested that...
jbecker$ grd2xyz spac.nc -bo3s | gmt gmtinfo -bi3f
grd2xyz: Warning: -b option with type s, S, or D are deprecated; Use <n>f or <n>d, with w to indicate swab
<Standard Input>: N = 80601 ←50/-10> <30/50> <5/17997>
grd2xyz spac.nc -bo3d | gmt gmtinfo -bi3f
<Standard Input>: N = 161202 ←107374184/2.72008302208e+23> ←3.140625/0> ←107374184/2.72008302208e+23>
so grd2xyz gives the expected results with correct and bogus -bi3<f|d> so I think gmtconvert is stuck in double for bo
Associated revisions
Fix issue #577
History
#1
Updated by Joseph about 3 years ago
duh!
Here is the obvious test
Works
grdtrack ridge.txt -Gspac.nc -C3000k/1k/1k -V -sa | gmt gmtconvert -o0,1,4 -T -bo3d | gmt gmtinfo -bi3d
<Standard Input>: N = 641428 ←44.3080784824/-11.6484643785> <37.7272855139/48.0782906623> <8.56908138662/13001.9969274>
doesn't work
grdtrack ridge.txt -Gspac.nc -C3000k/1k/1k -V -sa | gmt gmtconvert -o0,1,4 -T -bo3f | gmt gmtinfo -bi3f
grdtrack: Processing input grid(s)
grdtrack: Sampled 717239 points from grid spac.nc (401 x 201)
<Standard Input>: N = 1282856 ←3.40019101244e+38/3.40103841152e+38> ←3.40268858836e+38/3.40157366431e+38> ←3.40108303282e+38/3.40068164393e+38>
And since grd2xyz does work with -bo3f, convert has the issue.
#2
Updated by Paul about 3 years ago
- Status changed from New to Resolved
Yes indeed, confusion between -b and -o. Fixed in r13283.
#3
Updated by Paul almost 3 years ago
- Status changed from Resolved to Closed
- Assignee set to Paul
- Target version set to Candidate for next bugfix release
- % Done changed from 0 to 100
Closing this issue.