Re: [GRASS-user] raster map from coordinates in python

[Stefan Blumentrath]

Thanks, Nikos!
Interesting! Not 100% sure though, how to conclude from that post.
One voice there says "the two are not comparable one should use BytesIO, when 
input data is bytes, and StringIO when Input data is string".
However in the this case, both seem suitable. So, the performance comparison 
suggests that StringIO would be better for Pyhon 2, while BytesIO will be 
better for Python 3 (where cStringIO will be no longer available).
So, I tend to use BytesIO with regards to future compatibility...

Cheers
Stefan 

-Original Message-
From: Nikos Alexandris [mailto:n...@nikosalexandris.net] 
Sent: mandag 12. februar 2018 21.20
To: Stefan Blumentrath 
Cc: grass-user grass-user (grass-user@lists.osgeo.org) 

Subject: Re: [GRASS-user] raster map from coordinates in python

* Stefan Blumentrath  [2018-02-12 19:41:15 +]:

>StringIO can be replaced with BytesIO BTW, though I don`t know what difference 
>the two make...

Out of curiosity I did a search. https://stackoverflow.com/a/37463095

Nikos

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

Re: [GRASS-user] Issue with addon r.vif in MS Windows GUI installations (stand-alone v. 7.2.2 and 7.0.5)

[Dinarzarde Raheem]

Many thanks Paulo and Helmut. Have an osgeo4w installation of grass 7.4.0, so 
will run it on the console.

Best wishes,

Dinarzarde

From: Paulo van Breugel [p.vanbreu...@gmail.com]
Sent: 12 February 2018 23:45
To: Dinarzarde Raheem; Helmut Kudrnovsky
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Issue with addon r.vif in MS Windows GUI 
installations (stand-alone v. 7.2.2 and 7.0.5)

Hi Dinarzarde and Helmut

I checked on Windows (grass 7.4.0 installed using osgeo4w), and
installing r.vif using g.extension works fine, but after installing it
does not appear in the addon list in the Modules tab. The same is true
for a number of other addons I installed. There are, on the other hand,
a number of addons that appear in the list (r.regression.series,
r.series.lwr, v.kriging, and 6 others).

However, running these addons from the console (type in r.vif on the
console) works.


Best wishes

Paulo


On 2/12/18 8:40 PM, Dinarzarde Raheem wrote:
> Hi Helmut,
>
> I have been installing r.vif as you have indicated (i.e. by downloading from 
> the server using g.extension and opening the tree of installable raster 
> addons), but can now confirm after installing both the new and old versions 
> of r.vif on a Windows 10 (64 bit) machine, that r.vif isn't listed under the 
> Addons in the module tab in both Grass standalone GUI versions 7.2.2 and 
> 7.4.0 (i.e. there is no plus sign in front of Addons, so there is no way of 
> opening the tree of installed addons and selecting and running r.vif).
>
> Best wishes,
>
> Dinarzarde
>
>
> 
> From: Helmut Kudrnovsky [hel...@web.de]
> Sent: 11 February 2018 16:13
> To: Dinarzarde Raheem
> Cc: grass-user@lists.osgeo.org; Paulo van Breugel
> Subject: Aw: RE: [GRASS-user] Issue with addon r.vif in MS Windows GUI 
> installations (stand-alone v. 7.2.2 and 7.0.5)
>
>> Gesendet: Sonntag, 11. Februar 2018 um 16:36 Uhr
>> Von: "Dinarzarde Raheem" 
>> I tried GRASS GIS versions 7.4.0 (current stable) and GRASS GIS 7.2.2 (old 
>> stable) but can't see r.vif listed under Addons in the Modules tab (see 
>> attached >screenshot).
> you have to click on the + before "Raster" to open the tree of installable 
> raster addons.
>
>
>
>> One thing I noticed is that when you re-install Grass and then install r.vif 
>> you get this message:
>> (Sun Feb 11 16:29:48 2018)
>> g.extension extension=r.vif url=
>> WARNING: Extension  already installed. Re-installing...
>> Downloading precompiled GRASS Addons ...
>> Updating addons metadata file...
>> Installation of  successfully finished
>> (Sun Feb 11 16:29:57 2018) Command finished (9 sec)
> yes, it's an obvious message as you install the script from the server over 
> the local copy.
>
>> I guess by tomorrow the new version of r.vif should be available via the 
>> server so will try again tomorrow.
> the new version is already on the server and should be installable by 
> g.extension, see
>
> for winGRASS7.5.svn daily:
> https://wingrass.fsv.cvut.cz/grass75/x86_64/addons/grass-7.5.svn/
>
> for  winGRASS7.4.0:
> https://wingrass.fsv.cvut.cz/grass74/x86_64/addons/grass-7.4.0/
>
> etc
>
> kind regards
> Helmut
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Issue with addon r.vif in MS Windows GUI installations (stand-alone v. 7.2.2 and 7.0.5)

[Paulo van Breugel]

Hi Dinarzarde and Helmut

I checked on Windows (grass 7.4.0 installed using osgeo4w), and 
installing r.vif using g.extension works fine, but after installing it 
does not appear in the addon list in the Modules tab. The same is true 
for a number of other addons I installed. There are, on the other hand, 
a number of addons that appear in the list (r.regression.series, 
r.series.lwr, v.kriging, and 6 others).


However, running these addons from the console (type in r.vif on the 
console) works.



Best wishes

Paulo


On 2/12/18 8:40 PM, Dinarzarde Raheem wrote:

Hi Helmut,

I have been installing r.vif as you have indicated (i.e. by downloading from 
the server using g.extension and opening the tree of installable raster 
addons), but can now confirm after installing both the new and old versions of 
r.vif on a Windows 10 (64 bit) machine, that r.vif isn't listed under the 
Addons in the module tab in both Grass standalone GUI versions 7.2.2 and 7.4.0 
(i.e. there is no plus sign in front of Addons, so there is no way of opening 
the tree of installed addons and selecting and running r.vif).

Best wishes,

Dinarzarde



From: Helmut Kudrnovsky [hel...@web.de]
Sent: 11 February 2018 16:13
To: Dinarzarde Raheem
Cc: grass-user@lists.osgeo.org; Paulo van Breugel
Subject: Aw: RE: [GRASS-user] Issue with addon r.vif in MS Windows GUI 
installations (stand-alone v. 7.2.2 and 7.0.5)


Gesendet: Sonntag, 11. Februar 2018 um 16:36 Uhr
Von: "Dinarzarde Raheem" 
I tried GRASS GIS versions 7.4.0 (current stable) and GRASS GIS 7.2.2 (old stable) 
but can't see r.vif listed under Addons in the Modules tab (see attached 
>screenshot).

you have to click on the + before "Raster" to open the tree of installable 
raster addons.




One thing I noticed is that when you re-install Grass and then install r.vif 
you get this message:
(Sun Feb 11 16:29:48 2018)
g.extension extension=r.vif url=
WARNING: Extension  already installed. Re-installing...
Downloading precompiled GRASS Addons ...
Updating addons metadata file...
Installation of  successfully finished
(Sun Feb 11 16:29:57 2018) Command finished (9 sec)

yes, it's an obvious message as you install the script from the server over the 
local copy.


I guess by tomorrow the new version of r.vif should be available via the server 
so will try again tomorrow.

the new version is already on the server and should be installable by 
g.extension, see

for winGRASS7.5.svn daily:
https://wingrass.fsv.cvut.cz/grass75/x86_64/addons/grass-7.5.svn/

for  winGRASS7.4.0:
https://wingrass.fsv.cvut.cz/grass74/x86_64/addons/grass-7.4.0/

etc

kind regards
Helmut


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

Re: [GRASS-user] v.generalize failing on some geoms

[Markus Metz]

On Mon, Feb 12, 2018 at 6:22 PM, Paolo Cavallini 
wrote:
>
> Il 11/02/2018 18:34, Markus Metz ha scritto:
>
> > This implies that the data have been reprojected at some stage somewhere
> > from one SRS to the other. The most likely explanation for the different
> > results, particularly the topological errors reported by v.in.ogr, is
> > that non-topological polygons were reprojected. Can you make these geoms
> > in EPSG:3857 and EPSG:3003 available for testing?
>
> Hi Markus,
> thanks for your thoughts. Here the data, original and simplified, in two
> CRS (3003 is simplified correctly, 3857 not):
> http://www.faunalia.eu/~paolo/test_generalize.tar.xz

The original data in EPSG:3003 and EPSG:3857 are not identical. The
original data in EPSG:3003 are topologically correct, while the original
data in EPSG:3857 are not. Further on, the original data in EPSG:3857
contain features that are not present in the original data in EPSG:3003
which is quite strange.

Reprojecting the original data in EPSG:3003 to EPSG:3857 within GRASS works
fine, also with subsequent v.generalize.

That means that the original data in EPSG:3857 are some reprojected version
of the original original data (which are these?). The reprojection step,
apparently performed on polygons, not GRASS areas (how did you reproject?),
introduced topological errors. Please use native GRASS v.in.ogr + v.proj to
reproject polygons.

Markus M

> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] raster map from coordinates in python

[Stefan Blumentrath]

OK, found it!
Reading the manuals more carefully helps:

So, with my StringIO object "result", formated x y z, the following works:

grass.write_command('r.in.xyz', stdin=result.getvalue(), input='-', 
output=output,
 method='mean', separator=' ')

StringIO can be replaced with BytesIO BTW, though I don`t know what difference 
the two make...
Cheers
Stefan


