[GRASS-dev] Backporting the start_rast option in r.walk

[Pierre Roudier]

Hi,

I am a happy user the start_rast option in r.walk in GRASS 7,

Recently I realised that the option is not available on the stable
version of GRASS (6.4.2) when a student here tried one of my scripts.

Is there any plan to backport this, or should the student switch to GRASS 7?

Cheers,

Pierre

--
Scientist
Landcare Research, New Zealand
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Submission for Addons repository

[Hamish]

Brian wrote:
> I have a GRASS module that I'd like to submit to the Add-ons
> SVN repository so that users can install it via g.extension.
> The module is currently hosted here:
>  https://github.com/selimnairb/r.findtheriver
>
> I've followed the instructions here:
> http://grass.osgeo.org/grass64/source/SUBMITTING
> and think that I'm ready to submit the code.  What's the next
> step?

Hi Brian,

see  
https://trac.osgeo.org/grass/wiki/HowToContribute#WriteaccesstotheGRASS-Addons-SVNrepository


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

[GRASS-dev] Submission for Addons repository

[Brian Miles]

Hello,

I have a GRASS module that I'd like to submit to the Add-ons SVN repository so 
that users can install it via g.extension.

The module is currently hosted here:

https://github.com/selimnairb/r.findtheriver


I've followed the instructions here:

http://grass.osgeo.org/grass64/source/SUBMITTING

and think that I'm ready to submit the code.  What's the next step?


Thanks,

Brian Miles
Ph.D. candidate
Department of Geography
University of North Carolina at Chapel Hill

Saunders Hall
Campus Box 3220
Chapel Hill, NC 27599-3220




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

Re: [GRASS-dev] i.maxlik

[Markus Neteler]

(updating subject line)

On Mon, May 20, 2013 at 9:10 PM, Dr Colin Hindmarch
 wrote:
> Hi,
>
> Processing PNG files in i.maxlik (Windows-based GRASS), I got (and keep
> getting) the following message:
>
>
> "(Mon May 20 09:22:53 2013)
> i.maxlik group=sattar@user1 subgroup=subgroup sigfile=unsupervised_signature
> class=unsupervised_map
> ERROR: Unable to open signature file 
> (Mon May 20 09:22:53 2013) Command finished (0 sec)"
>
>
> I am trying to produce an unsupervised classification, but keep getting hung
> up in 'i.maxlik'. I have tried reloading the latest version of Grass along
> with the 'visual' software, but no luck - I seem to be stuck! I can see from
> the email exchanges that you are all very busy, but I would be grateful if
> someone could help me to move on.

Did you generate beforehand the signature file with i.gensig?

Perhaps this page is useful for you:
http://grasswiki.osgeo.org/wiki/Image_classification

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

Re: [GRASS-dev] grass7 - mac osx- 64bit python

[epi]

Il giorno 20/mag/2013, alle ore 15:39, Anna Petrášová  
ha scritto:

> 
> 
> 
> On Mon, May 20, 2013 at 8:21 PM, epi  wrote:
> thanks Anna!
> 
> that's my bathymetry  
> 
> http://geofemengineering.it//data/nviz_mac_wx-29_cocoa.png
> 
> 
> I tried to changing resolution, use the slope map as color, light settings 
> and other tools , everything was working properly :)
> 
> 
> few question :
> 
> is it possible to "unlock" the layer manager and the map display so that when 
> i move the layer manager the map window doesn't move with it ?
> 
> this behavior is only on Mac. Do also other multiple-window applications 
> behave this way (like gimp)?

I tryied GIMP  2.8.2 it doesn't have this behavior


> 
> an important bug:
> 
> i was looking for possible options in the preference settings to unlock the 
> movement of mapdispaly when the layer manager is mived, 
> but i had to force quit the gui every time i tried to do something in that 
> panel
> 
> when i click on "apply" in the console i have :
> Settings applied to current session but not saved
> 
> then the gui is no more responsive and i forced it to quit
> 
> it is working for me. I have no idea and probably debug messages won't help 
> much. You could put some print statements in the code to localize more the 
> problem (starting at gui_core/preferences.py). 

i try to hack in it .. everything happen after is printed : "Settings applied 
to current session but not saved"
i'll let you kn ow if i found something

>  
> 
> .. will  be nice to be able to set the transparence for the fringe panels :)
> 
> I see 

:)


> 
> i'll try to export the verbose debug ant test again all the other widgets.
> 
> thanks again.
> 
> BTW, Michael Barton has had recently problem to start grass 7 wxGUI due to 
> new (a few weeks ago) toolboxes system (for menu customization). You doesn't 
> seem to have any problem, is that right?

no i do not have any problem to start it, what i didn't tried is the main 
wizard at start .. because i set txt in the gisrc preference as default mode, 
i'll try to change to wx and see if any problem comes up

manu thanks!

Massimo

