Re: [GRASS-dev] r.randomforest built status

[Markus Neteler]

On Dec 19, 2016 5:41 AM,  wrote:
>
> Thanks for this – I have made some major changes to r.randomforest
recently, including adding options for spatial cross-validation.

This is great!

> I will move the import of pandas to a lazy import because I’m only using
pandas as a convenient way of saving the cross-validation results to file.
>
> Another question – r.randomforest is not really an appropriate name for
the module anymore. I have been adding features over time, based on my own
needs, but now it performs classification and regression using all of the
major machine learning methods, with random forests just being one of them.
>
> Is there a correct protocol for me to rename the script to something like
r.scikit.learn, or r.ml?

IMHO the name should reflect what it does and be understandable. So, r.ml
is a bit cryptic.

How about a new "family" r.learn.something? Maybe more will follow in
future.

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

Re: [GRASS-dev] r.randomforest built status

[Helmut Kudrnovsky]

> I will move the import of pandas to a lazy import because

AFAIU also the Scikit imports should be done by a lazy import. 



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/r-randomforest-built-status-tp5300348p5300387.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] r.randomforest built status

[dr.stevenpawley]

Thanks for this – I have made some major changes to r.randomforest recently, 
including adding options for spatial cross-validation. I will move the import 
of pandas to a lazy import because I’m only using pandas as a convenient way of 
saving the cross-validation results to file.

Another question – r.randomforest is not really an appropriate name for the 
module anymore. I have been adding features over time, based on my own needs, 
but now it performs classification and regression using all of the major 
machine learning methods, with random forests just being one of them. 

Is there a correct protocol for me to rename the script to something like 
r.scikit.learn, or r.ml?

Steve

From: Vaclav Petras
Sent: Sunday, December 18, 2016 2:42 PM
To: Helmut Kudrnovsky
Cc: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] r.randomforest built status


On Sun, Dec 18, 2016 at 3:40 PM, Helmut Kudrnovsky  wrote:
>
> Is there any "best practice" example available?


I've done it in this way :

https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.in.natura2000/v.in.natura2000.py#L151

accordingly an advice by Vaclav.

Maybe there are some other ways to do it.

Here is a example for more complicated case:

https://trac.osgeo.org/grass/changeset/66482/grass-addons/grass7/vector/v.class.ml
But I don't know what is best practice, perhaps as simple solution as possible 
- import in main() after parser() will work for most of the short modules and 
dependencies.

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

Re: [GRASS-dev] r.randomforest built status

[Vaclav Petras]

On Sun, Dec 18, 2016 at 3:40 PM, Helmut Kudrnovsky  wrote:

> >
> > Is there any "best practice" example available?
> 
>
> I've done it in this way :
>
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/
> vector/v.in.natura2000/v.in.natura2000.py#L151
>
> accordingly an advice by Vaclav.
>
> Maybe there are some other ways to do it.


Here is a example for more complicated case:

https://trac.osgeo.org/grass/changeset/66482/grass-addons/grass7/vector/v.class.ml

But I don't know what is best practice, perhaps as simple solution as
possible - import in main() after parser() will work for most of the short
modules and dependencies.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] d.linegraph indentation mess

[Vaclav Petras]

On Sat, Dec 17, 2016 at 7:15 AM, Markus Neteler  wrote:

>
> Indeed, the if() statement in 735 has some issues: braces missing or
> indentation wrong.
>
> Any idea how to fix that correctly?
>


I need to look at these two if more closely, but otherwise I think I'll
just reindent all and do the classic int -> size_t replacements.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] wxPython3 checkbox button issues: g.gui + g.mapsets -s

[Markus Neteler]

On Sun, Dec 18, 2016 at 10:00 PM, Anna Petrášová  wrote:
> You can test g.mapsets -s GUI dialog with CheckListCtrlMixin demo.

Thanks:

python /usr/share/doc/wxPython-docs/demo/CheckListCtrlMixin.py
--> broken.

> Add multiple maps dialog uses wx.CheckListBox.

python /usr/share/doc/wxPython-docs/demo/CheckListBox.py
--> ok (as we knew)

> Layer manager uses CustomTreeCtrl.

This one I found with grep:

python /usr/share/doc/wxPython-docs/demo/TreeMixin.py
--> broken (it is in the CustomTreeCtrl tab)

> So they all use different widgets. Although I can't rule out the
> possibility something's wrong in GRASS, I think it's a problem
> upstream.

