Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Sören Gebbert]

2016-10-06 21:26 GMT+02:00 Markus Metz :

> On Tue, Oct 4, 2016 at 11:02 PM, Sören Gebbert
>  wrote:
> >
> >
> > 2016-10-04 22:22 GMT+02:00 Markus Metz :
> >>
> >> Recently I fixed bugs in r.stream.order, related to stream length
> >> calculations which are in turn used to determine stream orders. The
> >> gunittest did not pick up 1) the bugs, 2) the bug fixes.
>
> sorry for the confusion, r.stream.order does not have any testsuite,
> only v.stream.order has.
>
> >>
> >> I agree, for tests during development, not for gunittests.
> >>
> >> From the examples I read, gunittests expect a specific output. If the
> >> expected output (obtained with an assumed correct version of the
> >> module) is wrong, the gunittest is bogus. gunittests are ok to make
> >> sure the output does not change, but not ok to make sure the output is
> >> correct. Two random examples are r.stream.order and r.univar.
> >
> >
> > I don't understand your argument here or i have a principal problem in
> > understanding the test topic.
> >
> > You have to implement a test that checks for correct output, this is the
> > meaning of a test.
>
> Exactly. During development, however, you need to run many more tests
> until you are confident that the output is correct. Then you submit
> the changes. My point is that modules need to be tested thoroughly
> during development (which is not always the case), and a testsuite to
> make sure that the output matches expectations is nice to have. In
> most cases,
>

Implement all tests while developing a module as gunittests and you will
have
a testsuite in the end. You have to implement the tests anyway, so why not
using gunittests from the beginning,
as part of the development process?

If you implement a Python library, then use doctests to document and check
functions and classes while
developing them. These doctests are part of the documentation and excellent
examples howto use
a specific function or class. And by pure magic, you will have a testsuite
in the end.
Have a look at PyGRASS, tons of doctests that are code examples and
validation tests
at the same time.

>
>  
> if [ $? -ne 0 ] ; then
>   echo "ERROR: Module  failed"
>   exit 1
> fi
>
> should do the job
>

Nope.

>
> no offence :-;
>
> > You have to design a test scenario from which you know
> > what the correct solution is and then you test for the correct solution.
> > What is with r.univar? Create a test map with a specific number of cells
> > with specific values and test if r.univar is able to compute the correct
> > values that you have validated by hand.
> >
> > -- what is the mean, min and max of 10 cells each with value 5? Its 5! --
>
> what is the correct standard deviation? sqrt((1/n) * SUM(x - mu)) or
> sqrt((1/(n - 1)) * SUM(x - mu))?
>
> If you decide to use the first version, then implement tests for the first
version.
If you decide to use the second version, then ... .
If you decide to support both versions, then implement tests for both
versions.


> r.univar uses sqrt((1/n) * SUM(x - mu)) but sqrt((1/(n - 1)) * SUM(x -
> mu)) might be more appropriate because you could argue that raster
> maps are always a sample. Apart from that, r.univar uses a one-pass
> method to calculate stddev which is debatable.
>

If you decide to implement a specific version of stddev, then write a test
for it.
Debating which version is more appropriate has nothing to do with the
actual software development process.

Best regards
Soeren


>
> Markus M
>
> >
> > The most simple check for that is the raster range check in gunittest. If
> > you know what the range of the resulting raster map has to be, then you
> can
> > test for it. If this is not enough then you can check against the
> > uni-variate statistic output of the raster map, since you know for sure
> what
> > the result is for min, mean, median, max and so on. If this is not
> > sufficient use r.out.ascii and check against the correct solution that
> you
> > have created beforehand. If this is not sufficient then use pygrass and
> > investigate each raster cell of the resulting output map.
> >
> > Best regards
> > Soeren
> >
> >>
> >> Markus M
> >>
> >> >
> >> > Best regards
> >> > Soeren
> >> >
> >> >>
> >> >> my2c
> >> >>
> >> >> Markus M
> >> >>
> >> >> >
> >> >> > Best
> >> >> > Sören
> >> >> >
> >> >> >>
> >> >> >> One thing we could think about is activating the toolbox idea a
> bit
> >> >> >> more
> >> >> >> and creating a specific OBIA toolbox in addons.
> >> >> >>
> >> >> >>> Identified candidates could be added to core once they fulfill
> the
> >> >> >>> requirements above. Would that happen only in minor releases or
> >> >> >>> would
> >> >> >>> that also be possible in point releases?
> >> >> >>
> >> >> >>
> >> >> >> Adding modules to core is not an API change, so I don't see why
> they
> >> >> >> can't
> >> >> >> be added at any time. But then again, having a series of new
> 

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Markus Metz]

On Tue, Oct 4, 2016 at 11:02 PM, Sören Gebbert
 wrote:
>
>
> 2016-10-04 22:22 GMT+02:00 Markus Metz :
>>
>> Recently I fixed bugs in r.stream.order, related to stream length
>> calculations which are in turn used to determine stream orders. The
>> gunittest did not pick up 1) the bugs, 2) the bug fixes.

sorry for the confusion, r.stream.order does not have any testsuite,
only v.stream.order has.

>>
>> I agree, for tests during development, not for gunittests.
>>
>> From the examples I read, gunittests expect a specific output. If the
>> expected output (obtained with an assumed correct version of the
>> module) is wrong, the gunittest is bogus. gunittests are ok to make
>> sure the output does not change, but not ok to make sure the output is
>> correct. Two random examples are r.stream.order and r.univar.
>
>
> I don't understand your argument here or i have a principal problem in
> understanding the test topic.
>
> You have to implement a test that checks for correct output, this is the
> meaning of a test.

Exactly. During development, however, you need to run many more tests
until you are confident that the output is correct. Then you submit
the changes. My point is that modules need to be tested thoroughly
during development (which is not always the case), and a testsuite to
make sure that the output matches expectations is nice to have. In
most cases,

 
if [ $? -ne 0 ] ; then
  echo "ERROR: Module  failed"
  exit 1
fi

should do the job

no offence :-;

> You have to design a test scenario from which you know
> what the correct solution is and then you test for the correct solution.
> What is with r.univar? Create a test map with a specific number of cells
> with specific values and test if r.univar is able to compute the correct
> values that you have validated by hand.
>
> -- what is the mean, min and max of 10 cells each with value 5? Its 5! --

what is the correct standard deviation? sqrt((1/n) * SUM(x - mu)) or
sqrt((1/(n - 1)) * SUM(x - mu))?

r.univar uses sqrt((1/n) * SUM(x - mu)) but sqrt((1/(n - 1)) * SUM(x -
mu)) might be more appropriate because you could argue that raster
maps are always a sample. Apart from that, r.univar uses a one-pass
method to calculate stddev which is debatable.

Markus M

>
> The most simple check for that is the raster range check in gunittest. If
> you know what the range of the resulting raster map has to be, then you can
> test for it. If this is not enough then you can check against the
> uni-variate statistic output of the raster map, since you know for sure what
> the result is for min, mean, median, max and so on. If this is not
> sufficient use r.out.ascii and check against the correct solution that you
> have created beforehand. If this is not sufficient then use pygrass and
> investigate each raster cell of the resulting output map.
>
> Best regards
> Soeren
>
>>
>> Markus M
>>
>> >
>> > Best regards
>> > Soeren
>> >
>> >>
>> >> my2c
>> >>
>> >> Markus M
>> >>
>> >> >
>> >> > Best
>> >> > Sören
>> >> >
>> >> >>
>> >> >> One thing we could think about is activating the toolbox idea a bit
>> >> >> more
>> >> >> and creating a specific OBIA toolbox in addons.
>> >> >>
>> >> >>> Identified candidates could be added to core once they fulfill the
>> >> >>> requirements above. Would that happen only in minor releases or
>> >> >>> would
>> >> >>> that also be possible in point releases?
>> >> >>
>> >> >>
>> >> >> Adding modules to core is not an API change, so I don't see why they
>> >> >> can't
>> >> >> be added at any time. But then again, having a series of new modules
>> >> >> can be
>> >> >> sufficient to justify a new minor release ;-)
>> >> >>
>> >> >>> Or is that already too much formality and if someone wishes to see
>> >> >>> an
>> >> >>> addon in core that is simply discussed on ML?
>> >> >>
>> >> >>
>> >> >> Generally, I would think that discussion on ML is the best way to
>> >> >> handle
>> >> >> this.
>> >> >>
>> >> >> Moritz
>> >> >>
>> >> >>
>> >> >> ___
>> >> >> grass-dev mailing list
>> >> >> grass-dev@lists.osgeo.org
>> >> >> http://lists.osgeo.org/mailman/listinfo/grass-dev
>> >> >
>> >> > ___
>> >> > grass-dev mailing list
>> >> > grass-dev@lists.osgeo.org
>> >> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>> >
>> >
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Sören Gebbert]

2016-10-04 22:22 GMT+02:00 Markus Metz :

> On Tue, Oct 4, 2016 at 5:42 PM, Sören Gebbert
>  wrote:
> > Hi,
> >>
> >>
> >> >
> >> > You are very welcome to write the missing tests for core modules.
> >> >
> >> > However, i don't understand the argument that because many core
> modules
> >> > have
> >> > no tests, therefore new modules don't need them. If developers of
> addon
> >> > module are serious about the attempt to make their modules usable and
> >> > maintainable for others, then they have to implement tests. Its and
> >> > integral
> >> > part of the development process and GRASS has a beautiful test
> >> > environment
> >> > hat makes writing tests easy. Tests and documentation are part of
> coding
> >> > and
> >> > not something special. I don't think this is a hard requirement.
> >> >
> >> > There is a nice statement that is not far from the truth: Untested
> code
> >> > is
> >> > broken code.
> >>
> >> these gunittests only test if a module output stays the same. This
> >
> >
> > This is simply wrong, please read the gunittest documentation.
>
> but then why does
> >
> > The gunittest for the v.stream.order addon is an example how its done:
> > https://trac.osgeo.org/grass/browser/grass-addons/grass7/
> vector/v.stream.order/testsuite/test_stream_order.py
>
> assume certain order numbers for features 4 and 7? What if these order
> numbers are wrong?
>

The checked order numbers are validated by hand. The test example is based
on artificial data, that i have created, for which i know what the correct
order numbers are. Hence i can test if certain features have specific order
numbers, since i know the correct solution.

>
> Recently I fixed bugs in r.stream.order, related to stream length
> calculations which are in turn used to determine stream orders. The
> gunittest did not pick up 1) the bugs, 2) the bug fixes.
>

Then better test implementations are required that checks for correct
output. If a bug was found a test should be written to check the bugfix.
Have a look at this commit that adds two new tests to validate the provided
bugfix:

https://trac.osgeo.org/grass/changeset/69586

A one line bugfix and 50 lines of test code. :)


>
> >
> > You can write gunittests that will test every flag, every option, their
> > combination and any output of a module. I have implemented plenty of
> tests,
> > that check for correct error handling. Writing tests is effort, but you
> have
> > to do it anyway. Why not implementing a gunittest for every feature while
> > developing the module?
> >>
> >>
> >> My guess for the r.stream.* modules is at least 40 man hours of
> >> testing to make sure they work correctly. That includes evaluation of
> >> float usage, handling of NULL data, comparison of results with and
> >> without the -m flag. Testing should be done with both high-res (LIDAR)
> >> and low-res (e.g. SRTM) DEMs.
> >
> >
> > Tests can be performed on artificial data that tests all aspects of the
> > algorithm. Tests that show the correctness of the algorithm for specific
> > small cases should be preferred. However, large data should not be an
> > obstacle to write a test.
>
> I agree, for tests during development, not for gunittests.
>
> From the examples I read, gunittests expect a specific output. If the
> expected output (obtained with an assumed correct version of the
> module) is wrong, the gunittest is bogus. gunittests are ok to make
> sure the output does not change, but not ok to make sure the output is
> correct. Two random examples are r.stream.order and r.univar.
>

I don't understand your argument here or i have a principal problem in
understanding the test topic.

You have to implement a test that checks for correct output, this is the
meaning of a test. You have to design a test scenario from which you know
what the correct solution is and then you test for the correct solution.
What is with r.univar? Create a test map with a specific number of cells
with specific values and test if r.univar is able to compute the correct
values that you have validated by hand.

-- what is the mean, min and max of 10 cells each with value 5? Its 5! --

The most simple check for that is the raster range check in gunittest. If
you know what the range of the resulting raster map has to be, then you can
test for it. If this is not enough then you can check against the
uni-variate statistic output of the raster map, since you know for sure
what the result is for min, mean, median, max and so on. If this is not
sufficient use r.out.ascii and check against the correct solution that you
have created beforehand. If this is not sufficient then use pygrass and
investigate each raster cell of the resulting output map.

Best regards
Soeren


> Markus M
>
> >
> > Best regards
> > Soeren
> >
> >>
> >> my2c
> >>
> >> Markus M
> >>
> >> >
> >> > Best
> >> > Sören
> >> >
> >> >>
> >> >> One thing we could think about is activating the toolbox idea a bit
> 

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Anna Petrášová]

On Tue, Oct 4, 2016 at 4:22 PM, Markus Metz
 wrote:
> On Tue, Oct 4, 2016 at 5:42 PM, Sören Gebbert
>  wrote:
>> Hi,
>>>
>>>
>>> >
>>> > You are very welcome to write the missing tests for core modules.
>>> >
>>> > However, i don't understand the argument that because many core modules
>>> > have
>>> > no tests, therefore new modules don't need them. If developers of addon
>>> > module are serious about the attempt to make their modules usable and
>>> > maintainable for others, then they have to implement tests. Its and
>>> > integral
>>> > part of the development process and GRASS has a beautiful test
>>> > environment
>>> > hat makes writing tests easy. Tests and documentation are part of coding
>>> > and
>>> > not something special. I don't think this is a hard requirement.
>>> >
>>> > There is a nice statement that is not far from the truth: Untested code
>>> > is
>>> > broken code.
>>>
>>> these gunittests only test if a module output stays the same. This
>>
>>
>> This is simply wrong, please read the gunittest documentation.
>
> but then why does
>>
>> The gunittest for the v.stream.order addon is an example how its done:
>> https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.stream.order/testsuite/test_stream_order.py
>
> assume certain order numbers for features 4 and 7? What if these order
> numbers are wrong?
>
> Recently I fixed bugs in r.stream.order, related to stream length
> calculations which are in turn used to determine stream orders. The
> gunittest did not pick up 1) the bugs, 2) the bug fixes.
>
>>
>> You can write gunittests that will test every flag, every option, their
>> combination and any output of a module. I have implemented plenty of tests,
>> that check for correct error handling. Writing tests is effort, but you have
>> to do it anyway. Why not implementing a gunittest for every feature while
>> developing the module?
>>>
>>>
>>> My guess for the r.stream.* modules is at least 40 man hours of
>>> testing to make sure they work correctly. That includes evaluation of
>>> float usage, handling of NULL data, comparison of results with and
>>> without the -m flag. Testing should be done with both high-res (LIDAR)
>>> and low-res (e.g. SRTM) DEMs.
>>
>>
>> Tests can be performed on artificial data that tests all aspects of the
>> algorithm. Tests that show the correctness of the algorithm for specific
>> small cases should be preferred. However, large data should not be an
>> obstacle to write a test.
>
> I agree, for tests during development, not for gunittests.
>
> From the examples I read, gunittests expect a specific output. If the
> expected output (obtained with an assumed correct version of the
> module) is wrong, the gunittest is bogus. gunittests are ok to make
> sure the output does not change, but not ok to make sure the output is
> correct. Two random examples are r.stream.order and r.univar.


I am not sure why are we discussing this, it's pretty obvious that
gunittests can serve to a) test inputs/outputs b) catch changes in
results (whether correct or incorrect) c) test correctness of results.
It just depends how you write them, and yes, for some modules c) is
more difficult to implement than for others.

Anna

>
> Markus M
>
>>
>> Best regards
>> Soeren
>>
>>>
>>> my2c
>>>
>>> Markus M
>>>
>>> >
>>> > Best
>>> > Sören
>>> >
>>> >>
>>> >> One thing we could think about is activating the toolbox idea a bit
>>> >> more
>>> >> and creating a specific OBIA toolbox in addons.
>>> >>
>>> >>> Identified candidates could be added to core once they fulfill the
>>> >>> requirements above. Would that happen only in minor releases or would
>>> >>> that also be possible in point releases?
>>> >>
>>> >>
>>> >> Adding modules to core is not an API change, so I don't see why they
>>> >> can't
>>> >> be added at any time. But then again, having a series of new modules
>>> >> can be
>>> >> sufficient to justify a new minor release ;-)
>>> >>
>>> >>> Or is that already too much formality and if someone wishes to see an
>>> >>> addon in core that is simply discussed on ML?
>>> >>
>>> >>
>>> >> Generally, I would think that discussion on ML is the best way to
>>> >> handle
>>> >> this.
>>> >>
>>> >> Moritz
>>> >>
>>> >>
>>> >> ___
>>> >> grass-dev mailing list
>>> >> grass-dev@lists.osgeo.org
>>> >> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>> >
>>> > ___
>>> > grass-dev mailing list
>>> > grass-dev@lists.osgeo.org
>>> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Markus Metz]

On Tue, Oct 4, 2016 at 5:42 PM, Sören Gebbert
 wrote:
> Hi,
>>
>>
>> >
>> > You are very welcome to write the missing tests for core modules.
>> >
>> > However, i don't understand the argument that because many core modules
>> > have
>> > no tests, therefore new modules don't need them. If developers of addon
>> > module are serious about the attempt to make their modules usable and
>> > maintainable for others, then they have to implement tests. Its and
>> > integral
>> > part of the development process and GRASS has a beautiful test
>> > environment
>> > hat makes writing tests easy. Tests and documentation are part of coding
>> > and
>> > not something special. I don't think this is a hard requirement.
>> >
>> > There is a nice statement that is not far from the truth: Untested code
>> > is
>> > broken code.
>>
>> these gunittests only test if a module output stays the same. This
>
>
> This is simply wrong, please read the gunittest documentation.

but then why does
>
> The gunittest for the v.stream.order addon is an example how its done:
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.stream.order/testsuite/test_stream_order.py

assume certain order numbers for features 4 and 7? What if these order
numbers are wrong?

Recently I fixed bugs in r.stream.order, related to stream length
calculations which are in turn used to determine stream orders. The
gunittest did not pick up 1) the bugs, 2) the bug fixes.

>
> You can write gunittests that will test every flag, every option, their
> combination and any output of a module. I have implemented plenty of tests,
> that check for correct error handling. Writing tests is effort, but you have
> to do it anyway. Why not implementing a gunittest for every feature while
> developing the module?
>>
>>
>> My guess for the r.stream.* modules is at least 40 man hours of
>> testing to make sure they work correctly. That includes evaluation of
>> float usage, handling of NULL data, comparison of results with and
>> without the -m flag. Testing should be done with both high-res (LIDAR)
>> and low-res (e.g. SRTM) DEMs.
>
>
> Tests can be performed on artificial data that tests all aspects of the
> algorithm. Tests that show the correctness of the algorithm for specific
> small cases should be preferred. However, large data should not be an
> obstacle to write a test.

I agree, for tests during development, not for gunittests.

From the examples I read, gunittests expect a specific output. If the
expected output (obtained with an assumed correct version of the
module) is wrong, the gunittest is bogus. gunittests are ok to make
sure the output does not change, but not ok to make sure the output is
correct. Two random examples are r.stream.order and r.univar.

Markus M