> 
> 
> Anna
> 
> 
> and generate more useful logs,
> 
> thanks
> 
> Massimo.
> 
> Il giorno 20/mag/2013, alle ore 13:20, Anna Petrášová  
> ha scritto:
> 
>> Hi,
>> 
>> 
>> On Mon, May 20, 2013 at 3:37 PM, epi  wrote:
>> Hi,
>> 
>> is one week now that i'm testing a grass7 build, using wx cocoa (svn version 
>> built from source)
>> 
>> i'm really happy to say that almost everything is working fine! 
>> 
>> glad to hear that, I quickly tested wxGUI some time ago on wxPython 2.9 on 
>> linux so the most apparent bugs should be fixed. Unfortunately most bugs you 
>> listed here are not reproducible on my ubuntu with 2.9 classic wxPython.
>> 
>> 
>> 
>> .. few debug reported here :
>> 
>> - profile tool :
>>  -- the pen widget doesn't draw a line and no profile is plotted but ...
>> if i select the "measure tool" make a measurement and then 
>> without quitting the measurement tool (boucle click on the canvas) i open 
>> the profile tool .. then the profile is plotted correctly
>> 
>> hm, I don't have this behavior, it's working properly. The only problem is 
>> that the dashed line does not disappear after rerendering.
>> 
>> - add text layer :
>> -- doesn't change the font size
>> 
>> - map composer run but doesn't have a toolbar
>> 
>> again, both work for me 
>> 
>> nothing is printed in the shell during the guy session, should i set some 
>> env var to have more verbose
>> 
>> this is normal, everything goes to gui command console, only when you switch 
>> to debug mode it goes to terminal
>>  
>> 
>> - nviz doesn't render the 3d canvas, but there is no crash :) , the 
>> rendering-progress-bar load , this the log in the wx console
>> 
>> please try again, I just updated the code for 2.9
>>  
>> 
>> 
>> Traceback (most recent call last):
>>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi
>> ndow.py", line 366, in OnPaint
>> 
>> self.DoPaint()
>>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi
>> ndow.py", line 406, in DoPaint
>> 
>> self.UpdateMap()
>>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi
>> ndow.py", line 1166, in UpdateMap
>> 
>> self.SwapBuffers()
>>   File "/usr/local/lib/wxPython-2.9.4.0/lib/python2.7/site-
>> packages/wx-2.9.4-osx_cocoa/wx/glcanvas.py", line 124, in
>> SwapBuffers
>> 
>> return _glcanvas.GLCanvas_SwapBuffers(*args, **kwargs)
>> wx._core
>> .
>> PyAssertionError
>> :
>> C++ assertion "context" failed at /BUILD/wxPython-
>> src-2.9.4.0/src/osx/cocoa/glcanvas.mm(289) in SwapBuffers():
>> should have current context
>> 
>> 
>> 
>> if there is something i can do to do more testing i will be happy to work on 
>>  it.
>> 
>> I cannot do much about the bugs which I can't reproduce, especially when 
>> there is no error...
>>  
>> 
>> p.s.
>> with wx 2.9 we have great webkit support
>> @Anna have already tried to work on we

Re: [GRASS-dev] grass7 - mac osx- 64bit python

[Anna Petrášová]

On Mon, May 20, 2013 at 8:21 PM, epi  wrote:

> thanks Anna!
>
> that's my bathymetry
>
> http://geofemengineering.it//data/nviz_mac_wx-29_cocoa.png
>
>
> I tried to changing resolution, use the slope map as color, light settings
> and other tools , everything was working properly :)
>
>
> few question :
>
> is it possible to "unlock" the layer manager and the map display so that
> when i move the layer manager the map window doesn't move with it ?
>

this behavior is only on Mac. Do also other multiple-window applications
behave this way (like gimp)?

>
> an important bug:
>
> i was looking for possible options in the preference settings to unlock
> the movement of mapdispaly when the layer manager is mived,
> but i had to force quit the gui every time i tried to do something in that
> panel
>
> when i click on "apply" in the console i have :
> Settings applied to current session but not saved
>
> then the gui is no more responsive and i forced it to quit
>

it is working for me. I have no idea and probably debug messages won't help
much. You could put some print statements in the code to localize more the
problem (starting at gui_core/preferences.py).


>
> .. will  be nice to be able to set the transparence for the fringe panels
> :)
>

I see

>
> i'll try to export the verbose debug ant test again all the other widgets.
>

thanks again.

BTW, Michael Barton has had recently problem to start grass 7 wxGUI due to
new (a few weeks ago) toolboxes system (for menu customization). You
doesn't seem to have any problem, is that right?


Anna


> and generate more useful logs,
>
> thanks
>
> Massimo.
>
> Il giorno 20/mag/2013, alle ore 13:20, Anna Petrášová <
> kratocha...@gmail.com> ha scritto:
>
> Hi,
>
>
> On Mon, May 20, 2013 at 3:37 PM, epi  wrote:
>
>> Hi,
>>
>> is one week now that i'm testing a grass7 build, using wx cocoa (svn
>> version built from source)
>>
>> i'm really happy to say that almost everything is working fine!
>>
>> glad to hear that, I quickly tested wxGUI some time ago on wxPython 2.9
> on linux so the most apparent bugs should be fixed. Unfortunately most bugs
> you listed here are not reproducible on my ubuntu with 2.9 classic wxPython.
>
>
>>
>> .. few debug reported here :
>>
>> - profile tool :
>> -- the pen widget doesn't draw a line and no profile is plotted but ...
>> if i select the "measure tool" make a measurement and then
>> without quitting the measurement tool (boucle click on the canvas) i open
>> the profile tool .. then the profile is plotted correctly
>>
>
> hm, I don't have this behavior, it's working properly. The only problem is
> that the dashed line does not disappear after rerendering.
>
> - add text layer :
>> -- doesn't change the font size
>>
>
>> - map composer run but doesn't have a toolbar
>>
>> again, both work for me
>
>>
>> nothing is printed in the shell during the guy session, should i set some
>> env var to have more verbose
>>
>
> this is normal, everything goes to gui command console, only when you
> switch to debug mode it goes to terminal
>
>
>>
>> - nviz doesn't render the 3d canvas, but there is no crash :) , the
>> rendering-progress-bar load , this the log in the wx console
>>
>
>  please try again, I just updated the code for 2.9
>
>
>>
>>
>> Traceback (most recent call last):
>>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi
>> ndow.py", line 366, in OnPaint
>>
>> self.DoPaint()
>>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi
>> ndow.py", line 406, in DoPaint
>>
>> self.UpdateMap()
>>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi
>> ndow.py", line 1166, in UpdateMap
>>
>> self.SwapBuffers()
>>   File "/usr/local/lib/wxPython-2.9.4.0/lib/python2.7/site-
>> packages/wx-2.9.4-osx_cocoa/wx/glcanvas.py", line 124, in
>> SwapBuffers
>>
>> return _glcanvas.GLCanvas_SwapBuffers(*args, **kwargs)
>> wx._core
>> .
>> PyAssertionError
>> :
>> C++ assertion "context" failed at /BUILD/wxPython-
>> src-2.9.4.0/src/osx/cocoa/glcanvas.mm(289) in SwapBuffers():
>> should have current context
>>
>>
>>
>> if there is something i can do to do more testing i will be happy to work
>> on  it.
>>
>
> I cannot do much about the bugs which I can't reproduce, especially when
> there is no error...
>
>
>>
>> p.s.
>> with wx 2.9 we have great webkit support
>> @Anna have already tried to work on webkit in wx ?
>>
>
> not yet, I probably missed something when I compiled wx 2.9, it was not
> working and then I didn't try again.
>
> Thanks and keep testing:)
>
> Anna
>
>
>
>> i will start to investigate this to see how to add a new tab to include
>> the Ipython notebook
>> if of interest, at this link there is a simple pyqt app that does
>> something similar :
>>
>> https://github.com/damianavila/vIPer/blob/master/viper.py
>>
>> Massimo.
>>
>>
>>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #820: r.in.wms doesn't work in WinGRASS installer distribution

