[GRASS-user] GitHub Discussions is enabled

[Nikos Alexandris]

Dear all,

GitHub Discussions is enabled 
(https://github.com/OSGeo/grass/discussions/1841) -- obviously and 
clearly _not_ replacing the mailing lists.


Warm regards, Nikos

ps- Thanks Vaclav for time and efforts put in to this

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS GIS Birthday Virtual Celebration

[Nikos Alexandris]

Dear all,

Happy Birthday for GRASS GIS!

Sad I missed the 'gathering'.

Cheers :-)


* Vaclav Petras  [2020-07-27 21:48:29 -0400]:


Dear GRASS GIS users and developers,

On Wednesday, July 29, we will celebrate GRASS GIS birthday!

Please, join us in a video call at 19:00 UTC. I will send a link to the call
here right before the meeting. We will use Zoom.

https://www.timeanddate.com/worldclock/converter.html?iso=20200729T19=1440=204=195=51=207=671

We will ponder the long history, perhaps question some technological
decisions, discuss some current issues, and think about the future of GRASS
GIS.

If you think this is not enough celebratory, bring your most complicated
GRASS GIS workflow. What would be a better way to celebrate than to explain
an obscure command from 10 years ago?

Best,
Vashek

PS: You can let me know privately if you have any questions or concerns
about joining this video call.



___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user



--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 
___

grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Failure to compile GRASS GIS 7.8 with Proj 6 and GDAL 3

[Nikos Alexandris]

* Nikos Alexandris  [2020-02-04 16:51:33 +0100]:


regarding PROJ, cleaning up ${prefix}/share with the proj.db and grids is
quite important because PROJ is evolving fast and any leftovers from a
previous installation might confuse software compiled against PROJ.


That I forgot to remove :D.
Won't existing files be overwritten by `make install` as root?


Actually, I did remote the `share/proj` directory too before
re-installing PROJ.

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Failure to compile GRASS GIS 7.8 with Proj 6 and GDAL 3

[Nikos Alexandris]

* Markus Metz  [2020-02-03 22:35:26 +0100]:


Hi Nikos,

On Mon, Feb 3, 2020 at 7:28 PM Nikos Alexandris 
wrote:


>>I got it working, more or less. Recompiling only PROJ did away most of
>>the errors but a few. I guess I need to recompile PROJ (+GEOS), then
>>GDAL, then the rest.
>
>Still need to fix a few more:
>
>Errors in:
>/osgeo/grass/general/g.proj
>/osgeo/grass/general/g.region
>/osgeo/grass/raster/r.horizon
>/osgeo/grass/raster/r.sun
>/osgeo/grass/raster3d/r3.out.netcdf
>
>```

Fixed, I had to remove left-over files from previous PROJ
installation(s).

(...why is there no `make uninstall` for PROJ, GEOS, etc.?)


if you compile from source, it is mostly your responsibility to clean up
old installations.


(Is there a good reason not to provide for `make uninstall` besides
more workload? --I actually have no idea what it takes to do so!)


Generally, cleaning up should happen in
${prefix}/lib[64]
${prefix}/include
${prefix}/share


Do you create yourself a "hardcoded" list of files you need to remove?
Otherwise, it's a time consuming hunting of files here and there.


regarding PROJ, cleaning up ${prefix}/share with the proj.db and grids is
quite important because PROJ is evolving fast and any leftovers from a
previous installation might confuse software compiled against PROJ.


That I forgot to remove :D.
Won't existing files be overwritten by `make install` as root?


Regarding GDAL compilation against PROJ, there was in GDAL 2 the configure
option
--with-static-proj4=ARG Compile with PROJ.4 statically (deprecated, use
--with-proj instead) (ARG=no or path)
in GDAL 3 there is only
--with-proj=ARG Compile with PROJ.x (ARG=yes or path)

This static proj linking in GDAL does not mean to link against a static
PROJ library, but to statically link against a given dynamic PROJ library,
i.e. the same PROJ library used at compile time will also be used at run
time. This is important to make sure that GDAL is not suddenly picking a
different PROJ library at run time when a new PROJ library becomes
available.

I ran in all these problems myself when adding support for PROJ 4, 5, and 6
in GRASS.

Markus M


Thank you Markus, Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Failure to compile GRASS GIS 7.8 with Proj 6 and GDAL 3

[Nikos Alexandris]

* Nikos Alexandris  [2020-02-03 18:15:31 +0100]:


* Nikos Alexandris  [2020-02-02 10:40:11 +0100]:


Markus Metz:


Hi Nikos,

PROJ is moving fast, please use the latest PROJ 6 release 6.3.0

On Sat, Feb 1, 2020 at 8:36 PM Nikos Alexandris 
wrote:


Dears,

I cannot get GRASS GIS 7.8 to compile with
proj
Rel. 6.0.0, March 1st, 2019


if possible, never use a x.0.0 release of any software, these new major
releases are usually full of bugs.

Markus M


Thank you Markus!
I got it working, more or less. Recompiling only PROJ did away most of
the errors but a few. I guess I need to recompile PROJ (+GEOS), then
GDAL, then the rest.


Still need to fix a few more:

Errors in:
/osgeo/grass/general/g.proj
/osgeo/grass/general/g.region
/osgeo/grass/raster/r.horizon
/osgeo/grass/raster/r.sun
/osgeo/grass/raster3d/r3.out.netcdf

```


Fixed, I had to remove left-over files from previous PROJ
installation(s).

(...why is there no `make uninstall` for PROJ, GEOS, etc.?)

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Failure to compile GRASS GIS 7.8 with Proj 6 and GDAL 3

[Nikos Alexandris]

* Markus Neteler  [2020-02-02 10:43:51 +0100]:


Hi Nikos,

On Sun, Feb 2, 2020 at 10:40 AM Nikos Alexandris
 wrote:
...

I got it working, more or less. Recompiling only PROJ did away most of
the errors but a few. I guess I need to recompile PROJ (+GEOS), then
GDAL, then the rest.


Would you mind to then add/update the relevant section in

https://grasswiki.osgeo.org/wiki/Compile_and_Install
?


Of course I will, but the https://trac.osgeo.org/grass/wiki/FuntooLinux
wiki page. Not the generic, which I think is still valid.

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Failure to compile GRASS GIS 7.8 with Proj 6 and GDAL 3

[Nikos Alexandris]

* Nikos Alexandris  [2020-02-02 10:40:11 +0100]:


Markus Metz:


Hi Nikos,

PROJ is moving fast, please use the latest PROJ 6 release 6.3.0

On Sat, Feb 1, 2020 at 8:36 PM Nikos Alexandris 
wrote:


Dears,

I cannot get GRASS GIS 7.8 to compile with
proj
Rel. 6.0.0, March 1st, 2019


if possible, never use a x.0.0 release of any software, these new major
releases are usually full of bugs.

Markus M


Thank you Markus!
I got it working, more or less. Recompiling only PROJ did away most of
the errors but a few. I guess I need to recompile PROJ (+GEOS), then
GDAL, then the rest.


Still need to fix a few more:

Errors in:
/osgeo/grass/general/g.proj
/osgeo/grass/general/g.region
/osgeo/grass/raster/r.horizon
/osgeo/grass/raster/r.sun
/osgeo/grass/raster3d/r3.out.netcdf

```
for DIRECTORY in /osgeo/grass/general/g.proj /osgeo/grass/general/g.region 
/osgeo/grass/raster/r.horizon /osgeo/grass/raster/r.sun 
/osgeo/grass/raster3d/r3.out.netcdf ;do cd $DIRECTORY && make ;echo ;done

: && gcc -L/osgeo/grass/dist.x86_64-pc-linux-gnu/lib 
-L/osgeo/grass/dist.x86_64-pc-linux-gnu/lib -Wl,--export-dynamic  -L/usr/lib64/ 
-Wl,-rpath-link,/osgeo/grass/dist.x86_64-pc-linux-gnu/lib -o 
/osgeo/grass/dist.x86_64-pc-linux-gnu/bin/g.proj OBJ.x86_64-pc-linux-gnu/create.o 
OBJ.x86_64-pc-linux-gnu/datumtrans.o OBJ.x86_64-pc-linux-gnu/input.o 
OBJ.x86_64-pc-linux-gnu/list_codes.o OBJ.x86_64-pc-linux-gnu/main.o 
OBJ.x86_64-pc-linux-gnu/output.o-lgrass_gproj.7.8 -lgrass_gis.7.8 -L/usr/local/lib 
-lgdal -L/usr/lib64/ -lproj-lm
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: 
/osgeo/grass/dist.x86_64-pc-linux-gnu/lib/libgrass_gproj.7.8.so: undefined 
reference to `proj_get_remarks'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: 
/osgeo/grass/dist.x86_64-pc-linux-gnu/lib/libgrass_gproj.7.8.so: undefined 
reference to `proj_normalize_for_visualization'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: 
/osgeo/grass/dist.x86_64-pc-linux-gnu/lib/libgrass_gproj.7.8.so: undefined 
reference to `proj_get_scope'
collect2: error: ld returned 1 exit status
make: *** [../../include/Make/Module.make:18: 
/osgeo/grass/dist.x86_64-pc-linux-gnu/bin/g.proj] Error 1

: && gcc -L/osgeo/grass/dist.x86_64-pc-linux-gnu/lib 
-L/osgeo/grass/dist.x86_64-pc-linux-gnu/lib -Wl,--export-dynamic  -L/usr/lib64/ 
-Wl,-rpath-link,/osgeo/grass/dist.x86_64-pc-linux-gnu/lib -o 
/osgeo/grass/dist.x86_64-pc-linux-gnu/bin/g.region OBJ.x86_64-pc-linux-gnu/adjust.o 
OBJ.x86_64-pc-linux-gnu/main.o OBJ.x86_64-pc-linux-gnu/printwindow.o 
OBJ.x86_64-pc-linux-gnu/zoom.o-lgrass_gproj.7.8 -lgrass_vector.7.8 -lgrass_dig2.7.8 
-lgrass_g3d.7.8 -lgrass_raster.7.8 -lgrass_gis.7.8 -lm  -L/usr/lib64/ -lproj-lm
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: 
/osgeo/grass/dist.x86_64-pc-linux-gnu/lib/libgrass_gproj.7.8.so: undefined 
reference to `proj_get_remarks'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: 
/osgeo/grass/dist.x86_64-pc-linux-gnu/lib/libgrass_gproj.7.8.so: undefined 
reference to `proj_normalize_for_visualization'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: 
/osgeo/grass/dist.x86_64-pc-linux-gnu/lib/libgrass_gproj.7.8.so: undefined 
reference to `proj_get_scope'
collect2: error: ld returned 1 exit status
make: *** [../../include/Make/Module.make:18: 
/osgeo/grass/dist.x86_64-pc-linux-gnu/bin/g.region] Error 1

: && gcc -L/osgeo/grass/dist.x86_64-pc-linux-gnu/lib 
-L/osgeo/grass/dist.x86_64-pc-linux-gnu/lib -Wl,--export-dynamic  -L/usr/lib64/ 
-Wl,-rpath-link,/osgeo/grass/dist.x86_64-pc-linux-gnu/lib -o 
/osgeo/grass/dist.x86_64-pc-linux-gnu/bin/r.horizon OBJ.x86_64-pc-linux-gnu/main.o
-lgrass_gproj.7.8 -lgrass_raster.7.8 -lgrass_gis.7.8 -lm  -L/usr/lib64/ -lproj-lm
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: 
/osgeo/grass/dist.x86_64-pc-linux-gnu/lib/libgrass_gproj.7.8.so: undefined 
reference to `proj_get_remarks'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: 
/osgeo/grass/dist.x86_64-pc-linux-gnu/lib/libgrass_gproj.7.8.so: undefined 
reference to `proj_normalize_for_visualization'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: 
/osgeo/grass/dist.x86_64-pc-linux-gnu/lib/libgrass_gproj.7.8.so: undefined 
reference to `proj_get_scope'
collect2: error: ld returned 1 exit status
make: *** [../../include/Make/Module.make:18: 
/osgeo/grass/dist.x86_64-pc-linux-gnu/bin/r.horizon] Error 1

: && gcc -L/osgeo/grass/dist.x86_64-pc-linux-gnu/lib 
-L/osgeo/grass/dist.x86_64-pc-linux-gnu/lib -Wl,--export-dynamic  -L/usr/lib64/ 
-Wl,-rpath-link,/osgeo/grass/dist.x86_64-pc-linux-gnu/lib -o 
/osgeo/grass/dist.x86_64-pc-linux-gnu/bin/r.sun OBJ.x86_64-pc-linux-gnu/main.o 
OBJ.x86_64-pc-linux-gnu/rsunlib.o-lgrass_gproj.7.8

Re: [GRASS-user] Failure to compile GRASS GIS 7.8 with Proj 6 and GDAL 3

[Nikos Alexandris]

Markus Metz:


Hi Nikos,

PROJ is moving fast, please use the latest PROJ 6 release 6.3.0

On Sat, Feb 1, 2020 at 8:36 PM Nikos Alexandris 
wrote:


Dears,

I cannot get GRASS GIS 7.8 to compile with
proj
Rel. 6.0.0, March 1st, 2019


if possible, never use a x.0.0 release of any software, these new major
releases are usually full of bugs.

Markus M


Thank you Markus!
I got it working, more or less. Recompiling only PROJ did away most of
the errors but a few. I guess I need to recompile PROJ (+GEOS), then
GDAL, then the rest.

Cheers, Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Failure to compile GRASS GIS 7.8 with Proj 6 and GDAL 3

[Nikos Alexandris]

Dears,

I cannot get GRASS GIS 7.8 to compile with

```
eselect gcc show
x86_64-pc-linux-gnu-9.2.0
```
+
```
make --version
GNU Make 4.2.1
```
+
zlib version 1.2.11-r3
+
```
eselect python show
python3.7
```
+
```
flex --version
flex 2.6.4
```
+
```
proj
Rel. 6.0.0, March 1st, 2019
```
+
```
geos-config --version
3.7.0
```
+
```
gdal-config --version
3.0.4
```
+
```
make distclean
./configure --with-freetype=yes 
--with-freetype-includes="/usr/include/freetype2/" --with-readline --with-geos
make
```

The `error.log` here: https://pastebin.com/rEgMmcPT
Running make from inside few directories with error(s):  
https://pastebin.com/PisKVBHP
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS GIS issues now on GitHub!

[Nikos Alexandris]

Great news.

Nikos


* Markus Neteler  [2020-01-23 21:30:12 +0100]:


*GRASS GIS bug reporting and feature request on GitHub now! *

As it was treated in the last GRASS GIS community sprint
<https://grasswiki.osgeo.org/wiki/Talk:GRASS_GIS_Community_Sprint_Prague_2019>,
and with the aim of keeping
things as simple as possible, we have finally activated the issue tracker
for bug reports
and feature requests in the GRASS GIS GitHub repo
<https://github.com/OSGeo/grass/issues>.

The old good trac <https://trac.osgeo.org/grass/> site still remains active
for tickets that were originally open there. So, if
you have opened a ticket in trac, please either close it and open a new one
in GitHub
referencing the discussion in trac, or just keep it open and comment there.

For *new issues starting today*, please use GitHub
<https://github.com/OSGeo/grass/issues> :)

We'll soon create a template to better follow the different issue types
(bug or enhancement),
topics/tags, operating systems, GRASS GIS versions, etc.



___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user



--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 
___

grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Do not report cells where thousands of maps have no data

[Nikos Alexandris]

GRASS GIS' `r.stats` modules does this:
```
r.stats input=$(g.list rast pattern=cru*.*1 separator=comma) -n -x -N
```

However, it won't do it for thousands of maps. Too many maps will hit
the '[Argument list too long]' error which is triggered by the ARG_MAX
constant.  Is there a work-around?

Else, I see no option but to set on a Python script that will loop over
thousands of maps and will identify pixels for which all maps have a
valid value.  Any recommendations (like best to user xarray or numpy or
rasterio or else...)?

Thank you, Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] tiling and 'cliping' DEMs

[Nikos Alexandris]

* Helmut Kudrnovsky  [2019-09-10 20:12:09 -0700]:


Rich Shepard wrote

I am downloading and importing 1m LiDAR DEMs for a 667 mi^2 (1727.5 km^2)
drainage basin. These are all in 7.5' topographic quad sections. The files
take up a lot of disk space and memory when working with them.

I assume that by careful setting of the region I can display the
individual
maps as a single map, and I can set a computational mask using the vector
basin watershed (boundary). Is there way to 'clip' the DEM using the
watershed map in the way that v.clip works with two vector maps? While the
workstation has 32G RAM and 2T of disk space I would like to limit the DEM
to the drainage basin itself and exclude all areas outside it.

Looking at all the r.* modules in core and extensions none strikes me as
the
appropriate tool.

I'm open to advice on working with huge raster files.

Regards,

Rich
___
grass-user mailing list



grass-user@.osgeo



https://lists.osgeo.org/mailman/listinfo/grass-user


To save diskspace,, build a virtual raster with your tiles outside GRASS  by
GDAL's  buildvrt, do r.external yourvirtual.vrt.

No import is needed for raster calculations, r.external to link the virtual
raster works nicely..


If there is no need for a GDAL VRT, then, alternatively, link all tiles
as pseudo-raster maps in GRASS GIS' data base, of course using
`r.external`. Then, build a GRASS GIS virtual raster data set using
`r.buildvrt`. Clipping or "extracting" parts of this VRT will expectedly
work.

Nikos


regarding to clip a raster to  vector extent, there a several ways. One may
be: g.region  -a raster=yourraster vector=yourvector followed by a r.mask
vector=yourvector then r.mapcal clippedraster=yourraster

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] licensing question: calling GRASS GIS modules via the grass.script API in an MIT/Apache licensed script ?

[Nikos Alexandris]

Maybe useful to know, there is the European Intellectual Property
Helpdesk (www.iprhelpdesk.eu).  However *only* offered to beneficiaries
of EU-funded research projects and EU SMSes involved in transnational
partnership agreements (such as Horizon 2020 projects).

Nikos

* Moritz Lennert  [2019-08-14 08:18:07 +0200]:


Ping.

Anyone ?

Or a pointer to whom I could ask ?

Moritz

On 7/05/19 10:42, Moritz Lennert wrote:

Hi,

We work with a company on a project where we use GRASS GIS to calculate
accessibility indicators. The main output we provide is a Python script
which calls GRASS GIS modules via the grass.script API. The company is
willing to make this script free software, but would like to license it
with a permissive license such as MIT or Apache.

I would think that calling GRASS GIS modules in a script does not
automatically imply the script has to be GPL, but what about the use of
the Python API ?

I would think that this case falls in the grey area described at [1] and
have tendency to think that MIT/Apache license would be allowed.

Does anyone have a more informed opinion ?

Moritz


[1] https://www.gnu.org/licenses/gpl-faq.html#MereAggregation




___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 
___

grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] question on Stray light Landsat 8 data

[Nikos Alexandris]

* Gabriel Cotlier  [2018-08-21 12:00:24 -0300]:


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?


The implemented algorithm (Du, 2015) bases upon the generalized
split-window algorithm proposed by Wan (2014). The 'stray light' issue
is not dealt upfront with this approach.  The 'stray light' issue is
dealt with an algorithmic correction introduced in the Collection 1
products.  And, of course, there might be more questions that relate to
the quality and performance of the algorithm by Du.

Regarding "water bodies", I don't know.



whether band 10 is better than band 11 in terms of correction processing
for Level -1  data products?


Band 10 is the one selected for the single-channel based LST products
that span across all Landsat sensors. See: "Landsat Provisional Surface
Temperature (ST) Digital Object Identification (DOI):
doi.org/10.5066/F7J38RTH".  Band 11 is the one with large calibration
uncertainties.

A good reference is this publication:

Malakar, N. K., Hulley, G. C., Hook, S. J., Laraby, K., Cook, M., &
Schott, J. R. (2018). An Operational Land Surface Temperature Product
for Landsat Thermal Data: Methodology and Validation. IEEE Transactions
on Geoscience and Remote Sensing, (99), 1-19.
http://dx.doi.org/10.1109/TGRS.2018.2824828.

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] turning sqlite journal off

[Nikos Alexandris]

* Markus Metz  [2019-05-15 22:55:13 +0200]:


On Tue, May 14, 2019 at 11:12 AM Panagiotis Mavrogiorgos 
wrote:


Hi Laura,

This thread seems to be related:

http://osgeo-org.1560.x6.nabble.com/SQLITE-db-locking-problem-td5182180.html

I also had a somewhat similar problem that was related to the VACUUM

command issued when closing a GRASS session (new session started before the
VACUUM of the previous session was finished)

If I understand this correctly, you are not supposed to concurrently use

the same sqlite database.

Yes, this is a limitation of sqlite, and the GRASS-internal sqlite driver
has been adapted accordingly as much as possible.


Nevertheless, concurrent reading is allowed.  Reading the discussion so
far, one may think that no concurrent use is possible at all.

See also https://sqlite.org/whentouse.html :

 "SQLite supports an unlimited number of simultaneous readers, but it
 will only allow one writer at any instant in time."

And in https://sqlite.org/lockingv3.html see 'SHARED'.
Also, https://stackoverflow.com/a/4060838/1172302.

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] Nice opportunity to show off GRASS functionality and topological vector format ?

[Nikos Alexandris]

* Nikos Alexandris  [2019-04-19 13:46:18 +0200]:


* Markus Metz  [2019-04-18 18:38:28 +0200]:


On Tue, Apr 16, 2019 at 11:07 AM Moritz Lennert <
mlenn...@club.worldonline.be> wrote:


Hi,

If anyone has some time and wants to show off some GRASS GIS power:

https://www.ecmwf.int/en/learning/workshops/ecmwf-summer-weather-code-2019

"The Summer of Weather Code(ESoWC) programme by the European Centre for
Medium-Range Weather Forecasts (ECMWF) is a collabrative online
programme to promote the development of weather-related open-source
software."

More specificially:

https://github.com/esowc/challenges_2019

And even more, I think this challenge is a fairly low hanging fruit
using GRASS GIS tools:

https://github.com/esowc/challenges_2019/issues/3


I agree, this reads like a low-hanging fruit. I could submit an abstract
until Sunday 21 April with a fairly detailed workflow, but I will most
probably not have the time to write such a tool: apparently they would like
to have a custom QGIS plugin.


Panos literally implemented Nyal Dawson's excellent recommendation(s)
[0, 1, 2] and exposing a GRASS GIS module/add-on is easy. An example is
the QGIS plugin [3] for the `r.estimap.recreation` plugin [4].

[0] https://lists.osgeo.org/pipermail/qgis-developer/2019-February/056155.html
[1] https://lists.osgeo.org/pipermail/qgis-developer/2019-February/056285.html
[2] https://github.com/qgis/QGIS/pull/9202
[3] https://gitlab.com/natcapes/natcapes_qgis
[4] https://gitlab.com/natcapes/r.estimap.recreation

This makes the process as easy as never before, as far as I understand.
In my humble view, this should be further adopted and advertised.

On/Off-topic (Cc-ing also the qgis-developer mailing list):

I left from the `r.estimap.recreation` project leaving behind one
remaining issue-to-solve: https://issues.qgis.org/issues/21322.

This issue concerns only the interface and does not affect the
core work of exposing a GRASS GIS add-on inside QGIS' Processing
Framework. Nevertheless, in my humble view, this issue is important to
the GRASS GIS community and having an up-to-date documentation will save
our time from figuring out how the interface related api works.


And here an entry in gis.se:
https://gis.stackexchange.com/a/319333/5256.

Nikos



Markus M



APPLICATION DEADLINE: SUNDAY, 21 APRIL 23:59 GMT


Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user



___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user



--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 
___

grass-dev mailing list
grass-...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 
___

grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Nice opportunity to show off GRASS functionality and topological vector format ?

[Nikos Alexandris]

* Markus Metz  [2019-04-18 18:38:28 +0200]:


On Tue, Apr 16, 2019 at 11:07 AM Moritz Lennert <
mlenn...@club.worldonline.be> wrote:


Hi,

If anyone has some time and wants to show off some GRASS GIS power:

https://www.ecmwf.int/en/learning/workshops/ecmwf-summer-weather-code-2019

"The Summer of Weather Code(ESoWC) programme by the European Centre for
Medium-Range Weather Forecasts (ECMWF) is a collabrative online
programme to promote the development of weather-related open-source
software."

More specificially:

https://github.com/esowc/challenges_2019

And even more, I think this challenge is a fairly low hanging fruit
using GRASS GIS tools:

https://github.com/esowc/challenges_2019/issues/3


I agree, this reads like a low-hanging fruit. I could submit an abstract
until Sunday 21 April with a fairly detailed workflow, but I will most
probably not have the time to write such a tool: apparently they would like
to have a custom QGIS plugin.


Panos literally implemented Nyal Dawson's excellent recommendation(s)
[0, 1, 2] and exposing a GRASS GIS module/add-on is easy. An example is
the QGIS plugin [3] for the `r.estimap.recreation` plugin [4].

[0] https://lists.osgeo.org/pipermail/qgis-developer/2019-February/056155.html
[1] https://lists.osgeo.org/pipermail/qgis-developer/2019-February/056285.html
[2] https://github.com/qgis/QGIS/pull/9202
[3] https://gitlab.com/natcapes/natcapes_qgis
[4] https://gitlab.com/natcapes/r.estimap.recreation

This makes the process as easy as never before, as far as I understand.
In my humble view, this should be further adopted and advertised.

On/Off-topic (Cc-ing also the qgis-developer mailing list):

I left from the `r.estimap.recreation` project leaving behind one
remaining issue-to-solve: https://issues.qgis.org/issues/21322.

This issue concerns only the interface and does not affect the
core work of exposing a GRASS GIS add-on inside QGIS' Processing
Framework. Nevertheless, in my humble view, this issue is important to
the GRASS GIS community and having an up-to-date documentation will save
our time from figuring out how the interface related api works.

Nikos



Markus M



APPLICATION DEADLINE: SUNDAY, 21 APRIL 23:59 GMT


Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user



___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user



--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 
___

grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] raster pixel value

[Nikos Alexandris]

* Nikos Alexandris  [2019-03-14 17:57:16 +0100]:


* Markus Metz  [2019-03-14 17:07:49 +0100]:


On Thu, Mar 14, 2019 at 3:16 PM Nikos Alexandris 
wrote:


Following up, why are there differences between GDAL and GRASS GIS in
the following example?

This ftp://ftp.soilgrids.org/data/aggregated/5km/OCDENS_M_sl1_5km_ll.tif
raster map, subject to `gdalinfo`:
```
gdalinfo OCDENS_M_sl1_5km_ll.tif -nogcp -nomd -norat -noct -nofl
Driver: GTiff/GeoTIFF
Files: OCDENS_M_sl1_5km_ll.tif
Size is 7200, 2987
Coordinate System is:
GEOGCS["WGS 84",
   DATUM["WGS_1984",
   SPHEROID["WGS 84",6378137,298.257223563,
   AUTHORITY["EPSG","7030"]],
   AUTHORITY["EPSG","6326"]],
   PRIMEM["Greenwich",0],
   UNIT["degree",0.0174532925199433],
   AUTHORITY["EPSG","4326"]]
Origin = (-180.000,87.375)
Pixel Size = (0.050,-0.050)
Corner Coordinates:
Upper Left  (-180.000,  87.370) (180d 0' 0.00"W, 87d22'12.00"N)
Lower Left  (-180.000, -61.980) (180d 0' 0.00"W, 61d58'48.00"S)
Upper Right ( 180.000,  87.370) (180d 0' 0.00"E, 87d22'12.00"N)
Lower Right ( 180.000, -61.980) (180d 0' 0.00"E, 61d58'48.00"S)
Center  (   0.000,  12.695) (  0d 0' 0.00"E, 12d41'42.00"N)
Band 1 Block=7200x1 Type=Int16, ColorInterp=Gray
 NoData Value=-32768
```

and GRASS GIS
```
# create a new Location
grass -c OCDENS_M_sl1_5km_ll.tif /geoyeux/grassdb/global/soil_grids/

# projection info
g.proj -g

name=WGS 84
datum=wgs84
ellps=wgs84
proj=ll
no_defs=defined
epsg=4326
unit=degree
units=degrees
meters=1.0

# raster info
r.info -g OCDENS_M_sl1_5km_ll

north=87.37
south=-61.98
east=180
west=-180
nsres=0.05
ewres=0.05
rows=2987
cols=7200
cells=21506400
datatype=CELL
ncats=0

# report non-NULL cells and their x, y grid location
r.stats OCDENS_M_sl1_5km_ll -n -x > stats_x
```

Comparing a few single pixels via:
```
while read LINE;do
   set -- $LINE
   echo " ($1,$2)
   echo "GDAL:  $(gdallocationinfo -valonly OCDENS_M_sl1_5km_ll.tif $1

$2)"

   echo "GRASS: $3"
   echo
done < stats_x_head
```

gives
```
(2930,77)
GDAL:  2090
GRASS: 2096

(2931,77)
GDAL:  2055
GRASS: 2090

(2932,77)
GDAL:  2063
GRASS: 2055

(2933,77)
GDAL:  2093
GRASS: 2063

(2934,77)
GDAL:  2240
GRASS: 2093

(2935,77)
GDAL:  2332
GRASS: 2240

(2936,77)
GDAL:  2296
GRASS: 2332

(2937,77)
GDAL:  2253
GRASS: 2296

(2938,77)
GDAL:  2179
GRASS: 2253

(2939,77)
GDAL:  2115
GRASS: 2179
```

Why these differences?


With r.stats -x, indexing starts with 1 (first row is 1).
With gdallocationinfo, indexing starts with 0 (first row is 0).


Updated:
```
while read LINE ;do
  set -- ${LINE}
  echo " ($1,$2)"
  echo "GDAL:  $(gdallocationinfo -valonly OCDENS_M_sl1_5km_ll.tif $(echo $1 - 1 
|bc) $(echo $2 - 1 |bc))"
  echo "GRASS: ${3}"
  echo
done < stats_x_head
```


For the sake of clarity, since the file `stats_x_head` is a GRASS GIS
output, where indexing starts from 1:
```
while read LINE ;do
   set -- ${LINE}
   ROW=$(echo $1 -1 |bc)
   COLUMN=$(echo $2 - 1 |bc)
   echo "GDAL  ($ROW, $COLUMN): $(gdallocationinfo -valonly OCDENS_M_sl1_5km_ll.tif 
$ROW $COLUMN)"
   echo "GRASS ($1, $2): ${3}"
   echo
done < stats_x_head
```

will return
```

GDAL  (2929, 76): 2096
GRASS (2930, 77): 2096

GDAL  (2930, 76): 2090
GRASS (2931, 77): 2090

GDAL  (2931, 76): 2055
GRASS (2932, 77): 2055

GDAL  (2932, 76): 2063
GRASS (2933, 77): 2063

GDAL  (2933, 76): 2093
GRASS (2934, 77): 2093

GDAL  (2934, 76): 2240
GRASS (2935, 77): 2240

GDAL  (2935, 76): 2332
GRASS (2936, 77): 2332

GDAL  (2936, 76): 2296
GRASS (2937, 77): 2296

GDAL  (2937, 76): 2253
GRASS (2938, 77): 2253

GDAL  (2938, 76): 2179
GRASS (2939, 77): 2179
```

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] raster pixel value

[Nikos Alexandris]

* Markus Metz  [2019-03-15 22:16:17 +0100]:


On Thu, Mar 14, 2019 at 11:31 PM Nikos Alexandris 
wrote:


Markus Metz:

>>With r.stats -x, indexing starts with 1 (first row is 1).
>>With gdallocationinfo, indexing starts with 0 (first row is 0).

I wonder if `-0` flag would make sense to be GDAL-compliant.


Note that the internal variables row() and col() of r.mapcalc also use
indices starting with 1. As long as the indexing is properly documented, I
don't see a problem. The r.stats manuals have been updated in trunk r74267
and relbr76 r74268. Maybe a PR for the documentation of gdallocationinfo is
needed?


I did search already the GDAL documentation, and the manual for
`gdallocationinfo`. On and off, the "C-style indexing starts at 0" is
mentioned here and there.  A clear entry on this in `gdallocationinfo`'s
manual will be purposive.

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] raster pixel value

[Nikos Alexandris]

Markus Metz:


With r.stats -x, indexing starts with 1 (first row is 1).
With gdallocationinfo, indexing starts with 0 (first row is 0).


I wonder if `-0` flag would make sense to be GDAL-compliant.
I created a Pull Request (in `grass-ci`) for a minor update in the manual.

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] raster pixel value

[Nikos Alexandris]

Francois Chartier:


I am asking a question on the fundamentals not on a particular example on
how the value within a raster cell is determined when multiple vector data
points are located within a raster cell footprint.
I use RST mostly and sometimes IDW for vector data points.


Nikos Alexandris:


Then, from https://grass.osgeo.org/grass76/manuals/rasterintro.html:

"Raster input maps are automatically cropped/padded and rescaled (using
nearest-neighbour resampling) to match the current region."


[..]

Here a visual example using this
ftp://ftp.soilgrids.org/data/aggregated/5km/OCDENS_M_sl1_5km_ll.tif
raster map in a GRASS GIS Location:
```
grass -c OCDENS_M_sl1_5km_ll.tif /geoyeux/grassdb/global/soil_grids/
r.in.gdal input=OCDENS_M_sl1_5km_ll.tif output=OCDENS_M_sl1_5km_ll
```

Select a random point and grow over it a 10^2 box
```
center_n=37.176279; center_e=22.839542 ;offset=0.25
g.region -g \
 e=$(echo $center_e + $offset |bc) \
 w=$(echo $center_e - $offset |bc) \
 s=$(echo $center_n - $offset |bc) \
 n=$(echo $center_n + $offset |bc) \
 res=0.05

projection=3
zone=0
n=37.426279
s=36.926279
w=22.589542
e=23.089542
nsres=0.05
ewres=0.05
rows=10
cols=10
cells=100
```

Clean file receiving the rendering, then draw the map’s cell values
```
d.erase
d.rast.num OCDENS_M_sl1_5km_ll@PERMANENT text_color=red grid_color=gray
```
Here https://i.imgur.com/2L9dWgX.png red are the original values.

Upscale
```
g.region -g res=0.1

projection=3
zone=0
n=37.426279
s=36.926279
w=22.589542
e=23.089542
nsres=0.1
ewres=0.1
rows=5
cols=5
cells=25
```

And over-draw the "new" map
```
d.rast.num OCDENS_M_sl1_5km_ll@PERMANENT text_color=blue grid_color=blue
```
Here https://i.imgur.com/bYgH6io.png blue are the resampled values.

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] raster pixel value

[Nikos Alexandris]

* Markus Metz  [2019-03-14 17:07:49 +0100]:


On Thu, Mar 14, 2019 at 3:16 PM Nikos Alexandris 
wrote:


Following up, why are there differences between GDAL and GRASS GIS in
the following example?

This ftp://ftp.soilgrids.org/data/aggregated/5km/OCDENS_M_sl1_5km_ll.tif
raster map, subject to `gdalinfo`:
```
gdalinfo OCDENS_M_sl1_5km_ll.tif -nogcp -nomd -norat -noct -nofl
Driver: GTiff/GeoTIFF
Files: OCDENS_M_sl1_5km_ll.tif
Size is 7200, 2987
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]]
Origin = (-180.000,87.375)
Pixel Size = (0.050,-0.050)
Corner Coordinates:
Upper Left  (-180.000,  87.370) (180d 0' 0.00"W, 87d22'12.00"N)
Lower Left  (-180.000, -61.980) (180d 0' 0.00"W, 61d58'48.00"S)
Upper Right ( 180.000,  87.370) (180d 0' 0.00"E, 87d22'12.00"N)
Lower Right ( 180.000, -61.980) (180d 0' 0.00"E, 61d58'48.00"S)
Center  (   0.000,  12.695) (  0d 0' 0.00"E, 12d41'42.00"N)
Band 1 Block=7200x1 Type=Int16, ColorInterp=Gray
  NoData Value=-32768
```

and GRASS GIS
```
# create a new Location
grass -c OCDENS_M_sl1_5km_ll.tif /geoyeux/grassdb/global/soil_grids/

# projection info
g.proj -g

name=WGS 84
datum=wgs84
ellps=wgs84
proj=ll
no_defs=defined
epsg=4326
unit=degree
units=degrees
meters=1.0

# raster info
r.info -g OCDENS_M_sl1_5km_ll

north=87.37
south=-61.98
east=180
west=-180
nsres=0.05
ewres=0.05
rows=2987
cols=7200
cells=21506400
datatype=CELL
ncats=0

# report non-NULL cells and their x, y grid location
r.stats OCDENS_M_sl1_5km_ll -n -x > stats_x
```

Comparing a few single pixels via:
```
while read LINE;do
set -- $LINE
echo " ($1,$2)
echo "GDAL:  $(gdallocationinfo -valonly OCDENS_M_sl1_5km_ll.tif $1

$2)"

echo "GRASS: $3"
echo
done < stats_x_head
```

gives
```
 (2930,77)
GDAL:  2090
GRASS: 2096

 (2931,77)
GDAL:  2055
GRASS: 2090

 (2932,77)
GDAL:  2063
GRASS: 2055

 (2933,77)
GDAL:  2093
GRASS: 2063

 (2934,77)
GDAL:  2240
GRASS: 2093

 (2935,77)
GDAL:  2332
GRASS: 2240

 (2936,77)
GDAL:  2296
GRASS: 2332

 (2937,77)
GDAL:  2253
GRASS: 2296

 (2938,77)
GDAL:  2179
GRASS: 2253

 (2939,77)
GDAL:  2115
GRASS: 2179
```

Why these differences?


With r.stats -x, indexing starts with 1 (first row is 1).
With gdallocationinfo, indexing starts with 0 (first row is 0).


Updated:
```
while read LINE ;do
   set -- ${LINE}
   echo " ($1,$2)"
   echo "GDAL:  $(gdallocationinfo -valonly OCDENS_M_sl1_5km_ll.tif $(echo $1 - 1 
|bc) $(echo $2 - 1 |bc))"
   echo "GRASS: ${3}"
   echo
done < stats_x_head
```

which gives
```
(2930,77)
GDAL:  2096
GRASS: 2096

(2931,77)
GDAL:  2090
GRASS: 2090

(2932,77)
GDAL:  2055
GRASS: 2055

(2933,77)
GDAL:  2063
GRASS: 2063

(2934,77)
GDAL:  2093
GRASS: 2093

(2935,77)
GDAL:  2240
GRASS: 2240

(2936,77)
GDAL:  2332
GRASS: 2332

(2937,77)
GDAL:  2296
GRASS: 2296

(2938,77)
GDAL:  2253
GRASS: 2253

(2939,77)
GDAL:  2179
GRASS: 2179
```
Danke Markus!



Markus M


Nikos


# meta

GRASS 7.7.svn (2019)
libgis Revision: 74118
libgis Date: 2019-02-21 10:38:28 +0100 (Thu, 21 Feb 2019)

GDAL 2.3.1, released 2018/06/22
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 
___

grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] raster pixel value

[Nikos Alexandris]

* Nikos Alexandris  [2019-03-14 15:11:51 +0100]:


Following up, why are there differences between GDAL and GRASS GIS in
the following example?

This ftp://ftp.soilgrids.org/data/aggregated/5km/OCDENS_M_sl1_5km_ll.tif
raster map, subject to `gdalinfo`:
```
gdalinfo OCDENS_M_sl1_5km_ll.tif -nogcp -nomd -norat -noct -nofl
Driver: GTiff/GeoTIFF
Files: OCDENS_M_sl1_5km_ll.tif
Size is 7200, 2987
Coordinate System is:
GEOGCS["WGS 84",
  DATUM["WGS_1984",
  SPHEROID["WGS 84",6378137,298.257223563,
  AUTHORITY["EPSG","7030"]],
  AUTHORITY["EPSG","6326"]],
  PRIMEM["Greenwich",0],
  UNIT["degree",0.0174532925199433],
  AUTHORITY["EPSG","4326"]]
Origin = (-180.000,87.375)
Pixel Size = (0.050,-0.050)
Corner Coordinates:
Upper Left  (-180.000,  87.370) (180d 0' 0.00"W, 87d22'12.00"N)
Lower Left  (-180.000, -61.980) (180d 0' 0.00"W, 61d58'48.00"S)
Upper Right ( 180.000,  87.370) (180d 0' 0.00"E, 87d22'12.00"N)
Lower Right ( 180.000, -61.980) (180d 0' 0.00"E, 61d58'48.00"S)
Center  (   0.000,  12.695) (  0d 0' 0.00"E, 12d41'42.00"N)
Band 1 Block=7200x1 Type=Int16, ColorInterp=Gray
NoData Value=-32768
```

