Re: [GRASS-dev] [GRASS GIS] #3055: Revise monochromatic color tables

[GRASS GIS]

#3055: Revise monochromatic color tables
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Display |Version:  unspecified
Resolution:  |   Keywords:  r.colors, d.rast, blues, greens,
   CPU:  |  oranges, reds, sepia, water
  Unspecified|   Platform:  Unspecified
-+-
Changes (by wenzeslaus):

 * Attachment "monochromatic_to_matplotlib.diff" added.

 Patch to change monochromatic/monochrome color tables from r64283 (#2557)
 to Matplotlib ones

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Color tables/rules now use standardized color parsing

[Vaclav Petras]

Dear all,

in r69708, I've changed the implementation of parsing color rules to use
the G_str_to_color() function instead of a custom mechanism. This, in
connection with r69683, adds the possibility to use HTML (CSS) style of
hexadecimal colors with leading hash.

So, now you can do:

r.colors elevation rules=- 

Re: [GRASS-dev] [GRASS GIS] #3184: v.vect.stats: errors in counts and statistics

[GRASS GIS]

#3184: v.vect.stats: errors in counts and statistics
-+--
  Reporter:  veroandreo  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  v.vect.stats
   CPU:  x86-64  |   Platform:  Linux
-+--

Comment (by mlennert):

 Replying to [comment:5 mlennert]:
 > Replying to [comment:4 veroandreo]:
 > > I applied the patch and tested.
 > > - For my data (615 points, 3600 areas split in 325 categories), I got
 Segmentation fault.
 >
 > Yes, i just noticed this for the original test data (test_areas,
 test_points) as well...

 I can get rid of the segfault, but results are still not good. I have the
 feeling the issue is more profound than what I initially thought, so it
 would be better if MarkusM had a look at it.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] v.wedge

[Vaclav Petras]

On Tue, Oct 18, 2016 at 5:58 PM, Vincent Bain  wrote:

>
> Hoping it can be useful I attach the bash script, don't know if it's
> worth making it an addon, I guess it would be better to write new addons
> in python... perhaps someone can turn it into something more "trendy"?
>

You can add it to GRASS Subversion sandbox (you need to get access unless
you already have it) or you can use some service like GitHub. This way, you
give a clear(er) way to contribute and a way to obtain latest version. If
you add makefile and doc, then it will be possible to install it with
g.extension (on Linux and Mac with G72).

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

Re: [GRASS-dev] [GRASS GIS] #3184: v.vect.stats: errors in counts and statistics

[GRASS GIS]

#3184: v.vect.stats: errors in counts and statistics
-+--
  Reporter:  veroandreo  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  v.vect.stats
   CPU:  x86-64  |   Platform:  Linux
-+--

Comment (by mlennert):

 Replying to [comment:4 veroandreo]:
 > I applied the patch and tested.
 > - For my data (615 points, 3600 areas split in 325 categories), I got
 Segmentation fault.

 Yes, i just noticed this for the original test data (test_areas,
 test_points) as well...

 > - For the data generated with the commands you just posted, the result
 looks fine when running v.vect.stats with -p flag.
 >
 > {{{
 > GRASS 7.3.svn (nc_spm_08_grass7):~ > v.vect.stats -p points=gc
 type=centroid areas=grid_one_cat points_col=col countcol=count
 statscol=sum method=sum
 > Selecting points for each area...
 >  100%
 > area_cat|count|sum
 > 1|9|18
 > }}}
 >
 > However, if you remove that flag, to actually update the attribute table
 (which for this case it is supposed to have only one category), I get:
 >
 > {{{
 > GRASS 7.3.svn (nc_spm_08_grass7):~ > v.db.select grid_one_cat
 > cat|row|col|rown|coln|count|sum
 > 1|3|1|C|A|9|18
 > 2|3|2|C|B||
 > 3|3|3|C|C||
 > 4|2|1|B|A||
 > 5|2|2|B|B||
 > 6|2|3|B|C||
 > 7|1|1|A|A||
 > 8|1|2|A|B||
 > 9|1|3|A|C||
 > }}}
 >
 > Is there something wrong with v.db.select or with v.edit? I followed all
 your steps. But even if I do {{{v.db.select grid_one_cat}}} before
 v.vect.stats (and after the v.edit step), I get all the old categories:
 >
 > {{{
 > GRASS 7.3.svn (nc_spm_08_grass7):~ > v.db.select grid_one_cat
 > cat|row|col|rown|coln
 > 1|3|1|C|A
 > 2|3|2|C|B
 > 3|3|3|C|C
 > 4|2|1|B|A
 > 5|2|2|B|B
 > 6|2|3|B|C
 > 7|1|1|A|A
 > 8|1|2|A|B
 > 9|1|3|A|C
 > }}}
 >
 > I'm lost...

 This is normal: the table is not changed by the v.category commands, only
 the cat values. So all the old entries are still there. To make it really
 clean, one would have to run v.db.connect -d, db.droptable, v.db.addtable
 after the v.category command.

--
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] #3184: v.vect.stats: errors in counts and statistics

[GRASS GIS]

#3184: v.vect.stats: errors in counts and statistics
-+--
  Reporter:  veroandreo  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  v.vect.stats
   CPU:  x86-64  |   Platform:  Linux
-+--

Comment (by veroandreo):

 I applied the patch and tested.
 - For my data (615 points, 3600 areas split in 325 categories), I got
 Segmentation fault.
 - For the data generated with the commands you just posted, the result
 looks fine when running v.vect.stats with -p flag.

 {{{
 GRASS 7.3.svn (nc_spm_08_grass7):~ > v.vect.stats -p points=gc
 type=centroid areas=grid_one_cat points_col=col countcol=count
 statscol=sum method=sum
 Selecting points for each area...
  100%
 area_cat|count|sum
 1|9|18
 }}}

 However, if you remove that flag, to actually update the attribute table
 (which for this case it is supposed to have only one category), I get:

 {{{
 GRASS 7.3.svn (nc_spm_08_grass7):~ > v.db.select grid_one_cat
 cat|row|col|rown|coln|count|sum
 1|3|1|C|A|9|18
 2|3|2|C|B||
 3|3|3|C|C||
 4|2|1|B|A||
 5|2|2|B|B||
 6|2|3|B|C||
 7|1|1|A|A||
 8|1|2|A|B||
 9|1|3|A|C||
 }}}

 Is there something wrong with v.db.select or with v.edit? I followed all
 your steps. But even if I do {{{v.db.select grid_one_cat}}} before
 v.vect.stats (and after the v.edit step), I get all the old categories:

 {{{
 GRASS 7.3.svn (nc_spm_08_grass7):~ > v.db.select grid_one_cat
 cat|row|col|rown|coln
 1|3|1|C|A
 2|3|2|C|B
 3|3|3|C|C
 4|2|1|B|A
 5|2|2|B|B
 6|2|3|B|C
 7|1|1|A|A
 8|1|2|A|B
 9|1|3|A|C
 }}}

 I'm lost...

--
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] #3184: v.vect.stats: errors in counts and statistics

[GRASS GIS]

#3184: v.vect.stats: errors in counts and statistics
-+--
  Reporter:  veroandreo  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  v.vect.stats
   CPU:  x86-64  |   Platform:  Linux
-+--
Changes (by mlennert):

 * Attachment "v_vect_stats_unique_cats.diff" added.

 patch (against trunk) to correctly uniquify list of cats

--
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] #3184: v.vect.stats: errors in counts and statistics

[GRASS GIS]

#3184: v.vect.stats: errors in counts and statistics
-+--
  Reporter:  veroandreo  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  v.vect.stats
   CPU:  x86-64  |   Platform:  Linux
-+--

Comment (by mlennert):

 I think I found the issue.

 When running with g.gisenv set=DEBUG=1, I get:


 {{{
 v.vect.stats -p points=gc type=centroid areas=grid_one_cat points_col=col
 countcol=count statscol=sum method=sum
 [...]
 D1/1: 9 cats loaded from vector (including duplicates)
 D1/1: 5 cats loaded from vector (unique)
 [...]
 }}}

 There should be only 1 unique cat.

 The attached patch seems to solve this for me, but it needs testing and
 review.

--
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] #3184: v.vect.stats: errors in counts and statistics (was: v.ect.stats: errors in counts and statistics)

[GRASS GIS]

#3184: v.vect.stats: errors in counts and statistics
-+--
  Reporter:  veroandreo  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  v.vect.stats
   CPU:  x86-64  |   Platform:  Linux
-+--

--
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] #3184: v.ect.stats: errors in counts and statistics

[GRASS GIS]

#3184: v.ect.stats: errors in counts and statistics
-+--
  Reporter:  veroandreo  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  v.vect.stats
   CPU:  x86-64  |   Platform:  Linux
-+--

Comment (by mlennert):

 Here's another example with internally generated data:


 {{{
 g.region res=1 n=3 s=0 w=0 e=3 -p
 v.mkgrid grid=3,3 map=grid
 v.extract grid type=centroid out=gc
 v.category grid type=centroid out=grid_no_cats cat=-1 op=del
 g.copy vect=grid_no_cats,grid_one_cat
 v.edit grid_one_cat type=centroid tool=catadd cat=1 bbox=0,0,3,3

 v.vect.stats -p points=gc type=centroid areas=grid points_col=col
 countcol=count statscol=sum method=sum
 Selecting points for each area...
  100%
 area_cat|count|sum
 1|1|1
 2|1|2
 3|1|3
 4|1|1
 5|1|2
 6|1|3
 7|1|1
 8|1|2
 9|1|3

 v.vect.stats -p points=gc type=centroid areas=grid_one_cat points_col=col
 countcol=count statscol=sum method=sum
 Selecting points for each area...
  100%
 area_cat|count|sum
 1|0|null
 1|0|null
 1|9|18
 1|0|null
 1|0|null
 }}}

 IOW, with all grid cells having the same cat value, results become
 nonsense except for one case. However, this one case is not the one
 uploaded to the vector attribute table when one doesn't use the '-p' flag.

--
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] #3187: Attribute table manager refreshing when connecting a distant sqlite database

[GRASS GIS]

#3187: Attribute table manager refreshing when connecting a distant sqlite
database
+-
 Reporter:  vincent |  Owner:  grass-dev@…
 Type:  defect  | Status:  new
 Priority:  minor   |  Milestone:  7.0.6
Component:  wxGUI   |Version:  svn-trunk
 Keywords:  database,layer  |CPU:  Unspecified
 Platform:  Linux   |
+-
 Given a vector map without layer, you may want to make a connection with
 an external database sqlite file. Doing this with the wxgui attribute
 table manager, when specifying the path for an existing sqlite file,
 'Table' and 'Key column' dropdown lists are not immediately refreshed, so
 it is not possible to set properly the new layer. Update only happens if
 you select another entry in the 'Driver' dropdown list (e.g. 'pg'), then
 set it back to 'sqlite'.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] next community sprint in Genova?

[Veronica Andreo]

Hi Lu,

I would say that for defining if extending to the weekend before or
after, we should also consider that 4-5 of february next year the
FOSSDEM will take place in Brussels (https://fosdem.org/2017/). Maybe,
some ppl would like to attend both events (?), dunno...


Best,
Vero

2016-10-19 15:46 GMT+02:00 Luca Delucchi :
> Hi devs,
>
> On 27 May 2016 at 12:08, Luca Delucchi  wrote:
>
>>
>> sorry I forgot the month, it should be February
>>
>
> I have some news, we have room booked from 6-8 February (I asked until
> 10), we can extend to the weekend to but I have to look for the room,
> do you prefer the weekend before (4-5) o after (11-12)?
>
> I also created a wiki page [0], please add your self to the
> participation list ;-)
>
> [0] https://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_Genova_2017
>
> --
> ciao
> Luca
>
> www.lucadelu.org
> ___
> 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] next community sprint in Genova?

[Luca Delucchi]

Hi devs,

On 27 May 2016 at 12:08, Luca Delucchi  wrote:

>
> sorry I forgot the month, it should be February
>

I have some news, we have room booked from 6-8 February (I asked until
10), we can extend to the weekend to but I have to look for the room,
do you prefer the weekend before (4-5) o after (11-12)?

I also created a wiki page [0], please add your self to the
participation list ;-)

[0] https://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_Genova_2017

-- 
ciao
Luca

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

Re: [GRASS-dev] [GRASS GIS] #3186: [PATCH] i.in.spotvgt: allow import of any band, not only NDVI

[GRASS GIS]

#3186: [PATCH] i.in.spotvgt: allow import of any band, not only NDVI
--+
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.6
 Component:  Imagery  |Version:  svn-trunk
Resolution:   |   Keywords:  i.in.spotvgt bands
   CPU:  Unspecified  |   Platform:  Unspecified
--+

Comment (by mlennert):

 I've replaced the patch with a new one, that loops through all bands. By
 default it only imports NDVI (as before), but by setting the -b flag the
 use can request import of all bands (B0, B2, B3, MIR, and NDVI).

 This changes the module API a bit as now the user points the module to the
 metadata file (0001_LOG.TXT) and not to the NDVI file. I would be possible
 to rewrite it so that the user can point to either of the two. Or just the
 NDVI file... I'll get back to it when I find the time, unless someone else
 wants to.

 As is, the patch does work for looping, though.

--
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] #3186: [PATCH] i.in.spotvgt: allow import of any band, not only NDVI

[GRASS GIS]

#3186: [PATCH] i.in.spotvgt: allow import of any band, not only NDVI
--+
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.6
 Component:  Imagery  |Version:  svn-trunk
Resolution:   |   Keywords:  i.in.spotvgt bands
   CPU:  Unspecified  |   Platform:  Unspecified
--+
Changes (by mlennert):

 * Attachment "i_in_spotvgt_all_bands.diff" added.

 patch to allow import of any band

--
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] #3186: [PATCH] i.in.spotvgt: allow import of any band, not only NDVI

[GRASS GIS]

#3186: [PATCH] i.in.spotvgt: allow import of any band, not only NDVI
--+
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.6
 Component:  Imagery  |Version:  svn-trunk
Resolution:   |   Keywords:  i.in.spotvgt bands
   CPU:  Unspecified  |   Platform:  Unspecified
--+
Changes (by mlennert):

 * milestone:   => 7.0.6


Comment:

 Am actually working on a different version that loops over all bands, so
 please ignore the current patch for now...

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Default behavior of g.list displaying all mapsets content

[Margherita Di Leo]

On Wed, Oct 19, 2016 at 11:56 AM, Margherita Di Leo 
wrote:

>
>
> On Wed, Oct 19, 2016 at 11:47 AM, Moritz Lennert <
> mlenn...@club.worldonline.be> wrote:
>
>> On 19/10/16 11:22, Margherita Di Leo wrote:
>>
>>>
>>>
>> There was a discussion about these questions on the ML at the time:
>> https://lists.osgeo.org/pipermail/grass-dev/2014-October/071381.html
>
>
> I must have missed that, or perhaps I had no strong opinion at that time,
> sorry about that.
>

It seems to me that the whole thread ended up with a general agreement that
the -m should be reverted?


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

Re: [GRASS-dev] [GRASS GIS] #3186: [PATCH] i.in.spotvgt: allow import of any band, not only NDVI

[GRASS GIS]

#3186: [PATCH] i.in.spotvgt: allow import of any band, not only NDVI
--+
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Imagery  |Version:  svn-trunk
Resolution:   |   Keywords:  i.in.spotvgt bands
   CPU:  Unspecified  |   Platform:  Unspecified
--+
Changes (by mlennert):

 * Attachment "i_in_spotvgt_all_bands.diff" added.

 patch to allow import of any band

