Re: [GRASS-PSC] [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8

[Markus Metz]

On Thu, Feb 11, 2021 at 1:29 PM Nicklas Larsson  wrote:
>
> Moritz,
>
> I'd be honoured!
> I will put it on GRASS Wiki [1] if you don't have another suggestion and
notify here when done.
>
Thanks a lot Nicklas for raising this discussion!

I am sure GRASS will benefit if we allow new C standard features, e.g.
handling of integer types, math constants, nan, inf, etc, which will also
improve portability.

Markus M

> Best,
> Nicklas
>
>
> [1] https://trac.osgeo.org/grass/wiki/RFC
>
>
>
> On Thursday, 11 February 2021, 12:54:30 CET, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>
>
> On 10/02/21 13:16, Nicklas Larsson wrote:
> > It would be most favourable for all contributors and the project if the
> > community could come to an agreement on this topic. I see no reason to
> > postpone a decision on this much longer.
> >
> > The final word on this need to be that of the PSC's. Whether through
> > simple vote or a RFC. However, a sounding of the opinion of the
> > dev-community on this matter is of equal importance and can be of help
> > for the PSC.
>
> Thanks a lot, Nicklas, for this very comprehensive summary !
>
> A suggestion made at the first meeting of the new PSC was to use this
> discussion as a use case for a more extensive usage of RFC's to put
> important decisions into more permanent documents than mailing list
> archives and to provoke a formal decision as you suggest. Would you be
> willing to write a first draft of such an RFC ?
>
>
> Moritz
___
grass-psc mailing list
grass-psc@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-psc

Re: [GRASS-PSC] GRASS add-on sharing and write access

[Markus Metz]

On Sun, Dec 17, 2017 at 5:36 AM, Anna Petrášová 
wrote:
>
> Hi Nagy,
>
> On Sat, Dec 16, 2017 at 2:06 PM, Nagy Edmond 
wrote:
> > Hi Anna,
> >
> > Thank you for pointing that out. It always computes one way between two
> > points indeed, but there is something that I should bring to light.
> >
> > While I was initially computing least-cost paths with r.drain using
r.walk
> > outputs as inputs I noticed a possible problem. I ran two parallel tests
> > with the same two points. In the first one, A was the starting position,
> > while B the stop position. In the second one, B was the start point and
A
> > the stop point. In r.walk, the results were anisotropic indeed, both the
> > walking cost and the movement direction raster outputs turned out
different,
> > as it would have been expected. But the r.drain module sadly did not
> > generate different least-cost paths, despite using different inputs. I
have
> > also checked this more than once, just to be sure of it.
> >
> > At one point I have also come across an article (Gietl et al. 2008 -
link
> > below) where the authors discuss and compare l.c.p. results obtained
with
> > different GIS (including GRASS), and they had also experienced some
problem
> > with the module (page 4), but I am not sure if it's the same I'm
having. In
> > any case, if nothing can be done about it, then I will mention the
> > limitation in the documentation.
> >
>
> you are right that r.drain seem to create the same path from A to B
> and back, there are some slight differences, but that can be just
> numerical cause. I am not sure why is that, if my expectation that the
> path for that DEM should be different is incorrect, or there is some
> problem in the algorithm.

It depends on the slope factor. Here is an example, based on the example in
the manual of r.walk (North Carolina sample dataset):

g.region region=swwake_30m -p

# create friction map based on land cover
r.recode input=landclass96 out=friction rules=- << EOF
1:3:0.1:0.1
4:5:10.:10.
6:6:1000.0:1000.0
7:7:0.3:0.3
EOF

r.walk -k elevation=elev_ned_30m friction=friction output=walkcost_ab
outdir=walkdir_ab start_coordinates=635576,216485
stop_coordinates=640206,222795 slope_factor=-0.05 lambda=0.5
r.drain -d input=walkcost_ab direction=walkdir_ab output=path_ab
drain=path_ab start_coordinates=640206,222795

r.walk -k elevation=elev_ned_30m friction=friction output=walkcost_ba
outdir=walkdir_ba start_coordinates=640206,222795
stop_coordinates=635576,216485 slope_factor=-0.05 lambda=0.5
r.drain -d input=walkcost_ba direction=walkdir_ba output=path_ba
drain=path_ba start_coordinates=635576,216485

Here, the paths from A to B and from B to A are different. Depending on the
settings, the paths can be nearly identical. Small differences can arise
because there can be several paths from A to B with equal cumulative costs.

> I don't think what the paper refers to is
> the same thing though.

In this paper, GRASS 6.1.0 was used, and back then r.drain did not have the
option to use a direction map as input, therefore r.drain could not be used
with the output of r.cost/r.walk.

Right now, r.drain is somewhat overloaded: it creates directions for a DEM
same way r.fill.dir does it, or it uses supplied directions, then the
module extracts least costly paths. I suggest to have a new module r.path
that extracts extract least costly paths from input directions and start
points and mark r.drain as deprecated.

Markus M

>
> Anna
>
> > All the best,
> > Nagy Edmond
> >
> > article -
> > http://proceedings.caaconference.org/paper/106_gietl_et_al_caa2007/
> >
> >
> >
> > --
> > Sent from: http://osgeo-org.1560.x6.nabble.com/GRASS-PSC-f4051248.html
> > ___
> > grass-psc mailing list
> > grass-psc@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-psc
> ___
> grass-psc mailing list
> grass-psc@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-psc
___
grass-psc mailing list
grass-psc@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-psc

Re: [GRASS-PSC] GRASS add-on sharing and write access

[Markus Metz]

On Fri, Dec 15, 2017 at 12:03 PM, Nagy Edmond 
wrote:
>
> Dear All,
>
> Thank you very much for your support.
>
> The add-on is now on GitHub. https://github.com/NagyEdmond/v.lcp.network
> Please feel free to evaluate it. Your feedback will be most welcome.

Instead of the compiled files, we would need the original files including a
Makefile. The html file should be a template (see source of other
scripts/modules), the real html file is then generated by make. The
contents of the directory v.lcp.network must be

v.lcp.network
├── Makefile
├── v.lcp.network.html
└── v.lcp.network.py

Best,

Markus M


>
> All the best,
> Nagy Edmond
>
>
>
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GRASS-PSC-f4051248.html
> ___
> grass-psc mailing list
> grass-psc@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-psc
___
grass-psc mailing list
grass-psc@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-psc

Re: [GRASS-PSC] GRASS add-on sharing and write access

[Markus Metz]

Dear Nagy,

On Thu, Dec 14, 2017 at 8:47 PM, Markus Neteler  wrote:
>
> Dear Nagy,
>
> On Thu, Dec 14, 2017 at 12:24 PM, Nagy Edmond 
wrote:
> > Dear GRASS-PSC,
> >
> > Recently, I've been working with least-cost paths in GRASS, and to save
up
> > time, I decided to automate the process by writing an add-on that
generates
> > a vector output resembling a network from a set of input vector points.
It
> > is mostly based on r.cost/r.walk and r.drain.
> >
> > I would be happy to share it with the community, and include it into the
> > official repository. To build some trust, I considered uploading the py
> > script on GitHub for you to look at the code, but I wasn't sure if that
> > would be acceptable. I can still do it if there is no problem.
>
> Feel free to post the link to the repo here.
>
> > I have also read the RFC2 and accept the legal consequences.
Unfortunately I
> > don't have a mentor, but I would appreciate if someone kindly suggested
> > someone.
>
> We'll collectively assist you :)

I am quite interested in your contribution and would like to assist you.

Markus M

>
> > My "osgeo_id" is "eno91".
>
> Welcome!
>
> I have now activated the access and added your record to
> "grass-addons/contributors.csv" in r71939.
>
> Here some hints: Please, prior to submission, check your code and
> manual contributions against the rules defined in the document
> Submitting (and its subsections):
>
> https://trac.osgeo.org/grass/wiki/Submitting
> --> Submitting rules
>
> This ensures a smooth integration into the standard GRASS code base
> and avoids portability problems.
>
> The "What's next" we addressed here:
> https://trac.osgeo.org/grass/wiki/HowToContribute#Thenwhat
>
> Happy coding,
> Markus
>
> --
> Markus Neteler
> GRASS GIS PSC Chair
> http://grass.osgeo.org
> ___
> grass-psc mailing list
> grass-psc@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-psc
___
grass-psc mailing list
grass-psc@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-psc

Re: [GRASS-PSC] too many branches = retirement GRASS6.5.svn (=develbranch6)

[Markus Metz]

On Sun, Apr 6, 2014 at 3:16 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
 On 06/04/14 13:46, Hamish wrote:


 As mentioned before, I wish to use the bulk of my grass dev time
 maintaining the grass 6 line. To do that properly I need a staging
 area, and devbr6 is it.

I don't see the need for a devbr6 because maintaining the GRASS 6 line
means backporting bug fixes from trunk. New functionality should be
implemented in trunk, as in any other project. Bug fixes are then
backported to the release branch, unfortunately we have now two
release branches. Apart from addons, there will most probably not be
any more GRASS 6 development, only GRASS 6 bug fixing, for which a
GRASS 6 release branch is IMHO sufficient.

I don't think it makes sense to maintain two GRASS major versions if
development aka adding new functionality should take place in both.
Some contributors like to implement new functionality in devbr6, but
most contributors follow the (IMHO logical) way of trunk - relbr. The
now proposed development way of trunk - relbr_7 - devbr6 - relbr6
or or also devbr6 - relbr6, skipping trunk, is unrealistic, will slow
down GRASS development, and might lead to diverging branches.

If GRASS 6, and release branch maintenance in general, is restricted
to bug fixing, it should be easy to maintain trunk and two release
branches. Granted that trunk is not abused as addon repository by
adding untested code.

My 2c,

Markus M


 Hosting a clone on github for that is too
 ridiculous and broken a situation to begin to contemplate.

 If devbr6 is removed I simply can not do the stable grass 6
 maintenance job properly. So without that there is really very little
 for me to contribute in future. It will not translate to me spending
 more time working on grass 7, only drive me away from the project.


 I think that seen Hamish' continued effort for this project this a serious
 enough situation to demand a solution.

 But maybe the idea to actually release a first version of grass7 in a not to
 far future is a way out.

 Hamish, maybe you could be the official grass6 maintainer, managing the
 whole grass6 development in the way you propose, i.e. any new development
 and bugfixes first go into grass6dev for a period of testing, before _you_
 make the decision that something can be backported to grass6release. I do
 think however, that for this to work, we would need to regularly publish
 snapshots of grass6dev for easy testing.

 All other devs only commit to grass6dev, never to grass6release.

 Just my 2¢,

 Moritz

 ___
 grass-psc mailing list
 grass-psc@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-psc
___
grass-psc mailing list
grass-psc@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-psc

Re: [GRASS-PSC] Fwd: Proposal: Merge grass-windows list into grass-user

[Markus Metz]

On Fri, Mar 22, 2013 at 5:59 PM, Markus Neteler nete...@osgeo.org wrote:
 Hi PSC,

 please see my proposal below. The rationale is to avoid that messages
 like this
 http://lists.osgeo.org/pipermail/grass-windows/2013-March/002354.html

Oops, fixed in r55498.

+1 for merging the lists, then I would have fixed it earlier...

Markus M


 remain unanswered, see also below. Feedback in grass-windows was
 all positive for the list merge. We can keep its archive as read-only.

 Objections?

 Markus


 -- Forwarded message --
 From: Markus Neteler nete...@osgeo.org
 Date: Tue, Jan 22, 2013 at 9:32 PM
 Subject: Proposal: Merge this list into grass-user
 To: grass-wind...@lists.osgeo.org


 Dear subscribers,

 in the past I observed a (for my taste) too high rate of unanswered
 emails here. Mails which could often have been answered easily
 on the grass-user mailing list since more people are subscribed
 there...

 Moreover, I think that GRASS GIS on MS-Windows has become
 kind of normal. Certainly there are still technical issues but those
 need to be discussed with developers anyway (and just a few are
 subscribed here).

 Hence my suggestion: what about merging this list into
 the grass-user list?
 Archive: http://lists.osgeo.org/pipermail/grass-user/

 I would appreciate discussion about the idea, there is no problem
 to continue this list as-is. Just a random idea for a potentially
 better service :-)

 Best,
 Markus
 ___
 grass-psc mailing list
 grass-psc@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-psc
