<div dir="ltr"><div><div>Hi Vero<br><br>On Wed, May 3, 2017 at 1:57 PM, Veronica Andreo <<a href="mailto:veroandreo@gmail.com">veroandreo@gmail.com</a>> wrote:<br>><br>> In the end, I found that the only way to get chelsa maps with the same resolution and extent than the MODIS 1km maps, was to import the whole chelsa map and subset with r.mapcalc since it uses the region settings.<br><br></div>Maybe you assumed that r.in.gdal -r is also doing resampling. The -r flag only cuts the input to cover the current region. For resampling you can use one of the r.resamp.* modules.<br><br></div>Markus M<br><div><div><div><br>><br>> thanks again, <br>> Vero<br>><br>><br>><br>><br>> 2017-05-03 8:15 GMT+02:00 Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>>:<br>>><br>>><br>>><br>>> On Tue, May 2, 2017 at 10:16 PM, Veronica Andreo <<a href="mailto:veroandreo@gmail.com">veroandreo@gmail.com</a>> wrote:<br>>> ><br>>> > Hi Helli,<br>>> ><br>>> > Yes, if you want the global map the -a flag plus the relaxed conditions for the extent of global maps are fine...<br>>> ><br>>> > However, I wanted to also only import the region i'm working on and make use of the -r flag in r.in.gdal... then the problems start... no combination of -a, raster or align parameters in r.region give me the correct region (either the resolution is wrong or the extent). My solution so far is import the global map with r.in.gdal -a, then use r.mapcalc to get the region I need... any other suggestion about better workflow is more than welcome :)<br>>><br>>> Be aware that the -r flag of r.in.gdal aligns the current region to the grid geometry of the input raster, i.e. the output might not match exactly the current region. For CHELSA that means that not only the input resolution is preserved, but also the 0.5 seconds shift to the West and South.<br>>><br>>> Can you provide an example why you think that the grid geometry of the imported raster is not correct?<br>>><br>>> Markus M<br>>><br>>> ><br>>> > best,<br>>> > Vero<br>>> ><br>>> > 2017-05-02 21:45 GMT+02:00 Helmut Kudrnovsky <<a href="mailto:hellik@web.de">hellik@web.de</a>>:<br>>> >><br>>> >> Veronica Andreo wrote<br>>> >> > Hi :)<br>>> >> ><br>>> >> > JFYI, CHELSA v1.2 is out<br>>> >> ><br>>> >> > 2017-02-07 15:43 GMT+01:00 Markus Neteler &lt;<br>>> >><br>>> >> > neteler@<br>>> >><br>>> >> > &gt;:<br>>> >> ><br>>> >> >> On Tue, Feb 7, 2017 at 3:32 PM, Markus Metz<br>>> >> >> &lt;<br>>> >><br>>> >> > markus.metz.giswork@<br>>> >><br>>> >> > &gt; wrote:<br>>> >> >> [...]<br>>> >> >> > Compared to GMTED, CHELSA extents further south to 90:0:0.5S which<br>>> >> >> conforms<br>>> >> >> > to the GMTED grid geometry. For CHELSA, however gdalinfo reports<br>>> >> >> > Pixel Size = (0.008333333300000,-0.008333333300000)<br>>> >> >> > while for GMTED, gdalinfo reports<br>>> >> >> > Pixel Size = (0.008333333333333,-0.008333333333333)<br>>> >> >> ><br>>> >> >> > The reason for the slightly smaller pixel size is most probably reduced<br>>> >> >> > floating point precision during creation of the CHELSA data.<br>>> >> >><br>>> >> >> from personal comm.:<br>>> >> >> They are currently investigating where the precision is cut in their<br>>> >> >> workflow (the upcoming V1.2 shall come with a related correction).<br>>> >> >><br>>> >> ><br>>> >> > Unfortunately they have not corrected the precision issue...<br>>> >> ><br>>> >> > gdalinfo CHELSA_temp_2_1979-2013_V1.2_land.tif<br>>> >> > Driver: GTiff/GeoTIFF<br>>> >> > Files: CHELSA_temp_2_1979-2013_V1.2_land.tif<br>>> >> > Size is 43200, 20880<br>>> >> > [...]<br>>> >> > Origin = (-180.000138888850017,83.999860415150010)<br>>> >> > Pixel Size = (0.008333333300000,-0.008333333300000)<br>>> >> ><br>>> >> > Corner Coordinates:<br>>> >> > Upper Left  (-180.0001389,  83.9998604) (180d 0' 0.50"W, 83d59'59.50"N)<br>>> >> > Lower Left  (-180.0001389, -90.0001389) (180d 0' 0.50"W, 90d 0' 0.50"S)<br>>> >> > Upper Right ( 179.9998597,  83.9998604) (179d59'59.49"E, 83d59'59.50"N)<br>>> >> > Lower Right ( 179.9998597, -90.0001389) (179d59'59.49"E, 90d 0' 0.50"S)<br>>> >> > Center      (  -0.0001396,  -3.0001392) (  0d 0' 0.50"W,  3d 0' 0.50"S)<br>>> >> > Band 1 Block=43200x1 Type=Float32, ColorInterp=Gray<br>>> >> >   NoData Value=-99999<br>>> >> ><br>>> >> > best,<br>>> >> > Vero<br>>> >><br>>> >> yes, AFAIK they're still working on it.<br>>> >><br>>> >> tested here ver.1.2 with r.in.gdal trunk and<br>>> >><br>>> >> -a<br>>> >>     Auto-adjustment for lat/lon<br>>> >>     Attempt to fix small precision errors in resolution and extents<br>>> >><br>>> >> it seems to give good results.<br>>> >><br>>> >><br>>> >><br>>> >><br>>> >> -----<br>>> >> best regards<br>>> >> Helmut<br>>> >> --<br>>> >> View this message in context: <a href="http://osgeo-org.1560.x6.nabble.com/CHELSA-climate-data-set-tp5284115p5319124.html">http://osgeo-org.1560.x6.nabble.com/CHELSA-climate-data-set-tp5284115p5319124.html</a><br>>> >> Sent from the Grass - Users mailing list archive at Nabble.com.<br>>> >> _______________________________________________<br>>> >> grass-user mailing list<br>>> >> <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>>> >> <a href="https://lists.osgeo.org/mailman/listinfo/grass-user">https://lists.osgeo.org/mailman/listinfo/grass-user</a><br>>> ><br>>> ><br>>> ><br>>> > _______________________________________________<br>>> > grass-user mailing list<br>>> > <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>>> > <a href="https://lists.osgeo.org/mailman/listinfo/grass-user">https://lists.osgeo.org/mailman/listinfo/grass-user</a><br>>><br>><br></div></div></div></div>