[gdal-dev] [mbsystem] [GMT4] Messy little problem between GMT4, GDAL 1.9.2 and ArcGIS 10
John Helly
hellyj at ucsd.edu
Mon May 6 11:57:49 PDT 2013
Hi Kurt.
Thanks for the reply.
You are correct that mbgrid outputs a GMT netCDF file. I was running
gdal_translate to overcome a weirdness that may no longer exist but
previously caused the output to be reflected when displayed in GIS
tools. This was due to a difference between GDAL utilities and the GMT
tools in indexing the data (as I recall).
Geotiffs are a nice alternative. I was just used to using netCDF.
Joaquim Luis explained the problem as due to gdal using an old GMT3
format (below)
>>
John,
No wonder the headers are different. The gdal_translate -of GMT converts
the grid into the old-old-old GMT3 version netCDF that was not CF
compliant. And if you want to do that, no need to call gdal_translate,
all you need is to append '=cf' to grid's name of mbgrid command (I'm
assuming that mbgrid delegates all grid writing work to GMT).
In summary, I don't see any problem here as it's very unlikely that Arc
will be able to read that old-old-old netCDF variant (unless it lets
GDAL do all the work)
Joaquim
>>
J.
On 5/5/13 5:39 PM, Kurt Schwehr wrote:
> Hi John,
>
> - It's Sunday so the brain isn't really engaged, but doesn't mbgrid
> output a gmt grd file? (your dump shows that) Why are you running
> gdal_translate when your issue was with qgis/gdal and your destination
> is ArcGIS?
>
> - gdal 1.10.0 is just out. Before trying anything else, you might try
> upgrading to that.
>
> - Why not write a geotif from gdal? You get the option of LZW
> compression then and a lot more tools can read geotif than can read
> gmt netcdf grids... it's also a much more tested path through gdal.
> Since I never seem to remember how to do compress and I always seem
> monstrous amounts of files... for the record, to LZW compress a
> geotif, add this:
> -co "COMPRESS=LZW"
>
> - are you seeing the same things from gdalinfo on the output as the
> input? (e.g. is gdal being self consistent)
>
> - you never mentioned what options you were passing to gdal_translate.
> One of your options could be the issue.
>
> -kurt
>
> On May 5, 2013, at 2:04 PM, John Helly <hellyj at ucsd.edu
> <mailto:hellyj at ucsd.edu>> wrote:
>
>> Hi.
>>
>> A few years ago I had a problem with GMT/GDAL interactions such that
>> the GMT netCDF files were reflected when read into Qgis (for
>> example). This was worked around by running it through
>> 'gdal_translate -of GMT'. There was also a discussion about this
>> being a bug in something in GDAL (since Qgis was using GDAL if I
>> remember correctly) that was supposed to have been fixed in some
>> version (obviously don't remember the details). At any rate, it
>> stopped being a problem for me but now something else is causing a
>> problem in files that have the following workflow:
>>
>> --> mbgrid (from MB-System) --> gdal_translate -of GMT --> ArcGIS
>> netCDF reader
>>
>> Now I find that gdal_translate appears to be changing the header in a
>> way such that ArcGIS cannot read the netCDF. The first 'ncdump -h'
>> below is what the header looks like before running through
>> gdal_translate and the second one is after gdal_translate.
>>
>> I'm sending this note to MB-System, GMT and GDAL groups since it
>> seems like an issue of import to all three. Any thoughts on this?
>>
>> J.
>>
>> =======================================Output from mbgrid before
>> gdal_translate ==================================================
>> ncdump -h MCBCP_BeachModel_UTM11N_Baseline.grdclip.nc
>> netcdf MCBCP_BeachModel_UTM11N_Baseline.grdclip {
>> dimensions:
>> x = 12626 ;
>> y = 12251 ;
>> variables:
>> double x(x) ;
>> x:long_name = "Easting (meters)" ;
>> x:actual_range = 444057.827834802, 469309.046567392 ;
>> double y(y) ;
>> y:long_name = "Northing (meters)" ;
>> y:actual_range = 3670183.00468016, 3694684.53612513 ;
>> float z(y, x) ;
>> z:long_name = "Topography (m)" ;
>> z:_FillValue = NaNf ;
>> z:actual_range = -1995.541015625, 599.818359375 ;
>>
>> // global attributes:
>> :Conventions = "COARDS/CF-1.0" ;
>> :title = "Topography Grid" ;
>> :history = "grdclip -V
>> /media/EXT4_Projects_01/SLR_Data/level1/MCBCP/Basemap/MCBCP_BeachModel_UTM11N_Baseline.grd
>> -G/media/EXT4_Projects_01/SLR_Data/level1/MCBCP/Basemap/MCBCP_BeachModel_UTM11N_Baseline.grdclip.nc
>> -Sa600/NaN -Sb-2000/NaN" ;
>> :description = "\n",
>> "\tProjection: UTM11N\n",
>> "\tGrid created by mbgrid\n",
>> "\tMB-system Version 5.3.1982\n",
>> "\tRun by <hellyj> on <StonestepsLinux> at <Thu Apr 25
>> 19:44:41 2013>" ;
>> :GMT_version = "4.5.9_r9909 [64-bit]" ;
>> }
>> =====================================Output from mbgrid after
>> gdal_translate ====================================================
>> ncdump -h MCBCP_BeachModel_UTM11N_Baseline.grdclip.flipped.nc
>> netcdf MCBCP_BeachModel_UTM11N_Baseline.grdclip.flipped {
>> dimensions:
>> side = 2 ;
>> xysize = 154681126 ;
>> variables:
>> double x_range(side) ;
>> x_range:units = "meters" ;
>> double y_range(side) ;
>> y_range:units = "meters" ;
>> double z_range(side) ;
>> z_range:units = "meters" ;
>> double spacing(side) ;
>> int dimension(side) ;
>> float z(xysize) ;
>> z:scale_factor = 1. ;
>> z:add_offset = 0. ;
>> z:node_offset = 1 ;
>>
>> // global attributes:
>> :title = "" ;
>> :source = "" ;
>> }
>>
>> --
>> John Helly, University of California, San Diego / San Diego Supercomputer Center / Scripps Institution of Oceanography / 760 840 8660 mobile / stonesteps (Skype) / stonesteps7 (iChat) /http://www.sdsc.edu/~hellyj
>
--
John Helly, University of California, San Diego / San Diego Supercomputer Center / Scripps Institution of Oceanography / 760 840 8660 mobile / stonesteps (Skype) / stonesteps7 (iChat) / http://www.sdsc.edu/~hellyj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20130506/097399a7/attachment.html>
More information about the gdal-dev
mailing list