___
grass-psc mailing list
grass-psc@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-psc

Re: [GRASS-PSC] Access to Grass addons

[Markus Metz]

On Wed, Mar 20, 2013 at 11:36 AM, Margherita Di Leo direg...@gmail.com wrote:


 On Wed, Mar 20, 2013 at 11:33 AM, Moritz Lennert
 mlenn...@club.worldonline.be wrote:

 On 20/03/13 10:31, Andrea Filipello wrote:

 Hello,
 my name is Andrea Filipello and I am a geologist . I am developing  some
 addons for landslide susceptibility assessment. My mentor is Luca
 Delucchi. I  would like to get the write access  to the GRASS-Addons.


 +1


 +1

+1
___
grass-psc mailing list
grass-psc@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-psc

Re: [GRASS-PSC] [GRASS-dev] Grass7 tech-preview release [was Re: [GRASS-user] to move or not move ? grass64 - ? - 7.0]

[Markus Metz]

I like the idea of a tech-preview release of GRASS7!

I think that no more (or at least not many) major changes will go into
GRASS 7, apart from the wxGUI code base. Therefore it would IMHO be
very beneficial to get more feedback on GRASS 7 in order to detect and
fix remaining bugs.

I also like your proposed release schedule of max 1-2 weeks.

Markus M


