Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Address topic http:https://gmt.soest.hawaii.edu/boards/1/topics/7807 #188

Merged
merged 1 commit into from
Nov 26, 2018

Conversation

PaulWessel
Copy link
Member

While the longitudes where correctly inferred to be pixel registered, disaster struck for latitudes...
Should be a bit more foolproof now.

While the longitudes where correctly inferred to be pixel registered, distaster struck for latitudes...
@PaulWessel PaulWessel requested review from joa-quim and a team November 26, 2018 00:32
@joa-quim joa-quim merged commit 1f0a0da into master Nov 26, 2018
@joa-quim joa-quim deleted the ncgridfix branch November 26, 2018 01:17
@joa-quim joa-quim restored the ncgridfix branch November 26, 2018 01:23
@joa-quim
Copy link
Member

I closed this too soon. It's not wrong but not totally right either. It's transforming the grid into a pixel registered one but the original data is grid registered. Doing it via GDAL gives what I think is the correct result.

C:\v>grdconvert result_ice_repository.grd?Solid_earth_deformation[0] -Glixo.grd

C:\v>grdconvert result_ice_repository.grd=gd+b0 -Glixo2.grd
Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute

C:\v>grdinfo lixo.grd
lixo.grd: Title: Produced by grdconvert
lixo.grd: Command: grdconvert result_ice_repository.grd?Solid_earth_deformation[0] -Glixo.grd
        (old cmd)
lixo.grd: Remark:
lixo.grd: Pixel node registration used [Cartesian grid]
lixo.grd: Grid file format: nf = GMT netCDF format (32-bit float), CF-1.7
lixo.grd: x_min: 0 x_max: 360 x_inc: 0.5 name: lon n_columns: 720
lixo.grd: y_min: -90 y_max: 90 y_inc: 0.5 name: lat n_rows: 360
lixo.grd: z_min: -0.000851899792906 z_max: 0.00316517567262 name: Solid_earth_deformation [m]
lixo.grd: scale_factor: 1 add_offset: 0
lixo.grd: format: netCDF-4 chunk_size: 144,180 shuffle: on deflation_level: 3

C:\v>grdinfo lixo2.grd
lixo2.grd: Title: Produced by grdconvert
lixo2.grd: Command: grdconvert result_ice_repository.grd=gd+b0 -Glixo2.grd
lixo2.grd: Remark:
lixo2.grd: Gridline node registration used [Cartesian grid]
lixo2.grd: Grid file format: nf = GMT netCDF format (32-bit float), CF-1.7
lixo2.grd: x_min: 0.25 x_max: 359.75 x_inc: 0.5 name:  n_columns: 720
lixo2.grd: y_min: -89.75 y_max: 89.75 y_inc: 0.5 name:  n_rows: 360
lixo2.grd: z_min: -0.000851899792906 z_max: 0.00316517567262 name: z
lixo2.grd: scale_factor: 1 add_offset: 0
lixo2.grd: format: netCDF-4 chunk_size: 144,180 shuffle: on deflation_level: 3

C:\v>

@joa-quim
Copy link
Member

The problem is that we rely on the existence of "node_offset" or "node_offset" or "valid_range" or "valid_min"/"valid_max" to guess if data is grid or pixel but if none exists, we assume data is pixel reg.

@PaulWessel
Copy link
Member Author

Given the original grid actually says the x-values are 0.25, .75, ..., 359.75 it is admitting it is pixel registered, which matches the even number of nodes. Even more so that min = -89.25 so I think only pixel registration makes sense.

@joa-quim
Copy link
Member

Yes, it has an even number of nodes but that doesn't necessarily make it more pixelated

length(0.25:0.5:359.75)
720

For this data, why a pixel reg -R[0 360] makes more sense then a grid reg of -R[0.25 359.75]?

C:\v>ncdump -h result_ice_repository.grd
netcdf result_ice_repository {
dimensions:
        lon = 720 ;
        lat = 360 ;
        time = 113 ;

@PaulWessel
Copy link
Member Author

Since we know it is a global grid it should be 360 by 180 degrees. I would say 0/360/-90/90 as pixel reg make much more sense than 0.25/359.75/-89.75/89.75 as gridline reg. Same file.

@joa-quim
Copy link
Member

joa-quim commented Nov 26, 2018

OK, I buy the global argument but the gmt_nc code is not basing its choice on a test for global regions.

@PaulWessel
Copy link
Member Author

No, it is basing it on xmin/dx giving a remainder of 0.5 *dx which is normally a good test to guess pixel registration. It cannot know for sure of course, so a grid form 0.25 to 9.75 with dx 0.5 could be 0/10 pixel or 0.25/9.75 gridline. Hard to know what the user meant without more info in the header, but it is still a reasonable guess. However, when the adjusted min/max gives a 360 range then I think we can be very sure. I don't think we would treat these two cases differently but we certainly would be more confident in the latter case and could print a long-verbose message to that effect.

@PaulWessel
Copy link
Member Author

Note that the original grid fails to use COARDS convention for longitude attribute: It has "degrees east" instead of "degrees_east". So it is also seen as a Cartesian grid.
Of course, it should not stop GMT from perhaps still figuring this out that it is geographic.

@seisman seisman deleted the ncgridfix branch December 20, 2018 21:29
obaney pushed a commit to obaney/gmt that referenced this pull request Aug 18, 2021
…ls#188)

Use a callback function passed to `GMT_Create_Session` to log error
messages instead of redirecting them to a file using
`GMT_Handle_Messages`. It's a lot cleaner and the code is more legible.
Other functions don't need to do anything to have their errors logged,
it's automatic.
The logged messaged are also printed to stderr so they will show up in
the Jupyter notebook.
This is useful when using the verbose mode (`V="d"`) in modules.

Switch to the Fatiando a Terra CI scripts and enable OSX testing on 
Travis.
Fatiando provides scripts for handling all of the CI tasks we need: 
https://github.com/fatiando/continuous-integration 
Use them instead of rewriting everything.

Fixes GenericMappingTools#164 
The Segmentation fault on OSX was happening because of the log file
that we used to capture the GMT output and include in the exception.
I have no idea why this happens.
But removing that fixes the issue so I'm happy not knowing.
obaney pushed a commit to obaney/gmt that referenced this pull request Aug 18, 2021
`ci` directory was removed in GenericMappingTools#188. Remove `ci` in `setup.py` 
and `.codeclimate.yml`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants