date:20150202


On 02/02/15 19:07, Glynn Clements wrote:


Moritz Lennert wrote:


For now, I've added a warning that you should know what you are doing if
you want to use these calls.


Why not just use suitable examples, e.g. using subprocess.Popen()
(without shell=True), with the caveat that on Windows it won't work
for scripts, only compiled executables.


But what exactly is the problem with using subprocess.call with
shell=True ?


It requires you to construct the correct string. If the command string
is a single literal string with all argument values consisting of
alphanumerics plus "safe" punctuation (i.e. characters which have no
meaning to any shell), that's simple enough.

But if any of the arguments are variable and *could* contain
characters which are meaningful to a shell, constructing the correct
string (the one which results in the called program's argv[] having
the intended values) isn't straightforward (and the exact rules vary
between platforms).

It's much simpler (and safer) to just remove the shell from equation
altogether and pass the individual arguments directly, rather than
trying to construct a string which, when deconstructed by the shell,
will produce the correct result.


Security issues ? Difficulties in calling shell scripts ?


Security would be a problem, but if you're dealing with potentially
malicious input, it's the least of your problems compared to the rest
of GRASS. Calling scripts on Windows is a different problem (setting
shell=True "solves" one problem while introducing more).


AFAICT, it's just a wrapper around Popen.wait(), or ?


subprocess.call() is a wrapper() around Popen() and Popen.wait().
Exactly the same issue applies to Popen() itself (it applies to
.call() *because* it applies to Popen() itself).



Ok, thanks for all the explanations.




I've now replaced this with:

   subprocess.Popen(['r.watershed', 'elevation=elevation',
'threshold=1', 'stream=raster_streams'])

or would it be better with .wait():

   import subprocess
   subprocess.Popen(['r.watershed', 'elevation=elevation',
'threshold=1', 'stream=raster_streams']).wait()


subprocess.call() is fine. It's using shell=True which is the problem.

For simple examples, I'd suggest using subprocess.call, and referring
them to the python.org documentation for the (2.x) subprocess module
for anything else.


Ok, I put .call back in.




And even though within GRASS Python it should always be Popen(), maybe
there are situations out there where calling a module via call() is
justifiable...


Well, depending upon what you mean by "GRASS Python", it should
arguably be grass.script.run_command() or similar.

Even if the wiki page isn't the right place to introduce that, it's
probably worth mentioning that it exists before users end up
recreating the wheel (e.g. if they care about being able to run both
executables and script and doing so on both Unix/MacOSX and Windows,
they'll end up having to learn the same lessons we have).



This is what the warning before the system call examples says:

"Warning: In many cases, system calls such as these demand that you 
really know what you are doing. If you want to program in Python, you 
are encouraged to rather use the existing Python APIs explained below 
instead of such system calls."


And then it goes on with:

"These system calls are easy to handle when no output is expected from 
the GRASS module. When output needs to be collected then the programming 
task already becomes a little harder unless you know what you are doing. 
Equally, they can be tricky when introducing variable arguments and 
special characters. It is for this reason that the Python GRASS 
libraries where developed that are explained in the next section."


I hope this is explicit enough.

Again, the aim of this page is not to give a programming course, but 
rather to show that you can program with and for GRASS in different way, 
from single system calls to GRASS modules to full-fledged programming 
with the C-API.


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

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

2015-02-02 Thread Yann Chemin

It may sound out of place, but would it be possible to call this dialog
anytime during a grass session to manage where you want to work through a
known, unified interface?
On Feb 3, 2015 4:42 AM, "Vaclav Petras"  wrote:

>
> On Mon, Feb 2, 2015 at 6:34 PM, Michael Barton 
> wrote:
>
>>  I think that they are equally as informative and the one on the left
>> takes up less space. Just my opinion.
>>
>>
> Replacing "Warning: " by nothing in r64407. Other changes included as
> well, most notably decreased vertical size at expense of Location and
> Mapset lists which are now as big as in 64. The whole dialog is just little
> bit bigger than in 64, so with smaller banner it will be hopefully smaller.
> I would prefer if it would be possible to make it smaller by dragging but
> it is not (I tried several times but I cannot get it work).
>
> I also changed the user visible strings, see commit for details but most
> importantly I add numbers to the boxes to make it clear in which order you
> should fill them (and that there is an order).
>
> Please, see screenshot (40%), commit message and diff for details.
>
> Vaclav
>
> http://trac.osgeo.org/grass/changeset/64407
>
>
>>  Michael
>>
>>  On Feb 2, 2015, at 4:11 PM, Vaclav Petras  wrote:
>>
>>
>>
>> On Mon, Feb 2, 2015 at 5:33 PM, Markus Neteler  wrote:
>>
>>>  On Mon, Feb 2, 2015 at 11:02 PM, Vaclav Petras 
>>> wrote:
>>> >
>>> > On Mon, Feb 2, 2015 at 4:50 PM, Michael Barton >> >
>>> > wrote:
>>> >>
>>> >> Unfortunately the screenshots are too low resolution for me to read
>>> them
>>> >> here. So I might miss something that is on the screenshot.
>>> >
>>> >
>>> > It's just about layout, don't worry about text. I can of course send
>>> full
>>> > size if somebody wants.
>>>
>>>  Please post at least double size...
>>>
>>>  I posted 25%, now posting 50% which is not significantly smaller then
>> 100% even after optipng, so I can post just one image at a time.
>>
>>  Here is what you see when you start 64 for the first time and when you
>> start current trunk for the first time.
>>
>>
>>> thanks
>>> 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] Making start of GRASS GIS easier for newcomers

2015-02-02 Thread Michael Barton

I think that they are equally as informative and the one on the left takes up 
less space. Just my opinion.

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
Tempe, AZ  85287-2402
USA

voice:  480-965-6262 (SHESC), 480-965-8130/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 Feb 2, 2015, at 4:11 PM, Vaclav Petras 
mailto:wenzesl...@gmail.com>> wrote:

On Mon, Feb 2, 2015 at 5:33 PM, Markus Neteler 
mailto:nete...@osgeo.org>> wrote:
On Mon, Feb 2, 2015 at 11:02 PM, Vaclav Petras 
mailto:wenzesl...@gmail.com>> wrote:
>
> On Mon, Feb 2, 2015 at 4:50 PM, Michael Barton 
> mailto:michael.bar...@asu.edu>>
> wrote:
>>
>> Unfortunately the screenshots are too low resolution for me to read them
>> here. So I might miss something that is on the screenshot.
>
>
> It's just about layout, don't worry about text. I can of course send full
> size if somebody wants.

Please post at least double size...

I posted 25%, now posting 50% which is not significantly smaller then 100% even 
after optipng, so I can post just one image at a time.

Here is what you see when you start 64 for the first time and when you start 
current trunk for the first time.

thanks
Markus

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

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

On Mon, Feb 2, 2015 at 4:59 PM, Vaclav Petras  wrote:

> On Mon, Feb 2, 2015 at 4:39 PM, Markus Neteler  wrote:
>
>> On Mon, Feb 2, 2015 at 9:01 PM, Markus Metz
>>  wrote:
>> > On Mon, Feb 2, 2015 at 8:01 PM, Vaclav Petras 
>> wrote:
>> >> More improvements for startup window in r64405.
>>
>> Please let's not welcome a (new) user with a warning... looks scary.
>
>
> I though that warning is better then error dialog which was there from
> very beginning of wxGUI. See comparison in the attachment. Note also that
> after pressing OK you got the browse dialog. I'm afraid I'm not able to
> deliver something better before the release, at least not RC2.
>

Would replacing the word "Warning" with "Hint", or nothing solve the issue
for you? Or changing the color? (Supposing that we don't have a mechanism
to create a dir automatically and we want to provide info to the user.)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

2015-02-02 Thread Markus Neteler

On Mon, Feb 2, 2015 at 11:02 PM, Vaclav Petras  wrote:
>
> On Mon, Feb 2, 2015 at 4:50 PM, Michael Barton 
> wrote:
>>
>> Unfortunately the screenshots are too low resolution for me to read them
>> here. So I might miss something that is on the screenshot.
>
>
> It's just about layout, don't worry about text. I can of course send full
> size if somebody wants.

Please post at least double size...

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

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

On Mon, Feb 2, 2015 at 4:50 PM, Michael Barton 
wrote:

> Unfortunately the screenshots are too low resolution for me to read them
> here. So I might miss something that is on the screenshot.

It's just about layout, don't worry about text. I can of course send full
size if somebody wants.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

On Mon, Feb 2, 2015 at 4:39 PM, Markus Neteler  wrote:

> On Mon, Feb 2, 2015 at 9:01 PM, Markus Metz
>  wrote:
> > On Mon, Feb 2, 2015 at 8:01 PM, Vaclav Petras 
> wrote:
> >> More improvements for startup window in r64405.
>
> Please let's not welcome a (new) user with a warning... looks scary.

I though that warning is better then error dialog which was there from very
beginning of wxGUI. See comparison in the attachment. Note also that after
pressing OK you got the browse dialog. I'm afraid I'm not able to deliver
something better before the release, at least not RC2.

If a grassdata dir and some location would be automatically created (copied
demo location), it should not show anything. Currently it is just using
whatever was there which apparently suffers from some mess in (between)
grass.py and gis_set.py which is creating some rc file but not good enough
and it is not checking if something is actually in the guessed gisdbase.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

2015-02-02 Thread Anna Petrášová

On Mon, Feb 2, 2015 at 3:01 PM, Markus Metz 
wrote:

> On Mon, Feb 2, 2015 at 8:01 PM, Vaclav Petras 
> wrote:
> > More improvements for startup window in r64405.
> >
> > Most notably you don't get error message when starting GRASS for the
> first
> > time without a rc file. After clicking OK, you would get a browse window.
> > Now you just get a warning text in the middle of the window and it is up
> to
> > you to read it and press the button. In my opinion, much less annoying
> > behavior.
> >
> > The descriptions are now in gray. This is system color, so it should work
> > with different themes. (This is not true for the things like warning
> text or
> > grayed out Mapsets)
> >
> > I changed the descriptions a little bit but it needs more care. Anybody
> can
> > change it now but perhaps we should try to discuss them without
> diverging to
> > how to do startup procedure differently. Also there is more strings, some
> > messages, they might need some revision too. E.g. should there be
> numbers in
> > the box titles? And what about the error messages?
> >
> > The windows issues are just partially fixed. It seems that wxPython is
> not
> > determining the wrapping properly. The widgets have the same boundaries
> in
> > widget inspector on MS Windows and on Linux. Just the text is wrapped
> > differently.
> >
> > The vertical size is bigger then it was before (you can compare at an
> image
> > posted earlier [2]). It will get smaller by using smaller banner image.
> > However, longer descriptions and the error/warning text are making it
> > bigger. Now the behavior of error/warning text is that it does not occupy
> > any space unless something is shown. Hopefully it will work on all
> platforms
> > (seems to work well on Linux and MS Windows). In theory, the window
> could be
> > re-sized by user to be smaller (if screen is small) but I'm not able to
> make
> > Location and Mapset lists to allow it. If I set minimal size, then they
> > actually use it from the beginning and I get unnecessary small lists. We
> > could get some vertical space by growing wider but then the Location and
> > Mapset lists are unnecessary wide.
> >
>
> For newcomers/no rc file: how about creating a new GRASS GIS database
> in $HOME, in there a new location with EPSG:4326 (latlong wgs84), the
> empty PERMANENT mapset will be created automatically. Does not apply
> to MS Windows, because the demolocation is created during
> installation.
>
>
I agree, we were suggesting this too.

Why not having a minimal welcome screen with a dropdown list for
> existing locations and a dropdown list for existing mapsets in the
> selected location, plus a prominent OK button and a change/manage
> button, nothing else?
>
> It's the difference between
>
> "You need to fill in this form first, and fix the errors in the form,
> after that you may enter GRASS GIS"
>

User wouldn't need to fill the form in case there is the wgs84 location
before starting grass. In case of errors, how would minimal welcome screen
help?


>
> and
>
> "Welcome! Just press OK to enter GRASS GIS"
>

It seems to me that the current list is easier to navigate than if the
locations and mapset would be in combo box. I often click on different
locations in the list to see the mapsets, that would be more difficult with
the combo boxes. Your suggestion is probably useful for new users, but is
convenient for normal users? Should we implement both and let people switch
it? I would try to avoid two solutions.

Should we somehow vote about this? We probably need to put all these
(detailed) suggestions on trac.

Anna




> Markus M
>
> > Vaclav
> >
> > [1] http://trac.osgeo.org/grass/changeset/64405
> > [2]
> >
> http://lists.osgeo.org/pipermail/grass-dev/attachments/20150121/62aad5af/attachment-0001.png
> >
> http://osgeo-org.1560.x6.nabble.com/attachment/5183019/1/startup_with_explanations.png
> >
> > ___
> > 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
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

2015-02-02 Thread Michael Barton


__

On Feb 2, 2015, at 2:31 PM, Vaclav Petras 
mailto:wenzesl...@gmail.com>> wrote:


On Mon, Feb 2, 2015 at 2:09 PM, Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:
To make this more compact, there is still extraneous information not needed 
below the location and mapset windows.

I don't think we have a consensus of what is the information needed. Shortest 
is no info but that's not ideal neither. Perhaps we should use word database 
rather then directory as a primary term, so users actually realize that it is 
something special.

gisdbase = database
location = 'subdatabase' (it also seems like a database)
mapset = namespace

I think that the right information is currently in the directions. But if we 
want to make it shorter, there are some things that could be removed with no 
loss. A Location could be used for a project but also might not. So that 
sentence could be left out, for example.


Also, error messages should be in popup error windows, not displayed on the 
main dialog.

We are trying to do the start of GRASS more friendly. As I already described, 
in 6.4 (and old 7) if you start GRASS and
1) the gisdbase is empty or
2) the gisdbase does not exist (after moving the grassdata dir or *during* 
manual editing of the field) or
3) you are starting GRASS for the first time (i.e. you had no rc file, try with 
mv ~/.grass7/rc ~/.grass7/rc.backup)
you get an error dialog. These are the states which beginner is likely to get. 
Popping up error dialogs are really unfriendly and warm welcome in command line 
with recommendation to get a "current catalog of available computer maps" will 
not really fix it. Moreover, the error dialogs are annoying for an advanced 
user too when all one needs to do it just to change one value.

These error messages as a part of the window is a modern/current technique how 
to deal with different errors and warnings which would soon overwhelm user. 
Another advantage is that user can read the error message again and again until 
the problem is solved. The need to press OK in error dialog is just extra step 
which you have to do and the result is that everybody is just pressing OK 
without reading the message and then the user doesn't know what was the problem.

1) and 2) were already fixed in r57549. 3) fixed in r64405 was a bit special 
because after pressing OK, you got browse dialog for gisdbase without knowing 
what it is and what is the relation with the other things (loc, mapset, data).

If there is no error message, the vertical space is used by Location and Mapset 
lists. (Before one line was still there but the error message had to be one 
line too).

The example message is great. You can specify what message is displayed in a 
popup, just like specifying it on the main screen. The only difference is that 
it does not take up space on the main dialog—especially if there are no errors. 
I don’t see a popup error message as being any less friendly than red text on 
the main dialog. But maybe others do.

Also, I’ve never had a problem with the size of the startup dialog. But you and 
others have mentioned it. So I’m trying to thing of ways to streamline it.



We need long enough descriptions and we need the error messages. If there is 
something extra, it is the banner and a little bit of Location and Mapset lists 
which are now higher than before (even with an error message). Look at the 
attached image and tell me if I should make the Location and Mapset smaller (I 
hope it will be possible do implement).

Unfortunately the screenshots are too low resolution for me to read them here. 
So I might miss something that is on the screenshot.

Michael


http://trac.osgeo.org/grass/changeset/57549/grass/trunk/gui/wxpython/gis_set.py
http://trac.osgeo.org/grass/changeset/64405/grass/trunk/gui/wxpython/gis_set.py


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

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

2015-02-02 Thread Markus Neteler

(now back from https://fosdem.org/2015/schedule/track/geospatial/ -
digging through the emails)

On Mon, Feb 2, 2015 at 9:01 PM, Markus Metz
 wrote:
> On Mon, Feb 2, 2015 at 8:01 PM, Vaclav Petras  wrote:
>> More improvements for startup window in r64405.

Please let's not welcome a (new) user with a warning... looks scary.

> For newcomers/no rc file: how about creating a new GRASS GIS database
> in $HOME,

+1

> in there a new location with EPSG:4326 (latlong wgs84), the
> empty PERMANENT mapset will be created automatically. Does not apply
> to MS Windows, because the demolocation is created during
> installation.

In theory the demolocation could be everywhere since it is part of the
source code and even contains a world map.

> Why not having a minimal welcome screen with a dropdown list for
> existing locations and a dropdown list for existing mapsets in the
> selected location, plus a prominent OK button and a change/manage
> button, nothing else?

+1
At FOSDEM, we discussed this issue and most discussion participants
thought exactly in this direction.

> It's the difference between
>
> "You need to fill in this form first, and fix the errors in the form,
> after that you may enter GRASS GIS"
>
> and
>
> "Welcome! Just press OK to enter GRASS GIS"

Yes, the latters reads way more inviting

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

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

On Mon, Feb 2, 2015 at 2:09 PM, Michael Barton 
wrote:

> To make this more compact, there is still extraneous information not
> needed below the location and mapset windows.

I don't think we have a consensus of what is the information needed.
Shortest is no info but that's not ideal neither. Perhaps we should use
word database rather then directory as a primary term, so users actually
realize that it is something special.

gisdbase = database
location = 'subdatabase' (it also seems like a database)
mapset = namespace

Also, error messages should be in popup error windows, not displayed on the
> main dialog.

We are trying to do the start of GRASS more friendly. As I already
described, in 6.4 (and old 7) if you start GRASS and
1) the gisdbase is empty or
2) the gisdbase does not exist (after moving the grassdata dir or *during*
manual editing of the field) or
3) you are starting GRASS for the first time (i.e. you had no rc file, try
with mv ~/.grass7/rc ~/.grass7/rc.backup)
you get an error dialog. These are the states which beginner is likely to
get. Popping up error dialogs are really unfriendly and warm welcome in
command line with recommendation to get a "current catalog of available
computer maps" will not really fix it. Moreover, the error dialogs are
annoying for an advanced user too when all one needs to do it just to
change one value.

These error messages as a part of the window is a modern/current technique
how to deal with different errors and warnings which would soon overwhelm
user. Another advantage is that user can read the error message again and
again until the problem is solved. The need to press OK in error dialog is
just extra step which you have to do and the result is that everybody is
just pressing OK without reading the message and then the user doesn't know
what was the problem.

1) and 2) were already fixed in r57549. 3) fixed in r64405 was a bit
special because after pressing OK, you got browse dialog for gisdbase
without knowing what it is and what is the relation with the other things
(loc, mapset, data).

If there is no error message, the vertical space is used by Location and
Mapset lists. (Before one line was still there but the error message had to
be one line too).

We need long enough descriptions and we need the error messages. If there
is something extra, it is the banner and a little bit of Location and
Mapset lists which are now higher than before (even with an error message).
Look at the attached image and tell me if I should make the Location and
Mapset smaller (I hope it will be possible do implement).

http://trac.osgeo.org/grass/changeset/57549/grass/trunk/gui/wxpython/gis_set.py
http://trac.osgeo.org/grass/changeset/64405/grass/trunk/gui/wxpython/gis_set.py
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

2015-02-02 Thread Markus Metz

On Mon, Feb 2, 2015 at 8:01 PM, Vaclav Petras  wrote:
> More improvements for startup window in r64405.
>
> Most notably you don't get error message when starting GRASS for the first
> time without a rc file. After clicking OK, you would get a browse window.
> Now you just get a warning text in the middle of the window and it is up to
> you to read it and press the button. In my opinion, much less annoying
> behavior.
>
> The descriptions are now in gray. This is system color, so it should work
> with different themes. (This is not true for the things like warning text or
> grayed out Mapsets)
>
> I changed the descriptions a little bit but it needs more care. Anybody can
> change it now but perhaps we should try to discuss them without diverging to
> how to do startup procedure differently. Also there is more strings, some
> messages, they might need some revision too. E.g. should there be numbers in
> the box titles? And what about the error messages?
>
> The windows issues are just partially fixed. It seems that wxPython is not
> determining the wrapping properly. The widgets have the same boundaries in
> widget inspector on MS Windows and on Linux. Just the text is wrapped
> differently.
>
> The vertical size is bigger then it was before (you can compare at an image
> posted earlier [2]). It will get smaller by using smaller banner image.
> However, longer descriptions and the error/warning text are making it
> bigger. Now the behavior of error/warning text is that it does not occupy
> any space unless something is shown. Hopefully it will work on all platforms
> (seems to work well on Linux and MS Windows). In theory, the window could be
> re-sized by user to be smaller (if screen is small) but I'm not able to make
> Location and Mapset lists to allow it. If I set minimal size, then they
> actually use it from the beginning and I get unnecessary small lists. We
> could get some vertical space by growing wider but then the Location and
> Mapset lists are unnecessary wide.
>

For newcomers/no rc file: how about creating a new GRASS GIS database
in $HOME, in there a new location with EPSG:4326 (latlong wgs84), the
empty PERMANENT mapset will be created automatically. Does not apply
to MS Windows, because the demolocation is created during
installation.

Why not having a minimal welcome screen with a dropdown list for
existing locations and a dropdown list for existing mapsets in the
selected location, plus a prominent OK button and a change/manage
button, nothing else?

It's the difference between

"You need to fill in this form first, and fix the errors in the form,
after that you may enter GRASS GIS"

and

"Welcome! Just press OK to enter GRASS GIS"

Markus M

> Vaclav
>
> [1] http://trac.osgeo.org/grass/changeset/64405
> [2]
> http://lists.osgeo.org/pipermail/grass-dev/attachments/20150121/62aad5af/attachment-0001.png
> http://osgeo-org.1560.x6.nabble.com/attachment/5183019/1/startup_with_explanations.png
>
> ___
> 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] Making start of GRASS GIS easier for newcomers

2015-02-02 Thread Michael Barton

To make this more compact, there is still extraneous information not needed
below the location and mapset windows. Also, error messages should be in popup
error windows, not displayed on the main dialog.

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
Tempe, AZ 85287-2402
USA

voice: 480-965-6262 (SHESC), 480-965-8130/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 Feb 2, 2015, at 12:01 PM, Vaclav Petras
mailto:wenzesl...@gmail.com>> wrote:

More improvements for startup window in r64405.

Most notably you don't get error message when starting GRASS for the first time
without a rc file. After clicking OK, you would get a browse window. Now you
just get a warning text in the middle of the window and it is up to you to read
it and press the button. In my opinion, much less annoying behavior.

The descriptions are now in gray. This is system color, so it should work with
different themes. (This is not true for the things like warning text or grayed
out Mapsets)

I changed the descriptions a little bit but it needs more care. Anybody can
change it now but perhaps we should try to discuss them without diverging to
how to do startup procedure differently. Also there is more strings, some
messages, they might need some revision too. E.g. should there be numbers in
the box titles? And what about the error messages?

The windows issues are just partially fixed. It seems that wxPython is not
determining the wrapping properly. The widgets have the same boundaries in
widget inspector on MS Windows and on Linux. Just the text is wrapped
differently.

The vertical size is bigger then it was before (you can compare at an image
posted earlier [2]). It will get smaller by using smaller banner image.
However, longer descriptions and the error/warning text are making it bigger.
Now the behavior of error/warning text is that it does not occupy any space
unless something is shown. Hopefully it will work on all platforms (seems to
work well on Linux and MS Windows). In theory, the window could be re-sized by
user to be smaller (if screen is small) but I'm not able to make Location and
Mapset lists to allow it. If I set minimal size, then they actually use it from
the beginning and I get unnecessary small lists. We could get some vertical
space by growing wider but then the Location and Mapset lists are unnecessary
wide.

Vaclav

[1] http://trac.osgeo.org/grass/changeset/64405
[2]
http://lists.osgeo.org/pipermail/grass-dev/attachments/20150121/62aad5af/attachment-0001.png

http://osgeo-org.1560.x6.nabble.com/attachment/5183019/1/startup_with_explanations.png

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

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

More improvements for startup window in r64405.

Most notably you don't get error message when starting GRASS for the first
time without a rc file. After clicking OK, you would get a browse window.
Now you just get a warning text in the middle of the window and it is up to
you to read it and press the button. In my opinion, much less annoying
behavior.

The descriptions are now in gray. This is system color, so it should work
with different themes. (This is not true for the things like warning text
or grayed out Mapsets)

I changed the descriptions a little bit but it needs more care. Anybody can
change it now but perhaps we should try to discuss them without diverging
to how to do startup procedure differently. Also there is more strings,
some messages, they might need some revision too. E.g. should there be
numbers in the box titles? And what about the error messages?

The vertical size is bigger then it was before (you can compare at an image
posted earlier [2]). It will get smaller by using smaller banner image.
However, longer descriptions and the error/warning text are making it
bigger. Now the behavior of error/warning text is that it does not occupy
any space unless something is shown. Hopefully it will work on all
platforms (seems to work well on Linux and MS Windows). In theory, the
window could be re-sized by user to be smaller (if screen is small) but I'm
not able to make Location and Mapset lists to allow it. If I set minimal
size, then they actually use it from the beginning and I get unnecessary
small lists. We could get some vertical space by growing wider but then the
Location and Mapset lists are unnecessary wide.

Vaclav

[1] http://trac.osgeo.org/grass/changeset/64405
[2]
http://lists.osgeo.org/pipermail/grass-dev/attachments/20150121/62aad5af/attachment-0001.png
http://osgeo-org.1560.x6.nabble.com/attachment/5183019/1/startup_with_explanations.png
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Compute mahalanobis distance using Scipy


Paulo van Breugel wrote:

> > The second version:
> >
> > > > VI = np.linalg.inv(covar)
> > > > delta = dat_ref - stat_mean[:,None,None]
> > > > m = np.sum(np.sum(delta[:,:,:,None] * delta[:,:,None,:] * 
> > > > VI[None,None,:,:],axis=-1),axis=-1)
> > > > stat_mah = np.sqrt(m)
> >
> > should work with delta being a 3-D array.
> >
> 
> Yes, but when running the lines above, I am getting the same error message:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
> ValueError: operands could not be broadcast together with shapes
> (3,77,78,78) (1,1,3,3)

Well, it's not quite the same; both operands now have the same number
of dimensions, but they're not compatible (essentially, for each
dimension either both values should be the same or one of them should
be one).

> >From what I can see from broadcasting rules, there is mismatch in the last
> and fore-last dimensions of VI[None,None,:,:] compared to the other two?
> 
> delta[:,:,:,None].shape
> (3, 77, 78, 1)
> 
> delta[:,:,None,:].shape
> (3, 77, 1, 78)
> 
> VI[None,None,:,:].shape
> (1, 1, 3, 3)

The problem was that delta is 3x77x78 whereas the code assumed that it
would be 77x78x3.

> I am really have to get a better grasp of working with these arrays, but in
> any case, after a bit trial and error, I came up with the following to
> compute m.
> 
>  m = np.sum(np.sum(delta[None,:,:,:] * VI[:,:,None,None],axis=1) * delta,
> axis=0)
> 
> 
> This does, in my limited testing, gives the same result as using the loop
> with
> 
> pow(distance.mahalanobis(cell_ref, stat_mean, VI),2).
> 
> 
> to be sure, does the above makes sense to you?

I believe that's correct.

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

Re: [GRASS-dev] New wiki page summarising GRASS APIs

Moritz Lennert wrote:

> >> For now, I've added a warning that you should know what you are doing if
> >> you want to use these calls.
> >
> > Why not just use suitable examples, e.g. using subprocess.Popen()
> > (without shell=True), with the caveat that on Windows it won't work
> > for scripts, only compiled executables.
> 
> But what exactly is the problem with using subprocess.call with 
> shell=True ?

It requires you to construct the correct string. If the command string
is a single literal string with all argument values consisting of
alphanumerics plus "safe" punctuation (i.e. characters which have no
meaning to any shell), that's simple enough.

But if any of the arguments are variable and *could* contain
characters which are meaningful to a shell, constructing the correct
string (the one which results in the called program's argv[] having
the intended values) isn't straightforward (and the exact rules vary
between platforms).

It's much simpler (and safer) to just remove the shell from equation
altogether and pass the individual arguments directly, rather than
trying to construct a string which, when deconstructed by the shell,
will produce the correct result.

> Security issues ? Difficulties in calling shell scripts ?

Security would be a problem, but if you're dealing with potentially
malicious input, it's the least of your problems compared to the rest
of GRASS. Calling scripts on Windows is a different problem (setting
shell=True "solves" one problem while introducing more).

> AFAICT, it's just a wrapper around Popen.wait(), or ?

subprocess.call() is a wrapper() around Popen() and Popen.wait(). 
Exactly the same issue applies to Popen() itself (it applies to
.call() *because* it applies to Popen() itself).

> I've now replaced this with:
> 
>   subprocess.Popen(['r.watershed', 'elevation=elevation', 
> 'threshold=1', 'stream=raster_streams'])
> 
> or would it be better with .wait():
> 
>   import subprocess
>   subprocess.Popen(['r.watershed', 'elevation=elevation', 
> 'threshold=1', 'stream=raster_streams']).wait()

subprocess.call() is fine. It's using shell=True which is the problem.

For simple examples, I'd suggest using subprocess.call, and referring
them to the python.org documentation for the (2.x) subprocess module
for anything else.

> And even though within GRASS Python it should always be Popen(), maybe 
> there are situations out there where calling a module via call() is 
> justifiable...

Well, depending upon what you mean by "GRASS Python", it should
arguably be grass.script.run_command() or similar.

Even if the wiki page isn't the right place to introduce that, it's
probably worth mentioning that it exists before users end up
recreating the wheel (e.g. if they care about being able to run both
executables and script and doing so on both Unix/MacOSX and Windows,
they'll end up having to learn the same lessons we have).

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

[GRASS-dev] 8th Bolsena Hacking Event open for registration! - May 31 to June 6 2015

2015-02-02 Thread Jeroen Ticheler

Dear all,

I'm proud to invite you for the eight Bolsena Hacking Event this year from 31 
May to 6 June 2015. 

The code sprint focusses collaboration between open source software developers. 
People can share experiences and come up with creative new ideas and 
collaborations. The week allows developers to actively work together and get 
their hands dirty coding great new stuff.

You are welcome to sign up and join the group. There is limited space (25 beds 
with only 13 beds remaining) so please book your place as soon as possible to 
guarantee your place. Full boarding for the week, including food, is 550 Euro 
(excl VAT) per person, the same as last years.

Sign up and read more at: Bolsena Hacking Event 2015 ( 
http://wiki.osgeo.org/wiki/Bolsena_Code_Sprint_2015 
 )

Hope to see a good crowd again this year! 

Ciao,
Jeroen


GeoCat introduces Bridge© 
An extension to ArcGIS© to instantly publish data and metadata on GeoServer and 
GeoNetwork.
See http://geocat.net  for more details. 

Jeroen Ticheler
GeoCat bv
Veenderweg 13
6721 WD Bennekom
The Netherlands
Tel: +31 (0)6 81286572
http://geocat.net 
 
 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Compute mahalanobis distance using Scipy

2015-02-02 Thread Paulo van Breugel

On Mon, Feb 2, 2015 at 3:40 PM, Paulo van Breugel 
wrote:

>
>
> On Mon, Feb 2, 2015 at 1:38 PM, Glynn Clements 
> wrote:
>
>>
>> Paulo van Breugel wrote:
>>
>> > > The main speed-up will come from "inlining" distance.mahalanobis(),
>> > > which is essentially:
>> > >
>> > > delta = u - v
>> > > m = np.dot(np.dot(delta, VI), delta)
>> > > return np.sqrt(m)
>> > >
>> > > np.dot(v, m) is equivalent to np.sum(v * m,axis=0), and np.dot(u,v) is
>> > > equivalent to np.sum(u * v), so the second line above is equivalent to
>> > >
>> > > m = np.sum(np.sum(delta[:,None] * VI * delta[None,:], axis=-1),
>> > > axis=-1)
>> >
>> >
>> > Smart! I can follow the logic, but I am not sure how to solve the
>> problem
>> > below:
>> >
>> >Traceback (most recent call last):
>> > File "", line 1, in 
>> > ValueError: operands could not be broadcast together with shapes
>> > (3,1,77,78) (3,3)
>> >
>> > Which refers to the different dimensions of delta and VI?
>>
>> The first version of the code (which is quoted above) will only work
>> with 1-D arrays. It's just a fairly direct translation of the existing
>> distance.mahalanobis() function, given to explain how it can then be
>> extened to 3-D arrays (i.e. a 2-D array of 1-D vectors).
>>
>> The second version:
>>
>> > > VI = np.linalg.inv(covar)
>> > > delta = dat_ref - stat_mean[:,None,None]
>> > > m = np.sum(np.sum(delta[:,:,:,None] * delta[:,:,None,:] *
>> VI[None,None,:,:],axis=-1),axis=-1)
>> > > stat_mah = np.sqrt(m)
>>
>> should work with delta being a 3-D array.
>>
>
>
> Yes, but when running the lines above, I am getting the same error message:
>
> Traceback (most recent call last):
>   File "", line 1, in 
> ValueError: operands could not be broadcast together with shapes
> (3,77,78,78) (1,1,3,3)
>
> From what I can see from broadcasting rules, there is mismatch in the last
> and fore-last dimensions of VI[None,None,:,:] compared to the other two?
>
> delta[:,:,:,None].shape
> (3, 77, 78, 1)
>
> delta[:,:,None,:].shape
> (3, 77, 1, 78)
>
> VI[None,None,:,:].shape
> (1, 1, 3, 3)
>
> I am really have to get a better grasp of working with these arrays, but
> in any case, after a bit trial and error, I came up with the following to
> compute m.
>
>  m = np.sum(np.sum(delta[None,:,:,:] * VI[:,:,None,None],axis=1) * delta,
> axis=0)
>
>
> This does, in my limited testing, gives the same result as using the loop
> with
>
> pow(distance.mahalanobis(cell_ref, stat_mean, VI),2).
>
>
> to be sure, does the above makes sense to you?
>


About the speed up.. that is indeed rather significant. With three layers
as input (cells: 1122582) my original function took 30 seconds, the one
above 0.23 seconds. Not bad :-)



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

