[GRASS-user] Re: r.in.gdal oddity
markus.metz.giswork at googlemail.com
Mon Oct 31 15:59:56 EDT 2011
Brian Oney wrote:
> Hi Markus M,
> Thanks, it works. Cooking with gas now.
So the import with the corrected raster is ok, i.e. is of global (-180
to 180 E, -60 to 90 N) extent?
> It is still odd though. It is not just an imprecision I am afraid. When I
> said "skinny", I was being modest.
> If you look a bit closer, it is not a minor error in import. The map (and
> the rest as well) is w=-180 e=-179.999... and north and south are normal. It
> should have a global extent.
The skinny appearance (just a tiny slice of data) happens because the
input data exceed 360 degree in E-W extent by a tiny fraction. This is
automatically adjusted such that the input data do not exceed 360
degree in E-W direction. Maybe this automated adjustment needs some
> A bit of additional info: when the location lacks a projection, I don't have
As expected, it's a latlon issue.
> Anyways, I appreciate the help.
> On 10/31/2011 09:15 AM, Markus Metz wrote:
>> Helmut Kudrnovsky wrote:
>>>> I am importing worldclim .asc files from the ipcc4 simulations
>>>> (http://ccafs-climate.org/). These are latlong files with a global
>>>> extent. I have compiled grass 6.4.2svn from source on ubuntu 11.10 and
>>>> hope that I did everything correctly, according to the wiki.
>>>> When importing, here is what I do and what happens:
>>>> r.in.gdal -o input="/D/Documents/Spatial_Datasets/Climate/WorldClim/\
>>>> hccpr_hadcm3_a2a_2020s_prec_2_5min_asc/prec_10.asc" output="prec_10"
>>> tested here with
>>> gdalinfo hccpr_hadcm3_a2a_2020s_prec_2_5min.asc
>>> Driver: AAIGrid/Arc/Info ASCII Grid
>>> Files: prec_10.asc
>>> Size is 8640, 3600
>>> Coordinate System is `'
>>> Origin = (-180.000000000000000,90.000000000119996)
>>> Pixel Size = (0.041666666666700,-0.041666666666700)
>>> Corner Coordinates:
>>> Upper Left (-180.0000000, 90.0000000)
>>> Lower Left (-180.0000000, -60.0000000)
>>> Upper Right ( 180.0000000, 90.0000000)
>>> Lower Right ( 180.0000000, -60.0000000)
>>> Center ( 0.0000000, 15.0000000)
>>> Band 1 Block=8640x1 Type=Int32, ColorInterp=Undefined
>>> NoData Value=-9999
>> There is a tiny precision loss:
>> Origin = (-180.000000000000000,90.000000000119996)
>> Pixel Size = (0.041666666666700,-0.041666666666700)
>> should be
>> Origin = (-180.000000000000000,90.000000000000000)
>> Pixel Size = (0.041666666666667,-0.041666666666667)
>> pixel size is now as close as possible to 2.5 min.
>> This is neither a gdal nor a grass bug, but a bug of the software used
>> to produce these data.
>> This can easily be fixed with e.g.
>> gdal_translate -a_ullr -180 90 180 -60 prec_1.asc prec_1.tif
>> then import the corrected tif.
>> Markus M
>> grass-user mailing list
>> grass-user at lists.osgeo.org
More information about the grass-user