[GRASS-dev] Forestfrag WARNING: ZSTD compression error -14: Unsupported frame parameter

2019-05-27 Thread Paulo van Breugel

Hi Václav / devs

I am running r.forestfrag in Windows 10, grass 7.6.2 Computation with a 
moving window size of 21 (but at another computer same happens at size 
9) gives met the following error:


C:\Users\brp\AppData\Roaming\GRASS7\addons/scripts/r.forestfrag.py 
input=groenreclass@landschap output=AAtest7 size=21

Step 1: Computing Pf values...
Step 2: Computing Pff values...
WARNING: ZSTD compression error -14: Unsupported frame parameter
ERROR: Error uncompressing raster data for row 328 of 


WARNING: No data base element files found
Traceback (most recent call last):
  File 
"C:\Users\brp\AppData\Roaming\GRASS7\addons/scripts/r.forestfrag.py", 
line 420, in  sys.exit(main(*gs.parser()))
  File 
"C:\Users\brp\AppData\Roaming\GRASS7\addons/scripts/r.forestfrag.py", 
line 290, in main ipl=ipl, tmpl4=expr1, tmpl5=expr2, pff=pff)
  File 
"C:\OSGEO4~1\apps\grass\grass76\etc\python\grass\script\raster.py", line 
111, in mapcalc " with expression: %s") % e)
  File 
"C:\OSGEO4~1\apps\grass\grass76\etc\python\grass\script\core.py", line 
667, in fatal error(msg)
  File 
"C:\OSGEO4~1\apps\grass\grass76\etc\python\grass\script\core.py", line 
651, in error    message(msg, flag='e')
  File 
"C:\OSGEO4~1\apps\grass\grass76\etc\python\grass\script\core.py", line 
584, in message run_command("g.message", flags=flag, message=msg, 
errors='ignore')
  File 
"C:\OSGEO4~1\apps\grass\grass76\etc\python\grass\script\core.py", line 
415, in run_command ps = start_command(*args, **kwargs)
  File 
"C:\OSGEO4~1\apps\grass\grass76\etc\python\grass\script\core.py", line 
382, in start_command

    return Popen(args, **popts)
  File 
"C:\OSGEO4~1\apps\grass\grass76\etc\python\grass\script\core.py", line 
76, in __init__ subprocess.Popen.__init__(self, args, **kwargs)
  File "C:\OSGEO4~1\apps\Python27\lib\subprocess.py", line 390, in 
__init__ errread, errwrite)
  File "C:\OSGEO4~1\apps\Python27\lib\subprocess.py", line 640, in 
_execute_child startupinfo)

WindowsError: [Error 206] De bestandsnaam of -extensie is te lang

Any idea what may be the problem here?

Greetings,

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

[GRASS-dev] How to commit changes in git to a release_branch?

2019-05-27 Thread Markus Neteler
Hi devs,

/me still learning :-)

So, I wanted to fix a user message ("make changelog" related) and I am
not sure if I got it right:

# the setting (directory layout based on Panos' git clone tricks):
[mneteler@oboe releasebranch_7_4 ]$ git remote -v
origin/home/mneteler/software/grass-p2/../grass-p3/master (fetch)
origin/home/mneteler/software/grass-p2/../grass-p3/master (push)
upstreamg...@github.com:OSGeo/grass.git (fetch)
upstreamg...@github.com:OSGeo/grass.git (push)

# the modification to be submitted
[mneteler@oboe releasebranch_7_4 ]$ git diff
diff --git a/include/Make/Docs.make b/include/Make/Docs.make
index adea0c228..15e9ef189 100644
--- a/include/Make/Docs.make
+++ b/include/Make/Docs.make
@@ -91,7 +91,7 @@ html2pdfdoccomplete:
$(call html_pdf vector,v.*.html)

 changelog:
-   @ echo "creating ChangeLog file (following 'master' only)..."
+   @ echo "creating ChangeLog file (following 'releasebranch_7_4' only)..."
@ # tools/gitlog2changelog.py creates a GNU style ChangeLog file:
python tools/gitlog2changelog.py

