Markus Neteler wrote: > this one looks like an urgent backport candidate for me? > > I think that one of my doctorate students just complained to > me that digitizing failed for him (I need to ask). > > In any case, this should go then into relbranch64 before it > is forgotten (and it is also more relevnt than the other r.li > cleanup fixes done in dev6branch. > > What do you think?
Hi Markus, that was just a first commit of a bigger r.li cleanup which I have started locally but not yet committed to the dev branches. I wanted to commit those various small fixes now to get them out of the way since my 'svn diff' was getting a bit cluttered. I am not surprised things failed really, to work well it will still need some commits I haven't made yet (I am just working through the code so far: completely untested), e.g. for that r.digit call related to the circle.txt file in the commit it will need the output map name passed on the command line since I changed r.digit into a "normal" G_parser() module 7+ years ago. For grass7 there is Luca's g.gui.rlisetup.py (I am not totally convinced about the g.gui.* naming), I am just keeping the raster/r.li r.li.setup dir in sync to avoid older code being in the "newer" branches. Much of r.li.setup will be deleted in trunk eventually since it needs Xmons, tcl/tk, shell scripts, etc. and is replaced by the wxPy version. So I think r.li.setup is too much broken to worry about for 6.4.3; I look to make one fix and see three more. Let's get 6.4.3 out the door asap and keep an improved r.li as a goal for 6.4.4. I looked at the list of r.li bugs in the trac system earlier, it is in need of some care. AFAICT it's nothing fatal, just many small fixes to work through. regards, Hamish _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev