-
Notifications
You must be signed in to change notification settings - Fork 346
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
Conversation
While the longitudes where correctly inferred to be pixel registered, distaster struck for latitudes...
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.
|
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. |
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. |
Yes, it has an even number of nodes but that doesn't necessarily make it more pixelated
For this data, why a pixel reg -R[0 360] makes more sense then a grid reg of -R[0.25 359.75]?
|
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. |
OK, I buy the global argument but the gmt_nc code is not basing its choice on a test for global regions. |
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. |
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. |
…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.
`ci` directory was removed in GenericMappingTools#188. Remove `ci` in `setup.py` and `.codeclimate.yml`.
While the longitudes where correctly inferred to be pixel registered, disaster struck for latitudes...
Should be a bit more foolproof now.