and GRASS GIS
```
# create a new Location
grass -c OCDENS_M_sl1_5km_ll.tif /geoyeux/grassdb/global/soil_grids/



# projection info
g.proj -g



name=WGS 84
datum=wgs84
ellps=wgs84
proj=ll
no_defs=defined
epsg=4326
unit=degree
units=degrees
meters=1.0


Something I did do, but forgot to copy-paste here:
```
g.region raster=OCDENS_M_sl1_5km_ll -g

projection=3
zone=0
n=87.37
s=-61.98
w=-180
e=180
nsres=0.05
ewres=0.05
rows=2987
cols=7200
cells=21506400
```

Nikos


# raster info
r.info -g OCDENS_M_sl1_5km_ll

north=87.37
south=-61.98
east=180
west=-180
nsres=0.05
ewres=0.05
rows=2987
cols=7200
cells=21506400
datatype=CELL
ncats=0


[rest deleted]
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] raster pixel value

[Nikos Alexandris]

Following up, why are there differences between GDAL and GRASS GIS in
the following example?

This ftp://ftp.soilgrids.org/data/aggregated/5km/OCDENS_M_sl1_5km_ll.tif
raster map, subject to `gdalinfo`:
```
gdalinfo OCDENS_M_sl1_5km_ll.tif -nogcp -nomd -norat -noct -nofl
Driver: GTiff/GeoTIFF
Files: OCDENS_M_sl1_5km_ll.tif
Size is 7200, 2987
Coordinate System is:
GEOGCS["WGS 84",
   DATUM["WGS_1984",
   SPHEROID["WGS 84",6378137,298.257223563,
   AUTHORITY["EPSG","7030"]],
   AUTHORITY["EPSG","6326"]],
   PRIMEM["Greenwich",0],
   UNIT["degree",0.0174532925199433],
   AUTHORITY["EPSG","4326"]]
Origin = (-180.000,87.375)
Pixel Size = (0.050,-0.050)
Corner Coordinates:
Upper Left  (-180.000,  87.370) (180d 0' 0.00"W, 87d22'12.00"N)
Lower Left  (-180.000, -61.980) (180d 0' 0.00"W, 61d58'48.00"S)
Upper Right ( 180.000,  87.370) (180d 0' 0.00"E, 87d22'12.00"N)
Lower Right ( 180.000, -61.980) (180d 0' 0.00"E, 61d58'48.00"S)
Center  (   0.000,  12.695) (  0d 0' 0.00"E, 12d41'42.00"N)
Band 1 Block=7200x1 Type=Int16, ColorInterp=Gray
 NoData Value=-32768
```

and GRASS GIS
```
# create a new Location
grass -c OCDENS_M_sl1_5km_ll.tif /geoyeux/grassdb/global/soil_grids/

# projection info
g.proj -g

name=WGS 84
datum=wgs84
ellps=wgs84
proj=ll
no_defs=defined
epsg=4326
unit=degree
units=degrees
meters=1.0

# raster info
r.info -g OCDENS_M_sl1_5km_ll

north=87.37
south=-61.98
east=180
west=-180
nsres=0.05
ewres=0.05
rows=2987
cols=7200
cells=21506400
datatype=CELL
ncats=0

# report non-NULL cells and their x, y grid location
r.stats OCDENS_M_sl1_5km_ll -n -x > stats_x
```

Comparing a few single pixels via:
```
while read LINE;do
   set -- $LINE
   echo " ($1,$2)
   echo "GDAL:  $(gdallocationinfo -valonly OCDENS_M_sl1_5km_ll.tif $1 $2)"
   echo "GRASS: $3"
   echo
done < stats_x_head
```

gives
```
(2930,77)
GDAL:  2090
GRASS: 2096

(2931,77)
GDAL:  2055
GRASS: 2090

(2932,77)
GDAL:  2063
GRASS: 2055

(2933,77)
GDAL:  2093
GRASS: 2063

(2934,77)
GDAL:  2240
GRASS: 2093

(2935,77)
GDAL:  2332
GRASS: 2240

(2936,77)
GDAL:  2296
GRASS: 2332

(2937,77)
GDAL:  2253
GRASS: 2296

(2938,77)
GDAL:  2179
GRASS: 2253

(2939,77)
GDAL:  2115
GRASS: 2179
```

Why these differences?

Nikos


# meta

GRASS 7.7.svn (2019)
libgis Revision: 74118
libgis Date: 2019-02-21 10:38:28 +0100 (Thu, 21 Feb 2019)

GDAL 2.3.1, released 2018/06/22
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] raster pixel value

[Nikos Alexandris]

* Francois Chartier  [2019-03-10 10:56:40 -0400]:


I am asking a question on the fundamentals not on a particular example on
how the value within a raster cell is determined when multiple vector data
points are located within a raster cell footprint.
I use RST mostly and sometimes IDW for vector data points.


Then, from https://grass.osgeo.org/grass76/manuals/rasterintro.html:

"Raster input maps are automatically cropped/padded and rescaled (using
nearest-neighbour resampling) to match the current region."

and

"GRASS raster map processing is always performed in the current region
settings (see g.region), i.e. the current region extent and current
raster resolution is used. If the resolution differs from that of the
input raster map(s), on-the-fly resampling is performed (nearest
neighbor resampling). If this is not desired, the input map(s) has/have
to be resampled beforehand with one of the dedicated modules.

The built-in nearest-neighbour resampling of raster data calculates the
centre of each region cell, and takes the value of the raster cell in
which that point falls.

If the point falls exactly upon a grid line, the exact result will be
determined by the direction of any rounding error. One consequence of
this is that downsampling by a factor which is an even integer will
always sample exactly on the boundary between cells, meaning that the
result is ill-defined."

Likely there is more on the subject.

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] raster pixel value

[Nikos Alexandris]

* Francois Chartier  [2019-03-10 09:38:13 -0400]:


Hi

i was wondering how the value of a pixel is determined when multiple data
points are located within a pixel, for 2d and 3d pixel.  I assume it is
based on the interpolation methodology of the raster. is this correct.
for large pixels where only data point is located within it, can the pixel
have a different value than that of the data point if through the
interpolation and due to surrounding points it generates a different value?
thks


Dear Francois,

your questions are a bit sketchy. What exactly are trying to do?

How the value of a pixel is determined when multiple data points are
located within a pixel?

Which multiple data points are you referring to?

Multiple raster data cells, which you get when you modify the
computational region (i.e. when you go from a given spatial resolution
to a coarser one)?
Did you try to resample a raster data set and wonder how the new cell's
value is computed? Which module did you try to use? Which methods?

Vector data points? Which interpolation module did you try?

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.width.funct in correct version

[Nikos Alexandris]

* Juan Lopez  [2019-02-20 06:20:48 -0400]:


I have found a discussion about r.width.funct in this list, but I am
not sure about the meaning of the final comment in order to solve the
problem.


Discussion is in this link

https://www.mail-archive.com/grass-user@lists.osgeo.org/msg37141.html

Bartolomei Chris and Markus Neteler says that it is already fixed.


I am trying to understand their comments.  I have exactly the same
problem.  r.width.fucnt is not working.


What I did:


  - I have Linux Mint 19.1 Cinnamon, based on Ubuntu Bionic.
  - Installed standard Grass 7.4.0 from Ubuntu repositories.
  - Applied r.width.funct and failed.
  - Removed this version and added new repository, recomended by
https://grass.osgeo.org/news/78/15/GRASS-GIS-7-4-2-released
  - System got updated and new version came to linux.
  - Installed  Grass 7.6.0 (new stable) from ppa:ubuntugis/ubuntugis-unstable
  - Problem remains the same.
  - Reinstalled  r.width.funct and failed.
  - Replaced script in  r.width.funct for the one presented in this
tread (https://www.mail-archive.com/grass-user@lists.osgeo.org/msg37141.html)
and failed.

I would like to keep the original standard repositories in order to
let administrative maintenance tasks as simple as possible.

Did I missed something to solve the problem?


Installation via g.extension fails here too:

```
→ g.version -r
GRASS 7.7.svn (2019)
libgis Revision: 73998
libgis Date: 2019-01-22 12:04:06 +0100 (Tue, 22 Jan 2019)
```
and
```
→ g.extension r.width.funct
Fetching  from GRASS GIS Addons repository (be patient)...
Compiling...
Traceback (most recent call last):
 File "/tmp/grass7-nik-25324/tmpnmZ2V7/r.width.funct/scripts/r.width.funct", line 45, 
in 
   import matplotlib #required by windows
ImportError: No module named matplotlib
make: *** 
[/osgeo/grasstrunk/dist.x86_64-pc-linux-gnu/include/Make/Html.make:14: 
r.width.funct.tmp.html] Error 1
ERROR: Compilation failed, sorry. Please check above error messages.
```

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Flood Forecasting Tool

[Nikos Alexandris]

Mehrdad Varedi wrote:


Hello dear Grassians!
I want to forecast flood around a river. I would like to know what is the
best tool in GRASS or applications based on GRASS to do this.


http://www.itzi.org/ is built on top of GRASS GIS. No idea if "around a
river" is out the tool's scope.

It is impressive: https://www.itzi.org/about/applications/.

Nikos


The best case >scenario is to have a system that could connect to a
weather service for >live forecasting. Is it a possibility?

Thanks for your help.

Mehrdad

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] High tension with r.resamp.rst

[Nikos Alexandris]

* Ghislain Vieilledent | CIRAD  [2019-02-06 
14:11:04 +0100]:


Dear GRASS GIS user,

I am using r.resamp.rst to interpolate climatic data at 30sec 
resolution over Africa.


Grass script, data, and results are available here:
https://nextcloud.fraisedesbois.net/index.php/s/CKzsZCSCqMTY9rq

#===

# Import Africa shapefile
v.in.ogr --overwrite input=gisdata/vectors/Africa layer=Africa output=Africa

# Rasterize Africa at 30 arc-sec resolution
g.region -ap vector=Africa res=0:00:30
v.to.rast input=Africa type=area output=Africa use=val value=1

# Import climate
r.in.gdal --overwrite input=gisdata/rasters/test1.1_044.tif output=test1_1

# Resample with RST
g.region -ap raster=test1_1
# Note: use maskmap=Africa to save computation time
r.resamp.rst --overwrite input=test1_1 elevation=test1_1_rst \\
ew_res=0.00833 ns_res=0.00833 maskmap=Africa
r.info test1_1_rst

# Resample to exact resolution 0:00:30
g.region -ap res=0:00:30
r.resample --overwrite input=test1_1_rst output=test1_1_30s

# Export
r.out.gdal --overwrite input=test1_1_30s \\
output=output/test1_1_30s.tif type=Float32 \\
createopt='compress=lzw,predictor=2'

#===

When I use r.info on the interpolated raster, it indicates a tension 
of 7278 in the comments which seems very high to me as the default 
value is 40.


|   Comments:
|tension=7278.552524
|dnorm=5.495598, zmult=1.00
|KMAX=50, KMIN=35, errtotal=0.000535
|zmin_data=0.056488, zmax_data=3.756866
|zmin_int=-0.066779, zmax_int=3.214336

On the other side, results do not look so bad (see test.pdf figure).


I am following this thread out of curiosity/interest on resampling.  The
.pdf file is not attached.  How big is it?

Nikos


Would you have any comment on this high value for the tension and do 
you think interpolation has been performed correctly ?


Best regards,

Ghislain

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Upscaling an elevation model

[Nikos Alexandris]

* Helmut Kudrnovsky  [2019-02-02 08:17:03 -0700]:


NikosAlexandris wrote

Dear "elevation" experts,

I am looking for ways to upscale a 5m resolution elevation model.  The
upscaled models will be subjected to a series of trials using
`r.watershed`.  Derivative products will be inputs for soil erosion
modelling.

In our wiki page about Interpolation [0], `r.resamp.stats` [1] is
presented as the only tool to resample a raster map to a coarser grid.
However, `r.resamp.rst` [2] also performs resampling to a lower
resolution.

[0] https://grasswiki.osgeo.org/wiki/Interpolation
[1] https://grass.osgeo.org/grass76/manuals/r.resamp.stats.html
[2] https://grass.osgeo.org/grass76/manuals/r.resamp.rst.html

While the target is to somewhat maintain "geomorphometric consistency"
across the different (coarser) scales, which tool is recommended?
For `r.resamp.stats`, would you recommend a resampling method other than
'average'?

Thank you, Nikos
___
grass-user mailing list



grass-user@.osgeo



https://lists.osgeo.org/mailman/listinfo/grass-user


you can see

https://grass.osgeo.org/grass74/manuals/addons/r.valley.bottom.html

"[]The MRVBF index assesses the flatness and lowness of terrain over
multiple scales and DEM resolutions[...]"

how it's there.


Ahoy Helmut,

resampling takes place through the helper function `refine()` [0]. Then,
if I understand it right, you use 'average' (for `r.resamp.stats`) only when
upscaling [1].

[0] 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.valley.bottom/r.valley.bottom.py#L391
[1] 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.valley.bottom/r.valley.bottom.py#L595.

You use 'bilinear' when downscaling (the slope and the "percentile" that
is), right? [2, 3]. The "percentile" (number of lower elevation points /
total number of points in surrounding region), is part of the algorithm.

[2] 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.valley.bottom/r.valley.bottom.py#L591
[3] 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.valley.bottom/r.valley.bottom.py#L601

Can we use this tool to say "look, our resampled elevation maps are
similar"?  But then, I'd need to run this for each resampled map and
compare the outputs (say MRVBF or/and MRRTF)?

Or is it simpler what you suggest?

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] How to generate a vector graphics file from GRASS CLI?

[Nikos Alexandris]

* Ken Mankoff  [2019-02-02 13:51:43 +0100]:



On 2019-02-02 at 11:51 +0100, Ken Mankoff  wrote...

One more ps.map question. What is the best/easiest method to patch
together multiple rasters with different colors?


From https://grasswiki.osgeo.org/wiki/Ps.map_scripts

"""If you want to show two or more overlapping raster maps you need to combine them with the 
r.patch module or r.mapcalc's '#' color operator. (see also the r.his and r.composite 
modules)"""

 -k.


Ken, there is also https://grass.osgeo.org/grass77/manuals/r.blend.html.

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Upscaling an elevation model

[Nikos Alexandris]

Dear "elevation" experts,

I am looking for ways to upscale a 5m resolution elevation model.  The
upscaled models will be subjected to a series of trials using
`r.watershed`.  Derivative products will be inputs for soil erosion modelling.

In our wiki page about Interpolation [0], `r.resamp.stats` [1] is
presented as the only tool to resample a raster map to a coarser grid.
However, `r.resamp.rst` [2] also performs resampling to a lower
resolution.

[0] https://grasswiki.osgeo.org/wiki/Interpolation
[1] https://grass.osgeo.org/grass76/manuals/r.resamp.stats.html
[2] https://grass.osgeo.org/grass76/manuals/r.resamp.rst.html

While the target is to somewhat maintain "geomorphometric consistency"
across the different (coarser) scales, which tool is recommended?
For `r.resamp.stats`, would you recommend a resampling method other than
'average'?

Thank you, Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] How to generate a vector graphics file from GRASS CLI?

[Nikos Alexandris]

* Ken Mankoff  [2019-01-29 08:43:56 +0100]:


Hi,

I'm trying to generate a vector graphics file (PDF, but EPS or PS is fine) from the GRASS 
CLI. I'd like to have both raster and vector output. When I follow the simple examples 
from PSDRIVER or CAIRO the result is always the same - only the last graphic appears. It 
is as though there is a "d.erase" between every command.

From https://grass.osgeo.org/grass76/manuals/psdriver.html

export GRASS_RENDER_IMMEDIATE=ps
export GRASS_RENDER_TRUECOLOR=TRUE
g.region raster=elevation
d.rast elevation
d.vect roadsmajor color=red

Only shows roads, no elevation.


Same here, with a different raster and vector map. Drawing my raster
map gives a 48M file. Then, drawing my vector map ends up with a 1.18M
file.

Nikos

[rest deleted]
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Overlapping pixels among DEM tiles to compute the LS factor for RUSLE

[Nikos Alexandris]

* Nikos Alexandris  [2019-01-26 00:13:38 +0100]:


* Ken Mankoff  [2019-01-25 11:50:29 -0800]:


Hi Nikos,

On 2019-01-25 at 07:18 -0800, Nikos Alexandris  
wrote...

A billion-pixel scaled DEM is the main input to compute the slope length
and steepness (LS) factor for RUSLE (`r.watershed`), only.

Tiling this DEM in tiles of 5K^2 pixels (`r.tile`), appears to be a
reasonable approach to parallelise this process.


As I learn more, it seems that it's completely wrong to tile this in
squares and that catchment/basin borders need to be essentially
respected.



Do you need to parallelise it? I just ran r.watershed on a 4.5 billion-pixel 
DEM w/o a problem on my laptop and I think it took ~6 hours, but I'm not sure. 
It might have been closer to 12. I have 32 GB of ram and gave half to the 
process, but told it to use disk instead of memory via the -m flag:

r.watershed -s -m elevation=phi threshold=100 drainage=dir memory=16384 --v 
--o


I just launched an all-in-one go, ~9e8 pixels finally. RAM is not an
issue here. Let's see the timing.


So, it worked out in 40 minutes! 


If I recall correctly, my initial attempt on my laptop (with 8GM of RAM
and without checking further options to use other available space)
wouldn't start the process.  And I rushed over to read something like
896000 instead of 89600. I am happy to have it done in 40
minutes now as well as mis-reading the number of pixels and having read
now a few things more on the subject.  "We" also have this related
tutorial:
https://ncsu-geoforall-lab.github.io/erosion-modeling-tutorial/index.html

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Overlapping pixels among DEM tiles to compute the LS factor for RUSLE

[Nikos Alexandris]

* Ken Mankoff  [2019-01-25 11:50:29 -0800]:


Hi Nikos,

On 2019-01-25 at 07:18 -0800, Nikos Alexandris  
wrote...

A billion-pixel scaled DEM is the main input to compute the slope length
and steepness (LS) factor for RUSLE (`r.watershed`), only.

Tiling this DEM in tiles of 5K^2 pixels (`r.tile`), appears to be a
reasonable approach to parallelise this process.


As I learn more, it seems that it's completely wrong to tile this in
squares and that catchment/basin borders need to be essentially
respected.



Do you need to parallelise it? I just ran r.watershed on a 4.5 billion-pixel 
DEM w/o a problem on my laptop and I think it took ~6 hours, but I'm not sure. 
It might have been closer to 12. I have 32 GB of ram and gave half to the 
process, but told it to use disk instead of memory via the -m flag:

r.watershed -s -m elevation=phi threshold=100 drainage=dir memory=16384 --v 
--o


I just launched an all-in-one go, ~9e8 pixels finally. RAM is not an
issue here. Let's see the timing.

Thank you dear Ken, Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Overlapping pixels among DEM tiles to compute the LS factor for RUSLE

[Nikos Alexandris]

A billion-pixel scaled DEM is the main input to compute the slope length
and steepness (LS) factor for RUSLE (`r.watershed`), only.

Tiling this DEM in tiles of 5K^2 pixels (`r.tile`), appears to be a reasonable
approach to parallelise this process.

I have no idea if an overlap among the different tiles is required (to
avoid border effects!?) and, if yes, how many pixels it should be.

Are there practical guidelines? Do I need to study the LS factor algorithm?
Is it something that analysts with experience in the domain can figure
out empirically?

Thank you, Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r.estimap.recreation add-on licensed by the European Commission

[Nikos Alexandris]

Dear community,

I am contented to announce the decision by the European Commission [0]
to release the GRASS GIS add-on `r.estimap.recreation` [1] as Open Source
Software under the European Union Public Licence (EUPL).

[0] 
https://gitlab.com/natcapes/r.estimap.recreation/blob/master/C_2018_8970_F1_COMMISSION_DECISION_EN_V3_P1_1006093.PDF
[1] https://gitlab.com/natcapes/r.estimap.recreation


In addition, the add-on shall be distributed under the GNU General Public
License (v2 or later) if that becomes a requirement for its distribution
through the official GRASS GIS Add-ons repository [2].

[2] https://grass.osgeo.org/download/addons/


I cordially thank Pedro Malaquias (Legal Officer, Central IP Service of the
European Commission, Joint Research Centre) for his support and deep
knowledge on the licensing issues to make this happen.


See also past related thread:

https://lists.osgeo.org/pipermail/grass-dev/2018-October/090338.html


For now, you can install under Linux the module using `g.extension`'s
`url` option [*]

[*] https://grass.osgeo.org/grass74/manuals/g.extension.html,
https://grass.osgeo.org/grass74/manuals/g.extension.html#installing-from-various-online-repositories:-github,-gitlab,-bitbucket


Soon to follow:

- some code clean-up and completion of tests
- update of documentation and (a separate) tutorial
- properly expose the module to QGIS
- publishing the code in https://trac.osgeo.org/grass/browser/grass-addons
- ensure functionality under Windows


Thankful for any kind of tests and constructive feedback.

Nikos

---
Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Semi-automatic classification of old thematic map

[Nikos Alexandris]

* Giuseppe Cillis  [2018-11-06 11:23:56 +0100]:


Dear all,
I would like to classify in a semi-automatic way, an old scanned thematic
map of land use.
The different classes of land use are represented by polygons of different
colors.
Which module can I use to identify the different land use classes?
Thanks


Dear Giuseppe,

have a look at
https://grasswiki.osgeo.org/wiki/Image_classification#Supervised_classification.

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] zonal statistics for multiple areas

[Nikos Alexandris]

* Alessandro Sebastiani  [2018-10-29 
21:32:51 +0100]:


thank you all for your suggestions.
Dear Nikos, I have some 0-1 rasters that represents presence-absence of
different land covers. Each raster's resolution is 10x10m, thus i want to
compute the sum in order to obtain the surface covered by each land cover
within my buffers. As regards to the buffer, i want to use the 0-100,
0-200, 0-300, 0-400 and 0-500 for computing stats. I can do it separately
with the module v.rast.stats. I just don't know how to loop it in a python
script


Dear Alessandro,

I don't have time to write back as I would like. Instead, I will send
you off-list some unpublished script.  With a bit of reading, there, you
might identify some ideas that will eventually help in what you are
doing.

Kind regards, Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] zonal statistics for multiple areas

[Nikos Alexandris]

Resending, as I forgot to Cc the list.

* Alessandro Sebastiani  [2018-10-29 
16:05:54 +0100]:


Hello to everybody,o


Hello Alessandro,


I hope my question is appropriate for this mail list. I have created 5
different buffer layers (d=100,200,300,400,500 m) from a point vector. Now
i want to compute some zonal statistics using different rasters as input.


You are in the right place. And the first guess is that what you need to
do is not difficult using GRASS GIS.

Which rasters exactly?  Would you want to use as base maps each of the
'0 to 100 m', '100 to 200 m' and so on "buffers"  or  '0 to 100 m', '0
to 200 m' and so on up to '0 to 500 m'?  And then, the 'other' maps
would be the 'cover' map, each time?

If you share exactly what you need to do, i.e. in form of an algorithm
using pseudo-syntax, it will be easier to understand and potentially
suggest ways to get this done.

For example:

```
for each Buffer in Buffers:
   compute zonal statistics using base=Buffer and cover=RasterX 
```


For example, you might be able to get part of this done using raster maps
only and `r.mapcalc` expressions, without the need to construct many loops and
require an extra step in the end to patch maps together.


I know how to do that separately, but i was wondering how could i automate
this procedure using a python script.


If you write down the way to do it separately, then you are just few
steps away in looping over your input rasters.  The key point is,
obviously, to express what is to be done in an unambiguous way.


I know python's basics, but i was not
able to do so following guidelines that i found on the internet, e.g GRASS
tutorial.


Please share which guidelines, i.e. which GRASS GIS tutorial you refer
to.


Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] How to get the area of a polygon in a layer

[Nikos Alexandris]

* Markus Neteler  [2018-10-26 22:34:45 +0200]:


Hi Nikos,

On Tue, Oct 23, 2018 at 5:32 PM Nikos Alexandris
 wrote:

Dear list,

is the
https://grass.osgeo.org/uploads/grass/sampledata/firedemo_grass7.sh
script available. This link is broken.


the correct link is:
https://grass.osgeo.org/sampledata/firedemo_grass7.sh

Where did you find the one you posted?


In the main 'Sample data' page,
https://grass.osgeo.org/download/sample-data/, I recall. It seems fixed
now.

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.rast in python script

[Nikos Alexandris]

* Frank David  [2018-10-24 12:04:43 +0200]:



Le 24/10/2018 à 11:58, Nikos Alexandris a écrit :

* Frank David  [2018-10-24 11:35:07 +0200]:


Stephan,

The G_OPT_OUTPUT option generate well the check box "add tree 
layer" in my script GUI.


My problem, now is how to add the raster output while I want to 
set his name by the script ? I succeed with g.copy my_raster_name 
to output_raster_name. The copy is well displayed but this creates 
a copy what is not very convenient...


g.rename

?


Nikos,

g.rename works too. But it's not more convenient because I need to 
keep my raster in his original name.


Cheers,

Frank



Frank,

apologies, but I think I missed the point of what you need to do. Is the
"copy" not convenient because of "wasting" space?  If yes, here another
suggestion then:

https://grasswiki.osgeo.org/wiki/LANDSAT#Hint:_Minimal_disk_space_copies

In Python, something like:

r.reclass(
   input=input_raster,
   output=output_raster,
   rules='-',
   stdin='*=*',
   verbose=False,
   quiet=True)

Nikos

--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.rast in python script

[Nikos Alexandris]

* Frank David  [2018-10-24 11:35:07 +0200]:


Stephan,

The G_OPT_OUTPUT option generate well the check box "add tree layer" 
in my script GUI.


My problem, now is how to add the raster output while I want to set 
his name by the script ? I succeed with g.copy my_raster_name to 
output_raster_name. The copy is well displayed but this creates a copy 
what is not very convenient...


g.rename

?


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.rast in python script

[Nikos Alexandris]

* Frank David  [2018-10-23 22:06:01 +0200]:

Thank you everybody for your help. Do you know why a 
run_command("d.rast"... in a python script is not enough to display a 
raster ? I don't understand why this command is so different.


Display a raster map where?

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] How to get the area of a polygon in a layer

[Nikos Alexandris]

Dear list,

is the
https://grass.osgeo.org/uploads/grass/sampledata/firedemo_grass7.sh
script available. This link is broken.

Thank you, Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.rast in python script

[Nikos Alexandris]

* Laurent C.  [2018-10-20 22:06:38 +0100]:


Hello Frank,

It is not very straightforward, but it is possible.
Here is an example on how I do it:

import os
import grass.script as gscript
from grass.pygrass.gis.region import Region

# Set general env
os.environ['GRASS_RENDER_IMMEDIATE'] = "cairo"
os.environ['GRASS_RENDER_FILE_COMPRESSION'] = "9"
os.environ['GRASS_RENDER_FILE_READ'] = "TRUE"


For reasons I don't understand, some times, the above way to set an environment
variable, does not work for me!

Then, I also use:
```
os.putenv("GRASS_RENDER_FILE", render_file)
```

Else, as we know, one can set these variables in a bash environment (see also
https://grass.osgeo.org/grass74/manuals/variables.html#setting-shell-environment-variables
https://grass.osgeo.org/grass74/manuals/variables.html#grass-related-files),
for example:
```bash
export GRASS_RENDER_IMMEDIATE=cairo
```

and retrieve them via
```python
RENDER_PATH = os.getenv(GRASS_RENDER_PATH)
```

Nikos


# Set image size using the region
region = Region()
xr = region.cols
yr = region.rows
ratio = xr/yr
height = int(WIDTH / ratio)  # Choose the width you like
os.environ['GRASS_RENDER_WIDTH'] = str(WIDTH)
os.environ['GRASS_RENDER_HEIGHT'] = str(height)

# Then you can draw
os.environ['GRASS_RENDER_FILE'] = img_file_name
gscript.run_command('d.rast', map=my_map, quiet=True)


Be aware that every time you run your script, it will add layer on the file.
So you might want to delete the png file between the runs.

Cheers,
Laurent


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.rast in python script

[Nikos Alexandris]

* Stefan Blumentrath  [2018-10-22 08:20:05 +]:


I think Laurents solution is for rendering maps to file/image.


If of interest, see also: 
https://lists.osgeo.org/pipermail/grass-user/2018-October/079436.html

Nikos



signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] tygrass, working with GRASS GIS under Terminology

[Nikos Alexandris]

Maybe of your interest,

an approach on rendering maps directly in the Terminology terminal while
working interactively or even while running a script:
https://gitlab.com/NikosAlexandris/tygrass

an experimental addon:
https://gitlab.com/NikosAlexandris/d.tyraster

a series of screencasts:
https://archive.org/details/GrassGisUnderTerminology [*]

Nikos

[*] replay is slow, to do: maybe some quality downgrade


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] How to get the area of a polygon in a layer

[Nikos Alexandris]

Kalindu Perera:


Commands are as follows

*r.ros,*
r.ros --overwrite model=fuel_model@demomapset
moisture_1h=1hour_moisture@demomapset moisture_live=live_moisture@demomapset
velocity=wind_speed@demomapset direction=wind_direction@demomapset
slope=slope@demomapset aspect=aspect@demomapset
elevation=elevation@demomapset base_ros=my_ros.base max_ros=my_ros.max
direction_ros=my_ros.maxdir spotting_distance=my_ros.spotdist

*r.spread,*
r.spread --overwrite base_ros=my_ros.base@demomapset
max_ros=my_ros.max@demomapset direction_ros=my_ros.maxdir@demomapset
start=fire_origin@demomapset wind_speed=wind_speed@demomapset
output=spread_time_observed

*After entering; r.category spread_time_observed,*
[image: 1.png]

*After entering; r.report spread_time_observed units=c,p,*
[image: Screenshot from 2018-10-15 21-40-46.png]


Dear Kalindu,

thank you for the above.

If all is right, you might just need to properly prepare the input data
and/or the output of `r.ros`, for example, to label raster categories
appropriately.  Then, modules like `r.report` will show also the label
for each raster category.

When drawing the `spread_time_observed` map, can you identify visually the
raster category of your interest?  If yes, pick up the the "Query
raster/vector map(s)" tool (4th button in wxGUI's Map Display window),
and select any pixel of the category of your interest.  This will tell
the value (of the pixel you selected) and a label (if any is given).

Knowing this value, you can extract all pixels of this value using
`r.mapcalc`. For example, say the raster category (or value) of
interest, is 3. Then, something like
```
r.mapcalc "category_3 = if(spread_time_observed == 3, 3, null())"
```
will create a map with all pixels of value 3.

I guess using this "category_3" map as an input to `r.surf.area` would
give the area estimation you require. Please, take care to read the
NOTES in `r.surf`area`'s manual about "edge effects" though.


Else, I think the easiest/fastest for me would to be to have access to sample
data (even via a private message). If possible, cutting out (setting via
`g.region`) a small fragment from your study area, and sharing would
allow me to "resolve" this.

Also, please don't post screenshots (if it is not about part of maps or other
visuals). For textual output, please always post the output of your commands
(as in copy and paste) or attach a text file.

For example, I would copy-and-paste the complete output of (or put in a
text file if a specific output of a command is really too long):

# in Bash
for MAP in fuel_model 1hour_moisture live_moisture wind_speed wind_direction 
slope aspect elevation my_ros.base my_ros.max my_ros.maxdir my_ros.spotdist 
fire_origin spread_time_observed ;do r.category $MAP ;done

# in Windows
see example in: 
https://lists.osgeo.org/pipermail/grass-user/2018-June/078526.html

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] How to get the area of a polygon in a layer

[Nikos Alexandris]

Please post the exact command you have used (copy-and-paste).

Then, what does
```
r.category spread_time_observed
```

and what does
```
r.report spread_time_observed units=c,p
```

return?

* Kalindu Perera  [2018-10-15 16:01:38 +0530]:


Dear Nikos,

We have used r.ros and r.spread commands for getting the wildfire
simulation.
After that, the output from the r.spread command is spread_time_observed
layer(This is the output from the simulation)
We use that layer as the input layer for the r.surf.area command.

We got many area outputs from that command output and couldn't identify
what area gives the area of the "burned" area
* I have attached the output from running r.surf.area command as an
attachment.

** Another question how we can extract only the "burned" area from the
spread_time_observed layer?

Thanks a lot for the quick reply
Looking forward to more knowledge

Best Regards
Kalindu Perera


On Mon, 15 Oct 2018 at 15:07, Nikos Alexandris 
wrote:


* Kalindu Perera  [2018-10-15 13:28:15 +0530]:

>Dear all,
>
>We are doing wildfire simulation in Grass GIS. We need to compare the area
>of 2 wildfire spreads after wildfire simulation ran. We tried to calculate
>the area of the spread using r.surf.area module. But we couldn't identify
>which is the area of the simulation from areas given from that. Could
>anyone tell us how to get an area from spread like this?

Dear Kalindu,

please post exact commands you already tried.

What are the simulation output maps?
Fitst, what does `r.category` and `r.report` return when used for
simulation
maps?

Then, maybe you need to "extract", each time, the "burned" area, then
use `r.surf.area` on it?

Nikos







--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] How to get the area of a polygon in a layer

[Nikos Alexandris]

* Kalindu Perera  [2018-10-15 13:28:15 +0530]:


Dear all,

We are doing wildfire simulation in Grass GIS. We need to compare the area
of 2 wildfire spreads after wildfire simulation ran. We tried to calculate
the area of the spread using r.surf.area module. But we couldn't identify
which is the area of the simulation from areas given from that. Could
anyone tell us how to get an area from spread like this?


Dear Kalindu,

please post exact commands you already tried.

What are the simulation output maps?
Fitst, what does `r.category` and `r.report` return when used for simulation
maps?

Then, maybe you need to "extract", each time, the "burned" area, then
use `r.surf.area` on it?

Nikos




signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.category

[Nikos Alexandris]

* Frank David  [2018-10-12 16:31:06 +0200]:

Ha yes ! a small part of the legend is displayed on the bottom of my 
map (I did not take care). I had probably activate d.legend by the 
past to test it.


But I don't know how to remove it ?


Right click on it, then "Remove legend".

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] EPSG 32633 and spatial resolution for hourly LST product from Copernicus

[Nikos Alexandris]

(For context see previous messages in this thread)

Nikos A:


>> g.region raster=g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc_LST
>> -pag w=-180 e=180


Markus M:


>this shifts the grid by half a cell to the east. The -a flag does
>not mak sense because 1) you want to force new extends, 2) there is
>no resolution given for use with the -a flag.


