On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier <gabikl...@gmail.com> wrote: > > Hello, > My question is how does it influence the fact that it say: > 360 degree EW extent is exceeded by 0.999827 cells
this is caused by the truncated resolution of 0.008333333300000 with a corrected resolution of 00:00:30, the message is > 360 degree EW extent is exceeded by 1 cells 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. 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. HTH, Markus M > > > > > > > while when I loaded a first file I defined a region as > > > which is exactly I suppose the correct region for the DMSP data.... then after loading the other layers it appears: > > 360 degree EW extent is exceeded by 0.999827 cells > 360 degree EW extent is exceeded by 1 cells > > Thanks a lot > Gabriel > > > > > On Sun, Aug 18, 2019 at 6:54 PM Gabriel Cotlier <gabikl...@gmail.com> wrote: >> >> 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? >> Thanks a lot. >> Gabriel >> >> On Sat, Aug 17, 2019 at 4:54 PM Gabriel Cotlier <gabikl...@gmail.com> wrote: >>> >>> Dear Nikos. >>> 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. >>> However in addition my routing also has a for loop which does not work ok as well. >>> I would appreciate a lot of you can give it a look and tell me how to make it work... >>> Thanks a lot in advance >>> Kind regards, >>> Gabriel >>> #####----------------------------------------------------------------------------------------- >>> # complete routine for intercalliration of DSMP/OLS light stable product >>> >>> import grass.script as gscript >>> import os >>> import os,glob >>> >>> # get working directory >>> print os.getcwd() >>> >>> # change working directory where raster files are >>> os.chdir('C:\\Users\\Gabriel\\Documents\\grassdata\\lights') >>> >>> # see files in directory >>> ls >>> >>> # import all raster files to grass --- here is a kind of problem...??? >>> for tif_file in glob.glob("*.tif"): >>> new_rast = os.path.splitext(tif_file)[0] >>> grass.run_command("r.in.gdal", flags="a", input=tif_file, output=new_rast) >>> >>> # get info of one of the imported raster >>> r.info map=F121996 >>> >>> # run intercalliration algorithm >>> 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 >>> >>> # correct general region adjust to raster file --- here the region is exactly 30 arc for the raster as I could see.... >>> g.region raster=F121996 >>> >>> # cerate a list of rasters in the mapset >>> # rastlist=grass.read_command("g.list",type="rast").split() >>> rasters = grass.read_command('g.list', type='raster').splitlines() >>> >>> # change working directory >>> os.chdir('C:\\Users\\Gabriel\\Desktop\\out') >>> >>> # save rasters in mapset to file >>> for raster in rasters: >>> grass.run_command('r.out.gdal', input=raster, output=raster + '.tiff', format='GTiff') >>> >>> On Wed, Aug 22, 2018 at 10:06 AM Gabriel Cotlier <gabikl...@gmail.com> wrote: >>>> >>>> Dear Nikos, >>>> >>>> Thanks a lot for your answer and the orientation. >>>> The information and the link are very useful. >>>> Kind regards, >>>> Gabriel >>>> >>>> >>>> On Wed, Aug 22, 2018 at 5:19 AM Nikos Alexandris < n...@nikosalexandris.net> wrote: >>>>> >>>>> * Gabriel Cotlier <gabikl...@gmail.com> [2018-08-21 12:00:24 -0300]: >>>>> >>>>> >Dear Nikos and GRASS users, >>>>> > >>>>> >I would like to ask if nonetheless the effect due to "stray light" the >>>>> >*i.landsat8.swlst* code for split window is still applicable to Landsat 8 >>>>> >data and whether these error is specially visible on water bodies? and >>>>> >whether band 10 is better than band 11 in terms of correction processing >>>>> >for Level -1 data products? >>>>> > >>>>> >Thanks a lot. >>>>> > >>>>> >Kind regards, >>>>> >Gabriel >>>>> >>>>> Dear Gabriel, >>>>> >>>>> for details and references, refer to >>>>> >>>>> https://landsat.gsfc.nasa.gov/landsat-8-thermal-data-ghost-free-after-stray-light-exorcism/ >>>>> >>>>> Make sure you use the newest Level-1 Collection 1 Landsat 8 products. >>>>> >>>>> I use `i.landsat8.swlst` and plan to improve it further. >>>>> >>>>> However, whether to prefer a Split-Window based approach, or another >>>>> Single-Channel one, depends on what you want to do. Think of spatial >>>>> extent and coverage of various land (cover) types, temporal extent >>>>> and more. >>>>> >>>>> Thermal remote sensing is hard(er) also because it's hard to get >>>>> ground-truth data sets so as to validate LST estimations. >>>>> >>>>> Nikos
_______________________________________________ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user