<div dir="ltr"><br><br>On Thu, Jul 5, 2018 at 3:03 PM, Gabriel Cotlier <<a href="mailto:gabiklm01@gmail.com">gabiklm01@gmail.com</a>> wrote:<br>><br>> Dear Nikos, Markus, and Vero,<br>><br>><br>> Here is a kind of very small routine I have run on the bases of our last chat.<br>> I guess most of steps are covered, but I still have two questions:<br>><br>><br><div>> 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". <br></div><div><br></div><div>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)<br></div>><br>> 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?<br><div><br></div><div>You are right, the first corresponds to the old raster region, the second to the adjusted raster region.<br></div><div><br></div><div>></div>> 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?<br><div><br></div><div>You need to use the -a flag for each input to r.in.gdal.<br></div><div>[...]</div><div>></div>> Step 3: seting the region to one of the imported maps with the code:<br>> ==================================================================<br>><br>> >r.region -a map=F121996<br><div><br></div><div>must be </div><div>g.region raster=F121996</div><div><br></div><div>the command</div><div>r.region -a map=F121996</div><div><br></div><div>adjusts the region of the raster map F121996, but does not set the current region to the raster map</div><div><br></div><div>Markus M</div><div><br></div><div>>                                                          </div>> 360 degree EW extent is exceeded by 0.999827 cells<br>> 360 degree EW extent is exceeded by 1 cells<br>> 360 degree EW extent is exceeded by 1 cells<br>> r.region complete.<br>><br>><br>> On Wed, Jun 27, 2018 at 4:55 AM, Nikos Alexandris <<a href="mailto:nik@nikosalexandris.net">nik@nikosalexandris.net</a>> wrote:<br>>><br>>> * Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> [2018-06-26 14:40:25 +0200]:<br>>><br>>><br>>>> On Tue, Jun 26, 2018 at 9:53 AM, Nikos Alexandris <<a href="mailto:nik@nikosalexandris.net">nik@nikosalexandris.net</a>><br>>>> wrote:<br>>>>><br>>>>><br>>>>> * Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> [2018-06-25 08:29:45 +0200]:<br>>>>><br>>>>> [..]<br>>>>><br>>>>>> The resolution is a bit wrong, it is 0.008333333300000 but should be<br>>>>>> 0.008333333333333, i.e. exactly 30 arc-seconds. This can be solved with<br>>>><br>>>> the<br>>>>>><br>>>>>> -a flag of r.in.gdal, or after import with r.region -a.<br>>>>>><br>>>>>> The message<br>>>>>><br>>>>>>> 360 degree EW extent is exceeded by 0.999827 cells<br>>>>>><br>>>>>><br>>>>>><br>>>>>> will change to<br>>>>>><br>>>>>>> 360 degree EW extent is exceeded by 1 cells<br>>>>>><br>>>>>><br>>>>>><br>>>>>> but will not go away, because 360 degree EW extent is exceeded in the<br>>>><br>>>> input<br>>>>>><br>>>>>> data, the first and last column cover the same geographical area. You can<br>>>>>> change your current region to chop of e.g. the first column: set the<br>>>><br>>>> region<br>>>>>><br>>>>>> to the raster, then modify the current region with g.region w=179:59:45W<br>>>><br>>>> -p<br>>>>>><br>>>>>> and use this region for further processing.<br>>><br>>><br>>><br>>>>> I guess this is worth being documented in the manual of the add-on.<br>>>><br>>>><br>>>> This is a universal problem applying to various raster data in latlong. The<br>>>> first issue, 30 sec represented as 0.008333333300000 instead of<br>>>> 0.008333333333333 is solved by r.in.gdal -a. The second problem, this extra<br>>>> column responsible that 360 degree EW extent is exceeded by 1 cell can be<br>>>> solved by setting the current region accordingly. This is also a universal<br>>>> problem. Maybe the manual of r.in.gdal could include a hint about how to do<br>>>> this. Generally, users are encouraged to inspect the output of <a href="http://r.info">r.info</a> after<br>>>> importing raster data to check if everything is as expected.<br>>><br>>><br>>> Danke Markus. We should collect some of these hints.<br>>><br>>> (<br>>> Oh! I took on a refreshing read-tour: a pixel's anchor point, pixel-is-area,<br>>> pixel-is-center, center-to-center extent model, precision of pixel size.<br>>> Yet, I ended up reading about many more issues that people have to deal<br>>> with.<br>>><br>>> Some interesting entries:<br>>><br>>> - <a href="https://gis.stackexchange.com/q/122670/5256">https://gis.stackexchange.com/q/122670/5256</a><br>>> - <a href="https://gis.stackexchange.com/a/243050/5256">https://gis.stackexchange.com/a/243050/5256</a><br>>> )<br>>><br>>>>> Would<br>>>>> it also make sense to let the module attempt to perform this "correction"?<br>>>><br>>>><br>>>> If you refer to i.nightlights.intercalibration, I would say no, because it<br>>>> is a more general issue not restricted to DMSP-OLS nightlight data. Even<br>>>> more general, the current region as set by the user is used for raster<br>>>> processing (with a very few exceptions).<br>>><br>>><br>>> Yes, I refer to it. Understood, I won't touch upon this within the<br>>> module.<br>>><br>>> Nikos<br>><br>><br></div>