[Dr Colin Hindmarch]

Hi,

Processing PNG files in i.maxlik (Windows-based GRASS), I got (and keep 
getting) the 
following message:

  "(Mon May 20 09:22:53 2013)
  i.maxlik group=sattar@user1 subgroup=subgroup sigfile=unsupervised_signature 
  class=unsupervised_map
  ERROR: Unable to open signature file 
  (Mon May 20 09:22:53 2013) Command finished (0 sec)"

I am trying to produce an unsupervised classification, but keep getting hung 
up in 'i.maxlik'. I have tried reloading the latest version of Grass along 
with the 'visual' software, but no luck - I seem to be stuck! I can see from 
the email exchanges that you are all very busy, but I would be grateful if 
someone could help me to move on.

Many thanks,

Colin.

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

Re: [GRASS-dev] grass7 - mac osx- 64bit python

[epi]

thanks Anna!

that's my bathymetry  

http://geofemengineering.it//data/nviz_mac_wx-29_cocoa.png


I tried to changing resolution, use the slope map as color, light settings and 
other tools , everything was working properly :)


few question :

is it possible to "unlock" the layer manager and the map display so that when i 
move the layer manager the map window doesn't move with it ?

an important bug:

i was looking for possible options in the preference settings to unlock the 
movement of mapdispaly when the layer manager is mived, 
but i had to force quit the gui every time i tried to do something in that panel

when i click on "apply" in the console i have :
Settings applied to current session but not saved

then the gui is no more responsive and i forced it to quit

.. will  be nice to be able to set the transparence for the fringe panels :)

i'll try to export the verbose debug ant test again all the other widgets.

and generate more useful logs,

thanks

Massimo.

Il giorno 20/mag/2013, alle ore 13:20, Anna Petrášová  
ha scritto:

> Hi,
> 
> 
> On Mon, May 20, 2013 at 3:37 PM, epi  wrote:
> Hi,
> 
> is one week now that i'm testing a grass7 build, using wx cocoa (svn version 
> built from source)
> 
> i'm really happy to say that almost everything is working fine! 
> 
> glad to hear that, I quickly tested wxGUI some time ago on wxPython 2.9 on 
> linux so the most apparent bugs should be fixed. Unfortunately most bugs you 
> listed here are not reproducible on my ubuntu with 2.9 classic wxPython.
> 
> 
> 
> .. few debug reported here :
> 
> - profile tool :
>   -- the pen widget doesn't draw a line and no profile is plotted but ...
> if i select the "measure tool" make a measurement and then 
> without quitting the measurement tool (boucle click on the canvas) i open the 
> profile tool .. then the profile is plotted correctly
> 
> hm, I don't have this behavior, it's working properly. The only problem is 
> that the dashed line does not disappear after rerendering.
> 
> - add text layer :
> -- doesn't change the font size
> 
> - map composer run but doesn't have a toolbar
> 
> again, both work for me 
> 
> nothing is printed in the shell during the guy session, should i set some env 
> var to have more verbose
> 
> this is normal, everything goes to gui command console, only when you switch 
> to debug mode it goes to terminal
>  
> 
> - nviz doesn't render the 3d canvas, but there is no crash :) , the 
> rendering-progress-bar load , this the log in the wx console
> 
> please try again, I just updated the code for 2.9
>  
> 
> 
> Traceback (most recent call last):
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi
> ndow.py", line 366, in OnPaint
> 
> self.DoPaint()
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi
> ndow.py", line 406, in DoPaint
> 
> self.UpdateMap()
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi
> ndow.py", line 1166, in UpdateMap
> 
> self.SwapBuffers()
>   File "/usr/local/lib/wxPython-2.9.4.0/lib/python2.7/site-
> packages/wx-2.9.4-osx_cocoa/wx/glcanvas.py", line 124, in
> SwapBuffers
> 
> return _glcanvas.GLCanvas_SwapBuffers(*args, **kwargs)
> wx._core
> .
> PyAssertionError
> :
> C++ assertion "context" failed at /BUILD/wxPython-
> src-2.9.4.0/src/osx/cocoa/glcanvas.mm(289) in SwapBuffers():
> should have current context
> 
> 
> 
> if there is something i can do to do more testing i will be happy to work on  
> it.
> 
> I cannot do much about the bugs which I can't reproduce, especially when 
> there is no error...
>  
> 
> p.s.
> with wx 2.9 we have great webkit support
> @Anna have already tried to work on webkit in wx ?
> 
> not yet, I probably missed something when I compiled wx 2.9, it was not 
> working and then I didn't try again.
> 
> Thanks and keep testing:)
> 
> Anna
> 
>  
> i will start to investigate this to see how to add a new tab to include the 
> Ipython notebook
> if of interest, at this link there is a simple pyqt app that does something 
> similar : 
> 
> https://github.com/damianavila/vIPer/blob/master/viper.py
> 
> Massimo.
> 
> 
> 

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

Re: [GRASS-dev] grass7 - mac osx- 64bit python

[Anna Petrášová]

Hi,


On Mon, May 20, 2013 at 3:37 PM, epi  wrote:

> Hi,
>
> is one week now that i'm testing a grass7 build, using wx cocoa (svn
> version built from source)
>
> i'm really happy to say that almost everything is working fine!
>
> glad to hear that, I quickly tested wxGUI some time ago on wxPython 2.9 on
linux so the most apparent bugs should be fixed. Unfortunately most bugs
you listed here are not reproducible on my ubuntu with 2.9 classic wxPython.


>
> .. few debug reported here :
>
> - profile tool :
> -- the pen widget doesn't draw a line and no profile is plotted but ...
> if i select the "measure tool" make a measurement and then
> without quitting the measurement tool (boucle click on the canvas) i open
> the profile tool .. then the profile is plotted correctly
>

hm, I don't have this behavior, it's working properly. The only problem is
that the dashed line does not disappear after rerendering.

- add text layer :
> -- doesn't change the font size
>

> - map composer run but doesn't have a toolbar
>
> again, both work for me

>
> nothing is printed in the shell during the guy session, should i set some
> env var to have more verbose
>

this is normal, everything goes to gui command console, only when you
switch to debug mode it goes to terminal


>
> - nviz doesn't render the 3d canvas, but there is no crash :) , the
> rendering-progress-bar load , this the log in the wx console
>

please try again, I just updated the code for 2.9


>
>
> Traceback (most recent call last):
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi
> ndow.py", line 366, in OnPaint
>
> self.DoPaint()
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi
> ndow.py", line 406, in DoPaint
>
> self.UpdateMap()
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi
> ndow.py", line 1166, in UpdateMap
>
> self.SwapBuffers()
>   File "/usr/local/lib/wxPython-2.9.4.0/lib/python2.7/site-
> packages/wx-2.9.4-osx_cocoa/wx/glcanvas.py", line 124, in
> SwapBuffers
>
> return _glcanvas.GLCanvas_SwapBuffers(*args, **kwargs)
> wx._core
> .
> PyAssertionError
> :
> C++ assertion "context" failed at /BUILD/wxPython-
> src-2.9.4.0/src/osx/cocoa/glcanvas.mm(289) in SwapBuffers():
> should have current context
>
>
>
> if there is something i can do to do more testing i will be happy to work
> on  it.
>

I cannot do much about the bugs which I can't reproduce, especially when
there is no error...


>
> p.s.
> with wx 2.9 we have great webkit support
> @Anna have already tried to work on webkit in wx ?
>

not yet, I probably missed something when I compiled wx 2.9, it was not
working and then I didn't try again.

Thanks and keep testing:)

Anna



> i will start to investigate this to see how to add a new tab to include
> the Ipython notebook
> if of interest, at this link there is a simple pyqt app that does
> something similar :
>
> https://github.com/damianavila/vIPer/blob/master/viper.py
>
> Massimo.
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1838: r.mask: allow use of vector map as input

[Nikos Alexandris]

Nikos Alexandris wrote:

> So the question is: I need to MASK that vector feature(s) out

(or in)

> from my raster  processing workflow: So I'll MASK'em. Intuitively, but maybe
> now

maybe _not_ wise 

> wise as you and Hamish note, a user could simply say:  r.mask
> vector=VectorMap where="Some SQL statement" and the module will set-up for
> him/her a MASK based on what he/her expects.

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

Re: [GRASS-dev] [GRASS GIS] #1838: r.mask: allow use of vector map as input

[Nikos Alexandris]

Paulo van Breugel wrote:

Hi Paulo!

> If you have a vector layer with (some) polygons that occur partly within
> the region of interest, finding the area that should become a mask means in
> that case spitting the polygon(s). Yes, of course you could do that, but
> you can equally well (easier in fact) set the region to match your vector
> layer (or the region of interest) manually.

I don't really understand the above.

> An exception? I don't know, each user will use the functions available in a
> different way. I personally would prefer the current implementation, or
> more in general, to avoid functions to set the region automatically. In my
> opinion that better fits the general work flow in GRASS: the user
> explicitly sets the region, and functions operate on that region.

Sure, I agree.

> On the other hand, r.mask with a raster as input is an exception as
> mentioned already mentioned, and one could argue that it is better to have
> the same behaviour both when using raster or vector as input.

My idea comes from what (I maybe wrongly consider as a fact) the r.mask module 
is used for:  a user wants to use a MASK in order to filter out (or in) cells 
while processing raster data.

So the question is: I need to MASK that vector feature(s) out from my raster 
processing workflow: So I'll MASK'em. Intuitively, but maybe now wise as you 
and Hamish note, a user could simply say:  r.mask vector=VectorMap where="Some 
SQL statement" and the module will set-up for him/her a MASK based on what 
he/her expects.


> It is important thought that r.mask does not change the region if you use
> raster as input, and that is something I really think should remain the
> case when using a vector as input. That means that even if you would
> implement the suggestion above, adjusting the region to the extend of the
> vector layer before creating the mask, that region should be set back to
> the initial extend after the mask is created.

Yes, of course the *current region settings* should be respected.

Anyway, thank you for your time answering/commenting. It's just an idea that 
might make life easier... if...

Thanks, Nikos

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

Re: [GRASS-dev] [GRASS GIS] #1838: r.mask: allow use of vector map as input

[GRASS GIS]

#1838: r.mask: allow use of vector map as input
--+-
  Reporter:  mlennert |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  7.0.0
 Component:  Raster   | Version:  svn-trunk
Resolution:  fixed|Keywords:  mask, vector, r.mask 
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-

Comment(by nikosa):

 O-K, I see.  So, not even a flag "-v" that will work *only* when a
 "vector=" and will obtain the bounding box coordinates of the queried
 vector map/feature(s)?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1838: r.mask: allow use of vector map as input

[Paulo van Breugel]

+ 1


On Mon, May 20, 2013 at 4:32 PM, GRASS GIS  wrote:

