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

[Markus Metz]

On Mon, Jun 25, 2018 at 4:33 PM, Gabriel Cotlier <gabiklm01 at gmail.com>
wrote:
>
> Dear Markus,
>
> Thanks a lot for the explanation.
>
> After importing the layer F101992 I did :
>
> r.region -a map=F101992 at PERMANENT
>
> and I got the results as you indicated, with the new resolution message:
>
> 360 degree EW extent is exceeded by 1 cells
>
> Nonetheless, the message of the old resolution (360 degree EW extent is
exceeded by 0.999827 cells) still appear but in the second line of the
message bellow:
>
> Could be this indicating it changed from old to new resolution?

Have you adjusted the current region to match the adjusted raster with
g.region -p raster=F101992
?

After that, the first or last column could be ignored in further processing
by setting the region as I suggested before.

Markus M
>
> Thanks a lot again for your help.
>
> Best regards,
>
> Gabriel
>
>
>
>
> On Mon, Jun 25, 2018 at 3:29 AM, Markus Metz <
markus.metz.giswork at gmail.com> wrote:
>>
>>
>>
>> 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/06ab4f81/attachment.html>