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

Thu Jul 5 14:28:30 PDT 2018

Dear Markus,
Thanks a lot for the explanation. For some reasoner every time I try to run
g.region I can's and I got this pop up dialog box as in the figure below,
and apparently g.region does not run...
How could be possible to solve it?
Thanks a lot again.
Best regards,
Gabriel

On Thu, Jul 5, 2018 at 2:24 PM, Markus Metz <markus.metz.giswork at gmail.com>
wrote:

>
>
> 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/13b85b6c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 92611 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20180705/13b85b6c/attachment-0001.png>