> #1838: r.mask: allow use of vector map as input
>
> --+-
>   Reporter:  mlennert |   Owner:  grass-dev@…
>   Type:  enhancement  |  Status:  closed
>   Priority:  normal   |   Milestone:  7.0.0
>  Component:  Raster   | Version:  svn-trunk
> Resolution:  fixed|Keywords:  mask, vector, r.mask
>   Platform:  Unspecified  | Cpu:  Unspecified
>
> --+-
>
> Comment(by hamish):
>
>  To be honest, I find it hard to justify not running `v.to.rast` + r.mask
>  as a two step process. You either respect the current region setting, or
>  the v.to.rast operation is partially undefined. Having the module change
>  the region (and if so, internally, via WIND_OVERRIDE & the
>  grass.use_temp_region() python function) for any reason seems like a
>  slight misfeature to me.
>
>  Consider the case that the vector is much larger than the raster (national
>  coastline, I'm offen making coastal "land.mask" rasters from that), you
>  wouldn't want to rasterize the entire country at the current raster
>  resolution. Of course it's possible to only shrink the region with a
>  little scripting work, and it could be a nice efficiency trick to do that,
>  but be careful that the logic for it might fail for lat/lon near the
>  dateline)
>
>
>  do one thing well,
>  Hamish
>
> --
> Ticket URL: 
> GRASS GIS 
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1838: r.mask: allow use of vector map as input

[Paulo van Breugel]

If you have a vector layer with (some) polygons that occur partly within
the region of interest, finding the area that should become a mask means in
that case spitting the polygon(s). Yes, of course you could do that, but
you can equally well (easier in fact) set the region to match your vector
layer (or the region of interest) manually.

An exception? I don't know, each user will use the functions available in a
different way. I personally would prefer the current implementation, or
more in general, to avoid functions to set the region automatically. In my
opinion that better fits the general work flow in GRASS: the user
explicitly sets the region, and functions operate on that region.

On the other hand, r.mask with a raster as input is an exception as
mentioned already mentioned, and one could argue that it is better to have
the same behaviour both when using raster or vector as input.

It is important thought that r.mask does not change the region if you use
raster as input, and that is something I really think should remain the
case when using a vector as input. That means that even if you would
implement the suggestion above, adjusting the region to the extend of the
vector layer before creating the mask, that region should be set back to
the initial extend after the mask is created.



On Mon, May 20, 2013 at 3:15 PM, GRASS GIS  wrote:

> #1838: r.mask: allow use of vector map as input
>
> --+-
>   Reporter:  mlennert |   Owner:  grass-dev@…
>   Type:  enhancement  |  Status:  closed
>   Priority:  normal   |   Milestone:  7.0.0
>  Component:  Raster   | Version:  svn-trunk
> Resolution:  fixed|Keywords:  mask, vector, r.mask
>   Platform:  Unspecified  | Cpu:  Unspecified
>
> --+-
>
> Comment(by nikosa):
>
>  Replying to [comment:6 pvanbosgeo]:
>  > One reason a user would not want to match the region extent to the
>  queried vector map could be that he/she is only interested in an area that
>  partly overlaps with the vector map, with polygons falling only partly
>  within the region. This still works with our suggestion, but only if the
>  region is set back to the initial one after the mask is created I guess.
>
>  If a user is interested in an area that partly overlaps with the vector
>  map, he doesn't really want to
>
>  {{{
>  r.mask vector=SomeVector
>  }}}
>
>  He rather needs to manually find the area of interest that will become a
>  MASK.  This sounds as an exception, rather than a general rule. What do
>  you think?
>
>  Thanks
>
> --
> Ticket URL: 
> GRASS GIS 
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1838: r.mask: allow use of vector map as input

[GRASS GIS]

#1838: r.mask: allow use of vector map as input
--+-
  Reporter:  mlennert |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  7.0.0
 Component:  Raster   | Version:  svn-trunk
Resolution:  fixed|Keywords:  mask, vector, r.mask 
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-

Comment(by hamish):

 To be honest, I find it hard to justify not running `v.to.rast` + r.mask
 as a two step process. You either respect the current region setting, or
 the v.to.rast operation is partially undefined. Having the module change
 the region (and if so, internally, via WIND_OVERRIDE & the
 grass.use_temp_region() python function) for any reason seems like a
 slight misfeature to me.

 Consider the case that the vector is much larger than the raster (national
 coastline, I'm offen making coastal "land.mask" rasters from that), you
 wouldn't want to rasterize the entire country at the current raster
 resolution. Of course it's possible to only shrink the region with a
 little scripting work, and it could be a nice efficiency trick to do that,
 but be careful that the logic for it might fail for lat/lon near the
 dateline)


 do one thing well,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] grass7 - mac osx- 64bit python

[epi]

Hi,

is one week now that i'm testing a grass7 build, using wx cocoa (svn version 
built from source)

i'm really happy to say that almost everything is working fine! 



.. few debug reported here :

- profile tool :
-- the pen widget doesn't draw a line and no profile is plotted but ...
if i select the "measure tool" make a measurement and then without 
quitting the measurement tool (boucle click on the canvas) i open the profile 
tool .. then the profile is plotted correctly
- add text layer :
-- doesn't change the font size

- map composer run but doesn't have a toolbar


nothing is printed in the shell during the guy session, should i set some env 
var to have more verbose

- nviz doesn't render the 3d canvas, but there is no crash :) , the 
rendering-progress-bar load , this the log in the wx console


Traceback (most recent call last):
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi
ndow.py", line 366, in OnPaint

self.DoPaint()
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi
ndow.py", line 406, in DoPaint

self.UpdateMap()
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi
ndow.py", line 1166, in UpdateMap

self.SwapBuffers()
  File "/usr/local/lib/wxPython-2.9.4.0/lib/python2.7/site-
packages/wx-2.9.4-osx_cocoa/wx/glcanvas.py", line 124, in
SwapBuffers

return _glcanvas.GLCanvas_SwapBuffers(*args, **kwargs)
wx._core
.
PyAssertionError
:
C++ assertion "context" failed at /BUILD/wxPython-
src-2.9.4.0/src/osx/cocoa/glcanvas.mm(289) in SwapBuffers():
should have current context



if there is something i can do to do more testing i will be happy to work on  
it.

p.s.
with wx 2.9 we have great webkit support
@Anna have already tried to work on webkit in wx ?
i will start to investigate this to see how to add a new tab to include the 
Ipython notebook
if of interest, at this link there is a simple pyqt app that does something 
similar : 

