Re: GMT 5 default format

Mikhail Tchernychev <[email protected]>
Newsgroups gmane.comp.gis.gmt.user
Message-ID <[email protected]>
Hi,

Sorry I missed all the discussion because of my time zone :(

I did some investigation yesterday and I found that  some of the GMT 5 
NC files
are in NetCDF format, and some of them are not.  This is very easy to 
see at the beginning of the file:
the first bytes says "CDF" or  0x89"HDF".

MagPick was just checking for "CDF" and rejecting the rest.

However from point of view of the NetCDF library these GMT 5  HDF files 
behave exactly as CDF, for instance
one could use "ncdump" program on them.

The examples are "BigIsland.nc" (CDF) and "tsu_chile60.nc" (HDF) files 
from grdcontour example.
You can use "ncdump" easily on both of files.

This comes from the fact that modern NetCDF is build on top of HDF( see 
for instance
http://www.unidata.ucar.edu/software/netcdf/docs/netCDF-CMake.html)

Under Linux, after I removed "CDF" string check from magpick, it was 
able to open HDF file
"tsu_chile60.nc" perfectly without any additional changes in the code. 
The reason was
because Linux magpick is compiled with stock netCDF 4 which is turn has 
HDF and everything else
enabled.

This did not work however on Windows because I was using static and some 
what old netCDF
with no further dependencies.

So I went online and got latest HDF 5 and CDF  4 and compiled them with 
CMake and VC 2010.
But I did not enable SZip in HDF. I also did not enable libcurl in netCDF.

Now under windows it was possible to open tsu_chile60.nc file but all 
values are reported as 0.
The header values were reported correctly.

Looking further I found that file "tsu_chile60.nc" uses compression.

At this point I just tried to remove compression with "h5repack" This 
created
valid HDF file with no compression, but neither GMT nor ncgump was able 
to read it.
But I could see it with HDFView.

I will follow with re-compilation of HDF with SZip and other features.

It would be nice I think to make difference between HDF and CDF clearly 
visible,
for instance with file extension, or reported by grdinfo.

Regarding the compression, sole netCDF library supports it on its own.

I hope you find this information useful,

Best Regards
Mikhail






















On 2/6/2014 6:31 AM, Lester Anderson wrote:
> Thanks for the information
> Cheers
> Lester
>
> > Date: Thu, 6 Feb 2014 11:52:21 +0000
> > From: [email protected]
> > Subject: Re: [GMT-HELP] GMT 5 default format
> > To: [email protected]
> >
> > Hi Remko and all
> >
> > That is all correct but I want also warn you guys about this GDAL
> > bug/limitation
> >
> > http://trac.osgeo.org/gdal/ticket/5291
> >
> > that will pop up (hidden) for instance to QGIS users
> >
> > Joaquim
> >
> > > Dear Lester,
> > >
> > > One option is to use
> > > gmt set IO_NC4_CHUNK_SIZE classic
> > >
> > > But I also want to urge you to either update the tools you use, or 
> if no update is available to urge the makers of those tools to finally 
> update to link against the netCDF 4 library.
> > >
> > > NetCDF 4 was introduced already some FIVE years ago and is now at 
> version 4.3.1.1. To hold off on the very useful functionalities of the 
> netCDF 4 library (particularly internal compression) would be like 
> trying to move the clock many years back.
> > >
> > > Remko
> > >
> > > On 6 Feb 2014, at 08:04, Lester 
> Anderson<[email protected]> wrote:
> > >
> > >> Hello,
> > >>
> > >> I have spotted a slight difference in the default grid formats 
> from v4 to v5 and this appears to give some issues loading into other 
> applications:
> > >>
> > >> VERSION 5
> > >> black1_emag2b_RTP.grd: Title: Anomaly reducted to the pole
> > >> black1_emag2b_RTP.grd: Command: grdredpol black1_emag2a.grd 
> -Gblack1_emag2b.grd -T2013 -W1 -F45/45 -V
> > >> black1_emag2b_RTP.grd: Remark:
> > >> black1_emag2b_RTP.grd: Gridline node registration used 
> [Geographic grid]
> > >> black1_emag2b_RTP.grd: Grid file format: nf = GMT netCDF format 
> (32-bit float),COARDS, CF-1.5
> > >> black1_emag2b_RTP.grd: x_min: 20 x_max: 50 x_inc: 0.0333333333333 
> name: longitude [degrees_east] nx: 901
> > >> black1_emag2b_RTP.grd: y_min: 35 y_max: 50 y_inc: 0.0333333333333 
> name: latitude [degrees_north] ny: 451
> > >> black1_emag2b_RTP.grd: z_min: -1385.10412598 z_max: 3309.81860352 
> name: nT
> > >> black1_emag2b_RTP.grd: scale_factor: 1 add_offset: 0
> > >> black1_emag2b_RTP.grd: format: netCDF-4 chunk_size: 129,151 
> shuffle: on deflation_level: 3<------
> > >>
> > >> VERSION 4
> > >> black1_emag2b_RTP_v2.grd: Title: Grid computed inside Mirone
> > >> black1_emag2b_RTP_v2.grd: Command:
> > >> black1_emag2b_RTP_v2.grd: Remark: File written from Matlab
> > >> black1_emag2b_RTP_v2.grd: Gridline node registration used 
> [Geographic grid]
> > >> black1_emag2b_RTP_v2.grd: Grid file format: nf = GMT netCDF 
> format (32-bit float), COARDS, CF-1.5
> > >> black1_emag2b_RTP_v2.grd: x_min: 20 x_max: 50 x_inc: 
> 0.0333333333333 name: longitude [degrees_east] nx: 901
> > >> black1_emag2b_RTP_v2.grd: y_min: 35 y_max: 50 y_inc: 
> 0.0333333333333 name: latitude [degrees_north] ny: 451
> > >> black1_emag2b_RTP_v2.grd: z_min: -1385.10412598 z_max: 
> 3309.81860352 name: z [unknown]
> > >> black1_emag2b_RTP_v2.grd: scale_factor: 1 add_offset: 0
> > >> black1_emag2b_RTP_v2.grd: format: classic<------
> > >>
> > >> The format reference from the headers are different. With version 
> 4 there are no issues loading GMT (netCDF) grids into other 
> applications like MagPick or QGIS (1.8 to 2.1), but with version 5 
> they are considered an unknown format, yet still the default format (=nf).
> > >>
> > >> From gmtdefaults:
> > >>
> > >> # I/O Parameters
> > >> #
> > >> IO_COL_SEPARATOR = tab
> > >> IO_GRIDFILE_FORMAT = nf
> > >> IO_GRIDFILE_SHORTHAND = false
> > >> IO_HEADER = false
> > >> IO_N_HEADER_RECS = 0
> > >> IO_NAN_RECORDS = pass
> > >> IO_NC4_CHUNK_SIZE = auto
> > >> IO_NC4_DEFLATION_LEVEL = 3
> > >> IO_LONLAT_TOGGLE = false
> > >> IO_SEGMENT_MARKER =>
> > >> #
> > >>
> > >> Should any parameters above be tweaked?
> > >>
> > >> It is not a big issue as it is easy to change to a format that 
> works in other applications, but it is worth noting that the subtle 
> change in the format seems to have a big impact, given that everything 
> else is identical. In terms of formats, what constitutes the "classic" 
> format in the list under grdreformat?
> > >>
> > >> Cheers
> > >> Lester
> > >> To unsubscribe, send the message "signoff gmt-help" to 
> [email protected]
> > > To unsubscribe, send the message "signoff gmt-help" to 
> [email protected]
> > >
> > >
> >
> > To unsubscribe, send the message "signoff gmt-help" to 
> [email protected]
> To unsubscribe, send the message "signoff gmt-help" to 
> [email protected] 




PLEASE NOTE: This message, including any attachments, may include privileged,
confidential and/or inside information. Any dissemination, distribution or copy
of this communication by   anyone other than the intended recipient is strictly
prohibited. If you are not the intended recipient, please notify the sender by
replying to this message and then delete it from your system. Information
provided via electronic media is not guaranteed against defects including
translation and transmission errors. The company accepts no liability for any
damage caused by any virus transmitted by this email.

Geometrics Inc. | 2190 Fortune Drive | San Jose, CA 95131 USA

To unsubscribe, send the message "signoff gmt-help" to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.