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
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