# create feature branch
[mneteler@oboe releasebranch_7_4 ]$ git checkout -b changelog_fix_msg_74
Minclude/Make/Docs.make
Switched to a new branch 'changelog_fix_msg_74'

# add the changed file
[mneteler@oboe releasebranch_7_4 ]$ git add include/Make/Docs.make

# commit
[mneteler@oboe releasebranch_7_4 ]$ git commit -m 'make changelog: fix
misleading msg'
[changelog_fix_msg_74 83a3049e6] make changelog: fix misleading msg
 1 file changed, 1 insertion(+), 1 deletion(-)

# push to feature branch
[mneteler@oboe releasebranch_7_4 ]$ git push origin changelog_fix_msg_74
Enumerating objects: 26, done.
Counting objects: 100% (26/26), done.
Delta compression using up to 4 threads
Compressing objects: 100% (19/19), done.
Writing objects: 100% (19/19), 4.65 KiB | 366.00 KiB/s, done.
Total 19 (delta 13), reused 1 (delta 0)
To /home/mneteler/software/grass-p2/../grass-p3/master
 * [new branch]  changelog_fix_msg_74 -> changelog_fix_msg_74

... and now what?
I hoped to see a open-PR message in the terminal but nothing...

Hints welcome, thanks,

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

Re: [GRASS-dev] (no subject)

2019-05-27 Thread Paulo van Breugel

Hi Maris

Thanks, your suggestion made me realize that I did not recompiled the 
gdal-grass plugin (which was still pointing to a grass 7.5 version). 
Great, all working again.


Cheers,

Paulo


On 5/27/19 11:33 AM, Maris Nartiss wrote:

Hello,
usually it indicates on some remnants of previous version lying around
somewhere. Check out also for all extensions or your own custom
modules as they need to be rebuilt too.

Māris.

piektd., 2019. g. 24. maijs, plkst. 18:18 — lietotājs Paulo van
Breugel () rakstīja:

Hi devs

I just did a completely fresh install of grass 7.6.2. The whole compilation is 
completed without issues. But when starting grass up, I am getting the 
following message.

GRASS 7.6.2svn (nc_spm_08_grass7):~ > ERROR 1: libgrass_raster.7.5.svn.so: 
cannot open shared object file: No such file or directory
ERROR 1: libgrass_raster.7.5.svn.so: cannot open shared object file: No such 
file or directory

I started completely anew, removed everything before compiling (as far as I 
know), including the .grass7 folder, so I wonder what else I could have done 
wrong? Any idea how I can find out where the problem lies?

Cheers,

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

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

Re: [GRASS-dev] (no subject)

2019-05-27 Thread Maris Nartiss
Hello,
usually it indicates on some remnants of previous version lying around
somewhere. Check out also for all extensions or your own custom
modules as they need to be rebuilt too.

Māris.

piektd., 2019. g. 24. maijs, plkst. 18:18 — lietotājs Paulo van
Breugel () rakstīja:
>
> Hi devs
>
> I just did a completely fresh install of grass 7.6.2. The whole compilation 
> is completed without issues. But when starting grass up, I am getting the 
> following message.
>
> GRASS 7.6.2svn (nc_spm_08_grass7):~ > ERROR 1: libgrass_raster.7.5.svn.so: 
> cannot open shared object file: No such file or directory
> ERROR 1: libgrass_raster.7.5.svn.so: cannot open shared object file: No such 
> file or directory
>
> I started completely anew, removed everything before compiling (as far as I 
> know), including the .grass7 folder, so I wonder what else I could have done 
> wrong? Any idea how I can find out where the problem lies?
>
> Cheers,
>
> Paulo
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #3854: r.stream.extract does not support fully qualified map names

2019-05-27 Thread GRASS GIS
#3854: r.stream.extract does not support fully qualified map names
--+-
 Reporter:  sbl   |  Owner:  grass-dev@…
 Type:  defect| Status:  new
 Priority:  normal|  Milestone:  7.6.2
Component:  Raster|Version:  svn-trunk
 Keywords:  r.stream.extract  |CPU:  All
 Platform:  All   |