https://github.com/damianavila/vIPer/blob/master/viper.py

Massimo.


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

Re: [GRASS-dev] [GRASS GIS] #1838: r.mask: allow use of vector map as input

[GRASS GIS]

#1838: r.mask: allow use of vector map as input
--+-
  Reporter:  mlennert |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  7.0.0
 Component:  Raster   | Version:  svn-trunk
Resolution:  fixed|Keywords:  mask, vector, r.mask 
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-

Comment(by nikosa):

 Replying to [comment:6 pvanbosgeo]:
 > One reason a user would not want to match the region extent to the
 queried vector map could be that he/she is only interested in an area that
 partly overlaps with the vector map, with polygons falling only partly
 within the region. This still works with our suggestion, but only if the
 region is set back to the initial one after the mask is created I guess.

 If a user is interested in an area that partly overlaps with the vector
 map, he doesn't really want to

 {{{
 r.mask vector=SomeVector
 }}}

 He rather needs to manually find the area of interest that will become a
 MASK.  This sounds as an exception, rather than a general rule. What do
 you think?

 Thanks

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] interp_type: cubic | bicubic

[Martin Landa]

Hi,

2013/5/16 Glynn Clements :
> Whichever is used, it should be consistent. I.e. either
> nearest/linear/cubic or nearest/bilinear/bicubic.
>
> The former might be preferable if we want to extend it to 3D
> interpolation (i.e. use nearest/linear/cubic regardless of the
> dimensionality, rather than using separate 2D/3D terminology).

OK, done in r56327, any review welcome of course. Probably would make
sense to incorporate into raster lib as INTERP_TYPE (see
lib/raster/sample.c) other methods, at least `lanczos`.

Martin

--
Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1838: r.mask: allow use of vector map as input

[GRASS GIS]

#1838: r.mask: allow use of vector map as input
--+-
  Reporter:  mlennert |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  7.0.0
 Component:  Raster   | Version:  svn-trunk
Resolution:  fixed|Keywords:  mask, vector, r.mask 
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-

Comment(by pvanbosgeo):

 One reason a user would not want to match the region extent to the queried
 vector map could be that he/she is only interested in an area that partly
 overlaps with the vector map, with polygons falling only partly within the
 region. This still works with our suggestion, but only if the region is
 set back to the initial one after the mask is created I guess.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Overflow warning in r.mapcalc calculation

[Paulo van Breugel]

On 05/20/2013 01:46 PM, Glynn Clements wrote:

Markus Metz wrote:


Happy to see this exchange of ideas. It would be great if this could be
implemented. Do you think it is useful I make a feature request on the bug
tracker (with link to this email thread) so the idea doesn't get lost?

Instead of

r.mapcalc "A = if(B==0,
(round(C/0.0001)-1175699902)/(300797-1175699902) *100.0, 1)"
--overwrite

try

r.mapcalc "A = if(B==0,
(round(C/0.0001)-1175699902.0)/(300797.0-1175699902.0) *100.0, 1)"
--overwrite

or better with whitespaces

r.mapcalc "A = if(B == 0, (round(C / 0.0001) - 1175699902.0) /
(300797.0 - 1175699902.0) * 100.0, 1)" --overwrite

adding .0 to numbers forces all calculations to be done with  floating
point double precision

That won't help; the problem is that round() returns an integer.

It wouldn't be particularly hard to change it so that the return type
is the same as the argument type, but that might break existing
scripts.


Hi Glynn,

In case you haven't seen it, Markus Metz has implemented in trunk r56313 
 the option to have the 
same raster type as output of round() as the input type, see ticket 1976 
(http://trac.osgeo.org/grass/ticket/).


I sure hope it does not brake existing scripts, as this is a very useful 
enhancement I think.


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

Re: [GRASS-dev] Overflow warning in r.mapcalc calculation

[Glynn Clements]

Rainer M. Krug wrote:

> >> Sounds like a sensible approach without adding to many new
> >> functions. But I would actually split the two, i.e. have two more
> >> arguments, where one specifies the type, 
> >> and the other one the number of decimals to round to, i.e.
> >> 
> >> round(x, 0, "I") would be the default, rounding to whole number and
> >> return an integer
> >
> > That interface isn't possible. r.mapcalc doesn't have a string type,
> > and there's no way that a function's return type can depend upon the
> > value of a parameter.
> 
> 
> In this case I would suggest different functions, e.g.
> 
> round(x) - as it is now
> 
> roundI(x, dec) - round to integer, dec>0 is ignored, dec<0 as below
> 
> roundD(x, dec) - round to double, where dec is the number of decimals it
> should be rounded to
> 
> roundF(x, dec) - round to float, where dec is the number of decimals it
> should be rounded to
> 
> if dec is positive, it is the number of decimals, if negative the
> ... (no idea what it is called, but if it is -1, 111 is rounded to 110,
> -2 111 is rounded to 100)
> 
> default from dec would be 0.
> 
> These different functions would also have the advantage of probably
> being faster then one single function.

1. I wouldn't bother with separate functions, but instead use the type
of the second argument to determine the return type, i.e.

round(x, 1)-> CELL
round(x, 1.0f) -> FCELL
round(x, 1.0)  -> DCELL

The value of the second argument can be ignored, or it can be used for
other purposes.

2. Rounding to a given number of decimals is unnecessarily limiting.
The algorithm for generalised rounding is essentially:

roundTo(x, k) = round(x / k) * k.

Rounding to N decimal places is just a case of using k=1/10^N. If you
allow k to be specified directly, then you can round to arbitrary
steps (e.g. k=5 would round to the nearest multiple of 5, etc).

3. However: there's a slight problem with doing it that way: 0.1 isn't
exactly representable in binary, so e.g. x/0.1 isn't equal to x*10; it
would be more accurate to use:

roundTo(x, k) = round(x * k) / k

where k is the reciprocal of the step, so k=10^N to round to N decimal
places (or k=2 to round to 1/2).

The downside is that the interface is less useful if you want to round
to something other than a fixed number of decimal places. E.g. if you
wanted to round to the nearest multiple of 45 degrees, you'd need to
use k=1.0/45, which isn't exactly representable.

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

Re: [GRASS-dev] GRASS GIS Visual Studio build

[Sören Gebbert]

Hi Rashad,


2013/5/20 Rashad M 

> Hi All,
>
> Is there any visual studio build of GRASS GIS.
>

Not to my knowledge.


> If no why?
>

The GRASS build system is based on UNIX Makefiles.

Best regards
Soeren


>
>
> --
> Regards,
>Rashad
>
> ___
> 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] Overflow warning in r.mapcalc calculation