--
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] #3186: [PATCH] i.in.spotvgt: allow import of any band, not only NDVI

[GRASS GIS]

#3186: [PATCH] i.in.spotvgt: allow import of any band, not only NDVI
+-
 Reporter:  mlennert|  Owner:  grass-dev@…
 Type:  enhancement | Status:  new
 Priority:  normal  |  Milestone:
Component:  Imagery |Version:  svn-trunk
 Keywords:  i.in.spotvgt bands  |CPU:  Unspecified
 Platform:  Unspecified |
+-
 Currently, i.in.spotvgt only imports NDVI bands. The attached patch
 againts trunk allows importing any band.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Default behavior of g.list displaying all mapsets content

[Margherita Di Leo]

On Wed, Oct 19, 2016 at 11:47 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 19/10/16 11:22, Margherita Di Leo wrote:
>
>> Dear all,
>>
>> currently the default behavior of g.list is to display all the files
>> present in all mapsets (which corresponds to g.list mapset=*), without
>> indicating where they are.
>> I would very much prefer g.list mapset=. as a default behavior, ignoring
>> what there is in other mapsets.
>>
>
> -1
>
> For me the current default behaviour, i.e. showing maps of all mapsets in
> the current search path is much more useful.
>
> If this is really not possible, at least specifying the mapset where the
>> maps are, if different from the current.
>> Perhaps:
>>
>> g.list vect
>> vect1
>> vect2
>> PERMANENT
>> vect3
>>
>> or:
>>
>> g.list vect
>> vect1
>> vect2
>> PERMANENT/vect3
>>
>> What do you think?
>>
>
> Have you seen the '-m' flag ?
>

Yes, thanks.

>
> And otherwise, the '-p' flag gives you pretty printed output by mapset.
>
> I guess we could discuss whether '-p' should be the default...
>

Yes indeed it is the 'default behavior' what I'm referring to

>
> There was a discussion about these questions on the ML at the time:
> https://lists.osgeo.org/pipermail/grass-dev/2014-October/071381.html


I must have missed that, or perhaps I had no strong opinion at that time,
sorry about that.
The reasons I don't like the current behavior is that, on one side is not
much informative (the maps sitting in the current mapset are likely the
ones I want to access the names most often, for other maps I find it
intuitive to explicitly ask for), and on the other side if you happen to
have several maps in a couple of mapset you end up with an unreadable blob.

Thanks

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

Re: [GRASS-dev] Default behavior of g.list displaying all mapsets content

[Moritz Lennert]

On 19/10/16 11:22, Margherita Di Leo wrote:

Dear all,

currently the default behavior of g.list is to display all the files
present in all mapsets (which corresponds to g.list mapset=*), without
indicating where they are.
I would very much prefer g.list mapset=. as a default behavior, ignoring
what there is in other mapsets.


-1

For me the current default behaviour, i.e. showing maps of all mapsets 
in the current search path is much more useful.



If this is really not possible, at least specifying the mapset where the
maps are, if different from the current.
Perhaps:

g.list vect
vect1
vect2
PERMANENT
vect3

or:

g.list vect
vect1
vect2
PERMANENT/vect3

What do you think?


Have you seen the '-m' flag ?

And otherwise, the '-p' flag gives you pretty printed output by mapset.

I guess we could discuss whether '-p' should be the default...

There was a discussion about these questions on the ML at the time: 
https://lists.osgeo.org/pipermail/grass-dev/2014-October/071381.html


Moritz


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

[GRASS-dev] Default behavior of g.list displaying all mapsets content

[Margherita Di Leo]

Dear all,

currently the default behavior of g.list is to display all the files
present in all mapsets (which corresponds to g.list mapset=*), without
indicating where they are.
I would very much prefer g.list mapset=. as a default behavior, ignoring
what there is in other mapsets.
If this is really not possible, at least specifying the mapset where the
maps are, if different from the current.
Perhaps:

g.list vect
vect1
vect2
PERMANENT
vect3

or:

g.list vect
vect1
vect2
PERMANENT/vect3

What do you think?
Thanks

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