On Tue, Mar 19, 2013 at 10:25 AM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
 On 18/03/13 23:04, Markus Neteler wrote:

 On Fri, Jan 11, 2013 at 9:53 AM, Rainer M Krugr.m.k...@gmail.com  wrote:
 ...

 Following the discussion, I would like to install GRASS 7 weekly
 snapshot. I relized the Binary
 link (http://grass.osgeo.org/download/software/) but it points back to
 the Linux Download page,
 but I could not find any binaries there for GRASS 7? Maybe this link
 should be removed?

 Just wondering, but not a problem, as I am going to install from source
 anyway.


 In the past days I have cleaned up several of the Web pages.
 I hope they are much clearer now. GRASS 7 downloads are now properly
 mentioned as well.


 Much clearer now !

 I would like to take this debate as an opportunity to touch upon the
 question of a possible tech-preview release of GRASS7.

 Several reasons for that:

 - More and more people are using it (and we are pushing more and more people
 toward using it). Binaries are available for windows and mac, but not for
 most Linux distributions. A preview release might make it easier for these
 distributions to package grass7 and make it available to a larger audience.

 - In many institutions it is (understandably) not easy to convince
 IT-managers to install development snapshots instead of released software.
 Having an official release (even if it is only a tech-preview release)
 should make it easier to install grass7 in institutional settings.

 - I think that grass7 is in a form where we can start advertising it more
 widely and more officially. In terms of timing, it would be great to be able
 to get this out before FOSS4G.

 - From my own egotistical viewpoint, I would love to be able to use grass7
 in my classes next school year, and having a release would make it much
 easier for me to do that.

 Concretely, I see the following type of procedure to make it possible:

 - Freeze the svn repository for any direct new commits for a short period
 (I'd say max 1-2 weeks). Only a few release managers should still have
 direct commit access at this point. (Another way to do it would be to keep
 commit rights open to anyone, and the role of the release managers would be
 to control all commits and revert those that aren't simple bug fixes during
 the freeze).

 - Publish the state of the code at the beginning of the freeze as RC1 with a
 wide call for testing.

 - Only bug fix* commits.

 - Publish RC2 after some bug fixing (possibly after one week).

 - Continue bug fixing*.

 - Release tech-preview (possibly at the end of week 2) with a huge
 disclaimer that this is a tech-preview release and not considered final and
 stable.

 - Open repository again for more general development.


 I don't think we should create a release branch as this would just be a
 tech-preview snaphot of the ongoing development.

 This obviously implies that we plan ahead and that all developers know when
 this freeze will happen, thus avoiding to commit any large and fundamental
 changes just before the freeze. And that we all put aside time during that
 freeze for testing and bug fixing.

 What do you think ?

 Moritz
 ___
 grass-dev mailing list
 grass-...@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-psc mailing list
grass-psc@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-psc

Re: [GRASS-PSC] Fwd: Age of GRASS GIS?

[Markus Metz]

Dear Jim,

thanks a lot for providing very interesting information about the
early stages of GRASS! I am one of the new GRASS developers and enjoy
discovering gems in earlier versions of GRASS that got lost at some
stage. With regard to the combine program of Van Warren, I think that
most of its functionality is now covered by r.mapcalc which is by now
one of the most important GRASS modules because of its versatility.
Moreover, those features that were ** NOT YET AVAILABLE ** in combine
are now available in r.mapcalc. The one single exception I could find
is the group operator which should be easy to (re-)implement.

A large proportion of the code of the first few GRASS versions is a
kind of quality assurance. It is amazing that code written 20 or more
years ago is still able to address the problems of tomorrow, giving
GRASS an advantage over other, younger GIS software packages.

Best regards,

Markus Metz


On Thu, Dec 13, 2012 at 8:43 PM, Markus Neteler nete...@osgeo.org wrote:
 Here another relevant message from Jim.

 m


 -- Forwarded message --
 From: Westervelt, James D ERDC-RDE-CERL-IL james.d.westerv...@erdc.dren.mil
 Date: Mon, Dec 10, 2012 at 5:22 PM
 Subject: Re: Age of GRASS GIS?
 To: Markus Neteler markus.nete...@fmach.it
 Cc: L. Van Warren v...@wdv.com


 Markus, I have no secrets :-)  Share as you wish.

 Attached is the scanned '83 document.  You can see the grass roots therein.

 I see that we hadn't yet put the programmer names on the manual entries.

 Note Van Warren's combine(1) program.  I really liked that program and would
 love to see it brought back to life.

 ___
 grass-psc mailing list
 grass-psc@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-psc

___
grass-psc mailing list
grass-psc@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-psc