Re: [GRASS-dev] [GRASS GIS] #2575: i.segment threshold error message should be updated

#2575: i.segment threshold error message should be updated
--+-
  Reporter:  madi |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  7.1.0
 Component:  Imagery  | Version:  svn-trunk
Resolution:  fixed|Keywords:  i.segment
  Platform:  All  | Cpu:  Unspecified  
--+-
Changes (by Madi):

  * status:  new => closed
  * resolution:  => fixed


-- 
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] #2574: r.surf.icw - not working with the last version of grass7

#2574: r.surf.icw - not working with the last version of grass7
-+--
 Reporter:  bhlevca  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Default  | Version:  svn-trunk
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by annakrat):

 I just fixed the g.remove calls in r64399.

-- 
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] #2574: r.surf.icw - not working with the last version of grass7

#2574: r.surf.icw - not working with the last version of grass7
-+--
 Reporter:  bhlevca  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Default  | Version:  svn-trunk
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by bhlevca):

 I found the problem I had a dangling raster map  named MASK that was
 screwing up.

 I deleted that and now it works properly.

 I am attaching my version and hopefully someone with access will update
 svn

 Thanks

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #2575: i.segment threshold error message should be updated

#2575: i.segment threshold error message should be updated
-+--
 Reporter:  madi |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Imagery  | Version:  svn-trunk
 Keywords:  i.segment|Platform:  All  
  Cpu:  Unspecified  |  
-+--
 i.segment group=small output=small_seg threshold=1
 (as well as threshold=0)

 yelds:

 ERROR: Threshold should be >= 0 and <= 1

 Since threshold=1 and threshold=0 are not accepted as valid options, the
 error message should be:

 ERROR: Threshold should be > 0 and < 1

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Compute mahalanobis distance using Scipy

2015-02-02 Thread Paulo van Breugel

On Mon, Feb 2, 2015 at 1:38 PM, Glynn Clements 
wrote:

>
> Paulo van Breugel wrote:
>
> > > The main speed-up will come from "inlining" distance.mahalanobis(),
> > > which is essentially:
> > >
> > > delta = u - v
> > > m = np.dot(np.dot(delta, VI), delta)
> > > return np.sqrt(m)
> > >
> > > np.dot(v, m) is equivalent to np.sum(v * m,axis=0), and np.dot(u,v) is
> > > equivalent to np.sum(u * v), so the second line above is equivalent to
> > >
> > > m = np.sum(np.sum(delta[:,None] * VI * delta[None,:], axis=-1),
> > > axis=-1)
> >
> >
> > Smart! I can follow the logic, but I am not sure how to solve the problem
> > below:
> >
> >Traceback (most recent call last):
> > File "", line 1, in 
> > ValueError: operands could not be broadcast together with shapes
> > (3,1,77,78) (3,3)
> >
> > Which refers to the different dimensions of delta and VI?
>
> The first version of the code (which is quoted above) will only work
> with 1-D arrays. It's just a fairly direct translation of the existing
> distance.mahalanobis() function, given to explain how it can then be
> extened to 3-D arrays (i.e. a 2-D array of 1-D vectors).
>
> The second version:
>
> > > VI = np.linalg.inv(covar)
> > > delta = dat_ref - stat_mean[:,None,None]
> > > m = np.sum(np.sum(delta[:,:,:,None] * delta[:,:,None,:] *
> VI[None,None,:,:],axis=-1),axis=-1)
> > > stat_mah = np.sqrt(m)
>
> should work with delta being a 3-D array.
>


Yes, but when running the lines above, I am getting the same error message:

Traceback (most recent call last):
  File "", line 1, in 
ValueError: operands could not be broadcast together with shapes
(3,77,78,78) (1,1,3,3)

>From what I can see from broadcasting rules, there is mismatch in the last
and fore-last dimensions of VI[None,None,:,:] compared to the other two?

delta[:,:,:,None].shape
(3, 77, 78, 1)

delta[:,:,None,:].shape
(3, 77, 1, 78)

VI[None,None,:,:].shape
(1, 1, 3, 3)

I am really have to get a better grasp of working with these arrays, but in
any case, after a bit trial and error, I came up with the following to
compute m.

 m = np.sum(np.sum(delta[None,:,:,:] * VI[:,:,None,None],axis=1) * delta,
axis=0)


This does, in my limited testing, gives the same result as using the loop
with

pow(distance.mahalanobis(cell_ref, stat_mean, VI),2).


to be sure, does the above makes sense to you?


Paulo










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

Re: [GRASS-dev] New wiki page summarising GRASS APIs


On 02/02/15 13:48, Glynn Clements wrote:


Moritz Lennert wrote:


For now, I've added a warning that you should know what you are doing if
you want to use these calls.