[Glynn Clements]

Markus Metz wrote:

> > Happy to see this exchange of ideas. It would be great if this could be
> > implemented. Do you think it is useful I make a feature request on the bug
> > tracker (with link to this email thread) so the idea doesn't get lost?
> 
> Instead of
> 
> r.mapcalc "A = if(B==0,
> (round(C/0.0001)-1175699902)/(300797-1175699902) *100.0, 1)"
> --overwrite
> 
> try
> 
> r.mapcalc "A = if(B==0,
> (round(C/0.0001)-1175699902.0)/(300797.0-1175699902.0) *100.0, 1)"
> --overwrite
> 
> or better with whitespaces
> 
> r.mapcalc "A = if(B == 0, (round(C / 0.0001) - 1175699902.0) /
> (300797.0 - 1175699902.0) * 100.0, 1)" --overwrite
> 
> adding .0 to numbers forces all calculations to be done with  floating
> point double precision

That won't help; the problem is that round() returns an integer.

It wouldn't be particularly hard to change it so that the return type
is the same as the argument type, but that might break existing
scripts.

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

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

[Michael Barton]

Hi Anna,

Thanks for the reminder. Just got set up here in Valencia and starting the 
course today. So it will be a few days at best before I can try to compile this 
on my MacBook Air.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu











On May 20, 2013, at 9:06 AM, Anna Petrášová 
mailto:kratocha...@gmail.com>> wrote:

Hi Michael,


On Tue, May 14, 2013 at 12:32 AM, Anna Petrášová 
mailto:kratocha...@gmail.com>> wrote:



On Mon, May 13, 2013 at 11:51 PM, Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:
Perhaps I discovered the problem. Both the distribution version (downloaded in 
the past hour) and (of course) the compiled version of menudata.xml are empty.

Yes, that's what I was thinking. Could you try to run this separately:

python core/toolboxes.py > xml/menudata.xml

which should be done during compilation but it seems to fail somehow. It should 
generate the xml menu file.

any update? I know you announced to be out of office but maybe you can try it 
anyway?

Anna



Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice:  480-965-6262 (SHESC), 480-727-9746 
(CSDC)
fax:  480-965-7671 (SHESC),  
480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, 
http://csdc.asu.edu











On May 13, 2013, at 2:18 PM, Anna Petrášová 
mailto:kratocha...@gmail.com>>
 wrote:

There might be a problem with compilation. Is there any error? Could you check 
file menudata.xml in gui/wxpython/xml/ and the same file in distribution? Is it 
there and what's inside?


On Mon, May 13, 2013 at 10:51 PM, Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:
Anna,

I deleted all the GUI code and did a new svn up and make distclean.

Just finished compiling and have the same error on startup. The GUI crashes.


Michael
__
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice:  480-965-6262 (SHESC), 480-727-9746 
(CSDC)
fax:  480-965-7671(SHESC), 
480-727-0709 (CSDC)
www:  http://csdc.asu.edu, 
http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On May 13, 2013, at 1:23 PM, Anna Petrášová 
mailto:kratocha...@gmail.com>>
 wrote:

Hi Michael,


On Mon, May 13, 2013 at 9:52 PM, Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:
I just compiled GRASS 7 Trunk.

It crashes on startup with the following error:

this is related to the new toolboxes and menu customization. I don't know what 
is wrong because it was tested successfully also on Windows. Could you check 
what you have in directory toolboxes which should be in the same folder as 
saved settings file? Also try make distclean or just make clean in gui/wxpython 
and remove manually the gui files from distribution.

Anna


GRASS 7.0.svn (nc_spm_08):~ > Traceback (most recent call last):
  File 
"/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py",
 line 140, in 
sys.exit(main())
  File 
"/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py",
 line 133, in main
app = GMApp(workspaceFile)
  File 
"/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py",
 line 45, in __init__
wx.App.__init__(self, False)
  File 
"/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core.py",
 line 7981, in __init__
self._BootstrapApp()
  File 
"/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core.py",
 line 7555, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File 
"/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py",
 line 79, in OnInit
workspace = self.workspaceFile)
  File 
"/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/lmgr/frame.py",
 line 106, in __init__
self._menuTreeBuilder = LayerManagerMenuData()
  File 
"/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/lmgr/menudata.py",
 line 31, in __init__
MenuTreeModelBuilder.__init__(self, filename)
  File 
"/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/core/menutree.py",
 line 61, in __init__
xmlTree = etree.parse(filename)
  File 
"/System/Library

Re: [GRASS-dev] [GRASS GIS] #1838: r.mask: allow use of vector map as input

[GRASS GIS]

#1838: r.mask: allow use of vector map as input
--+-
  Reporter:  mlennert |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  7.0.0
 Component:  Raster   | Version:  svn-trunk
Resolution:  fixed|Keywords:  mask, vector, r.mask 
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-

