[gdal-dev] define netcdf time dimension

[Dominik Schneider]

Hi Mike - Thanks for the response and sorry this wasn’t quite clear. IDL
data cubes are of the ENVI format and thus also have an associated ascii
.hdr file. A dataset with 10 bands is here:
https://dl.dropboxusercontent.com/u/5962491/IDLENVIswe.zip
There is no time data in the .mdl file, but I know that the 4416 bands are
hourly timesteps from 0:00 March 1 to 23:00 Aug 31

I could do this in R but was trying to avoid it because R is always so
frustratingly slow for these things…the gdal commandline utilities are much
more awesome!

iMac:~/Downloads $ gdalinfo swe.mdl
Driver: ENVI/ENVI .hdr Labelled
Files: swe.mdl
       swe.hdr
Size is 352, 190
Coordinate System is:
PROJCS["UTM_Zone_13N",
    GEOGCS["GCS_North_American_1983",
        DATUM["North_American_Datum_1983",
            SPHEROID["GRS_1980",6378137.0,298.257222101]],
        PRIMEM["Greenwich",0.0],
        UNIT["Degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["False_Easting",500000.0],
    PARAMETER["False_Northing",0.0],
    PARAMETER["Central_Meridian",-105.0],
    PARAMETER["Scale_Factor",0.9996],
    PARAMETER["Latitude_Of_Origin",0.0],
    UNIT["Meter",1]]
Origin = (444345.080000000016298,4436145.280000000260770)
Pixel Size = (30.000000000000000,-30.000000000000000)
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  444345.080, 4436145.280) (105d39' 9.74"W, 40d 4'25.45"N)
Lower Left  (  444345.080, 4430445.280) (105d39' 7.97"W, 40d 1'20.58"N)
Upper Right (  454905.080, 4436145.280) (105d31'43.92"W, 40d 4'27.72"N)
Lower Right (  454905.080, 4430445.280) (105d31'42.49"W, 40d 1'22.85"N)
Center      (  449625.080, 4433295.280) (105d35'26.03"W, 40d 2'54.21"N)
Band 1 Block=352x1 Type=Float32, ColorInterp=Undefined
Band 2 Block=352x1 Type=Float32, ColorInterp=Undefined
Band 3 Block=352x1 Type=Float32, ColorInterp=Undefined
Band 4 Block=352x1 Type=Float32, ColorInterp=Undefined
Band 5 Block=352x1 Type=Float32, ColorInterp=Undefined
Band 6 Block=352x1 Type=Float32, ColorInterp=Undefined
Band 7 Block=352x1 Type=Float32, ColorInterp=Undefined
Band 8 Block=352x1 Type=Float32, ColorInterp=Undefined
Band 9 Block=352x1 Type=Float32, ColorInterp=Undefined
Band 10 Block=352x1 Type=Float32, ColorInterp=Undefined
...
Band 4416 Block=352x1 Type=Float32, ColorInterp=Undefined

​

Dominik Schneider
o 303.735.6296 | c 518.956.3978


On Tue, Apr 14, 2015 at 12:07 AM, Michael Sumner <mdsumner at gmail.com> wrote:

>
>
> On Tue, 14 Apr 2015 at 05:46 Dominik Schneider <
> Dominik.Schneider at colorado.edu> wrote:
>
>> Hi -
>>
>> I have some .mdl files from IDL with .hdr header files that I’d like to
>> convert to netcdf.
>> The following code produces a netcdf file with a subdataset for each band
>> in the mdl file. Is there any way to define the bands as the time
>> dimension, in this case 4416 hourly timesteps?
>>
>> Or is there another tool that can convert this?
>>
>> gdal_translate -of NetCDF swe.mdl swe.nc
>>
>>
> Can you list the metadata printed out by gdalinfo swe.mdl?  What driver is
> used?
>
> Does that source file have time-metadata inside it each subdataset or do
> you need to assign it?
>
> Generally, the subdatasets are not considered as a time series - they are
> more like multiple variables for the same observation (whereas a 3rd and
> higher dimension/s are often unrolled into a multi-attributed 2D layer and
> the time/z step is stored on each band -  it's a bit of a mix/clash of
> worlds).
>
> Can you point to and example file somewhere?  I imagine you'll need a
> programmed solution, but it should be pretty easy with R or python or
> similar.  If R is of interest you can try this and take your question to
> the R community:
>
> library(raster)
> r <- stack("swe.mdl")
> r <- setZ(r, [whatever the vector of dates should be])  ## pseudocode
> writeRaster(r, "swe.nc")
>
> That all assumes quite a lot, including available NetCDF versions and
> packages, required structure in the output, interpretation of the data read
> in,  - so it's just included as an indication how it might be done.
>
> Cheers, Mike.
>
>
>> Thanks
>> Dominik​
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150414/dc30b6d7/attachment-0001.html>