Why not just use suitable examples, e.g. using subprocess.Popen()
(without shell=True), with the caveat that on Windows it won't work
for scripts, only compiled executables.


But what exactly is the problem with using subprocess.call with 
shell=True ? Security issues ? Difficulties in calling shell scripts ?


AFAICT, it's just a wrapper around Popen.wait(), or ?

I've now replaced this with:

 subprocess.Popen(['r.watershed', 'elevation=elevation', 
'threshold=1', 'stream=raster_streams'])


or would it be better with .wait():

 import subprocess
 subprocess.Popen(['r.watershed', 'elevation=elevation', 
'threshold=1', 'stream=raster_streams']).wait()


?

I guess this depends on what the programmer wants...



For C, it's somewhat harder, as there isn't a mechanism for executing
commands which is standard, simple, reliable and portable. GRASS'
G_spawn* functions mostly have the last 3 (other than not working for
scripts on Windows). fork()+exec*() isn't portable or particularly
simple, but is at least standard on POSIX systems. Windows doesn't
really have anything in that regard (you have to do the quoting
yourself, and the rules differ for executables and scripts).


I think that's why I don't think that we should fret too much about the 
specfic examples here. The main argument in the whole section is that it 
is possible to consider GRASS modules as an "API" in its own right of 
which you can call the "functions" (aka modules) from any programming 
language via system calls. The exact syntax of these calls are beyond 
the scope of the document.


And even though within GRASS Python it should always be Popen(), maybe 
there are situations out there where calling a module via call() is 
justifiable...


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

Re: [GRASS-dev] New wiki page summarising GRASS APIs

Moritz Lennert wrote:

> For now, I've added a warning that you should know what you are doing if 
> you want to use these calls.

Why not just use suitable examples, e.g. using subprocess.Popen()
(without shell=True), with the caveat that on Windows it won't work
for scripts, only compiled executables.

For C, it's somewhat harder, as there isn't a mechanism for executing
commands which is standard, simple, reliable and portable. GRASS'
G_spawn* functions mostly have the last 3 (other than not working for
scripts on Windows). fork()+exec*() isn't portable or particularly
simple, but is at least standard on POSIX systems. Windows doesn't
really have anything in that regard (you have to do the quoting
yourself, and the rules differ for executables and scripts).

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

Re: [GRASS-dev] Compute mahalanobis distance using Scipy


Paulo van Breugel wrote:

> > The main speed-up will come from "inlining" distance.mahalanobis(),
> > which is essentially:
> >
> > delta = u - v
> > m = np.dot(np.dot(delta, VI), delta)
> > return np.sqrt(m)
> >
> > np.dot(v, m) is equivalent to np.sum(v * m,axis=0), and np.dot(u,v) is
> > equivalent to np.sum(u * v), so the second line above is equivalent to
> >
> > m = np.sum(np.sum(delta[:,None] * VI * delta[None,:], axis=-1),
> > axis=-1)
> 
> 
> Smart! I can follow the logic, but I am not sure how to solve the problem
> below:
> 
>Traceback (most recent call last):
> File "", line 1, in 
> ValueError: operands could not be broadcast together with shapes
> (3,1,77,78) (3,3)
> 
> Which refers to the different dimensions of delta and VI?

The first version of the code (which is quoted above) will only work
with 1-D arrays. It's just a fairly direct translation of the existing
distance.mahalanobis() function, given to explain how it can then be
extened to 3-D arrays (i.e. a 2-D array of 1-D vectors).

The second version:

> > VI = np.linalg.inv(covar)
> > delta = dat_ref - stat_mean[:,None,None]
> > m = np.sum(np.sum(delta[:,:,:,None] * delta[:,:,None,:] * 
> > VI[None,None,:,:],axis=-1),axis=-1)
> > stat_mah = np.sqrt(m)

should work with delta being a 3-D array.

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

Re: [GRASS-dev] automatically save/open workspace in the Mapset

2015-02-02 Thread Yann Chemin

sure, it is there Moritz.
I would find that a nice option to be able to enable in Preferences.

On 2 February 2015 at 14:43, Moritz Lennert 
wrote:

> On 02/02/15 10:09, Yann Chemin wrote:
>
>> Hi,
>>
>> just a thought, it would be practical to have last maps seen reopen by
>> having a default mapset being written before closing wxgui, and first
>> reopened (if exists) on launching the wxgui in the same mapset.
>>
>
> You know that you can just save your workspace and open that in order to
> see the same maps displayed as before ? IMHO, this is more than enough and
> having maps displayed automatically each time I open a mapset would be
> counter-productive.
>
> Moritz
>



-- 

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

Re: [GRASS-dev] automatically save/open workspace in the Mapset


On 02/02/15 10:09, Yann Chemin wrote:

Hi,

just a thought, it would be practical to have last maps seen reopen by
having a default mapset being written before closing wxgui, and first
reopened (if exists) on launching the wxgui in the same mapset.


You know that you can just save your workspace and open that in order to 
see the same maps displayed as before ? IMHO, this is more than enough 
and having maps displayed automatically each time I open a mapset would 
be counter-productive.


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

[GRASS-dev] automatically save/open workspace in the Mapset

2015-02-02 Thread Yann Chemin

Hi,

just a thought, it would be practical to have last maps seen reopen by
having a default mapset being written before closing wxgui, and first
reopened (if exists) on launching the wxgui in the same mapset.

Yann

-- 

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

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

2015-02-02 Thread Martin Landa

Hi,

2015-01-28 19:59 GMT+01:00 Vaclav Petras :
> Done in r64345.

btw, on Windows the welcome screen is now somehow bigger, location
desc is missing and mapset desc is wrapped too much, see [1].

Martin

[1] http://geo1.fsv.cvut.cz/landa/grass71.png

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New wiki page summarising GRASS APIs