Bug #707
grdpaste in GMT4 can not deal with pixel registration grid
| Status: | Closed | Start date: | 2015-05-19 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Paul | % Done: | 100% | |
| Category: | - | |||
| Target version: | Candidate for next bugfix release | |||
| Affected version: | 4.5.x | Platform: |
Description
I am trying to paste two grid datas from ASTER GDEM:
$ grdinfo ASTGTM2_N30E116_dem.nc ASTGTM2_N30E116_dem.nc: Title: ASTGTM2_N30E116_dem.nc: Command: ASTGTM2_N30E116_dem.nc: Remark: ASTGTM2_N30E116_dem.nc: Pixel node registration used ASTGTM2_N30E116_dem.nc: Grid file format: cs (# 8) GMT netCDF format (short) (deprecated) ASTGTM2_N30E116_dem.nc: x_min: 115.999861111 x_max: 117.000138889 x_inc: 0.000277777777778 name: meters nx: 3601 ASTGTM2_N30E116_dem.nc: y_min: 29.9998611111 y_max: 31.0001388889 y_inc: 0.000277777777778 name: meters ny: 3601 ASTGTM2_N30E116_dem.nc: z_min: -112 z_max: 1731 name: meters ASTGTM2_N30E116_dem.nc: scale_factor: 1 add_offset: 0
$ grdinfo ASTGTM2_N30E117_dem.nc ASTGTM2_N30E117_dem.nc: Title: ASTGTM2_N30E117_dem.nc: Command: ASTGTM2_N30E117_dem.nc: Remark: ASTGTM2_N30E117_dem.nc: Pixel node registration used ASTGTM2_N30E117_dem.nc: Grid file format: cs (# 8) GMT netCDF format (short) (deprecated) ASTGTM2_N30E117_dem.nc: x_min: 116.999861111 x_max: 118.000138889 x_inc: 0.000277777777778 name: meters nx: 3601 ASTGTM2_N30E117_dem.nc: y_min: 29.9998611111 y_max: 31.0001388889 y_inc: 0.000277777777778 name: meters ny: 3601 ASTGTM2_N30E117_dem.nc: z_min: -210 z_max: 1701 name: meters ASTGTM2_N30E117_dem.nc: scale_factor: 1 add_offset: 0
The data are piexl registration, so the xmax of GridA and xmin of GridB do not have the same value.
grdpaste report that the two data do not share a common edge.
$ grdpaste ASTGTM2_N30E116_dem.nc ASTGTM2_N30E117_dem.nc -Gout.nc grdpaste: Grids do not share a common edge!
BTW, grdpaster in GMT5 does not have this problem.
History
#1
Updated by Paul over 2 years ago
- Status changed from New to Feedback
Think I remember those grids. They are obviously gridline-registered grids foolishly encoded as pixel grids with 0.5 arc second extended boundaries. Very lame. Instead of going -R116/117/30/31 -I1s with gridline-registration they must believe having lots of decimals is the way to go. Sigh... I a sure Joaquim will remember this case.
#2
Updated by Joaquim over 2 years ago
I mostly remember the painful debugging sessions to deal with those crazy limits in grids like this and those geotiffs from CGIAR.
And given that it works in GMT5 I certainly do not want to repeat the experience and from my side this is a "Closed as a: Wont fix" issue.
#3
Updated by Dongdong over 2 years ago
If I am a GMT4-only user, do I have to use grd2xyz to convert the grid data to xyz file, then use xyz2grd to convert it back to grid data with gridline-registration?
#4
Updated by Joaquim over 2 years ago
No. Better to use grdedit -T and if necessary a second run of grdedit -R to set the correct limits.
#5
Updated by Paul almost 2 years ago
- Status changed from Feedback to Closed
- Assignee set to Paul
- % Done changed from 0 to 100
The final solution to this issue is to use GMT5. GMT4 will not be fixed for this issue - it is too time-consuming for us to maintain beyond simple fixes.