>
> Best regards
> Soeren
>
>>
>> my2c
>>
>> Markus M
>>
>> >
>> > Best
>> > Sören
>> >
>> >>
>> >> One thing we could think about is activating the toolbox idea a bit
>> >> more
>> >> and creating a specific OBIA toolbox in addons.
>> >>
>> >>> Identified candidates could be added to core once they fulfill the
>> >>> requirements above. Would that happen only in minor releases or would
>> >>> that also be possible in point releases?
>> >>
>> >>
>> >> Adding modules to core is not an API change, so I don't see why they
>> >> can't
>> >> be added at any time. But then again, having a series of new modules
>> >> can be
>> >> sufficient to justify a new minor release ;-)
>> >>
>> >>> Or is that already too much formality and if someone wishes to see an
>> >>> addon in core that is simply discussed on ML?
>> >>
>> >>
>> >> Generally, I would think that discussion on ML is the best way to
>> >> handle
>> >> this.
>> >>
>> >> Moritz
>> >>
>> >>
>> >> ___
>> >> grass-dev mailing list
>> >> grass-dev@lists.osgeo.org
>> >> http://lists.osgeo.org/mailman/listinfo/grass-dev
>> >
>> > ___
>> > grass-dev mailing list
>> > grass-dev@lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Sören Gebbert]

Hi,

>
> >
> > You are very welcome to write the missing tests for core modules.
> >
> > However, i don't understand the argument that because many core modules
> have
> > no tests, therefore new modules don't need them. If developers of addon
> > module are serious about the attempt to make their modules usable and
> > maintainable for others, then they have to implement tests. Its and
> integral
> > part of the development process and GRASS has a beautiful test
> environment
> > hat makes writing tests easy. Tests and documentation are part of coding
> and
> > not something special. I don't think this is a hard requirement.
> >
> > There is a nice statement that is not far from the truth: Untested code
> is
> > broken code.
>
> these gunittests only test if a module output stays the same. This
>

This is simply wrong, please read the gunittest documentation.


> does not mean that a module output is correct. Tested code means first
> of all that the code has been tested with all sorts of input data and
> combinations of input data and flags. All these tests, e.g. what I did
>

The gunittest framework is designed to do exactly that.
It has plenty of methods to validate the output
of modules, ranging from key/value validation, over statistical analysis of
the output, to md5
checksum validation for raster, 3D raster, vector and binary/text file
output.
It can test floating point output to a specific precision to avoid rounding
errors or to consider the
variability of a random number based algorithm like random forest or
boosted regression trees.


> for i.segment or r.stream.* (where I am not even the main author)
> should IMHO not go into a gunittest framework because then running
> gunittests will take a very long time. In short, simply adding
> gunittests to addon modules is not enough, code needs to be tested
> more thoroughly during development than what can be done with
> gunittests.
>

The gunittest for the v.stream.order addon is an example how its done:
https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.stream.order/testsuite/test_stream_order.py

You can write gunittests that will test every flag, every option, their
combination and any output of a module. I have implemented plenty of tests,
that check for correct error handling. Writing tests is effort, but you
have to do it anyway. Why not implementing a gunittest for every feature
while developing the module?

>
> My guess for the r.stream.* modules is at least 40 man hours of
> testing to make sure they work correctly. That includes evaluation of
> float usage, handling of NULL data, comparison of results with and
> without the -m flag. Testing should be done with both high-res (LIDAR)
> and low-res (e.g. SRTM) DEMs.
>

Tests can be performed on artificial data that tests all aspects of the
algorithm. Tests that show the correctness of the algorithm for specific
small cases should be preferred. However, large data should not be an
obstacle to write a test.

Best regards
Soeren


> my2c
>
> Markus M
>
> >
> > Best
> > Sören
> >
> >>
> >> One thing we could think about is activating the toolbox idea a bit more
> >> and creating a specific OBIA toolbox in addons.
> >>
> >>> Identified candidates could be added to core once they fulfill the
> >>> requirements above. Would that happen only in minor releases or would
> >>> that also be possible in point releases?
> >>
> >>
> >> Adding modules to core is not an API change, so I don't see why they
> can't
> >> be added at any time. But then again, having a series of new modules
> can be
> >> sufficient to justify a new minor release ;-)
> >>
> >>> Or is that already too much formality and if someone wishes to see an
> >>> addon in core that is simply discussed on ML?
> >>
> >>
> >> Generally, I would think that discussion on ML is the best way to handle
> >> this.
> >>
> >> Moritz
> >>
> >>
> >> ___
> >> grass-dev mailing list
> >> grass-dev@lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/grass-dev
> >
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Helmut Kudrnovsky]

Martin Landa wrote
> Hi Markus,
> 
> 2016-10-04 16:13 GMT+02:00 Markus Metz 

> markus.metz.giswork@

> :
>> My guess for the r.stream.* modules is at least 40 man hours of
>> testing to make sure they work correctly. That includes evaluation of
>> float usage, handling of NULL data, comparison of results with and
>> without the -m flag. Testing should be done with both high-res (LIDAR)
>> and low-res (e.g. SRTM) DEMs.
> 
> about r.stream modules, ASAIR the major blocker for these modules to
> be moved to core is problem is memory mode, right? I don't remember if
> there is any ticket about that. Martin

at least as a comment in this ticket:

https://trac.osgeo.org/grass/ticket/2237#comment:1



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Upcoming-7-2-0-review-which-addons-to-move-to-core-tp5274533p5289237.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Martin Landa]

Hi Markus,

2016-10-04 16:13 GMT+02:00 Markus Metz :
> My guess for the r.stream.* modules is at least 40 man hours of
> testing to make sure they work correctly. That includes evaluation of
> float usage, handling of NULL data, comparison of results with and
> without the -m flag. Testing should be done with both high-res (LIDAR)
> and low-res (e.g. SRTM) DEMs.

about r.stream modules, ASAIR the major blocker for these modules to
be moved to core is problem is memory mode, right? I don't remember if
there is any ticket about that. Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Martin Landa]

Hi,

2016-10-02 21:27 GMT+02:00 Sören Gebbert :
> In my humble opinion we should accept only new modules in core, that are
> covered by gunittets and this should not only be related to addons. Every
> new module must have tests.

we should have definitely some official procedure (requirements) for
"graduating" module being part of core. Ideally written as a new RFC.
Does it make sense to you, any volunteer to start working on a draft
of RFC #6?

Martin

[1] https://trac.osgeo.org/grass/wiki/RFC

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Markus Metz]

On Sun, Oct 2, 2016 at 9:43 PM, Sören Gebbert
 wrote:
>
>
> 2016-10-02 13:24 GMT+02:00 Moritz Lennert :
>>
>> On 01/10/16 21:25, Blumentrath, Stefan wrote:
>>>
>>> Sounds fair enough as requirements for new core modules. “Maintainable
>>> code” would in praxis mean “the module has undergone a code review by a
>>> core developer”?
>>>
>>> Those requirements would add to Markus requirement of “maturity”, which
>>> I would interpret like “the module has been tested in praxis and options
>>> and flags are consolidated” (so no major changes are expected /
>>> planned)...?
>>>
>>>
>>>
>>> I am afraid, it seems only very few of the suggested modules are covered
>>> with unit tests. Most of them have a good documentation. No idea about
>>> the maintainability of the code...
>>>
>>>
>>>
>>> How should we proceed with this topic? Should the named modules (and
>>> from my point of view Moritz OBIA modules would be very welcome too)
>>
>>
>> They definitely do not meet the enounced criteria, yet. No tests and
>> AFAIK, most of them have only been used inhouse by my colleagues.
>>
>> So, I'm happy to have them live addons for now.
>>
>> This said, I think the requirement of tests is something I would like to
>> see discussed a bit more. This is a pretty heavy requirement and many
>> current core modules do not have unit tests...
>
> You are very welcome to write the missing tests for core modules.
>
> However, i don't understand the argument that because many core modules have
> no tests, therefore new modules don't need them. If developers of addon
> module are serious about the attempt to make their modules usable and
> maintainable for others, then they have to implement tests. Its and integral
> part of the development process and GRASS has a beautiful test environment
> hat makes writing tests easy. Tests and documentation are part of coding and
> not something special. I don't think this is a hard requirement.
>
> There is a nice statement that is not far from the truth: Untested code is
> broken code.

these gunittests only test if a module output stays the same. This
does not mean that a module output is correct. Tested code means first
of all that the code has been tested with all sorts of input data and
combinations of input data and flags. All these tests, e.g. what I did
for i.segment or r.stream.* (where I am not even the main author)
should IMHO not go into a gunittest framework because then running
gunittests will take a very long time. In short, simply adding
gunittests to addon modules is not enough, code needs to be tested
more thoroughly during development than what can be done with
gunittests.

My guess for the r.stream.* modules is at least 40 man hours of
testing to make sure they work correctly. That includes evaluation of
float usage, handling of NULL data, comparison of results with and
without the -m flag. Testing should be done with both high-res (LIDAR)
and low-res (e.g. SRTM) DEMs.

my2c

Markus M

>
> Best
> Sören
>
>>
>> One thing we could think about is activating the toolbox idea a bit more
>> and creating a specific OBIA toolbox in addons.
>>
>>> Identified candidates could be added to core once they fulfill the
>>> requirements above. Would that happen only in minor releases or would
>>> that also be possible in point releases?
>>
>>
>> Adding modules to core is not an API change, so I don't see why they can't
>> be added at any time. But then again, having a series of new modules can be
>> sufficient to justify a new minor release ;-)
>>
>>> Or is that already too much formality and if someone wishes to see an
>>> addon in core that is simply discussed on ML?
>>
>>
>> Generally, I would think that discussion on ML is the best way to handle
>> this.
>>
>> Moritz
>>
>>
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Sören Gebbert]

2016-10-02 13:24 GMT+02:00 Moritz Lennert :
>
> On 01/10/16 21:25, Blumentrath, Stefan wrote:
>>
>> Sounds fair enough as requirements for new core modules. “Maintainable
>> code” would in praxis mean “the module has undergone a code review by a
>> core developer”?
>>
>> Those requirements would add to Markus requirement of “maturity”, which
>> I would interpret like “the module has been tested in praxis and options
>> and flags are consolidated” (so no major changes are expected /
>> planned)...?
>>
>>
>>
>> I am afraid, it seems only very few of the suggested modules are covered
>> with unit tests. Most of them have a good documentation. No idea about
>> the maintainability of the code...
>>
>>
>>
>> How should we proceed with this topic? Should the named modules (and
>> from my point of view Moritz OBIA modules would be very welcome too)
>
>
> They definitely do not meet the enounced criteria, yet. No tests and
AFAIK, most of them have only been used inhouse by my colleagues.
>
> So, I'm happy to have them live addons for now.
>
> This said, I think the requirement of tests is something I would like to
see discussed a bit more. This is a pretty heavy requirement and many
current core modules do not have unit tests...

You are very welcome to write the missing tests for core modules.

However, i don't understand the argument that because many core modules
have no tests, therefore new modules don't need them. If developers of
addon module are serious about the attempt to make their modules usable and
maintainable for others, then they have to implement tests. Its and
integral part of the development process and GRASS has a beautiful test
environment hat makes writing tests easy. Tests and documentation are part
of coding and not something special. I don't think this is a hard
requirement.

There is a nice statement that is not far from the truth: Untested code is
broken code.

Best
Sören

>
> One thing we could think about is activating the toolbox idea a bit more
and creating a specific OBIA toolbox in addons.
>
>> Identified candidates could be added to core once they fulfill the
>> requirements above. Would that happen only in minor releases or would
>> that also be possible in point releases?
>
>
> Adding modules to core is not an API change, so I don't see why they
can't be added at any time. But then again, having a series of new modules
can be sufficient to justify a new minor release ;-)
>
>> Or is that already too much formality and if someone wishes to see an
>> addon in core that is simply discussed on ML?
>
>
> Generally, I would think that discussion on ML is the best way to handle
this.
>
> Moritz
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Nikos Alexandris]

* Moritz Lennert  [2016-10-02 13:24:41 +0200]:


On 01/10/16 21:25, Blumentrath, Stefan wrote:

Sounds fair enough as requirements for new core modules. “Maintainable
code” would in praxis mean “the module has undergone a code review by a
core developer”?

Those requirements would add to Markus requirement of “maturity”, which
I would interpret like “the module has been tested in praxis and options
and flags are consolidated” (so no major changes are expected /
planned)...?



I am afraid, it seems only very few of the suggested modules are covered
with unit tests. Most of them have a good documentation. No idea about
the maintainability of the code...



How should we proceed with this topic? Should the named modules (and
from my point of view Moritz OBIA modules would be very welcome too)


They definitely do not meet the enounced criteria, yet. No tests and
AFAIK, most of them have only been used inhouse by my colleagues.

So, I'm happy to have them live addons for now.

This said, I think the requirement of tests is something I would like to
see discussed a bit more. This is a pretty heavy requirement and many
current core modules do not have unit tests...


On the long run, GRASS-GIS modules deserve unit tests.  I think we
should invest efforts in this direction.

In this sense, I will try to integrate unit tests for every, hopefully,
useful code I share in form of a module.

Nikos



One thing we could think about is activating the toolbox idea a bit more
and creating a specific OBIA toolbox in addons.


Identified candidates could be added to core once they fulfill the
requirements above. Would that happen only in minor releases or would
that also be possible in point releases?


Adding modules to core is not an API change, so I don't see why they
can't be added at any time. But then again, having a series of new
modules can be sufficient to justify a new minor release ;-)


Or is that already too much formality and if someone wishes to see an
addon in core that is simply discussed on ML?


