[GRASS-user] question on i.nightlights.intercalibration code
Markus Metz
markus.metz.giswork at gmail.com
Tue Jun 26 05:40:25 PDT 2018
On Tue, Jun 26, 2018 at 9:53 AM, Nikos Alexandris <nik at nikosalexandris.net>
wrote:
>
> * Markus Metz <markus.metz.giswork at gmail.com> [2018-06-25 08:29:45 +0200]:
>
> [..]
>
>> The resolution is a bit wrong, it is 0.008333333300000 but should be
>> 0.008333333333333, i.e. exactly 30 arc-seconds. This can be solved with
the
>> -a flag of r.in.gdal, or after import with r.region -a.
>>
>> The message
>>
>>> 360 degree EW extent is exceeded by 0.999827 cells
>>
>>
>> will change to
>>
>>> 360 degree EW extent is exceeded by 1 cells
>>
>>
>> but will not go away, because 360 degree EW extent is exceeded in the
input
>> data, the first and last column cover the same geographical area. You can
>> change your current region to chop of e.g. the first column: set the
region
>> to the raster, then modify the current region with g.region w=179:59:45W
-p
>> and use this region for further processing.
>
>
> I guess this is worth being documented in the manual of the add-on.
This is a universal problem applying to various raster data in latlong. The
first issue, 30 sec represented as 0.008333333300000 instead of
0.008333333333333 is solved by r.in.gdal -a. The second problem, this extra
column responsible that 360 degree EW extent is exceeded by 1 cell can be
solved by setting the current region accordingly. This is also a universal
problem. Maybe the manual of r.in.gdal could include a hint about how to do
this. Generally, users are encouraged to inspect the output of r.info after
importing raster data to check if everything is as expected.
> Would
> it also make sense to let the module attempt to perform this "correction"?
If you refer to i.nightlights.intercalibration, I would say no, because it
is a more general issue not restricted to DMSP-OLS nightlight data. Even
more general, the current region as set by the user is used for raster
processing (with a very few exceptions).
Markus M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20180626/07018501/attachment.html>
More information about the grass-user
mailing list