<div dir="ltr">Dear Markus,<div>My message to your code: g.region -p n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E res=00:00:30 is in the picture bellow:</div><div><br></div><div><br></div><div><div><img src="cid:ii_jzkagfry0" alt="image.png" width="567" height="657" style="margin-right: 0px;"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 20, 2019 at 5:34 PM Gabriel Cotlier <<a href="mailto:gabiklm01@gmail.com">gabiklm01@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dear Markus,<div>My grass version is : GRASS GIS 7.6.1 </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 20, 2019 at 5:13 PM Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com" target="_blank">markus.metz.giswork@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dear Gabriel,<br><br>On Tue, Aug 20, 2019 at 9:50 PM Gabriel Cotlier <<a href="mailto:gabiklm01@gmail.com" target="_blank">gabiklm01@gmail.com</a>> wrote:<br>><br>> Dear Markus,<br>> So I run the command g.region w=179:59:45W e=180:00:15E<br>><br>> Now my log now before and after the command g.region w=179:59:45W e=180:00:15E is as follows:<br>><br>> 360 degree EW extent is exceeded by 1 cells<br>> 360 degree EW extent is exceeded by 1 cells<br>> (Tue Aug 20 16:41:45 2019) Command finished (0 sec) <br>> (Tue Aug 20 16:43:47 2019) <br>> g.region w=179:59:45W e=180:00:15E <br>> 360 degree EW extent is exceeded by 1.99983 cells<br>> 360 degree EW extent is exceeded by 1 cells<br>> (Tue Aug 20 16:43:48 2019) Command finished (0 sec) <br>> (Tue Aug 20 16:44:18 2019) <br>> g.region -p <br>> projection: 3 (Latitude-Longitude)<br>> zone: 0<br>> datum: wgs84<br>> ellipsoid: wgs84<br>> north: 75:00:15N<br>> south: 65:00:15S<br>> west: 179:59:45W<br>> east: 180:00:15E<br>> nsres: 0:00:30<br>> ewres: 0:00:30<br>> rows: 16801<br>> cols: 43200<br>> cells: 725803200<br>> 360 degree EW extent is exceeded by 1.99983 cells<br>> (Tue Aug 20 16:44:18 2019) Command finished (0 sec) <br><div><br></div><div>With GRASS 7.6, I can not reproduce this message.</div><div>g.region -p n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E res=00:00:30</div><div><br></div><div>gives me</div><div>projection: 3 (Latitude-Longitude)<br>zone: 0<br>datum: wgs84<br>ellipsoid: wgs84<br>north: 75:00:15N<br>south: 65:00:15S<br>west: 179:59:45W<br>east: 180:00:15E<br>nsres: 0:00:30<br>ewres: 0:00:30<br>rows: 16801<br>cols: 43200<br>cells: 725803200<br></div><div><br></div><div>without any messages that 360 degree EW extent is exceeded. Which GASS version are you using? I tested with GRASS 7.6 and GRASS 7.9.</div><div><br></div><div>Markus M</div><div><br></div><div>></div>> Now appears to say that is exceeded by 1.99983 cells.... why could this be happening?<br>> Thanks a lot <br>><br>> Regards<br>> Gabriel <br>><br>><br>><br>><br>><br>><br>><br>><br>><br>><br>><br>><br>> On Tue, Aug 20, 2019 at 4:33 PM Gabriel Cotlier <<a href="mailto:gabiklm01@gmail.com" target="_blank">gabiklm01@gmail.com</a>> wrote:<br>>><br>>> Dear Markus,<br>>> Thanks a lot for your response and explanation. <br>>> Changing the region to w=179:59:45W e=180:00:15E, am I not only avoiding the warning, but also changing the layers to be physically correct, right?<br>>><br>>> Thanks again for your help.<br>>> regards,<br>>> Gabriel<br>>> <br>>><br>>> On Tue, Aug 20, 2019 at 4:24 PM Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com" target="_blank">markus.metz.giswork@gmail.com</a>> wrote:<br>>>><br>>>> Dear Gabriel,<br>>>><br>>>> On Tue, Aug 20, 2019 at 12:19 AM Gabriel Cotlier <<a href="mailto:gabiklm01@gmail.com" target="_blank">gabiklm01@gmail.com</a>> wrote:<br>>>> ><br>>>> > Dear Markus,<br>>>> ><br>>>> > Thanks a lot for the clarification and explanation, your response was indeed helpful.<br>>>> ><br>>>> > I got for all maps in the mapset I used, for both the DMSP original raster layers and the intercallibrated rasrer layers the following:<br>>>> ><br>>>> > <a href="http://r.info" target="_blank">r.info</a> map= name_of_raster_map <br>>>> ><br>>>> > 360 degree EW extent is exceeded by 1 cells<br>>>> > 360 degree EW extent is exceeded by 1 cells<br>>>> ><br>>>> > Which, following what you said before in your response I understand makes it correct region, right?<br>>>><br>>>> this region is correct considering the resolution with is now exactly 30 arc seconds.<br>>>><br>>>> this region is not correct considering that 360 degree EW extent is exceeded by 1 cell. The first column from 180:00:15W to 179:59:45W and the last column from 179:59:45E to 180:00:15E spatially overlap, the first and last column of DMSP are duplicates with regard to their location. If you want to avoid this warning, you can set the region to w=179:59:45W e=180:00:15E.<br>>>><br>>>> Markus M<br>>>><br>>>> ><br>>>> > Another question I wanted to ask is: how to know whether the operation of intercallibration was correctly done, for tha I thought maybe thare is the a place from where I can corroborate whether the min and max values of each intercallibrated raster layer is correct?<br>>>> ><br>>>> ><br>>>> > I'm attaching the log of all the files I got from '<a href="http://r.info" target="_blank">r.info</a>' command in it there appears always for the region '360 degree EW extent is exceeded by 1 cells' and also the min and max value of each intercallibrated raster layer.<br>>>> ><br>>>> > So as to know if I got all the raster correctly intercallibrated maybe checking if the min and max value for each intercallibrated corresponds correctly is there a place where I can check that?<br>>>> ><br>>>> > Maybe according to my attached log file is possible to know if all the intercallibration operation was correctly done and thus the layers are ready for further study and analysis.<br>>>> ><br>>>> ><br>>>> > Thanks a lot again for your help.<br>>>> > Kind regards,<br>>>> > Gabriel<br>>>> ><br>>>> > Virus-free. <a href="http://www.avast.com" target="_blank">www.avast.com</a><br>>>> ><br>>>> > On Mon, Aug 19, 2019 at 4:41 PM Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com" target="_blank">markus.metz.giswork@gmail.com</a>> wrote:<br>>>> >><br>>>> >><br>>>> >><br>>>> >> On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <<a href="mailto:gabiklm01@gmail.com" target="_blank">gabiklm01@gmail.com</a>> wrote:<br>>>> >> ><br>>>> >> > Hello,<br>>>> >> > My question is how does it influence the fact that it say:<br>>>> >> > 360 degree EW extent is exceeded by 0.999827 cells<br>>>> >><br>>>> >> this is caused by the truncated resolution of 0.008333333300000<br>>>> >> with a corrected resolution of 00:00:30, the message is<br>>>> >><br>>>> >> > 360 degree EW extent is exceeded by 1 cells<br>>>> >><br>>>> >> considering the EW extents of 180:00:15W to 180:00:15E, that means that the first column from 180:00:15W to 179:59:45W and the last column from 179:59:45E to 180:00:15E spatially overlap, the first and last column of DMSP are duplicates with regard to their location. If you want to avoid this warning, you can set the region to w=179:59:45W e=180:00:15E.<br>>>> >><br>>>> >> Note that the recommended way to set a computational region to a raster map is g.region rast=name_of_raster_map. After that, as for DMSP, you might want to adjust the computational region to your needs, e.g. a smaller region of interest, or restrict it to 360 degrees EW extent in case the raster map is exceeding 360 degrees EW extent.<br>>>> >><br>>>> >> HTH,<br>>>> >><br>>>> >> Markus M<br>>>> >><br>>>> >> ><br>>>> >> ><br>>>> >> ><br>>>> >> ><br>>>> >> ><br>>>> >> ><br>>>> >> > while when I loaded a first file I defined a region as<br>>>> >> > <br>>>> >> ><br>>>> >> > which is exactly I suppose the correct region for the DMSP data.... then after loading the other layers it appears:<br>>>> >> ><br>>>> >> > 360 degree EW extent is exceeded by 0.999827 cells<br>>>> >> > 360 degree EW extent is exceeded by 1 cells<br>>>> >> ><br>>>> >> > Thanks a lot<br>>>> >> > Gabriel<br>>>> >> ><br>>>> >> ><br>>>> >> ><br>>>> >> ><br>>>> >> > On Sun, Aug 18, 2019 at 6:54 PM Gabriel Cotlier <<a href="mailto:gabiklm01@gmail.com" target="_blank">gabiklm01@gmail.com</a>> wrote:<br>>>> >> >><br>>>> >> >> Hello, another question, regarding i.nightlights.intercalibration, can I run this code as python package/lbrary loading it from Spyder or Jupiter Notebook instead of using GRASS interface, if so how is a convenient way to install i.nightlights.intercalibration in python using Spyder?<br>>>> >> >> Thanks a lot.<br>>>> >> >> Gabriel <br>>>> >> >><br>>>> >> >> On Sat, Aug 17, 2019 at 4:54 PM Gabriel Cotlier <<a href="mailto:gabiklm01@gmail.com" target="_blank">gabiklm01@gmail.com</a>> wrote:<br>>>> >> >>><br>>>> >> >>> Dear Nikos.<br>>>> >> >>> After a long time I'm trying to reproduce a routine I have for doing intercallibratrion of DMSP 1992-2012 but for some reason It doesn't work to me. I think is because the problem between the region of the layers 30 arc sec should resolution be from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds? and the computational region be the same ? I got stuck on how to set it to work... from the side of the region setting.<br>>>> >> >>> However in addition my routing also has a for loop which does not work ok as well.<br>>>> >> >>> I would appreciate a lot of you can give it a look and tell me how to make it work...<br>>>> >> >>> Thanks a lot in advance<br>>>> >> >>> Kind regards,<br>>>> >> >>> Gabriel<br>>>> >> >>> #####-----------------------------------------------------------------------------------------<br>>>> >> >>> # complete routine for intercalliration of DSMP/OLS light stable product<br>>>> >> >>><br>>>> >> >>> import grass.script as gscript<br>>>> >> >>> import os<br>>>> >> >>> import os,glob<br>>>> >> >>><br>>>> >> >>> # get working directory<br>>>> >> >>> print os.getcwd()<br>>>> >> >>><br>>>> >> >>> # change working directory where raster files are<br>>>> >> >>> os.chdir('C:\\Users\\Gabriel\\Documents\\grassdata\\lights')<br>>>> >> >>><br>>>> >> >>> # see files in directory<br>>>> >> >>> ls<br>>>> >> >>><br>>>> >> >>> # import all raster files to grass --- here is a kind of problem...???<br>>>> >> >>> for tif_file in glob.glob("*.tif"):<br>>>> >> >>> new_rast = os.path.splitext(tif_file)[0]<br>>>> >> >>> grass.run_command("r.in.gdal", flags="a", input=tif_file, output=new_rast)<br>>>> >> >>><br>>>> >> >>> # get info of one of the imported raster<br>>>> >> >>> <a href="http://r.info" target="_blank">r.info</a> map=F121996<br>>>> >> >>><br>>>> >> >>> # run intercalliration algorithm<br>>>> >> >>> i.nightlights.intercalibration image=F101992,F101993,F101994,F121994,F121995,F121996,F121997,F121998,F121999,F141997,F141998,F141999,F142000,F142001,F142002,F142003,F152000,F152001,F152002,F152003,F152004,F152005,F152006,F152007,F162004,F162005,F162006,F162007,F162008,F162009,F182010,F182011,F182012,F182013 suffix=c model=elvidge2014 -t<br>>>> >> >>><br>>>> >> >>> # correct general region adjust to raster file --- here the region is exactly 30 arc for the raster as I could see....<br>>>> >> >>> g.region raster=F121996<br>>>> >> >>><br>>>> >> >>> # cerate a list of rasters in the mapset<br>>>> >> >>> # rastlist=grass.read_command("g.list",type="rast").split()<br>>>> >> >>> rasters = grass.read_command('g.list', type='raster').splitlines()<br>>>> >> >>> <br>>>> >> >>> # change working directory<br>>>> >> >>> os.chdir('C:\\Users\\Gabriel\\Desktop\\out')<br>>>> >> >>> <br>>>> >> >>> # save rasters in mapset to file<br>>>> >> >>> for raster in rasters:<br>>>> >> >>> grass.run_command('r.out.gdal', input=raster, output=raster + '.tiff', format='GTiff')<br>>>> >> >>><br>>>> >> >>> On Wed, Aug 22, 2018 at 10:06 AM Gabriel Cotlier <<a href="mailto:gabiklm01@gmail.com" target="_blank">gabiklm01@gmail.com</a>> wrote:<br>>>> >> >>>><br>>>> >> >>>> Dear Nikos,<br>>>> >> >>>><br>>>> >> >>>> Thanks a lot for your answer and the orientation.<br>>>> >> >>>> The information and the link are very useful.<br>>>> >> >>>> Kind regards,<br>>>> >> >>>> Gabriel<br>>>> >> >>>><br>>>> >> >>>><br>>>> >> >>>> On Wed, Aug 22, 2018 at 5:19 AM Nikos Alexandris <<a href="mailto:nik@nikosalexandris.net" target="_blank">nik@nikosalexandris.net</a>> wrote:<br>>>> >> >>>>><br>>>> >> >>>>> * Gabriel Cotlier <<a href="mailto:gabiklm01@gmail.com" target="_blank">gabiklm01@gmail.com</a>> [2018-08-21 12:00:24 -0300]:<br>>>> >> >>>>><br>>>> >> >>>>> >Dear Nikos and GRASS users,<br>>>> >> >>>>> ><br>>>> >> >>>>> >I would like to ask if nonetheless the effect due to "stray light" the<br>>>> >> >>>>> >*i.landsat8.swlst* code for split window is still applicable to Landsat 8<br>>>> >> >>>>> >data and whether these error is specially visible on water bodies? and<br>>>> >> >>>>> >whether band 10 is better than band 11 in terms of correction processing<br>>>> >> >>>>> >for Level -1 data products?<br>>>> >> >>>>> ><br>>>> >> >>>>> >Thanks a lot.<br>>>> >> >>>>> ><br>>>> >> >>>>> >Kind regards,<br>>>> >> >>>>> >Gabriel<br>>>> >> >>>>><br>>>> >> >>>>> Dear Gabriel,<br>>>> >> >>>>><br>>>> >> >>>>> for details and references, refer to<br>>>> >> >>>>><br>>>> >> >>>>> <a href="https://landsat.gsfc.nasa.gov/landsat-8-thermal-data-ghost-free-after-stray-light-exorcism/" target="_blank">https://landsat.gsfc.nasa.gov/landsat-8-thermal-data-ghost-free-after-stray-light-exorcism/</a><br>>>> >> >>>>><br>>>> >> >>>>> Make sure you use the newest Level-1 Collection 1 Landsat 8 products.<br>>>> >> >>>>><br>>>> >> >>>>> I use `i.landsat8.swlst` and plan to improve it further.<br>>>> >> >>>>><br>>>> >> >>>>> However, whether to prefer a Split-Window based approach, or another<br>>>> >> >>>>> Single-Channel one, depends on what you want to do. Think of spatial<br>>>> >> >>>>> extent and coverage of various land (cover) types, temporal extent<br>>>> >> >>>>> and more.<br>>>> >> >>>>><br>>>> >> >>>>> Thermal remote sensing is hard(er) also because it's hard to get<br>>>> >> >>>>> ground-truth data sets so as to validate LST estimations.<br>>>> >> >>>>><br>>>> >> >>>>> Nikos</div>
</blockquote></div>
</blockquote></div>