Comment(by nikosa):

 Replying to [comment:2 mmetz]:
 > Replying to [comment:1 neteler]:
 > > Sounds very reasonable. Maybe they can develop the method? It will
 include
 > > (perhaps) SQL select option and column selection, then the
 rasterization...
 >
 > `r.mask` got new `vector`, `layer`, `cats`, and `where` options in
 r54302. The `input` option has been renamed to `raster`.
 ..
 > When a MASK is created from a raster, the extents and resolution of the
 raster map are used because r.reclass is used (that's the unchanged
 default behaviour as in GRASS 6), but when a MASK is created from a
 vector, the current region settings are used.

 Thanks!

 Nevertheless, currently, if the region extent doesn't match, the produced
 raster MASK is empty. Manually, I need to extract the vector features of
 my interest (`v.extract`), set the region (`g.region vect=`) and then use
 `r.mask` along with the `vector=` option.

 Would it be easy to make the region adjustment, when using a vector,
 automatic? Even if the user supplies an where="SQL clause"? If this action
 is not difficult to code, are there reasons for a user he would not want
 to match (at least) the region extent to the queried vector map?

 I need to integrate in a script this exact operation (hardcoded example
 here, the idea is to support scripting of course):

 {{{
 r.mask vect=wrs2_descending where="PATH=161 and ROW=076"
 }}}

 It would be nicer to get this done automatically.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1976: r.mapcalc: Allow rounding of floating numbers

[Rainer M. Krug]

"GRASS GIS"  writes:

> #1976: r.mapcalc: Allow rounding of floating numbers
> -+--
>  Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
>  Type:  enhancement  |  Status:  new  
>  Priority:  normal   |   Milestone:  7.0.0
> Component:  Raster   | Version:  unspecified  
>  Keywords:  r.mapcalc|Platform:  Unspecified  
>   Cpu:  Unspecified  |  
> -+--
>
> Comment(by mmetz):
>
>  Replying to [ticket:1976 pvanbosgeo]:
>  > The round() function in r.mapcalc always returns an integer, regardless
>  of its argument types. Integers are always 32-bit, so the result is
>  limited to the range +/- 2147483647 (2^31-1).
>  >
>  > Suggestion: extend the function to allow to round numbers outside the
>  integer range, and to round with a specific number of decimal places, like
>  e.g., the function round() in R.
>
>  Try trunk r56313.
>
>  The output type of round() is now the same like the input type. Rounding
>  to a given number of decimal places is supported with round(x, y) with y =
>  number of decimal places. The new function round(x, y) supports a negative
>  number of decimal places: for example, round(119, -1) results in 120, and
>  round(119, -2) results in 100.
<#secure method=pgpmime mode=sign>

Great - sounds like a perfect solution to me.

Thanks,

Rainer

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

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

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

[Anna Petrášová]

Hi Michael,


On Tue, May 14, 2013 at 12:32 AM, Anna Petrášová wrote:

>
>
>
> On Mon, May 13, 2013 at 11:51 PM, Michael Barton 
> wrote:
>
>>  Perhaps I discovered the problem. Both the distribution version
>> (downloaded in the past hour) and (of course) the compiled version of
>> menudata.xml are empty.
>>
>
> Yes, that's what I was thinking. Could you try to run this separately:
>
> python core/toolboxes.py > xml/menudata.xml
>
> which should be done during compilation but it seems to fail somehow. It
> should generate the xml menu file.
>

any update? I know you announced to be out of office but maybe you can try
it anyway?

Anna


>
>>  Michael
>> 
>> C. Michael Barton
>> Director, Center for Social Dynamics & Complexity
>> Professor of Anthropology, School of Human Evolution & Social Change
>> Arizona State University
>>
>>  voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
>>  fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  On May 13, 2013, at 2:18 PM, Anna Petrášová 
>>  wrote:
>>
>>  There might be a problem with compilation. Is there any error? Could
>> you check file menudata.xml in gui/wxpython/xml/ and the same file in
>> distribution? Is it there and what's inside?
>>
>>
>> On Mon, May 13, 2013 at 10:51 PM, Michael Barton 
>> wrote:
>>
>>> Anna,
>>>
>>>  I deleted all the GUI code and did a new svn up and make distclean.
>>>
>>>  Just finished compiling and have the same error on startup. The GUI
>>> crashes.
>>>
>>>
>>>  Michael
>>>__
>>> C. Michael Barton
>>> Director, Center for Social Dynamics & Complexity
>>> Professor of Anthropology, School of Human Evolution & Social Change
>>> Arizona State University
>>> Tempe, AZ  85287-2402
>>> USA
>>>
>>>  voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
>>> fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
>>> www:  http://csdc.asu.edu, http://shesc.asu.edu
>>> http://www.public.asu.edu/~cmbarton
>>>
>>>   On May 13, 2013, at 1:23 PM, Anna Petrášová 
>>>  wrote:
>>>
>>>   Hi Michael,
>>>
>>>
>>> On Mon, May 13, 2013 at 9:52 PM, Michael Barton 
>>> wrote:
>>>
 I just compiled GRASS 7 Trunk.

  It crashes on startup with the following error:

>>>
>>>  this is related to the new toolboxes and menu customization. I don't
>>> know what is wrong because it was tested successfully also on Windows.
>>> Could you check what you have in directory toolboxes which should be in the
>>> same folder as saved settings file? Also try make distclean or just make
>>> clean in gui/wxpython and remove manually the gui files from distribution.
>>>
>>>  Anna
>>>
>>>
  GRASS 7.0.svn (nc_spm_08):~ > Traceback (most recent call last):
   File
 "/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py",
 line 140, in 
 sys.exit(main())
   File
 "/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py",
 line 133, in main
 app = GMApp(workspaceFile)
   File
 "/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py",
 line 45, in __init__
 wx.App.__init__(self, False)
   File
 "/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core.py",
 line 7981, in __init__
 self._BootstrapApp()
   File
 "/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core.py",
 line 7555, in _BootstrapApp
 return _core_.PyApp__BootstrapApp(*args, **kwargs)
   File
 "/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py",
 line 79, in OnInit
 workspace = self.workspaceFile)
   File
 "/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/lmgr/frame.py",
 line 106, in __init__
 self._menuTreeBuilder = LayerManagerMenuData()
   File
 "/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/lmgr/menudata.py",
 line 31, in __init__
 MenuTreeModelBuilder.__init__(self, filename)
   File
 "/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/core/menutree.py",
 line 61, in __init__
 xmlTree = etree.parse(filename)
   File
 "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/etree/ElementTree.py",
 line 862, in parse
 tree.parse(source, parser)
   File
 "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/etree/ElementTree.py",
 line 587, in parse
 self._root = parser.close()
   File
 "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/etree/