Re: [GRASS-dev] GRASS and Anaconda

[Luca Delucchi]

Il gio 7 giu 2018, 20:58 Michael Barton  ha scritto:

> Along with helping me set up a new way to compile and package GRASS
> binaries for the Mac, Eric Hutton of the Community Surface Dynamics
> Modeling System (CSDMS – http//csdms.colorado.edu) has created a Conda
> recipe for building GRASS in the Anaconda environment. This is now deployed
> in the csdms stack at GitHub. Several versions of GRASS, for Linux and Mac
> are available. Details and instructions for building GRASS with Anaconda
> can be found at:
>
>
>
> https://github.com/csdms-stack/grass-recipe
>
>
>
> Many thanks to Eric and CSDMS
>
>
>
> Happy GRASSing!
>
> 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
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] GRASS and Anaconda

[Michael Barton]

No. These are not available for Anaconda, at least for Mac. I tried. You can 
get lastools, though and use them through the command line, including to change 
a laszip to ASCII for upload to GRASS using r.in.xyz.

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


From: Doug Newcomb 
Date: Thursday, June 7, 2018 at 12:03 PM
To: Michael Barton 
Cc: GRASS developers list , GRASS users 
, Eric Hutton 
Subject: Re: [EXTERNAL] [GRASS-dev] GRASS and Anaconda

Just glancing over the recipe, it does not look like liblas and laszip are 
included for LiDAR analysis.

Doug

On Thu, Jun 7, 2018 at 2:39 PM, Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:
Along with helping me set up a new way to compile and package GRASS binaries 
for the Mac, Eric Hutton of the Community Surface Dynamics Modeling System 
(CSDMS – 
http//csdms.colorado.edu)
 has created a Conda recipe for building GRASS in the Anaconda environment. 
This is now deployed in the csdms stack at GitHub. Several versions of GRASS, 
for Linux and Mac are available. Details and instructions for building GRASS 
with Anaconda can be found at:

https://github.com/csdms-stack/grass-recipe

Many thanks to Eric and CSDMS

Happy GRASSing!
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


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



--
Doug Newcomb
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

NOTE: This email correspondence and any attachments to and from this sender is 
subject to the Freedom of Information Act (FOIA) and may be disclosed to third 
parties.​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] [GRASS GIS] #3560: r.in.lidar: error to open valid LAZ file

[Newcomb, Doug]

On a related note, I tried compiling liblas1.8.1 ( current version)  on
Ubuntu 18.04 last night and I get a lot of errors out of the box that seem
to be related to compiler version.  Will need to set up a virtual 16.04 box
for the short term.

Doug

On Wed, May 9, 2018 at 4:14 PM, Newcomb, Doug  wrote:

>
>
> On Wed, May 9, 2018 at 4:02 PM, Markus Neteler  wrote:
>
>> On Wed, May 9, 2018 at 9:37 PM, Newcomb, Doug 
>> wrote:
>> > On Wed, May 9, 2018 at 3:21 PM, Markus Neteler 
>> wrote:
>> >>
>> >> Doug,
>> >>
>> >> On Wed, May 9, 2018 at 9:17 PM, Newcomb, Doug 
>> >> wrote:
>> >> > Markus,
>> >> > Liblas reads LAS version 1.2 , which is limited to 4.2 billion
>> points.
>> >>
>> >> I see. But "count" states 297.683.873 which is way less points?
>> >
>> > Good question
>> >
>> >> > You have to compile liblas with an older version of laszip .
>> >>
>> >> Uhm, why an _older_ version?
>> >
>> > The API to LASzip changed with version 3.   I use LASzip 2.2.0 compiled
>> with
>> > liblas from 2013 and have no problems so far.   https://laszip.org/
>> The most
>> > recent version of 3  was for version 1.4 of the LAS spec.
>> >
>> > You need to compile current pdal and current  liblas with different
>> versions
>> > of the Laszip library .
>>
>> On that machine is PDAL-1.7.0 (wit patches) which requires laszip 3.2.x.
>>
>> So, to compile liblas with an older laszip would be tricky.
>>
>
> On the machine I am using for this  , I have compiled the old laszip as
> the system laszip library and compile but do not install the newer one.  I
> then point pdal to the directory with the newer version when compiling it.
> So far, that seems to work.
>
>
>>
>> > pdal used to output version 1.2 of las data by default . I t worked
>> fine for
>> > me at version 1.6 . I have not checked if that is the case with version
>> > 1.7.1 .  1.7 had a bug which required a quick bugfix to 1.7.1, by the
>> way. (
>> > I do not recall the bug off of the top of my head.)
>>
>> The solution would be the implementation of r.in.pdal:
>> https://trac.osgeo.org/grass/ticket/3515
>
>
>>
>> to get rid of liblas which is not developed any more.
>
>
>> And/or package laz-perf sigh, so many hours already spent on
>> packaging...
>>
>> Markus
>>
>>
> Doug
>
> --
> Doug Newcomb
> USFWS
> 551F Pylon Dr
> Raleigh, NC
> 919-856-4520 ext. 14 doug_newc...@fws.gov
> 
> -
>
> *NOTE: This email correspondence and any attachments to and from this
> sender is subject to the Freedom of Information Act (FOIA) and may be
> disclosed to third parties.*​
>