Generally, I would think that discussion on ML is the best way to handle
this.

Moritz

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


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

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

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Moritz Lennert]

On 01/10/16 21:25, Blumentrath, Stefan wrote:

Sounds fair enough as requirements for new core modules. “Maintainable
code” would in praxis mean “the module has undergone a code review by a
core developer”?

Those requirements would add to Markus requirement of “maturity”, which
I would interpret like “the module has been tested in praxis and options
and flags are consolidated” (so no major changes are expected /
planned)...?



I am afraid, it seems only very few of the suggested modules are covered
with unit tests. Most of them have a good documentation. No idea about
the maintainability of the code...



How should we proceed with this topic? Should the named modules (and
from my point of view Moritz OBIA modules would be very welcome too)


They definitely do not meet the enounced criteria, yet. No tests and 
AFAIK, most of them have only been used inhouse by my colleagues.


So, I'm happy to have them live addons for now.

This said, I think the requirement of tests is something I would like to 
see discussed a bit more. This is a pretty heavy requirement and many 
current core modules do not have unit tests...


One thing we could think about is activating the toolbox idea a bit more 
and creating a specific OBIA toolbox in addons.



Identified candidates could be added to core once they fulfill the
requirements above. Would that happen only in minor releases or would
that also be possible in point releases?


Adding modules to core is not an API change, so I don't see why they 
can't be added at any time. But then again, having a series of new 
modules can be sufficient to justify a new minor release ;-)



Or is that already too much formality and if someone wishes to see an
addon in core that is simply discussed on ML?


Generally, I would think that discussion on ML is the best way to handle 
this.


Moritz

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

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Blumentrath, Stefan]

Sounds fair enough as requirements for new core modules. “Maintainable code” 
would in praxis mean “the module has undergone a code review by a core 
developer”?
Those requirements would add to Markus requirement of “maturity”, which I would 
interpret like “the module has been tested in praxis and options and flags are 
consolidated” (so no major changes are expected / planned)...?

I am afraid, it seems only very few of the suggested modules are covered with 
unit tests. Most of them have a good documentation. No idea about the 
maintainability of the code...

How should we proceed with this topic? Should the named modules (and from my 
point of view Moritz OBIA modules would be very welcome too) be considered as a 
kind of “wish list” from the community? Probably more voices would be needed, 
as we currently have no “download statistics” or similar measures which may 
tell us something about the popularity or wide spread application of a module 
that would give reason to integrate it into core...
Where should such wishes be collected? A wiki page? Knowing of such interest 
might be an incentive for an addon-developer to write a test or to improve 
documentation...

Identified candidates could be added to core once they fulfill the requirements 
above. Would that happen only in minor releases or would that also be possible 
in point releases?

Or is that already too much formality and if someone wishes to see an addon in 
core that is simply discussed on ML?

Cheers
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Sören 
Gebbert
Sent: 30. september 2016 22:29
To: Markus Neteler <nete...@osgeo.org>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

Hi,
I would strongly suggest to move only those addons into core, that have good 
documentation, maintainable code and python tests that run in the gunittest 
framework.

Just my 2c
Sören

2016-07-03 20:09 GMT+02:00 Markus Neteler 
<nete...@osgeo.org<mailto:nete...@osgeo.org>>:

Hi,

we may consider to move a few (!) mature addons to core.

Thoughts?

Markus

___
grass-dev mailing list
grass-dev@lists.osgeo.org<mailto:grass-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Sören Gebbert]

Hi,
I would strongly suggest to move only those addons into core, that have
good documentation, maintainable code and python tests that run in the
gunittest framework.

Just my 2c
Sören

2016-07-03 20:09 GMT+02:00 Markus Neteler :

> Hi,
>
> we may consider to move a few (!) mature addons to core.
>
> Thoughts?
>
> Markus
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Nikos Alexandris]

* Yann Chemin  [2016-09-30 10:14:39 +0200]:


Hi,

added my feelings (biased towards remote sensing, I admit)

+1 => r.streams.*
+1 => r.geomorphon
+0 => i.segment.hierarchical (+1 if manual complete)
+0 => v.class.mlpy
+1 => v.class.ml
+1 => r.randomforest
+1 => i.segment.stats
+1 => r.object.geometry
+0 => v.class.mlR
+0 => i.segment.uspo (but +1 if r.neighborhoodmatrix is included in core)
+1 => i.landsat8.*
+1 => i.spec.sam
+1 => i.edge
+1 => i.histo.match


i.histo.match deserves a fix to account for floats.
Too many To Dos, too little time.

Nikos

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

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Yann Chemin]

Hi,

added my feelings (biased towards remote sensing, I admit)

+1 => r.streams.*
+1 => r.geomorphon
+0 => i.segment.hierarchical (+1 if manual complete)
+0 => v.class.mlpy
+1 => v.class.ml
+1 => r.randomforest
+1 => i.segment.stats
+1 => r.object.geometry
+0 => v.class.mlR
+0 => i.segment.uspo (but +1 if r.neighborhoodmatrix is included in core)
+1 => i.landsat8.*
+1 => i.spec.sam
+1 => i.edge
+1 => i.histo.match



On 30 September 2016 at 09:19, Moritz Lennert 
wrote:

> On 29/09/16 23:49, Blumentrath, Stefan wrote:
>
>> Hi,
>>
>>
>>
>> This discussion is actually a bit old, but maybe it is not too late to
>> consider adding selected addons to trunk?
>>
>>
>>
>> From my personal user point of view the r.streams.* modules and
>> r.geomorphon are indeed top candidates for inclusion in core!
>>
>>
>>
>> However, also:
>>
>>
>>
>> i.segment.hierarchical (though manual is not yet complete)
>>
>
> I've been working on trying to understand the exact functioning of the
> module and on writing some documentation on this, but this has been
> side-tracked by the many other priorities at work...
>
>
> v.class.mlpy (drawback: requires mlpy library) or v.class.ml and
>>
>> r.randomforest
>>
>> could nicely complement the image classification tools in GRASS.
>>
>
> +1
>
> In the same line, it might be nice to add:
>
> i.segment.stats and r.object.geometry.
>
> And possibly also v.class.mlR and i.segment.uspo...
>
> Moritz
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Yann Chemin
Skype/FB: yann.chemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Moritz Lennert]

On 29/09/16 23:49, Blumentrath, Stefan wrote:

Hi,



This discussion is actually a bit old, but maybe it is not too late to
consider adding selected addons to trunk?



From my personal user point of view the r.streams.* modules and
r.geomorphon are indeed top candidates for inclusion in core!



However, also:



i.segment.hierarchical (though manual is not yet complete)


I've been working on trying to understand the exact functioning of the 
module and on writing some documentation on this, but this has been 
side-tracked by the many other priorities at work...




