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

Markus Metz markus.metz.giswork at gmail.com
Sun Jun 24 23:29:45 PDT 2018


On Mon, Jun 25, 2018 at 5:40 AM, Gabriel Cotlier <gabiklm01 at gmail.com>
wrote:
>
> Hello,
>
> I think I have found a similar situation solved for Linux version at:
>
> https://trac.osgeo.org/grass/ticket/2757#comment:21
>
> In my case I'm using GRASS 7.4.0 in Windows 10, and when I called for
metadata info of the layer I got the message bellow with the problem
highlighted in yellow bellow.
>
> What could be happening? It would be very helpful to understand what is
happening and how to solve importing many raster layers without this extent
problems.

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.

Markus M

>
> 360 degree EW extent is exceeded by 1.99983 cells
>
> (Mon Jun 25 00:30:04 2018) Command finished (0 sec)
>
>
>
>
>
> Virus-free. www.avg.com
>
> On Sun, Jun 24, 2018 at 5:09 PM, Gabriel Cotlier <gabiklm01 at gmail.com>
wrote:
>>
>> Dear Vero and Markus,
>>
>> Thanks a lot for the guidance and help.
>>
>> If I understood correctly:
>>
>> I first have to import one layer when I select a location setting the
coordinate system of that layer to the mapset of GRASS (at the start).
>>
>> Then I have to import all other layers to mapset using command
"r.in.gdal -a"
>>
>> r.in.gdal -a input=C:\Users\Gabriel\Documents\layers\F121995.tif
output=F121995
>>
>> Then I have to running "g.region" to set up the same extent to all
layers as follows:
>>
>> g.region raster=F121995
>>
>> and I got the layer processed and finished but the error did not went
way....
>>
>> |i Inter-satellite calibration of DMSP-OLS Nighttime Stable Lights
>> WARNING: Operating on current region
>>
>> |> Calibrating average visible Digital Number values
>> Regression coefficients: (-0.0515, 1.2293, -0.0038) | Associated R^2:
0.9178
>>
>> 360 degree EW extent is exceeded by 0.999827 cells
>> 360 degree EW extent is exceeded by 1 cells
>>
>> WARNING: As requested, timestamp transferring not attempted.
>> WARNING: No data base element files found
>>
>> (Sun Jun 24 17:05:31 2018) Command finished (1 min 2 sec)

>>
>> What could be doing wrong?
>> In addition I'm doing it for one layer here, is there a way to do it for
many layers at onces with command line or GUI dialog box?
>>
>> Thanks a lot again.
>>
>> Gabriel
>>
>> On Sat, Jun 23, 2018 at 6:31 AM, Markus Metz <
markus.metz.giswork at gmail.com> wrote:
>>>
>>>
>>>
>>> On Sat, Jun 23, 2018 at 11:10 AM, Veronica Andreo <veroandreo at gmail.com>
wrote:
>>> >
>>> > Hi,
>>> >
>>> > El sáb., 23 jun. 2018 4:35, Markus Metz <markus.metz.giswork at gmail.com>
escribió:
>>> >>
>>> >>
>>> >>
>>> >> On Fri, Jun 22, 2018 at 10:34 PM, Veronica Andreo <
veroandreo at gmail.com> wrote:
>>> >> >
>>> >> > Hi Gabriel,
>>> >> >
>>> >> > What you could do is import with r.in.gdal -a  that adjusts
resolution for lat long maps [0]
>>> >>
>>> >> that will help to fix the resolution from 0.008333333300000 to
0.008333333333333, i.e. exactly 30 arc-seconds. The software used to create
the raster data has stored the resolution with limited precision.
>>> >
>>> >
>>> > Right, I overlooked this
>>> >
>>> >> > and then (before the intercalibration step), set the region to one
of the imported maps with g.region raster=yourmap
>>> >>
>>> >> you will then get a message like
>>> >> 360 degree EW extent is exceeded by 1 cells
>>> >>
>>> >> which is correct because the first and last column are duplicates.
The cell centers cover -180, 180, and the EW extents regarding cell borders
are E: 180:00:15E, W: 180:00:15W, grown by half a cell, i.e. 15 arc-seconds.
>>> >
>>> >
>>> > So, solution is to just use the data with the extra 15 arc-seconds in
each side?
>>>
>>> yes, or chop off the first or last column: set the region to the
raster, then modify the current region with g.region w=179:59:45W -p
>>> >
>>> > Of I want data to fit 180/-180, would r.region mymap e=180 w=180 help
or will it change the data?
>>>
>>> this would modify the data because
>>> 1) the raster will be shifted by half a cell to the east
>>> 2) the cell size (ew resolution) will be changed
>>>
>>> Markus M
>>>
>>> >
>>> > Vero
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20180625/00b743b5/attachment.html>


More information about the grass-user mailing list