Confirmed. I have now report it upstream (say, to the Fedora package
maintainer):
https://bugzilla.redhat.com/show_bug.cgi?id=1405841

Thanks for the pointers.

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

Re: [GRASS-dev] wxPython3 checkbox button issues: g.gui + g.mapsets -s

[Anna Petrášová]

You can test g.mapsets -s GUI dialog with CheckListCtrlMixin demo.

Add multiple maps dialog uses wx.CheckListBox.

Layer manager uses CustomTreeCtrl.

So they all use different widgets. Although I can't rule out the
possibility something's wrong in GRASS, I think it's a problem
upstream.

Anna


On Sat, Dec 17, 2016 at 5:17 AM, Markus Neteler  wrote:
> Hi,
>
> I found yet another wxPython3 issue :( Running the selection dialog
> g.mapsets -s
>
> I can hardly read which mapset was [x] checked (see attached screenshot).
>
> From the code in
> gui/wxpython/modules/mapsets_picker.py
>
> I don't understand which wx demo (/usr/share/doc/wxPython-docs/demo/
> )I should try to possibly report it upstream.
> Or is it a GRASS issue?
>
> Likewise g.gui, where I have to "blindly" use the checkboxes in the
> layer tree while being fine in the map selection tool (see second
> screenshot).
>
> Any hints why they behave so differently?
>
> 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] r.randomforest built status

[Helmut Kudrnovsky]

Markus Neteler wrote
> On Sun, Dec 18, 2016 at 9:17 PM, Helmut Kudrnovsky 

> hellik@

>  wrote:
>> Helmut Kudrnovsky wrote
> ...
>>> what about to do some kind of a lazy import and move panda and scikit to
>>> def main()?
>>>
>>> It isn't needed for compiling only for running the python script.
>>>
>>> AFAIK panda is available in osgeo4w; check needed. Scikit isn't
>>> available.
>>
>> something similar like a "lazy import" is also needed for some other
>> addons,
>> E.g.
>>
>> https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/logs/r.denoise.log
> 
> Is there any "best practice" example available?
> 
> Markus
> ___
> grass-dev mailing list

> grass-dev@.osgeo

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

I've done it in this way :

https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.in.natura2000/v.in.natura2000.py#L151

accordingly an advice by Vaclav. 

Maybe there are some other ways to do it. 



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/r-randomforest-built-status-tp5300348p5300359.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] [release planning] 7.2.0

[Anna Petrášová]

On Sat, Dec 17, 2016 at 9:59 AM, Martin Landa  wrote:
> Hi,
>
> 2016-12-10 20:00 GMT+01:00 Vaclav Petras :
>>
>> Yes, that's it. Do you know how/where to push it upstream/downstream, so
>> that the right people look at it? It seemed that it is fixed at one point,
>> but the same behavior is back now.
>
> I tested various winGRASS versions on my Windows machine and most of
> them worked [1]. I lost track what version of GRASS is not working
> you? Ma
>

No version was working for me. The weird thing is it worked for one
student (I tested it myself on his computer), but for many other
students it failed. So I tested different versions on freshly
installed Windows 10 in Virtual Box on linux and nothing worked. This
was couple weeks back, I can test again this week.

Anna

> [1] https://trac.osgeo.org/grass/ticket/2996#comment:17
>
> --
> 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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.randomforest built status

[Markus Neteler]

On Sun, Dec 18, 2016 at 9:17 PM, Helmut Kudrnovsky  wrote:
> Helmut Kudrnovsky wrote
...
>> what about to do some kind of a lazy import and move panda and scikit to
>> def main()?
>>
>> It isn't needed for compiling only for running the python script.
>>
>> AFAIK panda is available in osgeo4w; check needed. Scikit isn't available.
>
> something similar like a "lazy import" is also needed for some other addons,
> E.g.
>
> https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/logs/r.denoise.log

Is there any "best practice" example available?

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

Re: [GRASS-dev] r.randomforest built status

[Helmut Kudrnovsky]

Helmut Kudrnovsky wrote
> 
> Markus Neteler wrote
>> On Sun, Dec 18, 2016 at 7:52 PM, Paulo van Breugel
>> 

>> p.vanbreugel@