Eh.. hm, right, using `-a` is nonsensical here :-)


More precise, this shifts the computational's region grid by half a
cell to the east. Right?


it shifts the raster map to the east, not the computational region.


Just a conceptual clarification, still after all these years:

`g.region` governs the computational region and `r.region` a raster
map's spatial specifications. These are related but independent.
How does `g.region` alter the raster map's location, if it can't modify
a raster map's spatial specifications?  Do you refer to any output that
will base upon the region set?


If the default of `-a` is "to align the region resolution to match the
region boundaries",



?
from the manual:
"With the *-a* flag all four boundaries are adjusted to be even multiples
of the resolution, aligning the region to the resolution supplied by the
user."

i.e. with the -a flag, the region boundaries are modified and the
resolution is kept. The default (without -a) is to align the region
resolution to match the region boundaries.


I misfired. The manual is clear, the `-a` flag adjusts the computational
region's boundaries to be even multiples of the spatial resolution
*supplied by the user*.

Two full examples of using `-a` to `g.region` the right way, hopefully:

```
r.in.gdal in=NETCDF:"g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc":LST 
out=import -o --o

WARNING: Datum  not recognised by GRASS and no parameters found
Over-riding projection check
360 degree EW extent is exceeded by 1.00019 cells
360 degree EW extent is exceeded by 0.000192261 cells
Importing raster map ...
100%
```
and
```
r.info import -g

360 degree EW extent is exceeded by 0.00019226 cells
360 degree EW extent is exceeded by 1.00019 cells
north=80.0223214291667
south=-79.977682386
east=179.977687153889
west=-180.022321429167
nsres=0.0446428582072328
ewres=0.0446428582072241
rows=3584
cols=8064
cells=28901376
datatype=CELL
ncats=0
```
and then setting the region via
```
g.region raster=import -ag nsres=0.0446428582072328 ewres=0.0446428582072241

360 degree EW extent is exceeded by 1.00019 cells
360 degree EW extent is exceeded by 0.00019226 cells
360 degree EW extent is exceeded by 0.00019226 cells
360 degree EW extent is exceeded by 1.00019 cells
projection=3
zone=0
n=80.0446447655684
s=-80.019073612
w=-180.044647149735
e=180.04291528
nsres=0.0446428582072328
ewres=0.0446428582072241
rows=3585
cols=8065
cells=28913025
```
or via
```
g.region raster=import -ag res=0.044642858207226

360 degree EW extent is exceeded by 1.00019 cells
360 degree EW extent is exceeded by 0.00019226 cells
360 degree EW extent is exceeded by 0.00019226 cells
360 degree EW extent is exceeded by 1.00019 cells
projection=3
zone=0
n=80.0446447655562
s=-80.01907349
w=-180.044647149742
e=180.04291535
nsres=0.044642858207226
ewres=0.044642858207226
rows=3585
cols=8065
cells=28913025
```

all of which looks fine, except for the "exceeding" warnings.

With `-a`
```
r.in.gdal in=NETCDF:"g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc":LST 
out=import_with_a -o -a

WARNING: Datum  not recognised by GRASS and no parameters found
Over-riding projection check
360 degree EW extent is exceeded by 0.000192261 cells
360 degree EW extent is exceeded by 1.00019 cells
Importing raster map ...
100%
```
and
```
r.info import_with_a -g
360 degree EW extent is exceeded by 1.00019 cells
north=80.02233
south=-79.96344
east=179.9457
west=-180.0223
nsres=0.04463889
ewres=0.04463889
rows=3584
cols=8064
cells=28901376
datatype=CELL
ncats=0
```
and then setting the region
```
g.region raster=import_with_a -ag res=0.04463889
360 degree EW extent is exceeded by 0.00019226 cells
360 degree EW extent is exceeded by 0.283136 cells
projection=3
zone=0
n=80.037527778
s=-79.99289
w=-180.02863889
e=179.984
nsres=0.04463889
ewres=0.04463889
rows=3585
cols=8065
cells=28913025
```
or
```
g.region raster=import_with_a -ag res=0.044642858207226
360 degree EW extent is exceeded by 1.00019 cells
360 degree EW extent is exceeded by 0.000192261 cells
projection=3
zone=0
n=80.0446447655562
s=-80.01907349
w=-180.044647149742
e=179.955361433328
nsres=0.044642858207226
ewres=0.044642858207226
rows=3585
cols=8064
cells=28909440
```

[..]


won't the above command try to modify the spatial
resolution, of the computational region, so as to perfectly fit inside
the currently set, of user provided, boundaries?

If, say, the region's boundaries are n=80 s=-80 w=-180 e=180 and the
raster map's rows and columns 3584 and 8064 respectively, won't the
above command try to 

Re: [GRASS-user] EPSG 32633 and spatial resolution for hourly LST product from Copernicus

[Nikos Alexandris]

Nikos wrote:


>> Import using r.in.gdal, _without_ any of `-l` or `-a` and then I get the
>> closest to the reported spatial resolution. Else, with `-a`, for
>> example, the spatial resolution is not as close to the "original" one.
>> Makes sense?


Markus M:


>what would be the output resolution and extends with r.in.gdal -a?
>Generally r.in.gdal -a provides the best results.


Importing without `-a`:


import
360 degree EW extent is exceeded by 0.00019226 cells
north=80.0223214291667
south=-79.977682386
east=179.977687153889
west=-180.022321429167
nsres=0.0446428582072328
ewres=0.0446428582072241
rows=3584
cols=8064
cells=28901376
datatype=CELL
ncats=0


Importing with `-a`:


import_with_a
north=80.02233
south=-79.96344


Markus M:


something went wrong here:

east=179.9457

east should be 180 - ew_res / 2

just like

west=-180.0223

i.e west = -180 - ew_res / 2

I will investigate


Reported here https://trac.osgeo.org/grass/ticket/3672#ticket.


nsres=0.04463889
ewres=0.04463889
rows=3584
cols=8064
cells=28901376
datatype=CELL
ncats=0


Nikos



signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] EPSG 32633 and spatial resolution for hourly LST product from Copernicus

[Nikos Alexandris]

Nikos wrote:


gdalinfo NETCDF:"g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc":LST
Driver: netCDF/Network Common Data Format
Files: g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc
Size is 8064, 3584
Coordinate System is:
GEOGCS["unknown",
DATUM["unknown",
SPHEROID["Spheroid",6378137,298.2572326660156]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]]]
Origin = (-180.022321429103613,80.022321429103613)
Pixel Size = (0.044642858207226,-0.044642858207226)

