On Tue, Feb 7, 2017 at 11:14 AM, Markus Neteler <neteler@osgeo.org> wrote:
On Tue, Sep 6, 2016 at 10:22 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
On Tue, Sep 6, 2016 at 8:12 PM, Helmut Kudrnovsky <hellik@web.de> wrote:
According to gdalinfo, the pixel sizes are
Pixel Size = (0.008333333300000,-0.008333333300000)
should be
Pixel Size = (0.008333333333333,-0.008333333333333)
i.e. fp precision is too low which explains why west is not exactly on
-180 but -180.0001389, just as south is not exactly -90 but
-90.0001389.
There are 43207 columns, but with 30 seconds there should be 43200
columns meaning that there are 7 excess columns to the east.
Considering that the 7 westernmost columns and the 7 easternmost
columns overlap, their values should be identical.
There are 21599 rows, but with 30 seconds covering -90, 90 there
should be 21600 rows. The northernmost row is missing and north should
be 89:59:30. The data would need to be prepared with gdal_translate,
cutting off the 7 excess columns to the east and fixing the extents,
before they can be imported into GRASS.
I had a conversation with the data provider.
according to them, the climate rasters are based upon GMTED2010 [1]
in the description of the GMTED2010 data [2]
30 arc-seconds GMTED2010 data:
Resolution (decimal degrees) 0.0083333333
gdalinfo says 0.008333333333333 which is exactly (within double
precision floating point accuracy) 30 arc seconds, while 0.0083333333
is not (documentation is inaccurate, data are accurate).
West extent: minimum X-coordinate (longitude) -180.0001388888
South extent: minimum (for mean): -90.0001388888 (for others:
-56.0001388888)
East extent: maximum X-coordinate (longitude) 179.9998611111
North extent: maximum Y-coordinate (latitude) 83.9998611111
Rows (for mean): 20,880 (for others: 16,800)
Columns: 43,200
it seems the original GMTED2010 data has an intentional half-pixel-shift.
Because GMTED2010 is based on SRTM which also has a half-pixel shift.
GMTED2010 has no excess columns and covers 360 degree in longitude
while SRTM with all tiles patched together has one excess column
because SRTM tiles overlap by one row/column.
The CHELSA extents are different from the GMTED2010 extents. If the
CHELSA climate raster grid geometry is based on GMTED2010, the CHELSA
grid geometry has been modified at some stage. The answer of the data
provider does not explain the grid geometry of the CHELSA raster data.
Helmut and me have contacted one of the CHELSA authors. He eventually
acknowledged that their coordinates are suboptimal and said that the
coordinate issues would originate from the GMTED2010 data set.
There is nothing wrong with the GMTED2010 grid geometry. It is based on SRTM, therefore there is a correct 0.5 arc seconds shift in GMTED2010:
n=83:59:59.50N
s=56:0:0.50S
w=180:0:0.50W
e=179:59:59.50E
What
they wrote on http://chelsa-climate.org/known-issues/ for their V1.0
is not sufficient. The CHELSA author yesterday said that he’ll fix the
coordinates for the next dataset release. Let’s see…
For now I have added a new CHELSA section in the Wiki:
https://grasswiki.osgeo.org/wiki/Global_datasets#CHELSA_climate_maps
You remove the 0.5 arc second shift? I guess it does not matter much for a 30 arc second pixel size.
Compared to GMTED, CHELSA extents further south to 90:0:0.5S which conforms to the GMTED grid geometry. For CHELSA, however gdalinfo reports
Pixel Size = (0.008333333300000,-0.008333333300000)
while for GMTED, gdalinfo reports
Pixel Size = (0.008333333333333,-0.008333333333333)
The reason for the slightly smaller pixel size is most probably reduced floating point precision during creation of the CHELSA data. Unfortunately it changes East from 179.9998611 to 179.9998597 and north from 83.9998611 to 83.9998604.
The more serious problem is that GRASS can not handle ll coordinates like 180:0:0.50W or 90:0:0.5S.
I have relaxed the ll restrictions in my local copy and can now import CHELSA and other for GRASS problematic ll datasets without getting e.g. a narrow N-S strip, or GRASS fixing a subtle rounding error that in fact is not an error. That means after each import I have to manually check if resolution and extents make sense, and if in doubt fix them with r.region.
Markus M
… if that’s right, no idea - some statistical analysis in complex
terrain like the Alps or similar would probably tell if the coordinate
fix is right.
best,
markusN
any idea?
The CHELSA grid geometry has been messed up at some stage and no
longer matches GMTED2010 at 30 arc seconds resolution. The excess 7
columns at the east and the missing northernmost row are a mystery. A
nice test would be to check if the westernmost 7 columns are identical
to the 7 easternmost columns since they cover the same area.
Otherwise, you can try gdal_translate to prepare the data for GRASS
import. The first thing I would do is evaluate spatial accuracy
(spatial pattern matching with worldclim).
Markus M
[1]
http://erouault.blogspot.co.at/2011/12/seamless-access-to-remote-global-multi.html
[2]https://pubs.usgs.gov/of/2011/1073/pdf/of2011-1073.pdf
best regards
Helmut
View this message in context: http://osgeo-org.1560.x6.nabble.com/CHELSA-climate-data-set-tp5284115p5284378.html
Sent from the Grass - Users mailing list archive at Nabble.com.
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
–
Markus Neteler
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog
