[GRASS-user] trouble with r.in.gdal to georeference a NetCDF file
Lee Eddington
lee.w.eddington at gmail.com
Mon Nov 11 21:55:47 PST 2013
Anna,
I tried your suggestion, but now I'm unable to import the data. Here's
some output showing the region and the error messages:
GRASS 6.4.3 (bali_d03_ll):~ > g.proj -p
-PROJ_INFO-------------------------------------------------
name : Lat/Lon
proj : ll
datum : wgs84
ellps : wgs84
no_defs : defined
towgs84 : 0.000,0.000,0.000
-PROJ_UNITS------------------------------------------------
unit : degree
units : degrees
meters : 1.0
GRASS 6.4.3 (bali_d03_ll):~ > g.region -p
projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 6:19:40.44S
south: 10:27:59.04S
west: 112:19:46.2E
east: 117:43:20.64E
nsres: 0:01:36.12
ewres: 0:01:37.56
rows: 155
cols: 199
cells: 30845
GRASS 6.4.3 (bali_d03_ll):~ > r.in.gdal -o
input="NETCDF:grassdata/bali/geo_em.d03.nc:HGT_M" output="d03_HGT_M"
Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
WARNING: Over-riding projection check
WARNING: G_set_window(): Illegal latitude for North
On Mon, Nov 11, 2013 at 9:21 PM, Anna Petrášová <kratochanna at gmail.com>wrote:
> Hi,
>
> On Mon, Nov 11, 2013 at 11:37 PM, Lee Eddington <lee.w.eddington at gmail.com
> > wrote:
>
>> I'm trying to import a NetCDF file from the WRF weather forecast model
>> with r.in.gdal, but I can't get it to georeference. Instead I end up with
>> a x,y coordinate system of rows and columns. The file georeferences fine
>> in a number of other weather graphics programs. I tried to follow the
>> directions at:
>>
>> http://www.gdal.org/frmt_netcdf.html
>>
>> but when I run gdalinfo I get the following:
>>
>> $ gdalinfo geo_em.d03.nc
>>
>> Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
>>
>> Driver: netCDF/Network Common Data Format
>>
>> Files: geo_em.d03.nc
>>
>> Size is 512, 512
>>
>> Coordinate System is `'
>>
>> Metadata:
>>
>> NC_GLOBAL#BOTTOM-TOP_GRID_DIMENSION=0
>>
>> NC_GLOBAL#CEN_LAT=-8.4095154
>>
>> NC_GLOBAL#CEN_LON=115.02
>>
>> NC_GLOBAL#corner_lats={ -10.454437, -6.3537445, -6.3537445, -10.454437,
>> -10.454437, -6.3537445, -6.3537445, -10.454437, -10.46785, -6.3401871,
>> -6.3401871, -10.46785, -10.46785, -6.3401871, -6.3401871, -10.46785 }
>>
>> NC_GLOBAL#corner_lons={ 112.3332, 112.3332, 117.70679, 117.70679,
>> 112.31956, 112.31956, 117.72044, 117.72044, 112.3332, 112.3332, 117.70679,
>> 117.70679, 112.31956, 112.31956, 117.72044, 117.72044 }
>>
>> NC_GLOBAL#DX=3000
>>
>> NC_GLOBAL#DY=3000
>>
>> NC_GLOBAL#DYN_OPT=2
>>
>> NC_GLOBAL#FLAG_MF_XY=1
>>
>> NC_GLOBAL#grid_id=3
>>
>> NC_GLOBAL#GRIDTYPE=C
>>
>> NC_GLOBAL#i_parent_end=99
>>
>> NC_GLOBAL#i_parent_start=34
>>
>> NC_GLOBAL#ISICE=24
>>
>> NC_GLOBAL#ISLAKE=-1
>>
>> NC_GLOBAL#ISOILWATER=14
>>
>> NC_GLOBAL#ISURBAN=1
>>
>> NC_GLOBAL#ISWATER=16
>>
>> NC_GLOBAL#j_parent_end=84
>>
>> NC_GLOBAL#j_parent_start=34
>>
>> NC_GLOBAL#MAP_PROJ=3
>>
>> NC_GLOBAL#MMINLU=USGS
>>
>> NC_GLOBAL#MOAD_CEN_LAT=-8.4095078
>>
>> NC_GLOBAL#NUM_LAND_CAT=24
>>
>> NC_GLOBAL#parent_grid_ratio=3
>>
>> NC_GLOBAL#parent_id=2
>>
>> NC_GLOBAL#POLE_LAT=90
>>
>> NC_GLOBAL#POLE_LON=0
>>
>> NC_GLOBAL#SIMULATION_START_DATE=0000-00-00_00:00:00
>>
>> NC_GLOBAL#SOUTH-NORTH_GRID_DIMENSION=154
>>
>> NC_GLOBAL#SOUTH-NORTH_PATCH_END_STAG=154
>>
>> NC_GLOBAL#SOUTH-NORTH_PATCH_END_UNSTAG=153
>>
>> NC_GLOBAL#SOUTH-NORTH_PATCH_START_STAG=1
>>
>> NC_GLOBAL#SOUTH-NORTH_PATCH_START_UNSTAG=1
>>
>> NC_GLOBAL#sr_x=1
>>
>> NC_GLOBAL#sr_y=1
>>
>> NC_GLOBAL#STAND_LON=115.02
>>
>> NC_GLOBAL#TITLE=OUTPUT FROM GEOGRID V3.4
>>
>> NC_GLOBAL#TRUELAT1=-8.4095001
>>
>> NC_GLOBAL#TRUELAT2=0
>>
>> NC_GLOBAL#WEST-EAST_GRID_DIMENSION=199
>>
>> NC_GLOBAL#WEST-EAST_PATCH_END_STAG=199
>>
>> NC_GLOBAL#WEST-EAST_PATCH_END_UNSTAG=198
>>
>> NC_GLOBAL#WEST-EAST_PATCH_START_STAG=1
>>
>> NC_GLOBAL#WEST-EAST_PATCH_START_UNSTAG=1
>>
>> Subdatasets:
>>
>> SUBDATASET_1_NAME=NETCDF:"geo_em.d03.nc":Times
>>
>> SUBDATASET_1_DESC=[1x19] Times (8-bit character)
>>
>> SUBDATASET_2_NAME=NETCDF:"geo_em.d03.nc":XLAT_M
>>
>> SUBDATASET_2_DESC=[1x153x198] XLAT_M (32-bit floating-point)
>>
>> SUBDATASET_3_NAME=NETCDF:"geo_em.d03.nc":XLONG_M
>>
>> SUBDATASET_3_DESC=[1x153x198] XLONG_M (32-bit floating-point)
>>
>> SUBDATASET_4_NAME=NETCDF:"geo_em.d03.nc":XLAT_V
>> .
>> .
>> .
>> .
>>
>> Corner Coordinates:
>>
>> Upper Left ( 0.0, 0.0)
>>
>> Lower Left ( 0.0, 512.0)
>>
>> Upper Right ( 512.0, 0.0)
>>
>> Lower Right ( 512.0, 512.0)
>>
>> Center ( 256.0, 256.0)
>>
>> The warning -
>>
>> Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
>>
>> leads me to believe that all the projection info is not being recognized,
>> but I'm not sure why. Is it possible that GDAL wasn't compiled with libnetcdf?
>> But if that's the case I would think that gdalinfo wouldn't work at all.
>>
>> I've imported the data into GRASS using:
>>
>> r.in.gdal input="NETCDF:geo_em.d03.nc:HGT_M" output="d03_HGT_M"
>> location="bali_d03"
>>
>> to create a new location.
>>
>> I also created a location with the Mercator projection of the data and
>> tried importing using:
>>
>> r.in.gdal -o input="NETCDF:grassdata/bali/geo_em.d03.nc:HGT_M"
>> output="d03_HGT_M"
>>
>> but as far as I can tell still get an x,y row,column coordinate system.
>>
>> I also have the lat and lon of each cell. Is there anyway to
>> georeference using that data?
>>
>>
>
> try to create a WGS84 latitude-longitude projection (EPSG 4326) and then
> run r.in.gdal with -o flag. At least that worked for me and I had similar
> gdalinfo output.
>
> Anna
>
>
>
>> Thanks,
>> Lee
>>
>> _______________________________________________
>> grass-user mailing list
>> grass-user at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20131111/8979c5a1/attachment.html>
More information about the grass-user
mailing list