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

[Brian Oney]

Yes, everything works great. Thanks again.

Ok, good to know. Yeah, the algorithm could be improved I guess. But, 
the improvement that I would suggest is supposed to be the -l flag, 
right? Just force it to be 180W and 180E... I thought (the -l flag) it 
is just a recent addition to GRASS 6.4, so maybe it needs a some t.l.c...

Thanks again.

Cheers,
Brian

On 10/31/2011 08:59 PM, Markus Metz wrote:
> 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