[GRASS-user] question on i.nightlights.intercalibration code

[Markus Metz]

On Thu, Jul 5, 2018 at 3:03 PM, Gabriel Cotlier <gabiklm01 at gmail.com> wrote:
>
> Dear Nikos, Markus, and Vero,
>
>
> Here is a kind of very small routine I have run on the bases of our last
chat.
> I guess most of steps are covered, but I still have two questions:
>
>
> 1. as you can see in the message after running the code the resolution is
finally set to 1, but before this message, it still appears "exceeded by
0.999827".

This message should appear only once, before the region of the raster is
adjusted. If it appears more often, this is caused by the current
computational region. Please adjust your current region with g.region (see
also below)
>
> The question is: does GRASS prints also the  "exceeded by 0.999827"
together with "exceeded by 1 cells" message because one corresponds to the
old resolution and the other to the new one, and it is letting know about
the change or is because other resason?

You are right, the first corresponds to the old raster region, the second
to the adjusted raster region.

>
> 2. How can I run this same code for many layers instead with one with
only one using the command r.in.gdal -a input=PathToMap output=MapName,
since r.in.gdal -a takes as input one layer at time?

You need to use the -a flag for each input to r.in.gdal.
[...]
>
> Step 3: seting the region to one of the imported maps with the code:
> ==================================================================
>
> >r.region -a map=F121996

must be
g.region raster=F121996

the command
r.region -a map=F121996

adjusts the region of the raster map F121996, but does not set the current
region to the raster map

Markus M

>
> 360 degree EW extent is exceeded by 0.999827 cells
> 360 degree EW extent is exceeded by 1 cells
> 360 degree EW extent is exceeded by 1 cells
> r.region complete.
>
>
> On Wed, Jun 27, 2018 at 4:55 AM, Nikos Alexandris <nik at nikosalexandris.net>
wrote:
>>
>> * Markus Metz <markus.metz.giswork at gmail.com> [2018-06-26 14:40:25
+0200]:
>>
>>
>>> 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.
>>
>>
>> Danke Markus. We should collect some of these hints.
>>
>> (
>> Oh! I took on a refreshing read-tour: a pixel's anchor point,
pixel-is-area,
>> pixel-is-center, center-to-center extent model, precision of pixel size.
>> Yet, I ended up reading about many more issues that people have to deal
>> with.
>>
>> Some interesting entries:
>>
>> - https://gis.stackexchange.com/q/122670/5256
>> - https://gis.stackexchange.com/a/243050/5256
>> )
>>
>>>> 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).
>>
>>
>> Yes, I refer to it. Understood, I won't touch upon this within the
>> module.
>>
>> Nikos
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20180705/6bb1c41a/attachment-0001.html>