-- 
Doug Newcomb
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] GRASS and Anaconda

[Newcomb, Doug]

Just glancing over the recipe, it does not look like liblas and laszip are
included for LiDAR analysis.

Doug

On Thu, Jun 7, 2018 at 2:39 PM, Michael Barton 
wrote:

> Along with helping me set up a new way to compile and package GRASS
> binaries for the Mac, Eric Hutton of the Community Surface Dynamics
> Modeling System (CSDMS – http//csdms.colorado.edu) has created a Conda
> recipe for building GRASS in the Anaconda environment. This is now deployed
> in the csdms stack at GitHub. Several versions of GRASS, for Linux and Mac
> are available. Details and instructions for building GRASS with Anaconda
> can be found at:
>
>
>
> https://github.com/csdms-stack/grass-recipe
>
>
>
> Many thanks to Eric and CSDMS
>
>
>
> Happy GRASSing!
>
> 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
>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Doug Newcomb
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS and Anaconda

[Michael Barton]

Along with helping me set up a new way to compile and package GRASS binaries 
for the Mac, Eric Hutton of the Community Surface Dynamics Modeling System 
(CSDMS – http//csdms.colorado.edu) has created a Conda recipe for building 
GRASS in the Anaconda environment. This is now deployed in the csdms stack at 
GitHub. Several versions of GRASS, for Linux and Mac are available. Details and 
instructions for building GRASS with Anaconda can be found at:

https://github.com/csdms-stack/grass-recipe

Many thanks to Eric and CSDMS

Happy GRASSing!
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

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

[GRASS-dev] [GRASS GIS] #3584: Remember recent mapsets

[GRASS GIS]

#3584: Remember recent mapsets
--+-
 Reporter:  wenzeslaus|  Owner:  grass-dev@…
 Type:  enhancement   | Status:  new
 Priority:  normal|  Milestone:  8.0.0
Component:  wxGUI |Version:  unspecified
 Keywords:  startup, welcome, recent, mapset  |CPU:  Unspecified
 Platform:  Unspecified   |
--+-
 GRASS GIS should store the recent mapsets and then offer them to the user.
 The recent mapsets list can be part of the ''Settings > GRASS working
 environment'' or the (new) startup.

 This is distinct from remembering recent workspaces (#2604) because
 mapsets are perhaps used more as they are. (All users need to start a
 session using mapsets rather workspace, at least until #3575 and #1204.)

 It is also distinct from remembering recent database (#572) because
 storing just the database (directory) does not give the desired quick
 access to the mapsets (to start a session) and because if we would just
 store recent mapsets they all can be from one database, so extracting
 database path from mapset path doesn't necessarily give the recent
 databases. In other words, last five mapsets can be all from one database,
 so that doesn't give us the last five databases.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3573: Save current working directory in wxGUI workspace and use it

[GRASS GIS]

#3573: Save current working directory in wxGUI workspace and use it
--+---
  Reporter:  wenzeslaus   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  8.0.0
 Component:  Startup  |Version:  unspecified
Resolution:   |   Keywords:  workspace, recent, startup, wxGUI
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by wenzeslaus):

 Replying to [comment:4 mlennert]:
 > Replying to [comment:2 wenzeslaus]:
 > > Replying to [comment:1 mlennert]:
 > > > I have to admin that I never even noticed that we had this option.
 > >
 > > Accessible from Setting or using cd command in the Console tab (you
 basically get some consistency between terminal and Console tab).
 >
 > I don't know what you mean by consistency, but when I cd in the console
 this (obviously) has no impact on the terminal pwd.

 Consistency in that the directory can be changed both for terminal and for
 the Console in GUI.

 > > > I find this a bit weird, first of all because I don't know what the
 "current working directory" actually means in GRASS GIS?
 > >
 > > It means just the same thing it means in the command line. Every
 program has current working directory (or whatever we want to call it).
 `cd` and `$PWD` or `pwd` in Linux command line, `os.getcwd()` and
 `os.chdir()` in Python.
 >
 > Yes, but here we have to be careful to be clear that when we say
 "program", we mean the GUI, not any GRASS module launched from anywhere.

 That's definitively something we could improve: putting it to a better
 place in menu, giving a better message when the change happens, ...

 > > > Does it have any other effect?
 > >
 > > You can put all your files for import and all color tables for one
 project into one directory (and perhaps subdirs) and then just cd there
 and you don't need to use full path just a relative one. I guess that's
 clear, but the point is that it applies for terminal as well as the GUI
 Console tab.
 >
 > I don't know what you mean by "it applies" ? How ? IIUC your ticket, you
 are pleading for that it should ? But this would only be for the situation
 where the pwd is stored in a workspace, or ?

 The functionality to change the directory is already in GUI, so the
 benefits of it apply to GUI Console as well as terminal (where is it
 natively).

 This ticket is just for the storing and loading from workspace.

 > >It is also advantageous when people are following commands in a list of
 instructions - you need to deal with specifying the path just once (and
 the exported files will be in the directory set at the beginning).
 >
 > But you have to be very careful to make sure that all commands are
 executed either only in the console/GUI or only in the terminal...

 I switch between them all the time, but I don't see beginners doing that.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Should a g.rename action be recorded in a map's history?

[Nikos Alexandris]

Dear developers,

would you consider as important a renaming of a map, such that it should
be recorded in its history?

After renaming,

- a vector map, it's likely possible to trace back its origin from its
 history (v.info -h)

- a raster map, that has been created with `r.mapcalc`, for example, there
is no way to tell where it comes from -- other than the command history
or guessing from the expression used that is recorded in its history.

If yes, should I file a ticket?

Thank you, Nikos


signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] r.series weights to zero

[Markus Metz]

On Tue, Jun 5, 2018 at 2:51 PM, Frank David  wrote:
>
> Hi all Grass users,
>
> It's seems that r.series weights does not accept zero as weight... Is it
possible ?

Yes, weights must be positive.

> and so, why ?

A zero weight means that all values in this map are ignored. Zero weights
can also cause the sum of weights to be zero, leading to division by zero
and finally to +inf / -inf as a result.

Markus M
>
> I've got the following error message when running r.series with one
weight set to 0
>
> "/usr/local/grass-7.4.0svn/etc/python/grass/script/core.py",
> line 332, in handle_errors
> returncode=returncode)
> grass.exceptions.CalledModuleError: Module run None
>
> Thank you for your comment.
>
> Frank
>
>
> ___
> grass-user mailing list
> grass-u...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3499: Backport of new ZSTD compression

[GRASS GIS]

#3499: Backport of new ZSTD compression
--+--
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.4.1
 Component:  LibRaster|Version:  unspecified
Resolution:   |   Keywords:  ZSTD compression
   CPU:  All  |   Platform:  All
--+--

Comment (by mmetz):

 Replying to [comment:4 Nikos Alexandris]:
 > Avoiding to open a new ticket, the
 https://grass.osgeo.org/grass75/manuals/variables.html#list-of-selected
 -(grass-related)-shell-environment-variables deserves an update. It does
 not mention anything about ZSTD.

 Thanks for the hint, done in trunk r72784. ZSTD is already mentioned in
 the G7:rasterintro and in the manual of G7:r.compress.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [release planning] 7.4.1

[Martin Landa]

Hi,

2018-06-06 18:46 GMT+02:00 Markus Neteler :
> Done in r72775 (release grass_7_4_1RC3) and source code uploaded.

* windows packages available (both standalone [1] and OSGeo4W Expr area).
* I have uploaded xenial package in ubuntugis expr repo [2], bionic
will be uploaded later since having problem described in [3].

Ma

[1] https://grass.osgeo.org/grass74/binary/mswindows/native/
[2] 
https://launchpad.net/~ubuntugis/+archive/ubuntu/ubuntugis-experimental/+packages?field.name_filter=grass&field.status_filter=published&field.series_filter=
[3] https://lists.osgeo.org/pipermail/ubuntu/2018-June/001733.html

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

Re: [GRASS-dev] [GRASS GIS] #3499: Backport of new ZSTD compression

[GRASS GIS]

#3499: Backport of new ZSTD compression
--+--
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.4.1
 Component:  LibRaster|Version:  unspecified
Resolution:   |   Keywords:  ZSTD compression
   CPU:  All  |   Platform:  All
--+--

Comment (by Nikos Alexandris):

 Avoiding to open a new ticket, the
 https://grass.osgeo.org/grass75/manuals/variables.html#list-of-selected
 -(grass-related)-shell-environment-variables deserves an update. It does
 not mention anything about ZSTD.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3583: g.search.modules to include addons

[GRASS GIS]

#3583: g.search.modules to include addons
--+-
 Reporter:  Nikos Alexandris  |  Owner:  grass-dev@…
 Type:  enhancement   | Status:  new
 Priority:  minor |  Milestone:
Component:  Default   |Version:  unspecified
 Keywords:|CPU:  Unspecified
 Platform:  Unspecified   |
--+-
 Currently, the search considers only the `module_items.xml` file
 
(https://trac.osgeo.org/grass/browser/grass/trunk/scripts/g.search.modules/g.search.modules.py#L197).

 Would it make sense for `g.search.modules` to search also for installed
 addons? Perhaps by including the `$GRASS_ADDON_BASE/modules.xml` or(/and?)
 `$GRASS_ADDON_PATH/modules.xml` file, in case this file exists.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3582: Removing a Mapset from inside a GRASS GIS session

[GRASS GIS]

#3582: Removing a Mapset from inside a GRASS GIS session
---+-
 Reporter:  Nikos Alexandris   |  Owner:  grass-dev@…
 Type:  enhancement| Status:  new
 Priority:  normal |  Milestone:
Component:  Default|Version:  unspecified
 Keywords:  mapset, remove, delete, erase  |CPU:  Unspecified
 Platform:  Unspecified|
---+-
 Would it possible to add a way to remove a Mapset, or multiple Mapsets,
 from the command line? For example, add a "remove" or "delete" or "erase"
 function to the existing `g.mapset` module.

 Points to consider:

 * This functionality should not be allowed, of course!, to request for a
 removal of the current Mapset. It should only allow for removal of
 other(s) than the current Mapset.

 * Only the owner of another, than the current, Mapset, or the "admin"
 (creator of PERMANENT?), will be able to remove it.

 * Following the existing way of removing "elements" of a Mapset, a force
 flag `-f` could be required, in order to actually remove such a directory,
 and all of its contents.

 * Such an option would, maybe, make for a safer practice, if implemented
 correctly, rather than leaving as the only option to remove a Mapset
 directory, directly via the host OS' deletion functions.

 * safe `rm` parctices https://serverfault.com/a/337098/181744

 See also https://trac.osgeo.org/grass/ticket/3577

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3573: Save current working directory in wxGUI workspace and use it

[GRASS GIS]

#3573: Save current working directory in wxGUI workspace and use it
--+---
  Reporter:  wenzeslaus   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  8.0.0
 Component:  Startup  |Version:  unspecified
Resolution:   |   Keywords:  workspace, recent, startup, wxGUI
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by mlennert):

 Replying to [comment:2 wenzeslaus]:
 > Replying to [comment:1 mlennert]:
 > > I have to admin that I never even noticed that we had this option.
 >
 > Accessible from Setting or using cd command in the Console tab (you
 basically get some consistency between terminal and Console tab).

 I don't know what you mean by consistency, but when I cd in the console
 this (obviously) has no impact on the terminal pwd.

 >
 > > I find this a bit weird, first of all because I don't know what the
 "current working directory" actually means in GRASS GIS?
 >
 > It means just the same thing it means in the command line. Every program
 has current working directory (or whatever we want to call it). `cd` and
 `$PWD` or `pwd` in Linux command line, `os.getcwd()` and `os.chdir()` in
 Python.

 Yes, but here we have to be careful to be clear that when we say
 "program", we mean the GUI, not any GRASS module launched from anywhere.

 >
 > > In the GUI I understand it to mean the directory that is opened by
 default in any file system widgets.
 >
 > Right. (At least that's how it works on Linux.) I usually forget about
 this behavior. This might be nice for some users and strange (but not
 necessarily confusing) to some others.

 It is very nice, as I've had situations where I had to save multiple image
 versions of the GUI screen into one directory and had to navigate to that
 directory each time. Now I know that I can cd into that directory in the
 console and thus make it the GUI's pwd. :-)

 > > Does it have any other effect?
 >
 > You can put all your files for import and all color tables for one
 project into one directory (and perhaps subdirs) and then just cd there
 and you don't need to use full path just a relative one. I guess that's
 clear, but the point is that it applies for terminal as well as the GUI
 Console tab.

 I don't know what you mean by "it applies" ? How ? IIUC your ticket, you
 are pleading for that it should ? But this would only be for the situation
 where the pwd is stored in a workspace, or ?

 >It is also advantageous when people are following commands in a list of
 instructions - you need to deal with specifying the path just once (and
 the exported files will be in the directory set at the beginning).

 But you have to be very careful to make sure that all commands are
 executed either only in the console/GUI or only in the terminal...

-- 
Ticket URL: 
GRASS GIS 

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