v.class.mlpy (drawback: requires mlpy library) or v.class.ml and

r.randomforest

could nicely complement the image classification tools in GRASS.


+1

In the same line, it might be nice to add:

i.segment.stats and r.object.geometry.

And possibly also v.class.mlR and i.segment.uspo...

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

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Blumentrath, Stefan]

Hi,

This discussion is actually a bit old, but maybe it is not too late to consider 
adding selected addons to trunk?

>From my personal user point of view the r.streams.* modules and r.geomorphon 
>are indeed top candidates for inclusion in core!

However, also:

i.segment.hierarchical (though manual is not yet complete)
v.class.mlpy (drawback: requires mlpy library) or v.class.ml and
r.randomforest
could nicely complement the image classification tools in GRASS.

r.gwr would strengthen the general modeling power of GRASS.

The wx.metadata modules would be very relevant for institutional users too, but 
I guess the currently numerous dependencies prohibit to move them to core...

Cheers
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Michael 
Barton
Sent: 5. juli 2016 00:06
To: GRASS developers <grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

The r.stream* modules have been around for quite awhile and are very useful.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu



On Jul 4, 2016, at 2:00 AM, 
grass-dev-requ...@lists.osgeo.org<mailto:grass-dev-requ...@lists.osgeo.org> 
wrote:

From: Helmut Kudrnovsky <hel...@web.de<mailto:hel...@web.de>>
Subject: Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core
Date: July 3, 2016 at 1:25:20 PM MST
To: <grass-dev@lists.osgeo.org<mailto:grass-dev@lists.osgeo.org>>


Markus Neteler wrote

Hi,

we may consider to move a few (!) mature addons to core.

Thoughts?

Markus

___
grass-dev mailing list


grass-dev@.osgeo<mailto:grass-dev@.osgeo>


http://lists.osgeo.org/mailman/listinfo/grass-dev


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

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Martin Landa]

Hi,

2016-07-05 15:06 GMT+02:00 Helena Mitasova :
> for r.stream* and r.geomorphon (both worth to be included into the core) it 
> would be useful
> to contact the developers (Jarek) -

please remember that r.stream modules has been already included in
trunk and later removed (before 7.0). The main reason was that the
modules give slightly different results when using memory swap
(AFAIR). There is also huge duplication of code (some parts should be
moved to a new library).

Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Rainer M Krug]

Markus Neteler  writes:

> On Mon, Jul 4, 2016 at 11:00 AM, Rainer M Krug  wrote:
>> Vaclav Petras  writes:
>>> This is out-of-topic here, but similarly we might want to introduce
>>> something like [deprecated] for modules, options and flags.
>>>
> ...
>>> Related to that, I wonder if we should create some standard
>>> mechanism for introducing experimental things - things which might
>>> later show as unstable,
>>> not useful or buggy. For example, I introduced v.decimate which is
>>> now in 7.2 branch. It has its merit but I started to think that
>>> perhaps a different set of
>>> functions or interface can be more useful there. I wonder if I
>>> should just put [experimental - use with care] at the end of the
>>> module description.
>>
>> I would add the following:
>>
>> 1) add [experimental] / [beta] / ... behind the in the menu
>> 2) disable the experimental / beta / ... addons
>> 3) add an option to enable all the experimental / beta / ... addons, which 
>> can than state
>> "experimental, might make your computer explode, use at own risk and only in
>> well ventilated rooms"...
>>
>> Cheers,
>>
>> Rainer
>
> Please open a dedicated ticket for this.

Done:

https://trac.osgeo.org/grass/ticket/3092

Rainer

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

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


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

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Yann]

On 05/07/2016 15:56, Markus Neteler wrote:

On Tue, Jul 5, 2016 at 3:21 PM, Yann  wrote:

I can see in imagery:

i.spec.sam, been working on it and using it for the last year. Will continue
working on it the coming years.

+1


What about the i.landsat8.* functions, bringing them in core will increase
the use of GRASSGIS for Landsat 8 processing...

That and/or this nice pansharpening addon:

https://github.com/NikosAlexandris/i.fusion.hpf


Yes +1

I will probably use i.ortho.corr soon, but for the time being, anybody using
it willing to voice it for core inclusion ?

Did you test it already?


Not yet into that kind of work and no data to try... Maybe by end of year.
is that the Bundle Block code?


Finally any or all of the i.evapo.* modules, they are straightforward robust
algorithms used for a long time by evapotranspiration people.

Vaclav, what about i.edge?

Cheers,
Yann


Markus

yann

--
-
Yann Chemin
Address: 3 Toul Melin, 56400 Plumergat
Mobile: +33 (0)7 83 85 52 34

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

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Yann]

what is the memory multiplier for a given image size to operate 
optimally in RAM?


1Gb image will need how many Gb RAM?


On 05/07/2016 15:57, Vaclav Petras wrote:

On Tue, Jul 5, 2016 at 9:21 AM, Yann  wrote:


Vaclav, what about i.edge?



Loads everything into memory without an option for "lowmem" processing.
That's not ideal.



--
-
Yann Chemin
Address: 3 Toul Melin, 56400 Plumergat
Mobile: +33 (0)7 83 85 52 34

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

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Markus Neteler]

On Tue, Jul 5, 2016 at 3:21 PM, Yann  wrote:
> I can see in imagery:
>
> i.spec.sam, been working on it and using it for the last year. Will continue
> working on it the coming years.

+1

> What about the i.landsat8.* functions, bringing them in core will increase
> the use of GRASSGIS for Landsat 8 processing...

That and/or this nice pansharpening addon:

https://github.com/NikosAlexandris/i.fusion.hpf

> I will probably use i.ortho.corr soon, but for the time being, anybody using
> it willing to voice it for core inclusion ?

Did you test it already?

> Finally any or all of the i.evapo.* modules, they are straightforward robust
> algorithms used for a long time by evapotranspiration people.
>
> Vaclav, what about i.edge?
>
> Cheers,
> Yann


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

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Markus Neteler]

On Mon, Jul 4, 2016 at 11:00 AM, Rainer M Krug  wrote:
> Vaclav Petras  writes:
>> This is out-of-topic here, but similarly we might want to introduce 
>> something like [deprecated] for modules, options and flags.
>>
...
>> Related to that, I wonder if we should create some standard mechanism for 
>> introducing experimental things - things which might later show as unstable,
>> not useful or buggy. For example, I introduced v.decimate which is now in 
>> 7.2 branch. It has its merit but I started to think that perhaps a different 
>> set of
>> functions or interface can be more useful there. I wonder if I should just 
>> put [experimental - use with care] at the end of the module description.
>
> I would add the following:
>
> 1) add [experimental] / [beta] / ... behind the in the menu
> 2) disable the experimental / beta / ... addons
> 3) add an option to enable all the experimental / beta / ... addons, which 
> can than state
> "experimental, might make your computer explode, use at own risk and only in
> well ventilated rooms"...
>
> Cheers,
>
> Rainer

