[GRASS-user] Re: r.in.gdal oddity

[Markus Metz]

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
improvement?

>
> A bit of additional info: when the location lacks a projection, I don't have
> problems.
As expected, it's a latlon issue.

Markus M

>
> Anyways, I appreciate the help.
>
> Cheers,
> Brian
>
>
>
>
> 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
>>>
>>> http://ccafs-climate.org/data/A2a_2020s/hccpr_hadcm3/hccpr_hadcm3_a2a_2020s_prec_2_5min_asc.zip
>>>
>>> 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.
>>
>> HTH,
>>
>> Markus M
>> _______________________________________________
>> grass-user mailing list
>> grass-user at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>