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,
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
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
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
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
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
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
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
>
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
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
>>>
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”?
>>
* 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
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
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
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 (!)
* 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 =>
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
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!
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: <g
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
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
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,
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
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
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
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
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
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
>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
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
ss-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>&
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
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
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
34 matches
Mail list logo