--+-
 r.stream.extract does not find the input elevation model, if it is
 specified with the fully qualified map name and it`s mapset is not on the
 search path.

 {{{
 grass /grassdata/LOCATION/my_mapset --exec r.stream.extract
 elevation=DTM_1m@my_other_mapset threshold=5000 stream_length=100
 stream_raster=DTM_1m_streams stream_vector=DTM_1m_streams
 }}}

 Gives:
 {{{
 ERROR: Raster map  not found.
 }}}

 While:
 {{{
 grass /grassdata/LOCATION/my_mapset --exec g.mapsets operation=add
 mapset=my_other_mapset
 grass /grassdata/LOCATION/my_mapset --exec r.stream.extract
 elevation=DTM_1m@my_other_mapset threshold=5000 stream_length=100
 stream_raster=DTM_1m_streams stream_vector=DTM_1m_streams
 }}}
 works.

 Probably because it uses
 [https://github.com/OSGeo/grass/blob/master/raster/r.stream.extract/main.c#L172
 G_find_raster] instead of
 [https://github.com/OSGeo/grass/blob/master/raster/r.stream.extract/main.c#L248
 G_find_raster2] ?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] grass-addons on github

2019-05-27 Thread Rainer M Krug
Disadvantage: From the GitHub blog:

Managing dynamic, rapidly evolving or heavily co-dependent repositories with 
submodules can quickly become frustrating. This post was focused on simple, 
relatively static parent-child repository relationships. A future follow-up 
post will detail some strategies to help manage more complex submodule 
workflows.
Probably not the easiest and most stable solution…



> On 27 May 2019, at 08:55, Rainer M Krug  wrote:
> 
> I am no git expert, so this could be completely off. But as far as I 
> understand it, git submodules 
> (https://git-scm.com/book/en/v2/Git-Tools-Submodules 
> ) are exactly for this 
> purpose.
> 
> From their description:
> 
> It often happens that while working on one project, you need to use another 
> project from within it. Perhaps it’s a library that a third party developed 
> or that you’re developing separately and using in multiple parent projects. A 
> common issue arises in these scenarios: you want to be able to treat the two 
> projects as separate yet still be able to use one from within the other.
> 
> Here’s an example. Suppose you’re developing a website and creating Atom 
> feeds. Instead of writing your own Atom-generating code, you decide to use a 
> library. You’re likely to have to either include this code from a shared 
> library like a CPAN install or Ruby gem, or copy the source code into your 
> own project tree. The issue with including the library is that it’s difficult 
> to customize the library in any way and often more difficult to deploy it, 
> because you need to make sure every client has that library available. The 
> issue with copying the code into your own project is that any custom changes 
> you make are difficult to merge when upstream changes become available.
> 
> Git addresses this issue using submodules. Submodules allow you to keep a Git 
> repository as a subdirectory of another Git repository. This lets you clone 
> another repository into your project and keep your commits separate.
> 
> 
> The different add-ons could be added as submodules, so they 
> would be in separate repos, 
> you don’t have to download all if you are only working on one, 
> the core team can exclude them easily if they do not work anymore from the 
> general build process (and re-add them as easy),
> Are treated, when complaint (as mentioned the windows binaries) as one single 
> repo.
> Developers of add-ons do not need write access to the core repo
> 
> Here is another link to the GitHub blog on how they can be used: 
> https://github.blog/2016-02-01-working-with-submodules/ 
> 
> 
> Cheers,
> 
> Rainer
> 
> 
> 
> 
>> On 25 May 2019, at 17:04, Markus Neteler > > wrote:
>> 
>> On Fri, May 24, 2019 at 4:25 PM Stefan Blumentrath
>> mailto:stefan.blumentr...@nina.no>> wrote:
>>> 
>>> Hi,
>>> 
>>> Collecting addons in a central repo seems very valuable to me too, for all 
>>> the reasons Vacslav mentioned.
>> 
>> +1
>> 
>>> I am no git expert either, but PRs should not be a big issue to do (unless 
>>> you are VERY productive). People could merge their own PRs, no?
>> 
>> Exactly.
>> 
>>> Creating a PR, does not mean it has to be reviewed by another dev, right? 
>>> In my organization colleagues even usr PRs for repos where they are the 
>>> only contributor...
>> 
>> I also prefer PRs. At least the changes have a chance to be reviewed
>> and appear more traceable.
>> 
>>> I would argue having procedures as equal as possible between addons and 
>>> core is just beneficial. Less confusion, fewer guidelines to maimtain, 
>>> possibility to have CI before things are merged, and training for new devs 
>>> that evolve from addon-dev to core-dev...
>> 
>> +1^2
>> 
>> Cheers,
>> Markus
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org 
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
> 
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
> UCT), Dipl. Phys. (Germany)
> 
> Orcid ID: -0002-7490-0066
> 
> Department of Evolutionary Biology and Environmental Studies
> University of Zürich
> Office Y34-J-74
> Winterthurerstrasse 190
> 8075 Zürich
> Switzerland
> 
> Office:   +41 (0)44 635 47 64
> Cell: +41 (0)78 630 66 57
> email:      rainer.k...@uzh.ch 
>   rai...@krugs.de 
> Skype: RMkrug
> 
> PGP: 0x0F52F982
> 
> 
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Orcid ID: -0002-7490-0066

Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office 

Re: [GRASS-dev] grass-addons on github

2019-05-27 Thread Rainer M Krug
I am no git expert, so this could be completely off. But as far as I understand 
it, git submodules (https://git-scm.com/book/en/v2/Git-Tools-Submodules 
) are exactly for this 
purpose.

From their description:

It often happens that while working on one project, you need to use another 
project from within it. Perhaps it’s a library that a third party developed or 
that you’re developing separately and using in multiple parent projects. A 
common issue arises in these scenarios: you want to be able to treat the two 
projects as separate yet still be able to use one from within the other.

Here’s an example. Suppose you’re developing a website and creating Atom feeds. 
Instead of writing your own Atom-generating code, you decide to use a library. 
You’re likely to have to either include this code from a shared library like a 
CPAN install or Ruby gem, or copy the source code into your own project tree. 
The issue with including the library is that it’s difficult to customize the 
library in any way and often more difficult to deploy it, because you need to 
make sure every client has that library available. The issue with copying the 
code into your own project is that any custom changes you make are difficult to 
merge when upstream changes become available.

Git addresses this issue using submodules. Submodules allow you to keep a Git 
repository as a subdirectory of another Git repository. This lets you clone 
another repository into your project and keep your commits separate.


The different add-ons could be added as submodules, so they 
would be in separate repos, 
you don’t have to download all if you are only working on one, 
the core team can exclude them easily if they do not work anymore from the 
general build process (and re-add them as easy),
Are treated, when complaint (as mentioned the windows binaries) as one single 
repo.
Developers of add-ons do not need write access to the core repo

Here is another link to the GitHub blog on how they can be used: 
https://github.blog/2016-02-01-working-with-submodules/ 


Cheers,

Rainer




> On 25 May 2019, at 17:04, Markus Neteler  wrote:
> 
> On Fri, May 24, 2019 at 4:25 PM Stefan Blumentrath
>  wrote:
>> 
>> Hi,
>> 
>> Collecting addons in a central repo seems very valuable to me too, for all 
>> the reasons Vacslav mentioned.
> 
> +1
> 
>> I am no git expert either, but PRs should not be a big issue to do (unless 
>> you are VERY productive). People could merge their own PRs, no?
> 
> Exactly.
> 
>> Creating a PR, does not mean it has to be reviewed by another dev, right? In 
>> my organization colleagues even usr PRs for repos where they are the only 
>> contributor...
> 
> I also prefer PRs. At least the changes have a chance to be reviewed
> and appear more traceable.
> 
>> I would argue having procedures as equal as possible between addons and core 
>> is just beneficial. Less confusion, fewer guidelines to maimtain, 
>> possibility to have CI before things are merged, and training for new devs 
>> that evolve from addon-dev to core-dev...
> 
> +1^2
> 
> Cheers,
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Orcid ID: -0002-7490-0066

Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland

Office: +41 (0)44 635 47 64
Cell:   +41 (0)78 630 66 57
email:  rainer.k...@uzh.ch
rai...@krugs.de
Skype: RMkrug

PGP: 0x0F52F982



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