So for the meanwhile I can use the workaround with compiling r.stream.* directly with the source for G7, however maybe other users in future are also interested in using these add-ons and will face similar problems I did.
sorry if OT but did I miss something? I thought r.stream* were going to core…?
cheers,
madi
–
Best regards,
Dr. Margherita DI LEO
Scientific / technical project officer
European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261
Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission.
On Thu, Jan 9, 2014 at 2:24 PM, Margherita Di Leo
<dileomargherita@gmail.com> wrote:
On Thu, Jan 9, 2014 at 1:25 PM, Johannes Radinger
So for the meanwhile I can use the workaround with compiling r.stream.*
directly with the source for G7, however maybe other users in future are
also interested in using these add-ons and will face similar problems I did.
sorry if OT but did I miss something? I thought r.stream* were going to
core..?
Maybe it just waits for somebody to put it there, we would like to see it in the core as well.
Do we need for some kind of procedure to decide (e.g. through PSC action, verify that it has been thoroughly tested)
and to designate a developer who moves the code from add-ons to the core?
Helena
Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu
"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”
On Jan 19, 2014, at 2:48 PM, Markus Neteler wrote:
On Thu, Jan 9, 2014 at 2:24 PM, Margherita Di Leo
<dileomargherita@gmail.com> wrote:
On Thu, Jan 9, 2014 at 1:25 PM, Johannes Radinger
So for the meanwhile I can use the workaround with compiling r.stream.*
directly with the source for G7, however maybe other users in future are
also interested in using these add-ons and will face similar problems I did.
sorry if OT but did I miss something? I thought r.stream* were going to
core..?
Maybe it just waits for somebody to put it there, we would like to see it in the core as well.
it's not only question of "putting it here". The modules need some
review (code, parameters, manuals). I will be able to help with this
procedure in some days. There will be hopefully more people
interested. Martin
Maybe it just waits for somebody to put it there, we would like to see it in the core as well.
it's not only question of "putting it here". The modules need some
review (code, parameters, manuals). I will be able to help with this
procedure in some days. There will be hopefully more people
interested. Martin
If that is the case, that is a completely different issue, I thought they are ready.
We can look at how much work it would be.
Then what about v.transects - it has been updated to grass7 and tested in class and has a manual and testing report available.
Can this module go to core? How do we make the decision for "ready to go" modules?
On Sun, Jan 19, 2014 at 9:08 PM, Helena Mitasova <hmitaso@ncsu.edu> wrote:
On Jan 19, 2014, at 3:01 PM, Martin Landa wrote:
Hi,
2014/1/19 Helena Mitasova <hmitaso@ncsu.edu>:
Maybe it just waits for somebody to put it there, we would like to see it in the core as well.
r.stream.extract is already in core, the other modules are scheduled to follow.
it's not only question of "putting it here". The modules need some
review (code, parameters, manuals). I will be able to help with this
procedure in some days. There will be hopefully more people
interested. Martin
If that is the case, that is a completely different issue, I thought they are ready.
I agree with Martin that the modules need some review. E.g. I
encountered a bug in r.stream.order where some stream segments got
order 0 (zero) which is invalid.
I am also interested in having these modules in core and want to help
with the review as soon as I find some time...
Markus M
We can look at how much work it would be.
Then what about v.transects - it has been updated to grass7 and tested in class and has a manual and testing report available.
Can this module go to core? How do we make the decision for "ready to go" modules?
On Mon, Jan 20, 2014 at 9:00 AM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
On Sun, Jan 19, 2014 at 9:08 PM, Helena Mitasova <hmitaso@ncsu.edu> wrote:
On Jan 19, 2014, at 3:01 PM, Martin Landa wrote:
it's not only question of "putting it here". The modules need some
review (code, parameters, manuals).
If that is the case, that is a completely different issue, I thought they are ready.
I agree with Martin that the modules need some review. E.g. I
encountered a bug in r.stream.order where some stream segments got
order 0 (zero) which is invalid.
I am also interested in having these modules in core and want to help
with the review as soon as I find some time...
Markus M
Concerning the release branch of GRASS 7, in r59606 the r.stream.*
modules got disabled.
If they are not yet production ready, should we move them back to Addons?
2014-10-07 17:32 GMT+02:00 Markus Neteler <neteler@osgeo.org>:
[...]
Concerning the release branch of GRASS 7, in r59606 the r.stream.*
modules got disabled.
If they are not yet production ready, should we move them back to Addons?
MarkusM: Is there any chance to fix them before releasing G70?
If not I would suggest to move them back to Addons... Martin
Concerning the release branch of GRASS 7, in r59606 the r.stream.*
modules got disabled.
If they are not yet production ready, should we move them back to Addons?
MarkusM: Is there any chance to fix them before releasing G70?
If not I would suggest to move them back to Addons… Martin
Can I urge please to take a decision, either ways.
Thank you,
madi
–
Best regards,
Dr. Margherita DI LEO
Scientific / technical project officer
European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261
Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission.
On Thu, Oct 23, 2014 at 5:35 PM, Martin Landa <landa.martin@gmail.com> wrote:
2014-10-23 17:23 GMT+02:00 Markus Neteler <neteler@osgeo.org>:
In case of moving them back to Addons, it would be r.stream.* except
for r.stream.extract.
any opinion from MarkusM who disabled r.streams.* modules in releasebranch_70?
I have now moved selected r.stream modules (r.stream.channel,
r.stream.distance, r.stream.order, r.stream.segment, r.stream.slope,
r.stream.snap, r.stream.stats) back from relbranch7 to Addons
(changesets r62511 and r62512).
These modules can now be installed with g.extension in GRASS GIS 7.0.svn.
Future fixes in trunk (i.e. GRASS GIS 7.1.svn) may be backported to
Addons at this point.
2014-11-01 1:07 GMT+01:00 Markus Neteler <neteler@osgeo.org>:
[...]
Future fixes in trunk (i.e. GRASS GIS 7.1.svn) may be backported to
Addons at this point.
we could probably also remove these modules from trunk and maintain
them on one place only (addons for now, can be changed in the future).
What do you think about that?
Future fixes in trunk (i.e. GRASS GIS 7.1.svn) may be backported to
Addons at this point.
we could probably also remove these modules from trunk and maintain
them on one place only (addons for now, can be changed in the future).
What do you think about that?
Martin
+1 for maintaining in one place.
regarding winGRASS the situation is following:
- in trunk: all r.stream.* are in trunk, only r.stream.basins is moved to
addon
- in relbranch7: only r.stream.extract is there, all others are in addon
regarding trunk winGRASS there is some doubling of r.stream.*-modules. most
of them are in trunk svn, you can then install these tools again by
g.extension, although they are already there.
On Sun, Nov 2, 2014 at 10:52 PM, Helmut Kudrnovsky <hellik@web.de> wrote:
Martin Landa wrote
we could probably also remove these modules from trunk and maintain
them on one place only (addons for now, can be changed in the future).
What do you think about that?
yes, good point.
Martin
+1 for maintaining in one place.
regarding winGRASS the situation is following:
- in trunk: all r.stream.* are in trunk, only r.stream.basins is moved to
addon
- in relbranch7: only r.stream.extract is there, all others are in addon
regarding trunk winGRASS there is some doubling of r.stream.*-modules. most
of them are in trunk svn, you can then install these tools again by
g.extension, although they are already there.
it's very confusing ...
Ok, now I have removed in r62560 all r.stream.* except for
r.stream.extract also from trunk (and before sync'ed trunk in r62558
and r62559 to the version in Addons which got moved therein from
relbranch7).
On Sun, Nov 2, 2014 at 11:26 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Sun, Nov 2, 2014 at 10:52 PM, Helmut Kudrnovsky <hellik@web.de> wrote:
Martin Landa wrote
we could probably also remove these modules from trunk and maintain
them on one place only (addons for now, can be changed in the future).
What do you think about that?
yes, good point.
+1
Once they are ready, the r.stream.* modules should be moved from
addons to both relbr7 and trunk.
Martin
+1 for maintaining in one place.
regarding winGRASS the situation is following:
- in trunk: all r.stream.* are in trunk, only r.stream.basins is moved to
addon
- in relbranch7: only r.stream.extract is there, all others are in addon
regarding trunk winGRASS there is some doubling of r.stream.*-modules. most
of them are in trunk svn, you can then install these tools again by
g.extension, although they are already there.
it's very confusing ...
Ok, now I have removed in r62560 all r.stream.* except for
r.stream.extract also from trunk (and before sync'ed trunk in r62558
and r62559 to the version in Addons which got moved therein from
relbranch7).
Most importantly it is the NULL handling that needs to be fixed, and
synced between the ram and disk modes. More generally, the ram and
disk modes need to be synced and validated. For ease of maintenance,
the ram mode could be removed.