[GRASS-user] CHELSA climate data set

Markus Metz markus.metz.giswork at gmail.com
Tue Feb 7 06:32:47 PST 2017


On Tue, Feb 7, 2017 at 11:14 AM, Markus Neteler <neteler at osgeo.org> wrote:
>
> On Tue, Sep 6, 2016 at 10:22 PM, Markus Metz
> <markus.metz.giswork at gmail.com> wrote:
> > On Tue, Sep 6, 2016 at 8:12 PM, Helmut Kudrnovsky <hellik at 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 at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/grass-user
> > _______________________________________________
> > grass-user mailing list
> > grass-user at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20170207/e0c9fae0/attachment-0001.html>


More information about the grass-user mailing list