From: grass-user [mailto:grass-user-boun...@lists.osgeo.org] On Behalf Of 
Stefan Blumentrath
Sent: mandag 12. februar 2018 14.42
To: grass-user grass-user (grass-user@lists.osgeo.org) 

Subject: [GRASS-user] raster map from coordinates in python

Dear all,

I have a numpy array with x,y, z coordinates that I would like to write to a 
rater map.
When I convert the array to a StringIO-object and feed it to r.in.xyz I get:
OSError: [Errno 7] Argument list too long
I checked the content of the StringIO object and it contains only three columns 
(separated by space) and rows separated by '\n'...
Any hints on how to accomplish that without writing out stuff to a textfile?

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

Re: [GRASS-user] v.generalize failing on some geoms

[Paolo Cavallini]

Il 11/02/2018 18:34, Markus Metz ha scritto:

> This implies that the data have been reprojected at some stage somewhere
> from one SRS to the other. The most likely explanation for the different
> results, particularly the topological errors reported by v.in.ogr, is
> that non-topological polygons were reprojected. Can you make these geoms
> in EPSG:3857 and EPSG:3003 available for testing?

Hi Markus,
thanks for your thoughts. Here the data, original and simplified, in two
CRS (3003 is simplified correctly, 3857 not):
http://www.faunalia.eu/~paolo/test_generalize.tar.xz
All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] LSMetrics - addon development