[...]

Corner Coordinates:
Upper Left  (-180.0223214,  80.0223214) (180d 1'20.36"W, 80d 1'20.36"N)
Lower Left  (-180.0223214, -79.9776824) (180d 1'20.36"W, 79d58'39.66"S)
Upper Right ( 179.9776872,  80.0223214) (179d58'39.67"E, 80d 1'20.36"N)
Lower Right ( 179.9776872, -79.9776824) (179d58'39.67"E, 79d58'39.66"S)
Center  (  -0.0223171,   0.0223195) (  0d 1'20.34"W,  0d 1'20.35"N)


Markus:


apparently the center of the left-most column is -180, therefore forcing
the corner to -180 would shift the grid by half a cell.



Import using r.in.gdal, _without_ any of `-l` or `-a` and then I get the
closest to the reported spatial resolution. Else, with `-a`, for
example, the spatial resolution is not as close to the "original" one.
Makes sense?



what would be the output resolution and extends with r.in.gdal -a?
Generally r.in.gdal -a provides the best results.


Importing with/out `-a` and `-al`:

for MAP in $(g.list raster pattern=import*) ;do echo $MAP && r.info -g $MAP && 
echo ;done

import
360 degree EW extent is exceeded by 0.00019226 cells
north=80.0223214291667
south=-79.977682386
east=179.977687153889
west=-180.022321429167
nsres=0.0446428582072328
ewres=0.0446428582072241
rows=3584
cols=8064
cells=28901376
datatype=CELL
ncats=0

import_with_a
north=80.02233
south=-79.96344
east=179.9457
west=-180.0223
nsres=0.04463889
ewres=0.04463889
rows=3584
cols=8064
cells=28901376
datatype=CELL
ncats=0

import_with_al
north=80.02233
south=-79.96344
east=179.968
west=-180
nsres=0.04463889
ewres=0.04463889
rows=3584
cols=8064
cells=28901376
datatype=CELL
ncats=0

The first "import" map's ns/ew resolution is closest to the original.



Better to cut off the west side (?):
```
g.region raster=g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc_LST -pag

w=-180 e=180

this shifts the grid by half a cell to the east. The -a flag does not make
sense because 1) you want to force new extends, 2) there is no resolution
given for use with the -a flag.


More precise, this shifts the computational's region grid by half a
cell to the east. Right?

If the default of `-a` is "to align the region resolution to match the
region boundaries", won't the above command try to modify the spatial
resolution, of the computational region, so as to perfectly fit inside
the currently set, of user provided, boundaries?

If, say, the region's boundaries are n=80 s=-80 w=-180 e=180 and the
raster map's rows and columns 3584 and 8064 respectively, won't the
above command try to adjust the region's resolution so as to fit these
cells inside these boundaries?



Using g.region -pg defaults to g.region -g. Use either -p or -g.o


I see.

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] EPSG 32633 and spatial resolution for hourly LST product from Copernicus

[Nikos Alexandris]

* Veronica Andreo  [2018-09-25 08:24:44 -0300]:


AFAIU, plate carree (lat long grid, no meters) is deprecated, and you
should use latlong instead. I had a similar issue with modis ocean color
products.

Do you at least get the same number of row and columns that is described by
gdalinfo when you import?


No, it is 512^2 (see below) against
```
g.regio -p
..
rows:   3584
cols:   8064
..
```

Markus' hint, not *directly* on the netCDF file, rather on one of the
layers:

gdalinfo NETCDF:"g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc":LST
Driver: netCDF/Network Common Data Format
Files: g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc
Size is 8064, 3584
Coordinate System is:
GEOGCS["unknown",
   DATUM["unknown",
   SPHEROID["Spheroid",6378137,298.2572326660156]],
   PRIMEM["Greenwich",0],
   UNIT["degree",0.0174532925199433,
   AUTHORITY["EPSG","9122"]]]
Origin = (-180.022321429103613,80.022321429103613)
Pixel Size = (0.044642858207226,-0.044642858207226)
Metadata:
 crs#grid_mapping_name=latitude_longitude
 crs#inverse_flattening=298.2572326660156
 crs#longitude_of_prime_meridian=0
 crs#semi_major_axis=6378137
 lat#axis=Y
 lat#long_name=latitude
 lat#standard_name=latitude
 lat#units=degrees_north
 lon#axis=X
 lon#long_name=longitude
 lon#standard_name=longitude
 lon#units=degrees_east
 LST#add_offset=273.15
 LST#ancillary_variables=Q_FLAGS, ERRORBAR_LST, TIME_DELTA, PERCENT_PROC_PIXELS
 LST#cell_methods=area:mean where land
 LST#coverage_content_type=physicalMeasurement
 LST#grid_mapping=crs
 LST#long_name=Land Surface Temperature
 LST#scale_factor=0.01
 LST#standard_name=surface_temperature
 LST#units=Kelvin
 LST#valid_range={-7000,8000}
 LST#_FillValue=-8000
 NC_GLOBAL#algorithm_version=GOES13-LST_v3.40, MSG3-LST_v7.14.0, 
HIMAWARI8-LST_v3.50, DataFusion_v5.2
 NC_GLOBAL#archive_facility=IPMA
 NC_GLOBAL#comment=Land Surface Temperature (LST) is the radiative skin 
temperature over land. LST plays an important role in the physics of land 
surface as it is involved in the processes of energy and water exc
hange with the atmosphere. LST is useful for the scientific community, namely 
for those dealing with meteorological and climate models. Accurate values of 
LST are also of special interest in a wide range of areas
related to land surface processes, including meteorology, hydrology, 
agrometeorology, climatology and environmental studies.
 NC_GLOBAL#contacts=Principal investigator (Researcher): isabel.tr...@ipma.pt; 
Instituto Português do Mar e da Atmosfera (IPMA); Rua C ao Aeroporto; Lisbon; 
1749-077; Portugal (PT); IPMA website; http://www.ipma.
pt
Originator (IPMA GIO-Global Land Help Desk): sandra.coe...@ipma.pt; Instituto 
Português do Mar e da Atmosfera (IPMA); Rua C ao Aeroporto; Lisbon; 1749-077; 
Portugal (PT); IPMA website; http://www.ipma.pt
Point of contact (GIO-Global Land Help Desk): helpd...@vgt.vito.be; Flemish 
Institute for Technological Research (VITO); Boeretang 200; Mol; 2400; Belgium 
(BE); VITO website; http://land.copernicus.eu/global/
Owner: entr-copernicus-ass...@ec.europa.eu; European Commission 
Directorate-General for Enterprise and Industry (EC-DGEI); Avenue d'Auderghem 
45; Brussels; 1049; Belgium (BE); EC-DGEI website; http://ec.europa.eu/
enterprise/
Custodian (Responsible): copernicuslandprodu...@jrc.ec.europa.eu; European 
Commission Directorate-General Joint Research Center (JRC); Via E.Fermi, 249; 
Ispra; 21027; Italy (IT); JRC website; http://ies.jrc.ec.eur
opa.eu
 NC_GLOBAL#Conventions=CF-1.6
 NC_GLOBAL#credit=LST products are generated by the land service of Copernicus, 
the Earth Observation programme of the European Commission. The LST algorithm, 
originally developed in the framework of the FP7/Geoland2, is generated from 
MTSAT/HIMAWARI and GOES data, respectively owned by JMA and NOAA, and combined 
with the LST product from MSG under copyright EUMETSAT, produced by LSA-SAF.
 NC_GLOBAL#date_created=2016-06-22T03:22:01Z
 NC_GLOBAL#gcmd_keywords=SURFACE TEMPERATURE
 NC_GLOBAL#gemet_keywords=solar radiation
 NC_GLOBAL#history=2016-06-22T03:22:01Z - Product generation;
 
NC_GLOBAL#identifier=urn:cgls:global:lst_v1_0.045degree:LST_201606220100_GLOBE_GEO_V1.2
 NC_GLOBAL#inspire_theme=Orthoimagery
 NC_GLOBAL#institution=IPMA
 NC_GLOBAL#iso19115_topic_categories=climatologyMeteorologyAtmosphere, 
imageryBaseMapsEarthCover
 NC_GLOBAL#long_name=Land Surface Temperature
 NC_GLOBAL#name=LST
 NC_GLOBAL#orbit_type=GEO
 NC_GLOBAL#other_keywords=Global
 NC_GLOBAL#parent_identifier=urn:cgls:global:lst_v1_0.045degree
 NC_GLOBAL#platform=GOES13, MSG3, HIMAWARI8
 NC_GLOBAL#processing_level=L4
 NC_GLOBAL#processing_mode=Near Real Time
 NC_GLOBAL#product_version=V1.2
 NC_GLOBAL#purpose=This product is first designed to fit the requirements of 
the Global Land component of Land Service of GMES-Copernicus. It can be also 
useful for all applications related to the environment monitoring.
 NC_GLOBAL#references=Product User Manual: 

[GRASS-user] EPSG 32633 and spatial resolution for hourly LST product from Copernicus

[Nikos Alexandris]

The hourly 5km LST product from Copernicus, as per the product user manual
(https://land.copernicus.eu/global/sites/cgls.vito.be/files/products/GIOGL1_PUM_LST-I1.40.pdf)

"is displayed in a regular latitude/longitude grid (plate carrée) with
the ellipsoid WGS 1984 (Terrestrial radius=6378km). This coordinate
reference system corresponds to EPSG code 32663. The resolution of the
grid is 5/112° (approximately 0.045°)."


I imported a map (netCDF) and set the region to match it. 
If '32633' unit is 'meter', any ideas on to do with the reported:


nsres:  0.04464286
ewres:  0.04464286

which is, obviously, not meters?
Is there something "hidden" in the netCDF file(s)?


Here is a `gdalinfo g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc`:
```
Driver: netCDF/Network Common Data Format
Files: g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc
Size is 512, 512
Coordinate System is `'
Metadata:
 NC_GLOBAL#algorithm_version=GOES13-LST_v3.40, MSG3-LST_v7.14.0, 
HIMAWARI8-LST_v3.50, DataFusion_v5.2
 NC_GLOBAL#archive_facility=IPMA
 NC_GLOBAL#comment=Land Surface Temperature (LST) is the radiative skin 
temperature over land. LST plays
an important role in the physics of land surface as it is involved in the 
processes of energy and water ex
change with the atmosphere. LST is useful for the scientific community, namely 
for those dealing with mete
orological and climate models. Accurate values of LST are also of special 
interest in a wide range of area
s related to land surface processes, including meteorology, hydrology, 
agrometeorology, climatology and en
vironmental studies.
 NC_GLOBAL#contacts=Principal investigator (Researcher): isabel.tr...@ipma.pt; 
Instituto Português do Mar
e da Atmosfera (IPMA); Rua C ao Aeroporto; Lisbon; 1749-077; Portugal (PT); 
IPMA website; http://www.ipma
.pt
Originator (IPMA GIO-Global Land Help Desk): sandra.coe...@ipma.pt; Instituto 
Português do Mar e da Atmosf
era (IPMA); Rua C ao Aeroporto; Lisbon; 1749-077; Portugal (PT); IPMA website; 
http://www.ipma.pt
Point of contact (GIO-Global Land Help Desk): helpd...@vgt.vito.be; Flemish 
Institute for Technological Research (VITO); Boeretang 200; Mol; 2400; Belgium 
(BE); VITO website; http://land.copernicus.eu/global/
Owner: entr-copernicus-ass...@ec.europa.eu; European Commission 
Directorate-General for Enterprise and Industry (EC-DGEI); Avenue d'Auderghem 
45; Brussels; 1049; Belgium (BE); EC-DGEI website; 
http://ec.europa.eu/enterprise/
Custodian (Responsible): copernicuslandprodu...@jrc.ec.europa.eu; European 
Commission Directorate-General Joint Research Center (JRC); Via E.Fermi, 249; 
Ispra; 21027; Italy (IT); JRC website; http://ies.jrc.ec.europa.eu
 NC_GLOBAL#Conventions=CF-1.6
 NC_GLOBAL#credit=LST products are generated by the land service of Copernicus, 
the Earth Observation programme of the European Commission. The LST algorithm, 
originally developed in the framework of the FP7/Geoland2, is generated from 
MTSAT/HIMAWARI and GOES data, respectively owned by JMA and NOAA, and combined 
with the LST product from MSG under copyright EUMETSAT, produced by LSA-SAF.
 NC_GLOBAL#date_created=2016-06-22T03:22:01Z
 NC_GLOBAL#gcmd_keywords=SURFACE TEMPERATURE
 NC_GLOBAL#gemet_keywords=solar radiation
 NC_GLOBAL#history=2016-06-22T03:22:01Z - Product generation;
 
NC_GLOBAL#identifier=urn:cgls:global:lst_v1_0.045degree:LST_201606220100_GLOBE_GEO_V1.2
 NC_GLOBAL#inspire_theme=Orthoimagery
 NC_GLOBAL#institution=IPMA
 NC_GLOBAL#iso19115_topic_categories=climatologyMeteorologyAtmosphere, 
imageryBaseMapsEarthCover
 NC_GLOBAL#long_name=Land Surface Temperature
 NC_GLOBAL#name=LST
 NC_GLOBAL#orbit_type=GEO
 NC_GLOBAL#other_keywords=Global
 NC_GLOBAL#parent_identifier=urn:cgls:global:lst_v1_0.045degree
 NC_GLOBAL#platform=GOES13, MSG3, HIMAWARI8
 NC_GLOBAL#processing_level=L4
 NC_GLOBAL#processing_mode=Near Real Time
 NC_GLOBAL#product_version=V1.2
 NC_GLOBAL#purpose=This product is first designed to fit the requirements of 
the Global Land component of Land Service of GMES-Copernicus. It can be also 
useful for all applications related to the environment monitoring.
 NC_GLOBAL#references=Product User Manual: 
http://land.copernicus.eu/global/sites/default/files/products/GIOGL1_PUM_LST_I1.10.pdf
Validation Report: 
http://land.copernicus.eu/global/sites/default/files/products/GIOGL1_VR_LST_I2.10.pdf
Product page: http://land.copernicus.eu/global/products/lst
 NC_GLOBAL#sensor=IMAG, SEVI, AHI
 NC_GLOBAL#source=Data was derived from satellite imagery.
 NC_GLOBAL#time_coverage_end=2016-06-22T01:30:00Z
 NC_GLOBAL#time_coverage_start=2016-06-22T00:30:00Z
 NC_GLOBAL#title=Global Land Surface Temperature for 2016-06-22T01:00:00Z
Subdatasets:
 
SUBDATASET_1_NAME=NETCDF:"g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc":ERRORBAR_LST
 SUBDATASET_1_DESC=[1x3584x8064] surface_temperature standard_error (16-bit 
integer)
 SUBDATASET_2_NAME=NETCDF:"g2_BIOPAR_LST_201606220100_GLOBE_GEO_V1.2.nc":LST
 SUBDATASET_2_DESC=[1x3584x8064] surface_temperature 

Re: [GRASS-user] Get map from https://lst.mundialis.de in GRASS GIS' data base

[Nikos Alexandris]

* Markus Neteler  [2018-09-24 17:04:13 +0200]:


On Mon, Sep 24, 2018 at 5:00 PM Markus Neteler  wrote:

On Fri, Sep 21, 2018 at 5:31 PM Nikos Alexandris
> Dears,
>
> can I get a fraction (spatial and temporal) of the maps shown under
> https://lst.mundialis.de/, directly in GRASS GIS?

Consider to contact mundialis for this :-)


As a side note: we published the global monthly MODIS LST data related
to the article:

Metz, M.; Andreo, V.; Neteler, M. A New Fully Gap-Free Time Series of
Land Surface Temperature from MODIS LST Data. Remote Sens. 2017, 9,
1333. https://doi.org/10.3390/rs9121333

here:
https://zenodo.org/record/1135230

best,
Markus


Danke Markus.

These are ~5.6km, not 1km though.

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] i.modis and missing support for HFD4 under Gentoo/Funtoo-Linux

[Nikos Alexandris]

Dears,

I am trying to use `i.modis.download`. There is this message
"GDAL installation has no support for HDF4, please update GDAL" that
won't let the module run at all.

Strangely, there is no 'hdf' use flag (Gentoo/Funtoo terminology) for
gdal (anymore?).

Any Gentoo users?

Thank you, Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Versions question [ANSWERED]

[Nikos Alexandris]

* Rich Shepard  [2018-09-22 10:30:35 -0700]:


On Sat, 22 Sep 2018, Hernán De Angelis wrote:


In my system the executables for the different grass versions look like this:
grass74
grass75
grass77


Hernán,

 A while ago I copied /usr/local/bin/grass75 to /usr/local/bin/grass and
used only 'grass' on the command line, so it was the executable for 7.5.svn
that ran.


Maybe better to softlink, instead of copying.

Nikos

[rest deleted]


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Get map from https://lst.mundialis.de in GRASS GIS' data base

[Nikos Alexandris]

Dears,

can I get a fraction (spatial and temporal) of the maps shown under
https://lst.mundialis.de/, directly in GRASS GIS?

Thank you, Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Raster based approach to compute Extent/Sum for categorical maps

[Nikos Alexandris]

Dears,

some background: I am exploring GRASS GIS' capabilities to run an
algorithm I built, by exclusively using raster maps and `r.*` modules.
Alternatives (i.e. Python based solutions) excluded.


Algorithm

1   B ← {0, .., m-1}
2   T ← {0, .., n-1}
3   W ← 0
4   R ← 0
5   F ← 0
6   MASK ← HQR
7   foreach {b} ⊆ B do
8  X ← 0
9  foreach {t} ⊆ T do
10 Wt ← Et * Ct
11 W ← W⋃{Wt}
12  S ← ∑t∈Wt
13 foreach t ← T do
14Rt ← Wt / S
15R ← R⋃{Rt}
16 X ← X⋃{R}

where:

B  is a set of (aggregation) boundaries (raster categories)

T  is a set of land types (raster categories)

E  denotes extent of "elements" in T (number of cells * area of current cell)

C  denotes a corresponding weighting factor for elements in T (labels for 
raster categories)

W  is an (empty) set to hold weighted extents of "elements" in T

S  denotes the sum of all elements in W

R  is an (empty) set to hold ratios of elements in W to S

X  is an (empty) set to hold all sets R for each iteration over the elements of 
B



Running it in GRASS GIS

Lines 10-11 compute a weighted extent for each "element" in T.
To exemplify, given

- a CELL map 'types' with zones of interest, i.e.
```
r.category types

1   Urban
2   Cropland
3   Woodland and forest
4   Grassland
5   Heathland and shrub
6   Sparsely vegetated land
7   Wetland
```

- a CELL map depicting areas of interest 'cells_of_interest', i.e.
```
r.category cells_of_interest
9
```

- a CELL 'scores' map with *float* values set as labels, i.e.
```
r.category scores
1   0.1
2   0.2
3   0.3
4   0.4
5   0.5
6   0.6
7   0.7
```


one way to do this in GRASS is using `r.mapcalc`'s '@' notation:

   # number of cells
   r.stats.zonal base=types cover=cells_of_interest method=count output=cells -r

   # extent
   r.mapcalc "extent = @cells * area()"
   r.stats.zonal base=types cover=extent method=average output=extent -r --o

   # weighted extents
   r.mapcalc "weighted = @extent * @scores" --o
   r.stats.zonal base=types cover=weighted method=average output=weighted -r --o


The 'weighted' map features now:
```
r.category weighted

1   15668750.00
2   54460500.00
3   78163500.00
4   15247000.00
5   -nan
6   15000.00
7   4294500.00
```

Note, also the extension `r.area` can be used somewhere.



Questions

Is it possible to compute the sum of values that are
set as labels to a raster map (here, the 'weighted' map),
using raster modules?  [Line 12 of the algorithm]

Essentially, how to compute and re-use the

```
sum_of = 15000 + 4294500 + 15247000 + 15668750 + 54460500 + 78163500
```

in an `r.mapcalc` expression?

If this is not directly possible, could the 'sum_of' be, for example, a label
to a raster map's category?

Perhaps, the same value 'sum_of' set as label to all of the categories
involved above?

If the above is doable, then, there should be a way to compute the ratio for
each element in W to S (Line 14).  Something like:

   r.mapcalc "ratios = @weighted / sum_of"

Thanks, Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Historic book

[Nikos Alexandris]

* Rich Shepard  [2018-08-29 13:56:31 -0700]:


On Wed, 29 Aug 2018, Markus Metz wrote:


I would be interested in it, and I would like to have it somewhere in the
GRASS archives. Those old manuals are a source of information that should
not be underestimated.


Markus M,

 The file is 20.7Mb so I uploaded a copy here:


 Everyone is welcome to download a copy; it will be available for 5 days.

Best regards,

Rich


Thank you Rich!

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] New CLI option --tmp-location in 7.5 to enhance --exec

[Nikos Alexandris]

Vaclav Petras  [2018-08-14 23:20:16 -0400]:


* Get SRS/CRS for a file:

 grass --tmp-location ~/data/elevation.tiff --exec g.proj -p


Nikos:


Perhaps test if the file exists and, if not, exit with an informative error
message?



In Python:

import os.path
os.path.isfile(fname)
?



Hi Nikos,

sounds good to me. Do you want to submit an issue and suggest a patch?

Vashek


https://trac.osgeo.org/grass/ticket/3537#comment:8

[rest deleted]

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.clip ... not clipping

[Nikos Alexandris]

* Helmut Kudrnovsky  [2018-08-17 00:18:01 -0700]:


Rich Shepard wrote

On Wed, 15 Aug 2018, Vaclav Petras wrote:


See r.clip module in addons for equivalent of v.clip:
https://grass.osgeo.org/grass74/manuals/addons/r.clip.html


Vaclav,

   r.clip is not working for me. I have a 13G DEM that I need to cut down
to
a more reasonable size. I set the region to a vector map of the county
boundary then run

r.clip in=dem_west out=dem_left

About 29 minutes later I see that the output file is the same size and
coverage as the input file. Doesn't matter if I use the '-r' option to
r.clip.

   What am I missing?


when you're not sure if a command/module is working as expected, it's always
good to try the example with the NC sample data set mentioned in the
manuals.

th manual's example works here, see screenshot:
raster_clip.jpg


without the commands you used (g.region, r.clip, etc), it's hard to find out
what is missing.


@Rich,

compare `r.info -g dem_west` with `g.region -g`, after you have set the
region to the desired extent, of course. They should be different. And,
then, `r.info -g dem_left` should match the current extent (`g.region
-g`).

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] New CLI option --tmp-location in 7.5 to enhance --exec

[Nikos Alexandris]

* Vaclav Petras  [2018-08-14 23:20:16 -0400]:

..


If you are interested, please, test this new functionality. It is an
opportunity to provide feedback before this feature lands in the 7.6
release.

Here are some things to try:

* Execute a module in a location created based on EPSG:

 grass --tmp-location EPSG:3358 --exec g.region -p

* Execute Python script in a location created based on EPSG:

 grass --tmp-location EPSG:3358 --exec script.py

* Examine the created location using a Bash command:

 grass --tmp-location EPSG:3358 --exec bash -c "g.proj -p && g.region -p
&& g.mapset -p && g.gisenv GISDBASE,LOCATION_NAME sep=/"

* Get SRS/CRS for a file:

 grass --tmp-location ~/data/elevation.tiff --exec g.proj -p


Perhaps test if the file exists and, if not, exit with an informative error
message?

In Python:

import os.path
os.path.isfile(fname) 


?

Currently, if the file does not exist, the process hangs:

```
Cleaning up temporary files...
Starting GRASS GIS...
```



* Get help text for a module:

 grass --tmp-location XY --exec r.neighbors --help

See the documentation and `grass --help` for more hints (and let me know
how these can be enhanced).

Best regards,
Vaclav


https://trac.osgeo.org/grass/ticket/3537
https://trac.osgeo.org/grass/ticket/3585
https://trac.osgeo.org/grass/ticket/3586
https://trac.osgeo.org/grass/changeset/72790
https://trac.osgeo.org/grass/changeset/73096
https://trac.osgeo.org/grass/changeset/73098
https://trac.osgeo.org/grass/changeset/73099


All works.
Fantastic work!

Kudos Radek and Vaclav,
Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Area statistics for categorical maps

[Nikos Alexandris]

* Nikos Alexandris  [2018-07-29 14:10:39 +0200]:


The obvious problem is: `r.stats` if CSV friendly but gives
approximations, `r.report` is not CSV friendly but the sum of relative
percentages sum up to 100%.

How do you report areal statistics?

See also: https://trac.osgeo.org/grass/ticket/507


If `r.report` is a wrapper around `r.stats`, why aren't percentage
outputs identical, for the same region and maps? Why does `r.report` sum
up to 100% while `r.stats` help reads

   -p   Print approximate (total percent may not be 100%) percents

?

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Area statistics for categorical maps

[Nikos Alexandris]

Recently, I "discovered" that `r.stats` and `r.report` accept multiple
raster input maps. Which is fantastic!

I am yet to find my "ideal" reporting method
for when involving 3 (or more) raster maps.

- `r.stats` reports _approximate_ percentages that
   refer to the complete extent of the computational region and
   has a CSV frinedly output than `r.report`.

- `r.report`, however, derives percentages that
   refer to the extent of the (preceding input raster map's)
   "super-category", which is useful.

Maybe "fix" `r.stats` to (also) provide
an option to get percentages relative to a "super-category"?

An example:

| 501||  3.405000| 1362|  4.50|
|||--|-|--|
||1|Urban. . . . . . . . . . . . . . . . . . . . .|  0.82|  328| 24.08|
||2|Cropland . . . . . . . . . . . . . . . . . . .|  1.26|  504| 37.00|
||3|Woodland and forest. . . . . . . . . . . . . .|  1.325000|  530| 38.91|

and (r.stats' output piped through `column -t`)

501   1  82.00328   1.08%
501   2  126.00   504   1.67%
501   3  1325000.00   530   1.75%

where:

- 501 is some map's category/pixel value, a map without labeled categories
- the second map's categories 1, 2 and 3 are labeled

- the first fragment comes from an `r.report` output
- the second fragment comes from an `r.stats` output

- km (above) and meters (below) agree
- pixel counts agree
- percentages don't agree, of course

`r.stats` will report these relative percentages by using the
"super-category" as a MASK. Using the first map and the value '501' as a
MASK, the results are:

|501| |  3.52| 1408|100.00|
|   |-|--|-|--|
|   |1|Urban. . . . . . . . . . . . . . . . . . . . . |  0.935000|  374| 26.56|
|   |2|Cropland . . . . . . . . . . . . . . . . . . . |  1.26|  504| 35.80|
|   |3|Woodland and forest. . . . . . . . . . . . . . |  1.325000|  530| 37.64|

and

501  1  935000.00   374  26.64%
501  2  126.00  504  35.90%
501  3  1325000.00  530  37.75%

The obvious problem is: `r.stats` if CSV friendly but gives
approximations, `r.report` is not CSV friendly but the sum of relative
percentages sum up to 100%.

How do you report areal statistics?

See also: https://trac.osgeo.org/grass/ticket/507

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r,in.gdal error when importing a jpeg2000 image

[Nikos Alexandris]

* Paul Shapley  [2018-07-18 09:32:56 +0100]:


Hi Users,

Trying to import an 8.7gb (jpeg2000) image into Grass 7.4.1 64 bit. I get
the error below. Tested the image in another OS GIS package and it opens
without issue. Not sure why Grass wont import it.

Thanks everyone!

Paul Shapley



If it's a driver issue (like Daniel mentions in his post) and GDAL can
read it, do you really need to import it? You know that you can link to
it via r.external.

Nikos

[..]


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Importing .tif

[Nikos Alexandris]

* Helmut Kudrnovsky  [2018-07-14 04:19:53 -0700]:




I did that before too. Did you also note that it takes "too much" >time to
create the Location using the '.tif' file?


it didn't take a long time to create the location.


For completion, using the same sample I used first in this thread:

```
time grass -c int_43120C4404.tif /geo/grassdb/onsight/nad83_cors96_utm_z10/
..
real0m25.083s
user0m0.184s
sys 0m21.699s
``
which is unusually long.

Seeing the other branch of this thread, about using the .tif file: in
this case, there is something in the image's geo-metadata that does not
play nice to create a new Location. Thus, it's best to use one of the
Shapefiles.

Nikos

[rest deleted]


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] script option

[Nikos Alexandris]

* Frank David  [2018-07-14 12:13:26 +0200]:


Hi Nikos,

You can find below the full interface script. The script is not yet 
finished. It may be helps you to understand the problem ?!
I don't really understand how works the parameter guidependency and 
with which key I must connect it. I did not find any doc about that.. 
do you know where I can find that ?


Frank, I don't know this option!

The search hits I can quickly find:
- 
https://grass.osgeo.org/grass74/manuals/libpython/script.html?highlight=guidependency.
- https://trac.osgeo.org/grass/search?q=guidependency

It is not mentioned in
https://grass.osgeo.org/grass75/manuals/g.parser.html. I think it
should.

A couple of grass-addons use it:

grass7/db/db.join/db.join.py:46:#% guidependency: ocolumn,scolumns
grass7/vector/v.stream.network/v.stream.network.py:38:#%  guidependency: 
layer,column
grass7/vector/v.civil/v.civil.py:72:##% guidependency: ocolumn,scolumns
grass7/vector/v.civil/v.civil.py:80:##% guidependency: ocolumn,scolumns
grass7/vector/v.gsflow.export/v.gsflow.export.py:36:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.export/v.gsflow.export.py:43:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.export/v.gsflow.export.py:50:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.export/v.gsflow.export.py:57:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.export/v.gsflow.export.py:64:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.export/v.gsflow.export.py:71:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.export/v.gsflow.export.py:78:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.export/v.gsflow.export.py:85:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.export/v.gsflow.export.py:92:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.export/v.gsflow.export.py:99:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.export/v.gsflow.export.py:106:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.gravres/v.gsflow.gravres.py:38:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.gravres/v.gsflow.gravres.py:45:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.gravres/v.gsflow.gravres.py:52:#%  guidependency: 
layer,column
grass7/vector/v.flexure/v.flexure.py:37:#%  guidependency: layer,column
grass7/vector/v.flexure/v.flexure.py:43:#%  guidependency: column
grass7/vector/v.gsflow.segments/v.gsflow.segments.py:36:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.segments/v.gsflow.segments.py:43:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.reaches/v.gsflow.reaches.py:37:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.reaches/v.gsflow.reaches.py:44:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.reaches/v.gsflow.reaches.py:51:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.reaches/v.gsflow.reaches.py:58:#%  guidependency: 
layer,column
grass7/vector/v.stream.inbasin/v.stream.inbasin.py:50:#%  guidependency: 
layer,column
grass7/vector/v.stream.inbasin/v.stream.inbasin.py:57:#%  guidependency: 
layer,column
grass7/vector/v.stream.inbasin/v.stream.inbasin.py:64:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.hruparams/v.gsflow.hruparams.py:37:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.hruparams/v.gsflow.hruparams.py:44:#%  guidependency: 
layer,column
grass7/vector/v.gsflow.hruparams/v.gsflow.hruparams.py:51:#%  guidependency: 
layer,column
grass7/gui/wxpython/wx.metadata/t.info.iso/t.info.iso.py:25:#% guidependency: 
input

Something new to learn.

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Importing .tif

[Nikos Alexandris]

* Rich Shepard  [2018-07-16 08:04:59 -0700]:


On Sat, 14 Jul 2018, Nikos Alexandris wrote:


gdalinfo int_43120C4404.tif -proj4 -nomd


Nilos/Helmut:

 For some reason I looked at the .xml file rather than running gdalinfo on
the 100th/quad .tif file. Creating a new location with that proj.4 string
allowed me to import the DLQ, but ... I still needed to use the '-o'
projection override. IIRC, the proj.4 string units are feet, but the image
itself is apparently in meters. Well, it's ESRI software and as long as it
imports I'm happy.

 The new imported raster map reprojected to the project location, so the
remaining question (which may not have an answer) is why three separate
color bands are imported (RGB)? The display is monochrome and all three
separate images *.red, *.green, and *.blue look the same on the monitor. Can
I display this DLQ in color? (I think the last time I used aerial
photographs or satellite imagery was with grass-4.1 or -5.x.)

Rich


I also think there might be something special to these images.
From another example file, LDQ-42124C2:

```
gdalinfo intensity_42124C2_1.tif -norat -nomd
..
Band 1 Block=64x64 Type=Byte, ColorInterp=Gray
 Description = Band_1
 Min=5.000 Max=255.000
 Minimum=5.000, Maximum=255.000, Mean=150.269, StdDev=39.671
 NoData Value=0
 Overviews: 583x908, 292x454, 146x227, 73x114, 37x57
Band 2 Block=64x64 Type=Byte, ColorInterp=Undefined
 Description = Band_2
 Min=5.000 Max=255.000
 Minimum=5.000, Maximum=255.000, Mean=150.269, StdDev=39.671
 NoData Value=0
 Overviews: 583x908, 292x454, 146x227, 73x114, 37x57
Band 3 Block=64x64 Type=Byte, ColorInterp=Undefined
 Description = Band_3
 Min=5.000 Max=255.000
 Minimum=5.000, Maximum=255.000, Mean=150.269, StdDev=39.671
 NoData Value=0
 Overviews: 583x908, 292x454, 146x227, 73x114, 37x57
```

Is it "ok" to have identical stats for all layers?

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Importing .tif

[Nikos Alexandris]

* Helmut Kudrnovsky  [2018-07-14 00:59:52 -0700]:


gdalinfo int_43120C4404.tif -proj4 -nomd

Driver: GTiff/GeoTIFF
Files: int_43120C4404.tif
  int_43120C4404.tif.ovr
  int_43120C4404.tif.aux.xml
Size is 865, 1739
Coordinate System is:
PROJCS["NAD_1983_CORS96_UTM_Zone_10N",
   GEOGCS["GCS_NAD_1983_CORS96",
   DATUM["NAD_1983_CORS96",
   SPHEROID["GRS_1980",6378137,298.257222101]],
   PRIMEM["Greenwich",0],
   UNIT["degree",0.0174532925199433]],
   PROJECTION["Transverse_Mercator"],
   PARAMETER["latitude_of_origin",0],
   PARAMETER["central_meridian",-123],
   PARAMETER["scale_factor",0.9996],
   PARAMETER["false_easting",50],
   PARAMETER["false_northing",0],
   UNIT["metre",1,
   AUTHORITY["EPSG","9001"]]]
PROJ.4 string is:
'+proj=utm +zone=10 +ellps=GRS80 +units=m +no_defs '
Origin = (711475.000,4798302.500)
Pixel Size = (0.500,-0.500)
Corner Coordinates:
Upper Left  (  711475.000, 4798302.500) (120d23'32.93"W, 43d18'28.22"N)
Lower Left  (  711475.000, 4797433.000) (120d23'34.13"W, 43d18' 0.06"N)
Upper Right (  711907.500, 4798302.500) (120d23'13.75"W, 43d18'27.78"N)
Lower Right (  711907.500, 4797433.000) (120d23'14.96"W, 43d17'59.62"N)
Center  (  711691.250, 4797867.750) (120d23'23.94"W, 43d18'13.92"N)
Band 1 Block=128x128 Type=Byte, ColorInterp=Gray
 Min=15.000 Max=223.000
 Minimum=15.000, Maximum=223.000, Mean=111.348, StdDev=14.186
 NoData Value=0
 Overviews: 433x870, 217x435


steps here

(1) create location by georeferenced file int_43120C4404.tif


(2)
r.in.gdal input=D:\temp\LDQ-43120C4\2012_OLC_Eastern OR
TIR\Intensity\int_43120C4404.tif output=fdgdfgf
WARNING: Datum  not recognised by GRASS and no parameters
found
Importing raster map ...

the datum isn't recognized, but raster imported

see

https://epsg.io/6782
https://epsg.io/6781


Helmut,

I did that before too. Did you also note that it takes "too much" time to
create the Location using the '.tif' file?

As well, trying a few things further, I have seen similar problems such
as the ones Rich mentions (trying to reproject, etc.).

This is why I ended up in using the Shapefile as a source.

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Importing .tif

[Nikos Alexandris]

Rich, I downloaded a sample LDQ file: 'LDQ-43120C4.zip'.

Some '.tif' files are inside the subdirectory 'Intensity'. GDAL says for
one of them:
```
gdalinfo int_43120C4404.tif -proj4 -nomd

Driver: GTiff/GeoTIFF
Files: int_43120C4404.tif
  int_43120C4404.tif.ovr
  int_43120C4404.tif.aux.xml
Size is 865, 1739
Coordinate System is:
PROJCS["NAD_1983_CORS96_UTM_Zone_10N",
   GEOGCS["GCS_NAD_1983_CORS96",
   DATUM["NAD_1983_CORS96",
   SPHEROID["GRS_1980",6378137,298.257222101]],
   PRIMEM["Greenwich",0],
   UNIT["degree",0.0174532925199433]],
   PROJECTION["Transverse_Mercator"],
   PARAMETER["latitude_of_origin",0],
   PARAMETER["central_meridian",-123],
   PARAMETER["scale_factor",0.9996],
   PARAMETER["false_easting",50],
   PARAMETER["false_northing",0],
   UNIT["metre",1,
   AUTHORITY["EPSG","9001"]]]
PROJ.4 string is:
'+proj=utm +zone=10 +ellps=GRS80 +units=m +no_defs '
Origin = (711475.000,4798302.500)
Pixel Size = (0.500,-0.500)
Corner Coordinates:
Upper Left  (  711475.000, 4798302.500) (120d23'32.93"W, 43d18'28.22"N)
Lower Left  (  711475.000, 4797433.000) (120d23'34.13"W, 43d18' 0.06"N)
Upper Right (  711907.500, 4798302.500) (120d23'13.75"W, 43d18'27.78"N)
Lower Right (  711907.500, 4797433.000) (120d23'14.96"W, 43d17'59.62"N)
Center  (  711691.250, 4797867.750) (120d23'23.94"W, 43d18'13.92"N)
Band 1 Block=128x128 Type=Byte, ColorInterp=Gray
 Min=15.000 Max=223.000
 Minimum=15.000, Maximum=223.000, Mean=111.348, StdDev=14.186
 NoData Value=0
 Overviews: 433x870, 217x435
```

Indeed, using this file's geo-metadata to create a new GRASS location,
ends up in `r.in.gdal` complaining while performing the projection
check.

Perhaps the geo-metadata in these .tif files are not a good match for
GRASS GIS (and its mechanism to detect reference systems).

The 'Shapefiles' directory contains various ancillary vector maps. One
such map is 'OLC_1-100th_Quadrangle_Index.shp' whose corresponding .prj
file content is:

PROJCS["NAD_1983_HARN_StatePlane_Oregon_North_FIPS_3601_Feet_Intl",GEOGCS["GCS_North_American_1983_HARN",DATUM["D_North_American_1983_HARN",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",8202099.737532808],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-120.5],PARAMETER["Standard_Parallel_1",44.34],PARAMETER["Standard_Parallel_2",46.0],PARAMETER["Latitude_Of_Origin",43.66],UNIT["Foot",0.3048]]

The file 'OLC_EASTERN_OR_TIR_2012_0_75_UTM.prj', however, appears to be
a match for the .tif file (?).

PROJCS["NAD_1983_CORS96_UTM_Zone_10N",GEOGCS["GCS_NAD_1983_CORS96",DATUM["D_NAD_1983_CORS96",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",50.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-123.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]

I used this vector map as a source, created a new Location/Mapset,
imported one '.tif' file without problems. The "FIPS 3601" is not the
correct one to use for the '.tif' files, in this example LDQ I
downloaded.

Hope the above is useful for you too.

Nikos


* Rich Shepard  [2018-07-13 15:47:34 -0700]:


 I've not found specific information on importing *.tif rasters so I winged
it to import a LiDAR Digital Quad (LDQ) map. This is my work flow and how
grass7.5svn responded.

 0. There are 4 files for each of the LDQs: *.aux, *.tfw, *.tif, and
*.tif.xml.

 1. Looking at the file, *.tif.xml, I learned the projection is
FIPS 3601. A web page listing FIPS codes and their EPSG equivalents showed
the latter is 32126.

 2. The command, 'grass75 -c EPSG:32126' created a new location.

 3. r.in.gdal 
in=$HOME/projects/oregon/estacada-rock/data/topography/estacada-45122c3/2009_OLC_Hood-to-Coast/45122c3302.tif
 out=ldq
ERROR: Projection of dataset does not appear to match current location.

  Dataset PROJ_INFO is:
  name: NAD83(HARN) / Oregon North
  datum: nad83harn
  ellps: grs80
  proj: lcc
  lat_1: 46
  lat_2: 44.34
  lat_0: 43.66
  lon_0: -120.5
  x_0: 250
  y_0: 0
  towgs84: 0,0,0,0,0,0,0
  no_defs: defined

  ERROR: proj

 This is my first question: Since the .xml file showed the projection as
FIPS 3601, and the equivalent EPSG code is 32126 is used to create the
location, why does grass75 see a mis-match?

 4. r.in.gdal -o 
in=$HOME/projects/oregon/estacada-rock/data/topography/estacada-45122c3/2009_OLC_Hood-to-Coast/45122c3302.tif
 out=ldq
Over-riding projection check
Importing 3 raster bands...
Importing raster map ...
100%
Importing raster map ...
100%
Importing raster map ...
100%

 This is my second question: While I can display each map in the monitor,
they 

Re: [GRASS-user] script option

[Nikos Alexandris]

* Frank David  [2018-07-13 19:26:36 +0200]:




Le 11/07/2018 à 09:31, Nikos Alexandris a écrit :

* Frank David  [2018-07-10 15:44:51 +0200]:




Le 10/07/2018 à 12:25, Nikos Alexandris a écrit :

* frank  [2018-07-10 08:05:29 +0200]:


Hi dear grass users,

I'm trying to get two field name of an attribute table 
(ctx_map) by the options of the gui. But I can access only at 
the first one and I don't find why...??. See my code below :


#%option G_OPT_V_MAP
#% key: ctx_map
#% description: vector data
#% required : yes
#% guidependency:layer,ctx_wf,ctx_wtg
#%end
#%option G_OPT_V_FIELD
#% key:ctx_layer
#% guidependency:ctx_wf,ctx_wtg
#%end
#%option G_OPT_DB_COLUMN
#% key:ctx_wf
#% description: wf name
#% required: yes
#%end
#%option G_OPT_DB_COLUMN
#% key:ctx_wtg
#% description: wtg name
#% required: yes
#%end

Thank you for your help.
Frank


Dear Frank,

Hello Nikos,


if you refer to the last two "column" options,
how do you try to access these, in the script?

Like,

options['ctx_wf']
options['ctx_wtg']

Absolutely


?

Also, what .xml does

x.ScriptName --interface-description

generate?
There is no error on compilation, and help tab display Flags and 
Parameters information, like (french accent are not well encoded):


Parameters:
obj_map=name [required]
Name of vector map
MH ou WTG projet
obj_layer=string
Layer number or name
Vector features can have category values in different layers. This 
number determines which layer to use. When used with direct OGR 
access this is the layer name.

Default: 1
obj_name=name [required]
Nom de l'objet
*ctx_map=name [required] **
**Name of vector map **
*Contexte éolien *
**ctx_layer=string **
**Layer number or name **
**Vector features can have category values in different layers. 
This number determines which layer to use. When used with direct 
OGR access this is the layer name. **

**Default: 1 **
**ctx_wf=name [required] **
*Nom du parc *
**ctx_wtg=name [required] **
*Identifiant éolienne


Ah, and what does `x.ScriptName --ui` return?
Maybe an encoding related issue? Related entries in trac:
https://trac.osgeo.org/grass/search?q=encoding+french=1=on=on=on=on


Nikos

Hello Nikos,

x.myscript --ui just launch the gui box.
I have found a trick to run the script. Actually I need one field from 
on vector table and 2 fields from an other vector table. like that it 
works :


#%option G_OPT_V_MAP
#% label: MH ou WTG projet
#% required : yes
#% guidependency: layer,obj
#%end
#%option G_OPT_V_FIELD
#% guidependency: obj
#%end
#%option G_OPT_DB_COLUMN
#% key: obj
#% description: Nom de l'objet
#% required: yes
#%end


#%option G_OPT_V_MAP
#% key: ctx_map
#% label: Contexte éolien
#% required : yes
#% guidependency:ctx_layer,ctx_wf,ctx_wtg
#%end
#%option G_OPT_V_FIELD
#% key:ctx_layer
#% guidependency:ctx_wf,ctx_wtg
#%end
#%option G_OPT_DB_COLUMN
#% key:ctx_wf
#% description: Nom du parc
#% required: yes
#%end
#%option G_OPT_DB_COLUMN
#% key:ctx_wtg
#% description: Identifiant éolienne
#% required: yes
#%end

But as soon as I try to name myself the first table by Key parameter 
like #%key : obj_map and add key name at layer (like in the second 
part of the code) It does not work anymore... It looks like the fisrt 
map is automatically named "map" by the gui. I don't mind but I find 
this strange. I'm sure there is a explanation,somewhere...

Cheers,
Frank


Perhaps there is something, and experienced developers will notice it fast.
Yet, why don't you share a minimal working code? At least the interface,
so I can try myself to compile. Even in private if you
prefer. I am willig to help in understanding this error. So I will learn
about it as well.

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Start in text mode: define new location with proj.4 string

[Nikos Alexandris]

* Rich Shepard  [2018-07-11 09:58:52 -0700]:


On Wed, 11 Jul 2018, Nikos Alexandris wrote:


Thanks. Then, the help's description deserves an update. Currently:

-gtext  use text based interface (show welcome screen) and set as default


Nikos,

 Then I guess an update is due. See attached screenshot. It has part of the
virtual console with the entered command and the resulting location wizard.

Best regards,

Rich


Sure, I tried it before suggesting to update the help's description.
I think it was not like that. Since I don't use frequently this option,
I didn't notice.

Thanks, Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Start in text mode: define new location with proj.4 string

[Nikos Alexandris]

* Rich Shepard  [2018-07-11 09:24:01 -0700]:


On Wed, 11 Jul 2018, Nikos Alexandris wrote:


By the way, the -gtext option is not relevant. It merely shows the
welcome/logo screen when launching a GRASS GIS session, then jumps back
to the command line.


Nikos,

 Not with 7.5svn. When I use '-gtext' I get the location wizard. After I
run through the process it goes away and I am left at the command line.


Thanks. Then, the help's description deserves an update. Currently:

-gtext  use text based interface (show welcome screen) and set as default

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Start in text mode: define new location with proj.4 string

[Nikos Alexandris]

* Rich Shepard  [2018-07-11 08:24:27 -0700]:


On Wed, 11 Jul 2018, Nikos Alexandris wrote:


I see. Maybe we should file an enhancement ticket, to provide this option
through the command line too?


Nikos,

 I don't know how common this is. This project is the first time I've had
DEM source files in ESRI GRID (*.adf) format and this format needs the
proj.4 string if the GUI location wizard is not used. Using the wizard from
the command line with the -gtext option works well, so the only need for a
new command line option is if the import will be handled by a script rather
than manually.


By the way, the -gtext option is not relevant. It merely shows the
welcome/logo screen when launching a GRASS GIS session, then jumps back
to the command line.

GRASS GIS remembers which option you used last time. That means, `grass
-gui` will be the "default": next time you execute `grass` it will
launch the GUI.

If you change your mind and do `grass -text`, this will the "default"
for next time you execute `grass`: it will launch only a command line
GRASS GIS session.

If you do `grass -gtext` it will end up with a command line session, not
the GUI.

Please correct me if I am mistaken.
Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Start in text mode: define new location with proj.4 string

[Nikos Alexandris]

* Rich Shepard  [2018-07-11 05:44:47 -0700]:


On Wed, 11 Jul 2018, Nikos Alexandris wrote:


The grass --help does not mention support for "Proj" strings. Only
geo(-referenced)file and EPSG.


Nikos,

 Yep. That's why I asked. So, on the infrequent occasions when source data
does not have a useful EPSG code but 'gdalinfo -proj4' provies the string
using the -gtext grass startup option allows that string to be used to
define a new location.


I see. Maybe we should file an enhancement ticket, to provide this
option through the command line too?

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] question on r.out.gdal in a loop

[Nikos Alexandris]

* Nikos Alexandris  [2018-07-11 09:14:47 +0200]:



Gabriel Cotlier wrote:


   I'm using grass 7.4.1 trying to export  all raster layers in the current
   mapset out of grass to a folder as GeoTiff files though a for loop from
   the python shell  as follows and I'm getting the error in red...
   What could be the problem?
   Thanks a lot in advance.
   Regards,
   Gabriel
   >>>import grass.script as gscript
   >>>rastlist=grass.read_command("g.list",type="rast")
   >>>rastlist
   F121996
   F121997
   F141999
   F142000


Micha Silver:

 Try:
 rastlist=grass.read_command("g.list",type="rast").split()


[..]



For me it works like:

rasters=grass.read_command('g.list', type='raster', 
separator='comma').split(',')


For splitting on newlines, there is splitlines(), i.e.

```
rasters = grass.read_command('g.list', type='raster').splitlines()
for raster in rasters:
   print "Raster:", raster
   raster += '.tif'
   print "Raster with extension:", raster
```

See https://docs.python.org/2/library/stdtypes.html#str.splitlines

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] script option

[Nikos Alexandris]

* Frank David  [2018-07-10 15:44:51 +0200]:




Le 10/07/2018 à 12:25, Nikos Alexandris a écrit :

* frank  [2018-07-10 08:05:29 +0200]:


Hi dear grass users,

I'm trying to get two field name of an attribute table (ctx_map) 
by the options of the gui. But I can access only at the first one 
and I don't find why...??. See my code below :


#%option G_OPT_V_MAP
#% key: ctx_map
#% description: vector data
#% required : yes
#% guidependency:layer,ctx_wf,ctx_wtg
#%end
#%option G_OPT_V_FIELD
#% key:ctx_layer
#% guidependency:ctx_wf,ctx_wtg
#%end
#%option G_OPT_DB_COLUMN
#% key:ctx_wf
#% description: wf name
#% required: yes
#%end
#%option G_OPT_DB_COLUMN
#% key:ctx_wtg
#% description: wtg name
#% required: yes
#%end

Thank you for your help.
Frank


Dear Frank,

Hello Nikos,


if you refer to the last two "column" options,
how do you try to access these, in the script?

Like,

options['ctx_wf']
options['ctx_wtg']

Absolutely


?

Also, what .xml does

x.ScriptName --interface-description

generate?
There is no error on compilation, and help tab display Flags and 
Parameters information, like (french accent are not well encoded):


Parameters:
obj_map=name [required]
Name of vector map
MH ou WTG projet
obj_layer=string
Layer number or name
Vector features can have category values in different layers. This 
number determines which layer to use. When used with direct OGR access 
this is the layer name.

Default: 1
obj_name=name [required]
Nom de l'objet
*ctx_map=name [required] **
**Name of vector map **
*Contexte éolien *
**ctx_layer=string **
**Layer number or name **
**Vector features can have category values in different layers. This 
number determines which layer to use. When used with direct OGR access 
this is the layer name. **

**Default: 1 **
**ctx_wf=name [required] **
*Nom du parc *
**ctx_wtg=name [required] **
*Identifiant éolienne


Ah, and what does `x.ScriptName --ui` return?
Maybe an encoding related issue? Related entries in trac:
https://trac.osgeo.org/grass/search?q=encoding+french=1=on=on=on=on

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Start in text mode: define new location with proj.4 string

[Nikos Alexandris]

* Micha Silver  [2018-07-10 22:34:53 +0300]:


  Reading the Startup page I do not see a way to apply the proj.4 string
to
create a new location on the command line. I know this is an option with
the
GUI location wizard but do not see the appropriate '-c' modifier to do
this
on the command line. If one of the startup manual options will do this,
and
I'm just not seeing it, please point me to it.

Rich

  What you've suggested in past posts seems to work fine (point to a
  shapefile with accompanying *.prj):

  grass -c /home/micha/work/BIDR/Ashalim/GIS/analysis_regions.shp
  test_location
  Creating new GRASS GIS location/mapset...
  .
  GRASS 7.4.0 (test_location):~ > g.proj -p
  -PROJ_INFO-
  name   : Israel_1993_Israeli_TM_Grid
  ellps  : grs80
  proj   : tmerc
  lat_0  : 31.7343936111
  lon_0  : 35.2045169445
  k  : 1.067
  x_0    : 219529.584
  y_0    : 626907.39
  no_defs    : defined
  -PROJ_UNITS
  unit   : Meter
  units  : Meters
  meters : 1
  GRASS 7.4.0 (test_location):~ >

  Unless I'm not understanding the problem.


The grass --help does not mention support for "Proj" strings. Only
geo(-referenced)file and EPSG.

Usage:
 grass75 [-h | -help | --help | --h] [-v | --version]
 [-c | -c geofile | -c EPSG:code[:datum_trans]]
 [-e] [-f] [-text | -gtext | -gui] [--config param]
 [[[GISDBASE/]LOCATION_NAME/]MAPSET]
 grass75 [FLAG]... GISDBASE/LOCATION_NAME/MAPSET --exec EXECUTABLE [EPARAM]...
 grass75 -c [geofile | EPSG] --tmp-location --exec EXECUTABLE [EPARAM]...

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Vector map point deleted but still displays

[Nikos Alexandris]

* Rich Shepard  [2018-07-10 15:11:32 -0700]:


 I removed a point from a vector map but it still shows up on the display
monitor (see attached screenshot, point #2). The attribute table no longer
contains that row:

cat|y|x|label
1|45.299844|-122.353975|USGS gauge
3|45.302761|-122.358851|Building

 I've tried to remove this point from the display using v.edit and the
vector editor in the GUI map display window. I've removed that features map
from the display and re-displayed it and killed the grass session and started a
new one, but that point #2 still shows up on the map.

 What have I done incorrectly?


Please post (also) the exact `v.edit` command.

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] question on r.out.gdal in a loop

[Nikos Alexandris]

Gabriel Cotlier wrote:


I'm using grass 7.4.1 trying to export  all raster layers in the current
mapset out of grass to a folder as GeoTiff files though a for loop from
the python shell  as follows and I'm getting the error in red...
What could be the problem?
Thanks a lot in advance.
Regards,
Gabriel
>>>import grass.script as gscript
>>>rastlist=grass.read_command("g.list",type="rast")
>>>rastlist
F121996
F121997
F141999
F142000


Micha Silver:

  Try:
  rastlist=grass.read_command("g.list",type="rast").split()


[..]

For me it works like:

rasters=grass.read_command('g.list', type='raster', 
separator='comma').split(',')

I wonder why the 'comma' is not mentioned for the separator option, when
asking for the module's help:
```
Lists available GRASS data base files of the user-specified data type 
optionally using the search pattern.

Usage:
g.list [-iretmpf] type=datatype[,datatype,...] [pattern=string]
  [exclude=string] [mapset=name[,name,...]] [separator=character]
  [region=name] [output=name] [--overwrite] [--help] [--verbose]
  [--quiet] [--ui]

Flags:
 -i   Ignore case
 -r   Use basic regular expressions instead of wildcards
 -e   Use extended regular expressions instead of wildcards
 -t   Print data types
 -m   Print fully-qualified map names (including mapsets)
 -p   Pretty printing in human readable format
 -f   Verbose listing (also list map titles)

Parameters:
  type   Data type(s)
 options: raster,raster_3d,vector,label,region,group,all
   pattern   Map name search pattern (default: all)
   exclude   Map name exclusion pattern (default: none)
mapset   Name of mapset to list (default: current search path)
 separator   Field separator
 default: newline
region   Name of saved region for map search (default: not restricted)
output   Name for output file
```

This on
```
g.version -r
GRASS 7.5.svn (2018)
libgis Revision: 72327
libgis Date: 2018-03-06 12:12:44 +0100 (Tue, 06 Mar 2018)
```

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] script option

[Nikos Alexandris]

* frank  [2018-07-10 08:05:29 +0200]:


Hi dear grass users,

I'm trying to get two field name of an attribute table (ctx_map) by 
the options of the gui. But I can access only at the first one and I 
don't find why...??. See my code below :


#%option G_OPT_V_MAP
#% key: ctx_map
#% description: vector data
#% required : yes
#% guidependency:layer,ctx_wf,ctx_wtg
#%end
#%option G_OPT_V_FIELD
#% key:ctx_layer
#% guidependency:ctx_wf,ctx_wtg
#%end
#%option G_OPT_DB_COLUMN
#% key:ctx_wf
#% description: wf name
#% required: yes
#%end
#%option G_OPT_DB_COLUMN
#% key:ctx_wtg
#% description: wtg name
#% required: yes
#%end

Thank you for your help.
Frank


Dear Frank,

if you refer to the last two "column" options,
how do you try to access these, in the script?

Like,

options['ctx_wf']
options['ctx_wtg']

?

Also, what .xml does

x.ScriptName --interface-description

generate?

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Unable to compile my module. ERROR: Variable 'LOCATION_NAME' not set

[Nikos Alexandris]

Leonida,

there is nothing to be seen (at least with my client) below the "but it
returns:".

Is the script available to test?  PM if you want.

Nikos

* leonidas  [2018-07-06 09:32:26 -0700]:


I'm trying to compile my script as grass module.
I followed the instructions of this  tutorial

.
I tried to compile my script as /sudo/ with:

but it returns:








signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[Nikos Alexandris]

* 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 lot again.
Best regards,
Gabriel


It is friendly, from the Operating System's side, trying to help in
handling GRASS GIS' .region files. Obviously, though, not required in
this case. It looks like you would need to search for how to tell the
Operating System to ignore .region files.


Thanks for the summary. In a shorter version:

r.in.gdal -a input=Fxy # for all images
g.region raster=Fx # only once
i.nightlights.intercalibration ...

or

r.in.gdal input=Fxy  # for all images
r.region -a map=Fxy  # for all images
g.region raster=Fx   # only once
i.nightlights.intercalibration ...


More detailed

# import *all* images with
r.in.gdal -a input=Fxy

(
This is the import command for one image. All related images have to be
imported like that. Easier via a for loop, i.e., under Linux, and within
from the directory where all images reside,

for RASTER in Fxy*.tif ;do r.in.gdal -a input=$RASTER output=$(basename $RASTER 
.tif) ;done

This is a somewhat more elaborated one-line command. This is easily
to be done through the GUI: you can select a "directory" from
inside which to import images.

I recall also a related post from Helmut, on how to approach this in
Windows, in the command line.
)

# set the computational region
g.region raster=Fxy

# inter-calibrate your images
i.nightlights.intercalibration ...


What about r.region?

First, some clarifications:

- `r.in.gdal` imports a raster/image in to the GRASS GIS data base, by
 converting it in a GRASS GIS native raster format. It also sets the
 extent and resolution of a raster/image.

- `r.region` works directly on the images extent. It is a tool to modify
 the raster's metadata directly.

- `g.region` set the computational region for a GRASS GIS Location/Mapset,
which is then what almost all raster modules will consider as the
"active" region to perform computations on.


The `r.region -a` would come in play in case you have already imported
the image without the `-a` option for `r.in.gal`, say Fxy. and then you'd want 
to fix the pixel size
imprecision issue that Markus pointed out.

That would be:

r.in.gdal input=Fxy  # for all images
r.region -a map=Fxy  # for all images
g.region raster=Fxy  # only once!
i.nightlights.intercalibration  # for all related images


Since you are re-importing the images, using `r.in.gdal -a`, you don't
need to employ r.region at any step.


Finally,

if the above won't work, then there be something else that causes the
problem.

Please, do not hesitate to write back about this. We all have our own way
of learning. If whatever is discussed so far, is still not clear enough,
then let us try one more time: I will try to learn/improve how to better
communicate, in written form, these command instructions. And you could try to
go through what is written one more time, and take notes, one-by-one.

Best, Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Semi-automatic classification with GRASS modules

[Nikos Alexandris]

* Michele Zurlo  [2018-07-06 07:27:29 +0200]:





Thank you for your answer. I will add a texture channel to run i.cluster.



I recall that I naively have tried to "abuse" the module by using the
same input image twice!


Only a curiosity I know that i.cluster is an old way to approach to
aerial images, but in the future will be there the possibility to use
the module even with an image?
Sometimes to have this image cluster could be very useful.


The input can be any set of raster/image. It's a k-means based
clustering algorithm after all and the classification is then performed
with `i.maxlik`.

Michele, if your goal is to get "segments", then classify these, why not
work with `i.segment` or/and `/addons/i.superpixels.slic`?

I guess you already know all this. I hope the discussion stimulates
a productive brainstorming.

Cheers, Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Semi-automatic classification with GRASS modules

[Nikos Alexandris]

Michele Zurlo:

[..]


I use this e-mail also to make a question, during a work I tried to
classify a pancromatic aerial image using an unsupervised approach.
Running i.cluster it gave me an error indicating that it needs more
than two classes. What I missed?


Dear Michele, the algorithm behind i.cluster does not work with less
than two input images. See also:
https://trac.osgeo.org/grass/ticket/1908.

Kind of a common practice, is to use another input derived from the first.
I.e., some synthetic image, derived from the aerial panchromatic one.
See https://grass.osgeo.org/grass74/manuals/r.texture.html.

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Possible Grass Bug

[Nikos Alexandris]

* Rich Shepard  [2018-06-30 16:04:33 -0700]:


On Sun, 1 Jul 2018, ubuntu wrote:


What is the difference between the console at the layer manager tab and
the GRASS 7.4.0 (nc_spm_08_grass7):~ > at the ubuntu terminal? when should
I use the console and when the other one? And what is the difference
between wx0,1,2, ... windows and the Grass GIS Map Display window (the one
that loads along with the layer manager)?


Nozhan,

 You will find that you have more control working at the console,
particularly when the wxGUI does not recognize files you want to use. The
GUI can be quite useful, but working at the console is preferred by those
who are used to working on consoles in linux, *BSD, and various unices.
Also, you can write scripts to perform repetative or complex processes and
run them from the command line. The GUI does not support this.


Please note that (Python) scripting is possible via the GUI as well. There is a
Python tab and a simple Python script editor integrated (since at least
version 7.4). Simple examples are also included. I don't use them, so I don't
have an opinion about their usability.

There is also the wxGUI Graphical Modeler. It too has the script
editor integrated. In 2008, I requested for such an option:
https://trac.osgeo.org/grass/ticket/131. Not speaking Python at the time,
I asked for help to learn. I think it can be a good starting point in Python
scripting for GRASS GIS. The 'Help' menu offers links to various
resources. Adding one or two more resources, like
https://github.com/wenzeslaus/python-grass-addon, is meaningful.

Nikos


 Either on a 'getting started' or wiki page is a list of commands to start
grass. In your installation 'grass' and 'grass74' are synonymous. If you run
multiple versions (e.g., 7.4.x and 7.5svn) then you want to assign each to a
unique name.




signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[Nikos Alexandris]

* 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 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.


I guess this is worth being documented in the manual of the add-on. Would
it also make sense to let the module attempt to perform this "correction"?

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[Nikos Alexandris]

* 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

Veronica is right, and I am ignorant for so many things when it comes to 
Windows.

In Linux, one may use the syntax `some_command` or
$(some_command). It's a smart way to feed-in longer list of items, such
as map names in GRASS GIS. Note, the former is old-style, so best to use the $()
notation (if of interest, see
https://unix.stackexchange.com/a/5782/13011).

You might want to re-check the extent you have set, so as to
get rid of the "360 degree EW extent is exceeded by 0.999827 cells"
messages (?). Depending on how you have set your region, maybe the `-a`
option for `g.region` would help (?).

The last failing image is not a computational error. The error
message
--%<---

ValueError: The selected model does not know about this
combination of Satellite + Year!

--->%--
means that there are no coefficients for satellite "F18" and for the
year 2013. You may read this in
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_coefficients.py#L99
and the referenced papers, of course.

For various reasons, I did not improve the script in
handling this situations. I just let it emit an error message. I hardly
remember having modified this message to say something like "There are
given coefficients for satellite F?? and Year ". But I can't trace
anything in my local repository.

(
Note, there are many newer algorithms. It would be obviously great to
integrate some of them in the existing module. If a new model bases upon
a similar math formula, then it's only necessary to add:

1. a new set of coefficients in 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_coefficients.py#L38

2. a new equation in 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_equations.py#L15

3. a new subclass, for the new model, in 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_models.py

Maybe more work if there is a substantially different math logic.
)

Thanks, Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.nightlights.intercalibration, Problem with running code

[Nikos Alexandris]

Dear Gabriel,

I realise, now, that if you try to run something with $() or backticks
in a input box, in the (G)UI, it won't work.

Try, please, directly the command line (or the Console in the GUI):

i.nightlights.intercalibration image=$(g.list rast pattern=F* sep=,) suffix=c 
model=elvidge2014


The following will _not_ work:

i.nightlights.intercalibration image= image=$(g.list rast pattern=F* sep=,) 
suffix=suffix=c model=elvidge2014


Nikos

ps- Kind request, please keep posting on the list.



* Nikos Alexandris  [2018-06-20 04:07:27 +0200]:


Dear Gabriel,

try this:

i.nightlights.intercalibration image=$(g.list rast pattern=F* sep=,)

Details: the command `g.list` is not actually run, I think.

Use the proper syntax, which is to enclose the command with a
"$(g.list type=raster)".
In my repository, and in the the manual there is still some demo
command using backticks, like:  

i.nightlights.intercalibration image=`g.list rast pattern=F* sep=,`

which is the old style. Better the new style, i.e.:

i.nightlights.intercalibration image=$(g.list rast pattern=F* sep=,)

If you don't do this, the module will "think" that the option `image`
is fed with only:

image=g.list

and the rest of the line will be treated as extra arguments.

Nikos
- Original Message -
From:
"Gabriel Cotlier" 

To:

Cc:

Sent:
Tue, 19 Jun 2018 12:44:33 -0300
Subject:
[GRASS-user] i.nightlights.intercalibration, Problem with running code

Problem with running _i.nightlights.intercalibration
_
_ for the
_Elvidge(2014) model-coefficients.

 Steps I have followed:

1.I have imported the following layers:

(Tue Jun 19 12:29:20
2018) 


g.list
type=raster 


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

(Tue Jun 19 12:29:21 2018) Command finished (0
sec)
 

 

2. I have run the code on the dialog box of
_i.nightlights.intercalibration
__ :

_

_
_

3. I got the following error message:

(Tue Jun 19 12:31:26 2018)                           
                          

i.nightlights.intercalibration image=g.list type=raster         
                                             
       suffix=c model=elvidge2014

|i Inter-satellite calibration of DMSP-OLS Nighttime Stable Lights

WARNING: Operating on current region

|> Calibrating average visible Digital Number values

WARNING: No data base element files found

Traceback (most recent call last):

  File "C:UsersGabrielAppDataRoamingGRASS7addons/scrip

ts/i.nightlights.intercalibration.py [1]", line 525, in 

    sys.exit(main())

  File "C:UsersGabrielAppDataRoamingGRASS7addons/scrip

ts/i.nightlights.intercalibration.py [2]", line 340, in main

    model_parameters = retrieve_model_parameters(Model,

*args)

  File "C:UsersGabrielAppDataRoamingGRASS7addons/scrip

ts/i.nightlights.intercalibration.py [3]", line 242, in

retrieve_model_parameters

    model = model_class(*args, **kwargs)

  File "C:UsersGabrielAppDataRoamingGRASS7addonsetci

.nightlights.intercalibrationintercalibration_models.py",

line 155, in __init__

    CalibrationModel.__init__(self, author, satellite, year)

  File "C:UsersGabrielAppDataRoamingGRASS7addonsetci

.nightlights.intercalibrationintercalibration_models.py",

line 43, in __init__

    year=self.year)

  File "C:UsersGabrielAppDataRoamingGRASS7addonsetci

.nightlights.intercalibrationintercalibration_models.py",

line 63, in verify_year

    available_years = COEFFICIENTS[author][satellite].keys()

KeyError: 'g.l'

(Tue Jun 19 12:31:27 2018) Command finished (1 sec)           
                 

Thanks a lot for your help
 and
assistance
.

Best regards,

Gabriel 



Links:
--
[1] http://i.nightlights.intercalibration.py
[2] http://i.nightlights.intercalibration.py
[3] http://i.nightlights.intercalibration.py




___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailma

Re: [GRASS-user] i.nightlights.intercalibration, Problem with running code

[Nikos Alexandris]

Dear Gabriel,

try this:

i.nightlights.intercalibration image=$(g.list rast pattern=F* sep=,)

Details: the command `g.list` is not actually run, I think.

Use the proper syntax, which is to enclose the command with a
"$(g.list type=raster)".
In my repository, and in the the manual there is still some demo
command using backticks, like:  

i.nightlights.intercalibration image=`g.list rast pattern=F* sep=,`

which is the old style. Better the new style, i.e.:

i.nightlights.intercalibration image=$(g.list rast pattern=F* sep=,)

If you don't do this, the module will "think" that the option `image`
is fed with only:

image=g.list

and the rest of the line will be treated as extra arguments.

Nikos
- Original Message -
From:
 "Gabriel Cotlier" 

To:

Cc:

Sent:
Tue, 19 Jun 2018 12:44:33 -0300
Subject:
[GRASS-user] i.nightlights.intercalibration, Problem with running code

Problem with running _i.nightlights.intercalibration
_
_ for the 
_Elvidge(2014) model-coefficients.

 Steps I have followed:

1.I have imported the following layers:

(Tue Jun 19 12:29:20
2018) 


g.list
type=raster 


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

(Tue Jun 19 12:29:21 2018) Command finished (0
sec) 
 

 

2. I have run the code on the dialog box of
_i.nightlights.intercalibration
__ :

_

_
_

3. I got the following error message:

(Tue Jun 19 12:31:26 2018)                           
                          

i.nightlights.intercalibration image=g.list type=raster         
                                             
       suffix=c model=elvidge2014

|i Inter-satellite calibration of DMSP-OLS Nighttime Stable Lights

WARNING: Operating on current region

|> Calibrating average visible Digital Number values

WARNING: No data base element files found

Traceback (most recent call last):

  File "C:UsersGabrielAppDataRoamingGRASS7addons/scrip

ts/i.nightlights.intercalibration.py [1]", line 525, in 

    sys.exit(main())

  File "C:UsersGabrielAppDataRoamingGRASS7addons/scrip

ts/i.nightlights.intercalibration.py [2]", line 340, in main

    model_parameters = retrieve_model_parameters(Model,

*args)

  File "C:UsersGabrielAppDataRoamingGRASS7addons/scrip

ts/i.nightlights.intercalibration.py [3]", line 242, in

retrieve_model_parameters

    model = model_class(*args, **kwargs)

  File "C:UsersGabrielAppDataRoamingGRASS7addonsetci

.nightlights.intercalibrationintercalibration_models.py",

line 155, in __init__

    CalibrationModel.__init__(self, author, satellite, year)

  File "C:UsersGabrielAppDataRoamingGRASS7addonsetci

.nightlights.intercalibrationintercalibration_models.py",

line 43, in __init__

    year=self.year)

  File "C:UsersGabrielAppDataRoamingGRASS7addonsetci

.nightlights.intercalibrationintercalibration_models.py",

line 63, in verify_year

    available_years = COEFFICIENTS[author][satellite].keys()

KeyError: 'g.l'

(Tue Jun 19 12:31:27 2018) Command finished (1 sec)           
                 

Thanks a lot for your help
 and 
assistance
.

Best regards,

Gabriel 



Links:
--
[1] http://i.nightlights.intercalibration.py
[2] http://i.nightlights.intercalibration.py
[3] http://i.nightlights.intercalibration.py

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] grass gis book

[Nikos Alexandris]

* Rich Shepard  [2018-06-04 05:27:51 -0700]:


On Sun, 3 Jun 2018, Francois Chartier wrote:


I will start with this:
https://grasswiki.osgeo.org/wiki/From_GRASS_GIS_novice_to_power_user_(workshop_at_FOSS4G_Boston_2017)


Francois,

 An excellent choice. I was not aware of this resource so providing the URL
on the mail list makes it avaiable to others like you. Good catch!

Best regards,

Rich


Don't forget also this one: 
http://www.training.gismentors.eu/grass-gis-workshop-jena-2018/
When I first read through, I was like... "OK".

Cheers, Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] new GRASS virtual raster in trunk

[Nikos Alexandris]

* Markus Metz  [2018-06-04 14:37:41 +0200]:


A new GRASS virtual raster format has been added to trunk in r72761-4,
together with a new module to build a GRASS VRT: r.buildvrt.

*r.buildvrt* builds a virtual raster (VRT) that is a mosaic of the list of
input raster maps. The purpose of such a VRT is to provide fast access to
small subsets of the VRT, also with multiple simultaneous read requests.

*r.buildvrt* creates a list of raster maps that can be located in different
mapsets. The ouput is a read-only link to the original raster maps which is
only valid if the original raster maps remain in the originally indicated
mapset. A VRT can also be built from raster maps registered with
*r.external*.

Reading the whole VRT is slower than reading the equivalent single raster
map. Only reading small parts of the VRT provides a performance benefit.
Please test!

Markus M


Speechless! Respect Mr. Metz.


A working test:

# get extents
g.region -ec 
raster=L5192028_02820090723_Rad_ref_TRC_BYTE_FROMGLCaggV1@PERMANENT res=1000

north-south extent: 214230.00
east-west extent:   246330.00
center easting: 741150.00
center northing:510.00

# set east to center easting of landcover map
g.region -a e=738150.00 res=1000

# build a "half" map
r.mapcalc "WestHalf = 1" --o

# set west to center easting of land cover map, reset east
g.region w=738150.00 e=$(echo "246330/2 + 741150" |bc) res=1000 -a

# build other half
r.mapcalc "EastHalf = 2" --o

# combine
r.buildvrt input=WestHalf,EastHalf out=fIRSTgRASSYvRT --o title="First GRASS GIS 
Virtual Raster Map"

# ?
r.info -ge fIRSTgRASSYvRT

north=5208000
south=4992000
east=865000
west=617000
nsres=1000
ewres=1000
rows=216
cols=248
cells=53568
datatype=CELL
ncats=0
map=fIRSTgRASSYvRT
mapset=lst
location=lst_time_series
database=/geo37/grassdb
date="Mon Jun  4 16:02:58 2018"
creator="nik"
title="First GRASS GIS Virtual Raster Map"
timestamp="none"
units="none"
vdatum="none"
source1=""
source2=""
description="generated by r.buildvrt"
comments="r.buildvrt --overwrite input="WestHalf,EastHalf" output="fIRSTgRASSY\vRT" 
title="First GRASS GIS Virtual Raster Map""

# see in-terminal
g.region -a raster=L5192028_02820090723_Rad_ref_TRC_BYTE_FROMGLCaggV1@PERMANENT 
res=1000
ty.d.rast fIRSTgRASSYvRT  # terminology's `tycat`

Thank you so very much Markus, Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] new GRASS virtual raster in trunk

[Nikos Alexandris]

* Nikos Alexandris  [2018-06-04 15:36:14 +0200]:


* Rich Shepard  [2018-06-04 05:56:16 -0700]:


On Mon, 4 Jun 2018, Markus Metz wrote:


A new GRASS virtual raster format has been added to trunk in r72761-4,
together with a new module to build a GRASS VRT: r.buildvrt.


Markus,

For folks like me who have not followed this thread please explain the
problem for which a raster VRT is the solution.

Best regards,

Rich


Dear Rich,

(sorry Markus for my intervention -- just so excited about this new
creation of yours!)

if I may, virtual raster maps allow to treat an arbitrary number of
raster maps as one map. Hence, it is not required to patch hundreds or
thousands or more (?) raster map tiles, to build a single map.

Why build a single map?  Because the one or the other module or workflow
need it, in order to be able to process the entire computational extent
of interest.


In my case, I treat 177 tiles that cover European territories,
for each of which there exists a raster map (of 1 x 1 pixels).
Having one raster map, for the whole of Europe, will make it easier to
extract zonal statistics, for example.





So, in the general case of many raster maps, that form say, a "canonical"
tile grid, zones of interest (say vector boundaries), for which is asked
to extract statistics, are possibly split over two to up to four raster
map tiles. It takes some respectable amount of time of handcrafting, to
get stats for each tile, assembly then results for zones that don't
entirely fall inside one tile.


Not to forget: somewhere before the processing, of course, a `g.region`
to set the extent over a zone of interest, is required. With A VRT, the
whole "split-up in different raster maps" problem goes away.

Nikos


I am sure there are better explanations or even more complicated
problems for which a Virtual raster is the answer. In short, however,
and the way I understand things, it is a "work-around" to avoid dealing
with huge raster data sets. Huge as in file size. And, while the total
processing time, might not necessarily drop down, depending on the
work-flow, the time to script a solution decreases dramatically.


Nikos, happy to be a GRASS GIS user.




--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] new GRASS virtual raster in trunk

[Nikos Alexandris]

* Rich Shepard  [2018-06-04 05:56:16 -0700]:


On Mon, 4 Jun 2018, Markus Metz wrote:


A new GRASS virtual raster format has been added to trunk in r72761-4,
together with a new module to build a GRASS VRT: r.buildvrt.


Markus,

 For folks like me who have not followed this thread please explain the
problem for which a raster VRT is the solution.

Best regards,

Rich


Dear Rich,

(sorry Markus for my intervention -- just so excited about this new
creation of yours!)

if I may, virtual raster maps allow to treat an arbitrary number of
raster maps as one map. Hence, it is not required to patch hundreds or
thousands or more (?) raster map tiles, to build a single map.

Why build a single map?  Because the one or the other module or workflow
need it, in order to be able to process the entire computational extent
of interest.


In my case, I treat 177 tiles that cover European territories,
for each of which there exists a raster map (of 1 x 1 pixels).
Having one raster map, for the whole of Europe, will make it easier to
extract zonal statistics, for example.


So, in the general case of many raster maps, that form say, a "canonical"
tile grid, zones of interest (say vector boundaries), for which is asked
to extract statistics, are possibly split over two to up to four raster
map tiles. It takes some respectable amount of time of handcrafting, to
get stats for each tile, assembly then results for zones that don't
entirely fall inside one tile.

I am sure there are better explanations or even more complicated
problems for which a Virtual raster is the answer. In short, however,
and the way I understand things, it is a "work-around" to avoid dealing
with huge raster data sets. Huge as in file size. And, while the total
processing time, might not necessarily drop down, depending on the
work-flow, the time to script a solution decreases dramatically.


Nikos, happy to be a GRASS GIS user.


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.mapcalc

[Nikos Alexandris]

* jaindamini  [2018-06-01 01:48:41 -0700]:




I have been trying to digitize a Landsat 8 image for that in the layer
manager  I am creating a new raster map for it but it isn't allowing me
every time this error arrives.


Hi,

can you be a bit more specific in what you are trying to do?
I tested the following expression,

r.mapcalc "test = int( null() )"

and it works.

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS GIS virtual raster data sets

[Nikos Alexandris]

* Markus Metz  [2018-06-01 08:24:20 +0200]:


On Thu, May 31, 2018 at 10:41 PM, Markus Neteler  wrote:


On Wed, May 30, 2018 at 4:21 PM, Nikos Alexandris
 wrote:
> Dears,
>
> I guess there is no GRASS GIS built-in implementation of GDAL's VRT
> concept (several related ideas listed
> https://trac.osgeo.org/grass/wiki/Grass8Planning).

I wish to see that as well (and discussed it a while ago with our dear
Markus M...


I have an idea about how to implement native GRASS VRT, but no resources to
do so...


That is great! If I may ask, is time the main requirement?


GRASS GIS would gain a lot having the possibility to virtually mosaik
raster tiles.

> Once past some compilation issues, I am about to try to build a VRT
> based on native GRASS GIS raster maps (using GDAL with support for GRASS
> GIS raster data), then link to this VRT via `r.external` from inside a
> regular Mapset.

Interesting, will that not cause loop dependencies?



I didn't think about it carefully then. Stefan's test shows that you are
right, I guess.

My naive thinking was: source images are, each, an inode. A VRT is a list of
filenames pointing to inodes. Link via r.external to the VRT which points
to the source inodes. Essentially, an indirect way to read GRASS GIS
raster maps, from inside a valid GRASS GIS session.

I guess I miss important parts of GRASS GIS' raster data model which
render the above schema to be of no use.




I thought of true internal support for that to avoid loops.

> As a side-note, an image without pre-computed statistics stored in its
> metadata, will require some time for `r.external` to work. The latter
> likely forces  this computation.
>
> Perhaps it is faster to use `gdalinfo`'s '-stats' option to do this.


It will not be faster because you would need gdalinfo -mm -stats in order
to get the actual values, not an approximation. Sometimes an approximation
of the stats based on a subsample is stored in the metadata of a raster.


>
> I wonder if there are smart ways to build, in GRASS GIS' data base,
> a larger virtual raster map out of many smaller ones, without the need
> to actually patch the latter ones in a new raster map file.

I guess that some C code needs to be touched in lib/raster/ to allow
for a VRT-style raster concept.


Yes.


Maybe we missed the current GSoC train for this idea :)>


The tricky part is to get a qualified student for this project.


(I wish I could be in this position! :-/)

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user