[GRASS-dev] [GRASS-user] wxGUI raster digitizer available

Thu Nov 20 12:03:02 PST 2014

While trying to replicate the steps, I found out it worked this time.
Difference was that last time I edited a very large map so the process got
probably stuck. Sorry for the false alarm. And again, a great new feature!!

On Thu, Nov 20, 2014 at 7:31 PM, Anna Petrášová <kratochanna at gmail.com>
wrote:

>
>
> On Thu, Nov 20, 2014 at 4:37 AM, Paulo van Breugel <p.vanbreugel at gmail.com
> > wrote:
>
>> Hi Anna
>>
>> This is great, thanks! This is going to be a real time saver.
>>
>> I am having trouble however running it. I seems to work fine except that
>> I can't save the edits. To leave the editing session, I have to select no
>> when asked to save the work.
>>
>> Not sure if the below helps, but in the terminal I get the message:
>> GRASS_INFO_ERROR(30864,1): Raster map <pnv_malawi2_ag2_backupcopy_30725>
>> not found
>> GRASS_INFO_END(30864,1)
>>
>> From the command console:
>>
>> Exception in thread Thread-8:
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/threading.py", line 810, in
>> __bootstrap_inner
>>     self.run()
>>   File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/core/gt
>> hread.py", line 94, in run
>>     ret = vars()['callable'](*args, **kwds)
>>   File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/rdigit/
>> controller.py", line 467, in _exportRaster
>>     output=self._editedRaster, overwrite=True, quiet=True)
>>   File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
>> ipt/core.py", line 373, in run_command
>>     return handle_errors(returncode, returncode, args,
>> kwargs)
>>   File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
>> ipt/core.py", line 308, in handle_errors
>>     returncode=returncode)
>> CalledModuleError: Module run None ['r.patch', '--o', '--q',
>> u'input=x47731795,pnv_malawi2_ag2_backupcopy_30725',
>> u'output=pnv_malawi2_ag2 at vegetation'] ended with error
>> Process ended with non-zero return code 1. See errors in the
>> (error) output.
>>
>
> Strange, could you describe the exact steps?
>
>
>
>>
>>
>>
>> On Wed, Nov 19, 2014 at 11:56 PM, Anna Petrášová <kratochanna at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Nov 19, 2014 at 3:31 PM, Markus Neteler <neteler at osgeo.org>
>>> wrote:
>>>
>>>> Hi Anna,
>>>>
>>>> On Tue, Nov 18, 2014 at 5:19 AM, Anna Petrášová <kratochanna at gmail.com>
>>>> wrote:
>>>> > Hi all,
>>>> >
>>>> > I added raster digitizer in r62792 in trunk.
>>>>
>>>> what a great job!
>>>>
>>>> If you didn't find it: it is in the "Map Display" windows, then
>>>> selector on the right side (2D/3D/Vector digitizer/Raster digitizer).
>>>>
>>>
>>> Once everything works, I will probably make a short video tutorial.
>>>
>>>>
>>>> > You are welcome to test it and
>>>> > report bugs/enhancements.
>>>> > It currently allows to draw areas, lines and points and specify width
>>>> to
>>>> > buffer individual features. We can discuss some changes in gui
>>>> interface and
>>>> > behavior if you find the current one intuitive.  There is still a lot
>>>> to
>>>> > improve especially in the drawing part (needs some refactoring of the
>>>> old
>>>> > drawing code).
>>>>
>>>> One general thing I found (also valid for the vector digitizer): I
>>>> wonder where to put a message what the mouse buttons mean.
>>>> Maybe in the status bar at bottom of the display/digitizer window?
>>>>
>>>> > Features:
>>>> > - draw area, line, point
>>>>
>>>> ... works.
>>>>
>>>> > - specify buffer width for individual features to create for example
>>>> > circles, roads of certain width...
>>>>
>>>> ... maybe rename from "Width" to "Buffer width"? Otherwise it could be
>>>> confused with the drawing line width.
>>>>
>>>
>>> There is not much space in toolbar..., especially if we in the future
>>> add more items (settings, label editing for example). What about just
>>> 'Buffer'? Currently the width is the width of the buffered line/diameter of
>>> the point (circle), which means 2 x buffer distance, so if we change it to
>>> buffer, then the value should be half of the line width?
>>>
>>>>
>>>> > - specify background map
>>>>
>>>> ... works (maybe have a button to optionally take computational region
>>>> from that map?)
>>>>
>>>
>>> Yes possibly, I am not sure about the region in general, if there should
>>> be any special handling.
>>>
>>>>
>>>> > - simple undo
>>>> > - save button to save results during drawing
>>>>
>>>> here I got an issue somewhere:
>>>>
>>>> Exception in thread Thread-4:
>>>> Traceback (most recent call last):
>>>>   File "/usr/lib64/python2.7/threading.py", line 811, in
>>>> __bootstrap_inner
>>>>     self.run()
>>>>   File "/home/neteler/software/grass71/dist.x86_64-unknown-
>>>> linux-gnu/gui/wxpython/core/gthread.py", line 94, in run
>>>>     ret = vars()['callable'](*args, **kwds)
>>>>   File "/home/neteler/software/grass71/dist.x86_64-unknown-
>>>> linux-gnu/gui/wxpython/rdigit/controller.py", line 432, in
>>>> _exportRaster
>>>>     if item.GetPropertyVal('widthValue') and \
>>>>   File "/home/neteler/software/grass71/dist.x86_64-unknown-
>>>> linux-gnu/gui/wxpython/mapwin/graphics.py", line 439, in
>>>> GetPropertyVal
>>>>     raise KeyError(_("Property does not exist: %s") %
>>>> (propName))
>>>> KeyError: 'Property does not exist: widthValue'
>>>>
>>>>
>>>>
>>> it normally works... Does this happen every time?
>>>
>>>
>>>> > - keeps drawing order in the output raster map
>>>> > - change color of drawing
>>>> > - doesn't block gui when exporting raster (which can take some time)
>>>>
>>>> Nice!
>>>>
>>>> > Does not support (yet?):
>>>> > - adding labels
>>>> > - interactive setting color of raster cells (not planned, there are
>>>> other tools)
>>>> > - vector export/import
>>>> >
>>>> > Known issues:
>>>> > - r.in.poly supports only CELL (I just realized that, this must be
>>>> changed)
>>>>
>>>> (meanwhile you changed that already, thanks)
>>>>
>>>> > - various small drawing issues
>>>> > - slow when exporting features with buffers (r.grow is slow, probably
>>>> > because it's a script)
>>>>
>>>> Not sure but r.buffer would be appropriate/faster?
>>>>
>>>
>>> I considered that but the cells grown by r.buffer have different values
>>> than the original ones, so I would have to reclassify it, so I am not sure
>>> if it would be faster in the end.
>>>
>>>
>>> Thanks for your feedback!
>>>
>>> Anna
>>>
>>>
>>>> Markus
>>>>
>>>
>>>
>>> _______________________________________________
>>> grass-dev mailing list
>>> grass-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20141120/95f08fbd/attachment.html>