>>  wrote:
>>> Hi Steven / devs
>>>
>>> The build status of r.randomforest shows it failed to build. From the
>>> log
>>> file this seems to be because Pandas is not installed
>>>
>>> ...
>>> ERROR: Pandas not installed
>>> make: *** [r.randomforest.tmp.html] Error 1
>>> rm r.randomforest.tmp.html
>>> ...
>> 
>> AFAIK we have no pandas installed on the osgeo6 server aka
>> grass.osgeo.org.
>> Perhaps the same is true for the Windows build server.
>> 
>>> This is also why, I guess, it is not on
>>> https://grass.osgeo.org/grass70/manuals/addons/?
>> 
>> Yes, unfortunately.
>> 
>> Markus
>> ___
>> grass-dev mailing list

>> grass-dev@.osgeo

>> http://lists.osgeo.org/mailman/listinfo/grass-dev
> what about to do some kind of a lazy import and move panda and scikit to 
> def main()?
> 
> It isn't needed for compiling only for running the python script. 
> 
> AFAIK panda is available in osgeo4w; check needed. Scikit isn't available.

something similar like a "lazy import" is also needed for some other addons,
E.g.

https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/logs/r.denoise.log





-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/r-randomforest-built-status-tp5300348p5300357.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] r.randomforest built status

[Helmut Kudrnovsky]

Markus Neteler wrote
> On Sun, Dec 18, 2016 at 7:52 PM, Paulo van Breugel
> 

> p.vanbreugel@

>  wrote:
>> Hi Steven / devs
>>
>> The build status of r.randomforest shows it failed to build. From the log
>> file this seems to be because Pandas is not installed
>>
>> ...
>> ERROR: Pandas not installed
>> make: *** [r.randomforest.tmp.html] Error 1
>> rm r.randomforest.tmp.html
>> ...
> 
> AFAIK we have no pandas installed on the osgeo6 server aka
> grass.osgeo.org.
> Perhaps the same is true for the Windows build server.
> 
>> This is also why, I guess, it is not on
>> https://grass.osgeo.org/grass70/manuals/addons/?
> 
> Yes, unfortunately.
> 
> Markus
> ___
> grass-dev mailing list

> grass-dev@.osgeo

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

what about to do some kind of a lazy import and move panda and scikit to 
def main()?

It isn't needed for compiling only for running the python script. 

AFAIK panda is available in osgeo4w; check needed. Scikit isn't available. 



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/r-randomforest-built-status-tp5300348p5300355.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] r.randomforest built status

[Markus Neteler]

On Sun, Dec 18, 2016 at 7:52 PM, Paulo van Breugel
 wrote:
> Hi Steven / devs
>
> The build status of r.randomforest shows it failed to build. From the log
> file this seems to be because Pandas is not installed
>
> ...
> ERROR: Pandas not installed
> make: *** [r.randomforest.tmp.html] Error 1
> rm r.randomforest.tmp.html
> ...

AFAIK we have no pandas installed on the osgeo6 server aka grass.osgeo.org.
Perhaps the same is true for the Windows build server.

> This is also why, I guess, it is not on
> https://grass.osgeo.org/grass70/manuals/addons/?

Yes, unfortunately.

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

[GRASS-dev] r.randomforest built status

[Paulo van Breugel]

Hi Steven / devs

The build status of r.randomforest shows it failed to build. From the log
file this seems to be because Pandas is not installed

...
ERROR: Pandas not installed
make: *** [r.randomforest.tmp.html] Error 1
rm r.randomforest.tmp.html
...

This is also why, I guess, it is not on
https://grass.osgeo.org/grass70/manuals/addons/?

Cheers,

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

Re: [GRASS-dev] question on setup.hint-update on http://download.osgeo.org/osgeo4w/

[Helmut Kudrnovsky]

Martin Landa wrote
> 2016-12-18 17:36 GMT+01:00 Helmut Kudrnovsky 

> hellik@

> :
>>  >So the next standalone installer should
>>>also include rbatch package.
>>
>> standalone has these R batchfiles already inside since ~2 years.
> 
> Ok, so why rbatch package is needed? Just for OSGe4W? Then standalone
> installer should use files installed by rbatch package.
> 
> Ma
> 
> -- 
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> grass-dev mailing list

> grass-dev@.osgeo

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

See 

https://trac.osgeo.org/grass/browser/grass/trunk/mswindows/external/rbatch

I've added them (oh) 3 years ago to svn and this R-winGRASS coupling works
since then in standalone installer.

But I've found no time (and support)  to add these files to osgeo4w in these
3 years; since I've done a retry some days ago to implement this in osgeo4w
; thus my Setup.hint update a few days ago. 

now standalone and osgeo4w are on par now regarding R coupling. 

It's debatable now to move rbatch out of GRASS svn. 

Any opinion? 



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/question-on-setup-hint-update-on-http-download-osgeo-org-osgeo4w-tp5300264p5300339.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] question on setup.hint-update on http://download.osgeo.org/osgeo4w/

[Martin Landa]

2016-12-18 17:36 GMT+01:00 Helmut Kudrnovsky :
>  >So the next standalone installer should
>>also include rbatch package.
>
> standalone has these R batchfiles already inside since ~2 years.

Ok, so why rbatch package is needed? Just for OSGe4W? Then standalone
installer should use files installed by rbatch package.

Ma

-- 
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] question on setup.hint-update on http://download.osgeo.org/osgeo4w/

[Helmut Kudrnovsky]

 >So the next standalone installer should 
>also include rbatch package. 

standalone has these R batchfiles already inside since ~2 years. 



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/question-on-setup-hint-update-on-http-download-osgeo-org-osgeo4w-tp5300264p5300334.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] question on setup.hint-update on http://download.osgeo.org/osgeo4w/

[Martin Landa]

Hi,

2016-12-17 17:17 GMT+01:00 Helmut Kudrnovsky :
>>> http://download.osgeo.org/osgeo4w/x86_64/release/grass/grass-daily/setup.hint
>>> http://download.osgeo.org/osgeo4w/x86/release/grass/grass-daily/setup.hint

updated. I have also updated setup.hint for stable releases [1,2] and
updated packaging environment. So the next standalone installer should
also include rbatch package. Testing welcome. Ma

[1] http://download.osgeo.org/osgeo4w/x86/release/grass/grass/setup.hint
[2] http://download.osgeo.org/osgeo4w/x86_64/release/grass/grass/setup.hint

-- 
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] i.superpixels.slic ( was: #3142 Implementing SLIC image segmentation)

[Moritz Lennert]

On 18/12/16 14:01, Rashad Kanavath wrote:

Hello,

As promised, I had pushed code to G7 addons repo

https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.superpixels.slic



Great job, thanks a lot !



I had tested with some small datasets and is working.

More testing welcome :)


I get the following warning during installation:

main.c: In function ‘main’:
main.c:514:13: warning: implicit declaration of function ‘min’ 
[-Wimplicit-function-declaration]

 seedx = min(g_width-1,seedx);
 ^~~

I think you have to explicitely define min() through a macro, or AFAIK 
you can use fmin() as elsewhere in the code.


Also:

- The output as it is now is not very useful. What we would need is a 
map with each pixel containing the label of the superpixel it belongs 
to. In the original code, there are both outputs: i) an image of the 
superpixel limits overlayed over the original image, ii) the labeled pixels


- Linked to the above: currently the superpixel boundaries are two 
pixels wide. A one-pixel boundary would be enough.


- I don't know the details of the algorithm well enough, but would it be 
possible to extend it beyond the use of r,g,b maps as input. Ideally, 
the use should be able to provide a group as input and all maps in the 
group are used in the definition of the superpixels. This should also 
include the case when you only have one band (e.g. black and white 
orthophoto).



Again, many thanks for taking this first step, allowing us to test !

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

Re: [GRASS-dev] i.superpixels.slic ( was: #3142 Implementing SLIC image segmentation)

[Rashad Kanavath]

Hello,

As promised, I had pushed code to G7 addons repo

https://trac.osgeo.org/grass/browser/grass-addons/grass7/
imagery/i.superpixels.slic

I had tested with some small datasets and is working.

More testing welcome :)




On Wed, Dec 14, 2016 at 4:55 PM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> Le Wed, 14 Dec 2016 16:02:38 +0100,
> Rashad Kanavath  a écrit :
>
> > Hello,
> >
> > From the trac ticket, I had started on slic implementation in grass.
> > I had an beta version
> > based on orginal c++ code. i.superpixels.slic
> >
> > It accepts three inputs for r,g,b and output a map with contour
> > segments,
> >
> > there  is work to expose some parameters such as pixelsize / step
> > size, compactness, no. of iteration as input to grass module.
> >
> > I hope to have a version ready for testing by end of this week.
>
>
> Wow, great work !
>
> > I can upload current code to grass addons / github if anyone is
> > interested in testing.
>
> Addons makes it easier for windows users to test without having to
> compile themselves, so I would suggest to put it there.
>
> Moritz
>



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