Please open a dedicated ticket for this.

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

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Vaclav Petras]

On Tue, Jul 5, 2016 at 9:21 AM, Yann  wrote:

> Vaclav, what about i.edge?



Loads everything into memory without an option for "lowmem" processing.
That's not ideal.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Yann]

I can see in imagery:

i.spec.sam, been working on it and using it for the last year. Will 
continue working on it the coming years.


What about the i.landsat8.* functions, bringing them in core will 
increase the use of GRASSGIS for Landsat 8 processing...


I will probably use i.ortho.corr soon, but for the time being, anybody 
using it willing to voice it for core inclusion ?


Finally any or all of the i.evapo.* modules, they are straightforward 
robust algorithms used for a long time by evapotranspiration people.


Vaclav, what about i.edge?

Cheers,
Yann

--
-
Yann Chemin
Address: 3 Toul Melin, 56400 Plumergat
Mobile: +33 (0)7 83 85 52 34

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

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Helena Mitasova]

for r.stream* and r.geomorphon (both worth to be included into the core) it 
would be useful 
to contact the developers (Jarek) - 

Vasek, can you please email him to ask about their interest 
in getting the modules included and make the necessary adjustments?
From my discussion with Jarek last year I got an impression that they have 
improved versions
of these modules, but I am not sure how those conform to the GRASS core 
standards in terms
of portability. However, they were interested in having the modules in core 
GRASS.

Helena

> On Jul 5, 2016, at 4:31 AM, Helmut Kudrnovsky  wrote:
> 
>> The r.stream* modules have been around for quite awhile and are very useful. 
> 
> regarding the r.stream.*-modules, some tickets may be solved first:
> 
> https://trac.osgeo.org/grass/ticket/2516
> https://trac.osgeo.org/grass/ticket/2356
> https://trac.osgeo.org/grass/ticket/2348
> https://trac.osgeo.org/grass/ticket/2302
> https://trac.osgeo.org/grass/ticket/2301
> https://trac.osgeo.org/grass/ticket/2296
> https://trac.osgeo.org/grass/ticket/2237
> https://trac.osgeo.org/grass/ticket/2218
> 
> 
> 
> -
> best regards
> Helmut
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/Upcoming-7-2-0-review-which-addons-to-move-to-core-tp5274533p5274703.html
> Sent from the Grass - Dev mailing list archive at Nabble.com.
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html

"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.” 

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

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Helmut Kudrnovsky]

>The r.stream* modules have been around for quite awhile and are very useful. 

regarding the r.stream.*-modules, some tickets may be solved first:

https://trac.osgeo.org/grass/ticket/2516
https://trac.osgeo.org/grass/ticket/2356
https://trac.osgeo.org/grass/ticket/2348
https://trac.osgeo.org/grass/ticket/2302
https://trac.osgeo.org/grass/ticket/2301
https://trac.osgeo.org/grass/ticket/2296
https://trac.osgeo.org/grass/ticket/2237
https://trac.osgeo.org/grass/ticket/2218



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Upcoming-7-2-0-review-which-addons-to-move-to-core-tp5274533p5274703.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Adrien ANDRÉ]

Hi,

I agree.


Le 05/07/2016 00:05, Michael Barton a écrit :
> The r.stream* modules have been around for quite awhile and are very
> useful.
> 

-- 
Adrien André
www.mapaou-web.fr
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Michael Barton]

The r.stream* modules have been around for quite awhile and are very useful.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu



On Jul 4, 2016, at 2:00 AM, 
grass-dev-requ...@lists.osgeo.org<mailto:grass-dev-requ...@lists.osgeo.org> 
wrote:

From: Helmut Kudrnovsky <hel...@web.de<mailto:hel...@web.de>>
Subject: Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core
Date: July 3, 2016 at 1:25:20 PM MST
To: <grass-dev@lists.osgeo.org<mailto:grass-dev@lists.osgeo.org>>


Markus Neteler wrote
Hi,

we may consider to move a few (!) mature addons to core.

Thoughts?

Markus

___
grass-dev mailing list

grass-dev@.osgeo

http://lists.osgeo.org/mailman/listinfo/grass-dev


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

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Rainer M Krug]

Vaclav Petras  writes:

> On Sun, Jul 3, 2016 at 6:32 PM, Markus Neteler  wrote:
>
>  The general criteria are
>  - code follows submission standards
>  - must be portable
>  - must be well documented with examples
>  - must be of interest to a wider audience
>
> I would add "well tested (i.e. very mature) or having somebody willing to fix 
> it (soon) if needed".
>
> Related to that, I wonder if we should create some standard mechanism for 
> introducing experimental things - things which might later show as unstable,
> not useful or buggy. For example, I introduced v.decimate which is now in 7.2 
> branch. It has its merit but I started to think that perhaps a different set 
> of
> functions or interface can be more useful there. I wonder if I should just 
> put [experimental - use with care] at the end of the module description.

I would add the following:

1) add [experimental] / [beta] / ... behind the in the menu
2) disable the experimental / beta / ... addons
3) add an option to enable all the experimental / beta / ... addons, which can 
than state
"experimental, might make your computer explode, use at own risk and only in
well ventilated rooms"...

Cheers,

Rainer

>
> This is out-of-topic here, but similarly we might want to introduce something 
> like [deprecated] for modules, options and flags.
>
> Vaclav
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


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

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Vaclav Petras]

On Sun, Jul 3, 2016 at 6:32 PM, Markus Neteler  wrote:

> The general criteria are
> - code follows submission standards
> - must be portable
> - must be well documented with examples
> - must be of interest to a wider audience
>

I would add "well tested (i.e. very mature) or having somebody willing to
fix it (soon) if needed".

Related to that, I wonder if we should create some standard mechanism for
introducing experimental things - things which might later show as
unstable, not useful or buggy. For example, I introduced v.decimate which
is now in 7.2 branch. It has its merit but I started to think that perhaps
a different set of functions or interface can be more useful there. I
wonder if I should just put [experimental - use with care] at the end of
the module description.

This is out-of-topic here, but similarly we might want to introduce
something like [deprecated] for modules, options and flags.

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

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Yann]

Any imagery modules that would be possible candidates?

On 03/07/2016 20:09, Markus Neteler wrote:

Hi,

we may consider to move a few (!) mature addons to core.

Thoughts?

Markus



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


--
-
Yann Chemin
Address: 3 Toul Melin, 56400 Plumergat
Mobile: +33 (0)7 83 85 52 34

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