Upcoming 7.2.0: review which addons to move to core

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Upcoming 7.2.0: review which addons to move to core

Markus Neteler

Hi,

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

Thoughts?

Markus


_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 7.2.0: review which addons to move to core

Helmut Kudrnovsky
Markus Neteler wrote
Hi,

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

Thoughts?

Markus

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
What are the criterias to move to core? usefulness, code matureness,...?
best regards
Helmut
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 7.2.0: review which addons to move to core

ychemin
In reply to this post by Markus Neteler
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
> [hidden email]
> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 7.2.0: review which addons to move to core

Markus Neteler


On Jul 4, 2016 12:26 AM, "Yann" <[hidden email]> wrote:
>
> Any imagery modules that would be possible candidates?

Why not... which do you have in mind?

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

Markus


_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 7.2.0: review which addons to move to core

wenzeslaus

On Sun, Jul 3, 2016 at 6:32 PM, Markus Neteler <[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 7.2.0: review which addons to move to core

RKrug
Vaclav Petras <[hidden email]> writes:

> On Sun, Jul 3, 2016 at 6:32 PM, Markus Neteler <[hidden email]> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

signature.asc (463 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 7.2.0: review which addons to move to core

Michael Barton
In reply to this post by Markus Neteler
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)



On Jul 4, 2016, at 2:00 AM, [hidden email] wrote:

From: Helmut Kudrnovsky <[hidden email]>
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


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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 7.2.0: review which addons to move to core

Helmut Kudrnovsky
In reply to this post by Michael Barton
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 7.2.0: review which addons to move to core

Helena Mitasova-7
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 <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 7.2.0: review which addons to move to core

ychemin
In reply to this post by Michael Barton
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 7.2.0: review which addons to move to core

Markus Neteler
On Tue, Jul 5, 2016 at 3:21 PM, Yann <[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 7.2.0: review which addons to move to core

wenzeslaus
In reply to this post by ychemin

On Tue, Jul 5, 2016 at 9:21 AM, Yann <[hidden email]> wrote:
Vaclav, what about i.edge?


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

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 7.2.0: review which addons to move to core

Markus Neteler
In reply to this post by RKrug
On Mon, Jul 4, 2016 at 11:00 AM, Rainer M Krug <[hidden email]> wrote:
> Vaclav Petras <[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 7.2.0: review which addons to move to core

ychemin
In reply to this post by Markus Neteler


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

> On Tue, Jul 5, 2016 at 3:21 PM, Yann <[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 7.2.0: review which addons to move to core

ychemin
In reply to this post by wenzeslaus
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 <[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 7.2.0: review which addons to move to core

Markus Neteler
In reply to this post by ychemin
On Tue, Jul 5, 2016 at 4:10 PM, Yann <[hidden email]> wrote:
> On 05/07/2016 15:56, Markus Neteler wrote:
>> On Tue, Jul 5, 2016 at 3:21 PM, Yann <[hidden email]> ...
...
>>> 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?

Not at all... the Bundle Block adjustment project got stuck. The status of i.ortho.* is here:
https://trac.osgeo.org/grass/browser/grass/trunk/imagery/i.ortho.photo/README

"

STATUS:

        The i.ortho.photo suite of modules has been temporarily disabled

        from GRASS 7 as they are heavily dependent on the text-based

        Vask libary and interactive XDRIVER monitors, both of which

        have been removed. As the modules are rewritten to run in non-

        interactive mode or with a wxPython frontend, they will be

        added back into GRASS 7. This work will be undertaken in the

        trunk SVN.




     G6                  G7
frontend:
 i.ortho.photo  -> i.ortho.rectify + TODO wxGUI

internal:
 libes/         -> lib/
 menu/          -> TODO (wxGUI, use g.gui.gcp classes)
 photo.elev/    -> i.ortho.elev/
 photo.2target/ -> ? i.ortho.transform/
 photo.camera/  -> i.ortho.camera/
 photo.2image/  -> ? (wxGUI, use g.gui.gcp classes: fiducial marks)
 photo.init/    -> i.ortho.init/
 photo.rectify/ -> ? i.ortho.rectify/


"

Still some work...

Markus

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 7.2.0: review which addons to move to core

RKrug
In reply to this post by Markus Neteler
Markus Neteler <[hidden email]> writes:

> On Mon, Jul 4, 2016 at 11:00 AM, Rainer M Krug <[hidden email]> wrote:
>> Vaclav Petras <[hidden email]> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

signature.asc (463 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 7.2.0: review which addons to move to core

Martin Landa
In reply to this post by Helena Mitasova-7
Hi,

2016-07-05 15:06 GMT+02:00 Helena Mitasova <[hidden email]>:
> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
SBL
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 7.2.0: review which addons to move to core

SBL
In reply to this post by Michael Barton

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:[hidden email]] On Behalf Of Michael Barton
Sent: 5. juli 2016 00:06
To: GRASS developers <[hidden email]>
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)

 

 

 

On Jul 4, 2016, at 2:00 AM, [hidden email] wrote:

 

From: Helmut Kudrnovsky <[hidden email]>

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



Markus Neteler wrote

Hi,

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

Thoughts?

Markus

_______________________________________________
grass-dev mailing list



[hidden email]



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

 

 


_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
12