Dear Markus I fowled your instructions and worked :
- first start GRASS in the PERMANENT mapset, then run
'g.region -p n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E res=00:00:30
-s'
- close grass,
open grass again in my mapsert where my data is and run the command:
'g.region -p'
and and it
On Wed, Aug 28, 2019 at 12:54 PM Gabriel Cotlier
wrote:
>
> Dear Markus,
> Thanks a lot for your replay,
> I have tried the command to change default region with g.region -p
n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E res=00:00:30 -s
> and did not allow me because according to the error
Dear Markus,
Thanks a lot for your replay,
I have tried the command to change default region with g.region -p
n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E res=00:00:30 -s
and did not allow me because according to the error message bellow my data
is in a mapset that is not . I have two
On Tue, Aug 27, 2019 at 2:25 PM Gabriel Cotlier wrote:
>
> Dear Markus,
>
> here is my log of the command, "g.region -d -u -p":
>
>
> (Tue Aug 27 09:23:26 2019)
> g.region -d -u -p
> 360 degree EW extent is exceeded by 1.99983 cells
> 360 degree EW extent is exceeded by 1.99983 cells
>
imported into QGIS layer visible and the of the layer properties are:
[image: image.png]
On Tue, Aug 27, 2019 at 9:27 AM Gabriel Cotlier wrote:
> while for individual raster maps I get:
>
> [image: image.png]
>
> On Tue, Aug 27, 2019 at 9:25 AM Gabriel Cotlier
> wrote:
>
>> What should I do
while for individual raster maps I get:
[image: image.png]
On Tue, Aug 27, 2019 at 9:25 AM Gabriel Cotlier wrote:
> What should I do in this case?
>
> On Tue, Aug 27, 2019 at 9:24 AM Gabriel Cotlier
> wrote:
>
>> Dear Markus,
>>
>> here is my log of the command, "g.region -d -u -p":
>>
>>
>>
What should I do in this case?
On Tue, Aug 27, 2019 at 9:24 AM Gabriel Cotlier wrote:
> Dear Markus,
>
> here is my log of the command, "g.region -d -u -p":
>
>
> (Tue Aug 27 09:23:26 2019)
>
> g.region -d -u -p
>
> 360 degree EW extent is exceeded by 1.99983 cells
> 360 degree EW extent is
Dear Markus,
here is my log of the command, "g.region -d -u -p":
(Tue Aug 27 09:23:26 2019)
g.region -d -u -p
360 degree EW extent is exceeded by 1.99983 cells
360 degree EW extent is exceeded by 1.99983 cells
projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid:
On Mon, Aug 26, 2019 at 1:14 AM Gabriel Cotlier wrote:
>
> Dear Markus,
>
> I uninstall and reinstall grass 7.6.1 64 bits and still my log for the
commands
>
> g.region -p
>
> and
>
> g.region -p n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E res=00:00:30
>
> are respectively :
>
> (Sun Aug 25
Dear Markus,
I uninstall and reinstall grass 7.6.1 64 bits and still my log for the
commands
g.region -p
and
g.region -p n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E res=00:00:30
are respectively :
(Sun Aug 25 20:01:47 2019)
g.region -p
360 degree EW extent is exceeded by 1.99983
Dear Nikos,
Thanks a lot for the explanation.
Regards,
Gabriel
On Fri, Jul 6, 2018 at 4:55 AM, Nikos Alexandris
wrote:
> * Gabriel Cotlier [2018-07-05 18:28:30 -0300]:
>
> Dear Markus,
>> Thanks a lot for the explanation. For some reasoner every time I try to
>> run
>> g.region I can's and I
* Gabriel Cotlier [2018-07-05 18:28:30 -0300]:
Dear Markus,
Thanks a lot for the explanation. For some reasoner every time I try to run
g.region I can's and I got this pop up dialog box as in the figure below,
and apparently g.region does not run...
How could be possible to solve it?
Thanks a
Dear Markus,
Thanks a lot for the explanation. For some reasoner every time I try to run
g.region I can's and I got this pop up dialog box as in the figure below,
and apparently g.region does not run...
How could be possible to solve it?
Thanks a lot again.
Best regards,
Gabriel
On
On Thu, Jul 5, 2018 at 3:03 PM, Gabriel Cotlier wrote:
>
> Dear Nikos, Markus, and Vero,
>
>
> Here is a kind of very small routine I have run on the bases of our last
chat.
> I guess most of steps are covered, but I still have two questions:
>
>
> 1. as you can see in the message after running
Dear Nikos, Markus, and Vero,
Here is a kind of very small routine I have run on the bases of our last
chat.
I guess most of steps are covered, but I still have two questions:
1. as you can see in the message after running the code the resolution is
finally set to 1, but before this message,
On Tue, Jun 26, 2018 at 9:53 AM, Nikos Alexandris
wrote:
>
> * Markus Metz [2018-06-25 08:29:45 +0200]:
>
> [..]
>
>> The resolution is a bit wrong, it is 0.0083330 but should be
>> 0.008, i.e. exactly 30 arc-seconds. This can be solved with
the
>> -a flag of r.in.gdal, or
* Markus Metz [2018-06-25 08:29:45 +0200]:
[..]
The resolution is a bit wrong, it is 0.0083330 but should be
0.008, 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
On Mon, Jun 25, 2018 at 4:33 PM, Gabriel Cotlier
wrote:
>
> Dear Markus,
>
> Thanks a lot for the explanation.
>
> After importing the layer F101992 I did :
>
> r.region -a map=F101992@PERMANENT
>
> and I got the results as you indicated, with the new resolution message:
>
> 360 degree EW extent
On Mon, Jun 25, 2018 at 5:40 AM, Gabriel Cotlier
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
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
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
On Sat, Jun 23, 2018 at 11:10 AM, Veronica Andreo
wrote:
>
> Hi,
>
> El sáb., 23 jun. 2018 4:35, Markus Metz
escribió:
>>
>>
>>
>> On Fri, Jun 22, 2018 at 10:34 PM, Veronica Andreo
wrote:
>> >
>> > Hi Gabriel,
>> >
>> > What you could do is import with r.in.gdal -a that adjusts resolution
for
Hi,
El sáb., 23 jun. 2018 4:35, Markus Metz
escribió:
>
>
> On Fri, Jun 22, 2018 at 10:34 PM, Veronica Andreo
> 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
On Fri, Jun 22, 2018 at 10:34 PM, Veronica Andreo
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.0083330 to
0.008, i.e. exactly 30 arc-seconds. The software
>Are you using Windows? I think you cannot use g.list inside a command as we
do in Linux
not as elegant in linux, but you can do something similar in windows too
e.g. in the winGRASS command line:
:\>FOR /F %c in ('g.list "type=raster" "pattern=*2" "mapset=user1"
"separator=comma"') DO SET
Hi Gabriel,
What you could do is import with r.in.gdal -a that adjusts resolution for
lat long maps [0] and then (before the intercalibration step), set the
region to one of the imported maps with g.region raster=yourmap
HTH,
Vero
[0] https://grass.osgeo.org/grass74/manuals/r.in.gdal.html
El
Dear Nikos and Veronica,
Thanks a lot for your emails, I'm happy it worked!
I will try to avoid of the extent message "360 degree EW extent is
exceeded by 0.999827 cells" using: g.region -a, should I enter this
command before importing the images - raster data layers ?
Thanks a lot again for
* Gabriel Cotlier [2018-06-21 18:24:38 -0300]:
Hello Veronica,
Thanks a lot it worked!!
Dear Gabriel,
Thanks for posting details and great it works. Don't worry about the
last image, there are no coefficients for F18 and 2013. We are forced
to skip this image in any analysis.
Details
Hello Veronica,
Thanks a lot it worked!!
following the line you wrote:
i.nightlights.intercalibration image=img1,img2,img3 suffix=c elvidge2014
and got the error:
(Thu Jun 21 17:36:56
2018)
i.nightlights.intercalibration
It is a bit difficult to read, can you post the command you used? It seems
you typed image twice, suffic instead of suffix and you are using $() to
pass the list of map names which is not necesary, AFAIU. Try the following:
i.nightlights.intercalibration image=img1,img2,img3 suffix=c
Hello Vero,
Thanks a lot for your response.
I have tried that with no results, with the error in the image bellow:
On Thu, Jun 21, 2018 at 12:12 PM, Veronica Andreo
wrote:
> Hi Gabriel,
>
> Are you using Windows? I think you cannot use g.list inside a command as
> we do in Linux.
Hi Gabriel,
Are you using Windows? I think you cannot use g.list inside a command as we
do in Linux. Solution would be to first get the list of comma separated map
names and then paste it in the i.nightlights command.
HTH,
Vero
El jue., 21 jun. 2018 11:05, Gabriel Cotlier escribió:
> I have
I have tried to run i.i.nightlights.intercalibration on the command line
and got the following error:
What could be happening?
Thanks a lot
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
I have tried to run i.i.nightlights.intercalibration on the command line
and got the following error:
What could be happening?
Thanks a lot
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
34 matches
Mail list logo
