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 <[email protected]> wrote: > > > On Thu, Jul 5, 2018 at 3:03 PM, Gabriel Cotlier <[email protected]> > 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 < > [email protected]> wrote: > >> > >> * Markus Metz <[email protected]> [2018-06-26 14:40:25 > +0200]: > >> > >> > >>> On Tue, Jun 26, 2018 at 9:53 AM, Nikos Alexandris < > [email protected]> > >>> wrote: > >>>> > >>>> > >>>> * Markus Metz <[email protected]> [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 > > > > >
_______________________________________________ grass-user mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-user