[Bernardo Santos]

 Dear Moritz, 
thanks for the answer and the examples. I'll try to put the functions and files 
in this format and test them like that.I am not sure how to build these 
makefile files but I'll try to follow the patterns I find in the other examples 
of modules.Once this is done, I'll post it here.
Which GRASS version I should use to do that?
Regarding the comparison with the other GRASS tools, LSMetrics is complementary 
to many of the functions the r.li suite offers. I still could not test r.pi 
since I had some trouble installing it, but I'll try it again  so that I can 
compare both packages. I believe they are also somehow complementary in many of 
the functions.
Best,Bernardo


Em quarta-feira, 7 de fevereiro de 2018 13:15:03 BRST, Moritz Lennert 
 escreveu:  
 
 Dear Bernardo,

On 07/02/18 14:55, Bernardo Santos wrote:
> Dear list,
> 
> We have been developing a python application called LSMetrics to 
> calculate landscape metrics for environmental management and ecological 
> research. All functions/metrics use GRASS modules in the process of 
> calculation. More information here:
> https://github.com/LEEClab/LS_METRICS/wiki

Great, thanks !

Out of curiosity: could you maybe explain how this application compares 
to the existing r.li suite of modules in GRASS core 
(https://grass.osgeo.org/grass74/manuals/r.li.html) and the r.pi suite 
of modules in GRASS addons (there seems to be a problem with building 
the manual pages, but you can get an idea by looking at the 
description.html file here: 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.pi) ? 
I am no expert in the field of landscape metrics and am just wondering 
how this all fits into the picture.

> 
> Basically we have several python functions, each of which calculates a 
> different metric. All of them are then called by a single function that 
> can coordinate the calculation of several metrics for several maps in a row.
> Currently the metrics can be calculated for input maps using a grafical 
> interface (we call it from the GRASS shell using "python 
> LS_metrics_v1_0_0.py") or by calling python shell from the GRASS shell 
> and then using python scripting to call the functions (importing 
> functions and then calling them directly). We wish to transform these 
> function into one (or more than one) grass addon.
> 
> Then I have two questions:
> - Do you think it would be better to build a single addon (e.g. called 
> r.ls.metrics) so that each metrics is defined by a parameter (e.g. 
> method = "patch_size", "fragment_size", "structural connectivity" ...), 
> or rather a set of addons, each one corresponding to a single landscape 
> metrics (e.g. r.ls.patch_size, r.ls.fragment_size, ...)?

The other two suites have gone for separate modules for each metric. I'm 
not sure what the rationale was behind that choice, but I guess we 
should try to be consistent across similar module suites.

> 
> - Also, I have looked on how to build the addon in GRASS help pages but 
> I am not sure about some details. Can you send me some references to 
> ease that process?

The basic idea for a module for addons is to create a directory with the 
source file(s), the html file for the manual page and a Makefile.

Please follow the general submitting rules as explained at 
https://trac.osgeo.org/grass/wiki/Submitting.

To get an idea of the structure of a suite of modules in Addons, you 
could look at the recently added r.sentinel tools: 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.sentinel

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

Re: [GRASS-user] python parse_command

[Anna Petrášová]

Isn't the problem that you have there r.in_xyz instead of r.in.xyz?

Anna

On Feb 12, 2018 9:35 AM, "Pietro"  wrote:

Dear Jonathan,

the error is due to grass_session that is not creating the location if
missing.
I don't have time in this day to fix this issue in grass_session, so the
fastest fsolution at the momenth is to check and create what is needed step
by step.

I did not have xyz file to test so I've only execute g.gisenv and it works,
let me know if it works also with r.inxyz:

```python
from __future__ import print_function
import os

from grass_session import Session
from grass.script import core as gcore

GISDBASE = "/tmp/grassdata"
LOCATION = "nrw"
EPSG = "EPSG:4326"


if not os.path.exists(GISDBASE):
os.makedirs(GISDBASE)

if not os.path.exists(os.path.join(GISDBASE, LOCATION)):
with Session(gisdb=GISDBASE, location=LOCATION,
 create_opts=EPSG):
print("Created a new location!")
else:
print("Location already exist!")


with Session(gisdb=GISDBASE, location=LOCATION, mapset="elevation",
 create_opts=""):
gcore.run_command("g.gisenv")
```

Best regards

Pietro

___
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

Re: [GRASS-user] python parse_command

[Pietro]

Dear Jonathan,

the error is due to grass_session that is not creating the location if
missing.
I don't have time in this day to fix this issue in grass_session, so the
fastest fsolution at the momenth is to check and create what is needed step
by step.

I did not have xyz file to test so I've only execute g.gisenv and it works,
let me know if it works also with r.inxyz:

```python
from __future__ import print_function
import os
from grass_session import Session
from grass.script import core as gcore

GISDBASE = "/tmp/grassdata"
LOCATION = "nrw"
EPSG = "EPSG:4326"


if not os.path.exists(GISDBASE):
os.makedirs(GISDBASE)

if not os.path.exists(os.path.join(GISDBASE, LOCATION)):
with Session(gisdb=GISDBASE, location=LOCATION,
 create_opts=EPSG):
print("Created a new location!")
else:
print("Location already exist!")


with Session(gisdb=GISDBASE, location=LOCATION, mapset="elevation",
 create_opts=""):
gcore.run_command("g.gisenv")
```

Best regards

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

[GRASS-user] raster map from coordinates in python

[Stefan Blumentrath]

Dear all,

I have a numpy array with x,y, z coordinates that I would like to write to a 
rater map.
When I convert the array to a StringIO-object and feed it to r.in.xyz I get:
OSError: [Errno 7] Argument list too long
I checked the content of the StringIO object and it contains only three columns 
(separated by space) and rows separated by '\n'...
Any hints on how to accomplish that without writing out stuff to a textfile?

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

[GRASS-user] python parse_command

[Jonathan Reith]

 Dear list,
I am struggling with my python code.
I am trying to get the computational region of a xyz-file. If I use
r.in.xyz in GRASS itself, it works all just fine, but using it in python
I always get an error.
Here is my code:

from grass_session import Session
from grass.script import core as gcore
from grass.pygrass.modules.shortcuts import general as g
from grass.pygrass.modules.shortcuts import raster as r

with Session(gisdb="/home/jreith/grassdata",
location="nrw",mapset="elevation", create_opts="EPSG:4326"):
compregion = gcore.parse_command('r.in_xyz',
input="/geodaten/dgm1.xyz", flags='s',
output="new_file",separator='space')


The error:

Traceback (most recent call last):
  File "grass_scripts/grass_dem.py", line 32, in 
    compregion = gcore.parse_command('r.in_xyz',
input="/geodaten/dgm1.xyz", flags='s',
output="new_file",separator='space')
  File

"/home/jreith/source/grass-7.4.svn/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
line 516, in parse_command
    res = read_command(*args, **kwargs)
  File

"/home/jreith/source/grass-7.4.svn/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
line 471, in read_command
    process = pipe_command(*args, **kwargs)
  File

"/home/jreith/source/grass-7.4.svn/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
line 444, in pipe_command
    return start_command(*args, **kwargs)
  File

"/home/jreith/source/grass-7.4.svn/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
line 380, in start_command
    return Popen(args, **popts)
  File

"/home/jreith/source/grass-7.4.svn/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
line 74, in __init__
    subprocess.Popen.__init__(self, args, **kwargs)
  File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1343, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

I appreciate any help and hope I made myself clear.

best regards
Jonathan

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