Hi all,
I would like to modify `g.mlist` to enable listing multiple types from
all mapsets in the given location. Now you can list multiple types
from search path, ie.
$ g.mlist rast,vect -m
raster map(s) available in mapset <g6>:
x@g6
vector map(s) available in mapset <g6>:
b@g6
obce6@g6
vector map(s) available in mapset <PERMANENT>:
kltm50@PERMANENT
lesy@PERMANENT
merene_body@PERMANENT
obce@PERMANENT
obce_b@PERMANENT
orp@PERMANENT
zel_stan@PERMANENT
zelez@PERMANENT
but it's hardly parsable
$ g.mlist rast,vect -m --q
x@g6
b@g6
obce6@g6
kltm50@PERMANENT
lesy@PERMANENT
merene_body@PERMANENT
obce@PERMANENT
obce_b@PERMANENT
orp@PERMANENT
zel_stan@PERMANENT
zelez@PERMANENT
so I was thinking to add a new flag which prints also element type
rast x@g6
vect b@g6
vect obce6@g6
vect kltm50@PERMANENT
...
(do we really need a new flag for that? There is probably nobody who
is parsing multiple types from `g.mlist`. So probably element type
could be automatically printed when mutiple types and `--q` flag are
given (?) Maybe too tricky...
The remaining question how to implement all mapsets search.
mapset=.
means search path
1) do we introduce special character for all mapsets ? (preferable I would say)
2) do we introduce new flag ?
Thanks for your ideas in advance! Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
Martin,
g.mlist already has -t flag for printing element types.
rast/x@g6
vect/b@g6
vect/obce6@g6
vect/kltm50@PERMANENT
Regarding all mapsets search, it should be (1) because a new flag for all mapsets & mapset=. (default for the current mapset) have a conflict meaning and can be confusing. Maybe, mapset=- (minus)?
Curious why we need all mapsets search…
Huidae
···
On Sun, May 25, 2014 at 3:43 AM, Martin Landa <landa.martin@gmail.com> wrote:
Hi all,
I would like to modify g.mlist to enable listing multiple types from
all mapsets in the given location. Now you can list multiple types
from search path, ie.
$ g.mlist rast,vect -m
raster map(s) available in mapset :
x@g6
vector map(s) available in mapset :
b@g6
obce6@g6
vector map(s) available in mapset :
kltm50@PERMANENT
lesy@PERMANENT
merene_body@PERMANENT
obce@PERMANENT
obce_b@PERMANENT
orp@PERMANENT
zel_stan@PERMANENT
zelez@PERMANENT
but it’s hardly parsable
$ g.mlist rast,vect -m --q
x@g6
b@g6
obce6@g6
kltm50@PERMANENT
lesy@PERMANENT
merene_body@PERMANENT
obce@PERMANENT
obce_b@PERMANENT
orp@PERMANENT
zel_stan@PERMANENT
zelez@PERMANENT
so I was thinking to add a new flag which prints also element type
rast x@g6
vect b@g6
vect obce6@g6
vect kltm50@PERMANENT
…
(do we really need a new flag for that? There is probably nobody who
is parsing multiple types from g.mlist. So probably element type
could be automatically printed when mutiple types and --q flag are
given (?) Maybe too tricky…
The remaining question how to implement all mapsets search.
mapset=.
means search path
- do we introduce special character for all mapsets ? (preferable I would say)
- do we introduce new flag ?
Thanks for your ideas in advance! Martin
–
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
another option (you might have considered it already) is to allow option mapset to have multiple inputs. So 2 steps would be needed, first get all mapsets with g.mapsets -l and then g.mlist with these mapsets. I suppose you need it for the wxDataCatalog?
Anna
···
On Sun, May 25, 2014 at 7:45 AM, Huidae Cho <grass4u@gmail.com> wrote:
Martin,
g.mlist already has -t flag for printing element types.
rast/x@g6
vect/b@g6
vect/obce6@g6
vect/kltm50@PERMANENT
Regarding all mapsets search, it should be (1) because a new flag for all mapsets & mapset=. (default for the current mapset) have a conflict meaning and can be confusing. Maybe, mapset=- (minus)?
Curious why we need all mapsets search…
Huidae
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Sun, May 25, 2014 at 3:43 AM, Martin Landa <landa.martin@gmail.com> wrote:
Hi all,
I would like to modify g.mlist to enable listing multiple types from
all mapsets in the given location. Now you can list multiple types
from search path, ie.
$ g.mlist rast,vect -m
raster map(s) available in mapset :
x@g6
vector map(s) available in mapset :
b@g6
obce6@g6
vector map(s) available in mapset :
kltm50@PERMANENT
lesy@PERMANENT
merene_body@PERMANENT
obce@PERMANENT
obce_b@PERMANENT
orp@PERMANENT
zel_stan@PERMANENT
zelez@PERMANENT
but it’s hardly parsable
$ g.mlist rast,vect -m --q
x@g6
b@g6
obce6@g6
kltm50@PERMANENT
lesy@PERMANENT
merene_body@PERMANENT
obce@PERMANENT
obce_b@PERMANENT
orp@PERMANENT
zel_stan@PERMANENT
zelez@PERMANENT
so I was thinking to add a new flag which prints also element type
rast x@g6
vect b@g6
vect obce6@g6
vect kltm50@PERMANENT
…
(do we really need a new flag for that? There is probably nobody who
is parsing multiple types from g.mlist. So probably element type
could be automatically printed when mutiple types and --q flag are
given (?) Maybe too tricky…
The remaining question how to implement all mapsets search.
mapset=.
means search path
- do we introduce special character for all mapsets ? (preferable I would say)
- do we introduce new flag ?
Thanks for your ideas in advance! Martin
–
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Sun, May 25, 2014 at 3:43 AM, Martin Landa <landa.martin@gmail.com>wrote:
I would like to modify `g.mlist` to enable listing multiple types from
all mapsets in the given location. Now you can list multiple types
from search path, ie.
This is just a reminder of recent discussions about g.mlist and g.mremove.
It seems that we want a lot of changes in them.
g.mlist warnings for layers found in other mapsets
http://trac.osgeo.org/grass/ticket/2255
g.list and g.mlist should be able to handle strds, str3ds, stvds
http://trac.osgeo.org/grass/ticket/2266
g.mremove: adding 'map name exclusion pattern' option
http://lists.osgeo.org/pipermail/grass-dev/2014-March/067800.html
g.mremove: add an option to use 'map name exclusion patterns' like is
available in g.mlist
http://trac.osgeo.org/grass/ticket/2228
More recent discussion about g.mremove at http://lists.osgeo.org/pipermail/grass-dev/2014-May/068774.html
As I mentioned in the above thread, I prefer the g.mlist interface because it’s easier to add more types and the exclude parameter.
I thought about the “all” mapset special character. “…” would be more logical than “-” because it means go up to the current location and list all mapsets under it.
···
On Sun, May 25, 2014 at 3:43 AM, Martin Landa <landa.martin@gmail.com> wrote:
I would like to modify g.mlist to enable listing multiple types from
all mapsets in the given location. Now you can list multiple types
from search path, ie.
This is just a reminder of recent discussions about g.mlist and g.mremove. It seems that we want a lot of changes in them.
g.mlist warnings for layers found in other mapsets
http://trac.osgeo.org/grass/ticket/2255
g.list and g.mlist should be able to handle strds, str3ds, stvds
http://trac.osgeo.org/grass/ticket/2266
g.mremove: adding ‘map name exclusion pattern’ option
http://lists.osgeo.org/pipermail/grass-dev/2014-March/067800.html
g.mremove: add an option to use ‘map name exclusion patterns’ like is available in g.mlist
http://trac.osgeo.org/grass/ticket/2228
Hi,
2014-05-25 13:45 GMT+02:00 Huidae Cho <grass4u@gmail.com>:
g.mlist already has -t flag for printing element types.
ooops, I completely overlooked this flag...
Regarding all mapsets search, it should be (1) because a new flag for all
mapsets & mapset=. (default for the current mapset) have a conflict meaning
and can be confusing. Maybe, mapset=- (minus)?
This would make sense to me.
Curious why we need all mapsets search..
For data catalog [1] (call `g.mlist` for location just once).
Thanks, Martin
[1] http://trac.osgeo.org/grass/wiki/wxGUIDevelopment/wxDataCatalog
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
Hi,
2014-05-25 15:05 GMT+02:00 Anna Petrášová <kratochanna@gmail.com>:
another option (you might have considered it already) is to allow option
mapset to have multiple inputs. So 2 steps would be needed, first get all
mapsets with g.mapsets -l and then g.mlist with these mapsets. I suppose you
need it for the wxDataCatalog?
yes, we were thinking about that. Thanks, Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
Hi,
2014-05-25 16:01 GMT+02:00 Huidae Cho <grass4u@gmail.com>:
I thought about the "all" mapset special character. ".." would be more
logical than "-" because it means go up to the current location and list all
mapsets under it.
good idea, Martin
On Sun, May 25, 2014 at 7:45 AM, Huidae Cho <grass4u@gmail.com> wrote:
Regarding all mapsets search, it should be (1) because a new flag for all
mapsets & mapset=. (default for the current mapset) have a conflict meaning
and can be confusing. Maybe, mapset=- (minus)?
On the other hand, a flag is more aligned with what other modules are using
and does not need any special (magic) syntax.
Hi,
2014-05-25 16:01 GMT+02:00 Huidae Cho <grass4u@gmail.com>:
I thought about the "all" mapset special character. ".." would be more
logical than "-" because it means go up to the current location and list all
mapsets under it.
done in r60528 (mapset=..). Related question do we need both g.list
and g.mlist when g.mlist seems to cover whole functionality of g.list
(-p/-f)... ?
Martin
Looks great! Personally I don’t see a reason to have two versions of list/remove. Time to replace the old g.list,remove with the g.m* version?
On May 28, 2014 4:23 AM, “Martin Landa” <landa.martin@gmail.com> wrote:
Hi,
2014-05-25 16:01 GMT+02:00 Huidae Cho <grass4u@gmail.com>:
I thought about the “all” mapset special character. “…” would be more
logical than “-” because it means go up to the current location and list all
mapsets under it.
done in r60528 (mapset=…). Related question do we need both g.list
and g.mlist when g.mlist seems to cover whole functionality of g.list
(-p/-f)… ?
Martin
Hi,
2014-05-28 15:07 GMT+02:00 Huidae Cho <grass4u@gmail.com>:
Looks great! Personally I don't see a reason to have two versions of
list/remove. Time to replace the old g.list,remove with the g.m* version?
personally I agree, if we decide to do that, it should be done ASAP
(testing in trunk, backport to relbr70).
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
Please see http://trac.osgeo.org/grass/ticket/2228 also.
···
On Wed, May 28, 2014 at 9:21 AM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2014-05-28 15:07 GMT+02:00 Huidae Cho <grass4u@gmail.com>:
Looks great! Personally I don’t see a reason to have two versions of
list/remove. Time to replace the old g.list,remove with the g.m* version?
personally I agree, if we decide to do that, it should be done ASAP
(testing in trunk, backport to relbr70).
Martin
–
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
On 28 May 2014 15:21, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
Hi
2014-05-28 15:07 GMT+02:00 Huidae Cho <grass4u@gmail.com>:
Looks great! Personally I don't see a reason to have two versions of
list/remove. Time to replace the old g.list,remove with the g.m* version?
personally I agree, if we decide to do that, it should be done ASAP
(testing in trunk, backport to relbr70).
me too
Martin
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
Hi,
I don’t think that there will be any issue but to introduce the idea how testing can be used, I added a test of the most essential functionality of g.list. Once g.list is replaced by g.mlist, the test can be used to ensure that old g.list functionality works as expected. (In fact I used g.mlist output as a reference in test, so it is already tested.)
This is more a proof of concept but it serves its purpose at the same time. Feel free to comment or try to add your tests. You don’t have to bother with things like a location etc. Just expect that you are in a (empty) user1 mapset of nc_smp location and run the tests there (not in your precious production location). In the future, these things will be hopefully managed by the testing framework. You can even write in bash if you have ideas what or how to test (it will be converted to Python later).
Vaclav
http://trac.osgeo.org/grass/browser/grass/trunk/general/g.list/test_g_list.py?rev=60619
···
On Thu, May 29, 2014 at 5:08 AM, Luca Delucchi <lucadeluge@gmail.com> wrote:
On 28 May 2014 15:21, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
Hi
2014-05-28 15:07 GMT+02:00 Huidae Cho <grass4u@gmail.com>:
Looks great! Personally I don’t see a reason to have two versions of
list/remove. Time to replace the old g.list,remove with the g.m* version?
personally I agree, if we decide to do that, it should be done ASAP
(testing in trunk, backport to relbr70).
me too
Martin
–
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
I tested g.mlist with the attached script. I started from test_g_list.py and replaced g.list with g.mlist -p and g.list -f with g.mlist -f. g.mlist passed the test, which means g.list == g.mlist -p & g.list -f == g.mlist -f.
g.mlist does everything g.list does and provides more functionalities, so do we want to retire the old g.list and replace it with g.mlist?
(attachments)
test_g_mlist_vs_g_list.py (10.1 KB)
···
On Fri, May 30, 2014 at 9:35 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
Hi,
I don’t think that there will be any issue but to introduce the idea how testing can be used, I added a test of the most essential functionality of g.list. Once g.list is replaced by g.mlist, the test can be used to ensure that old g.list functionality works as expected. (In fact I used g.mlist output as a reference in test, so it is already tested.)
This is more a proof of concept but it serves its purpose at the same time. Feel free to comment or try to add your tests. You don’t have to bother with things like a location etc. Just expect that you are in a (empty) user1 mapset of nc_smp location and run the tests there (not in your precious production location). In the future, these things will be hopefully managed by the testing framework. You can even write in bash if you have ideas what or how to test (it will be converted to Python later).
Vaclav
http://trac.osgeo.org/grass/browser/grass/trunk/general/g.list/test_g_list.py?rev=60619
On Thu, May 29, 2014 at 5:08 AM, Luca Delucchi <lucadeluge@gmail.com> wrote:
On 28 May 2014 15:21, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
Hi
2014-05-28 15:07 GMT+02:00 Huidae Cho <grass4u@gmail.com>:
Looks great! Personally I don’t see a reason to have two versions of
list/remove. Time to replace the old g.list,remove with the g.m* version?
personally I agree, if we decide to do that, it should be done ASAP
(testing in trunk, backport to relbr70).
me too
Martin
–
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
2014-06-03 9:43 GMT+02:00 Huidae Cho <grass4u@gmail.com>:
[...]
g.mlist does everything g.list does and provides more functionalities, so do
we want to retire the old g.list and replace it with g.mlist?
+1 (same should be done for g.mremove). Martin
you mean the new g.mremove with the g.mlist interface (http://trac.osgeo.org/grass/attachment/ticket/2228/g-mremove-main.diff)?
···
On Tue, Jun 3, 2014 at 4:01 AM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2014-06-03 9:43 GMT+02:00 Huidae Cho <grass4u@gmail.com>:
[…]
g.mlist does everything g.list does and provides more functionalities, so do
we want to retire the old g.list and replace it with g.mlist?
+1 (same should be done for g.mremove). Martin
2014-06-03 10:04 GMT+02:00 Huidae Cho <grass4u@gmail.com>:
you mean the new g.mremove with the g.mlist interface
(http://trac.osgeo.org/grass/attachment/ticket/2228/g-mremove-main.diff)?
I had in mind replacing g.remove with g.mremove, but right,
consolidating interfaces would be also nice...
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
On Tue, Jun 3, 2014 at 4:08 AM, Martin Landa <landa.martin@gmail.com> wrote:
2014-06-03 10:04 GMT+02:00 Huidae Cho <grass4u@gmail.com>:
> you mean the new g.mremove with the g.mlist interface
> (http://trac.osgeo.org/grass/attachment/ticket/2228/g-mremove-main.diff
)?
I had in mind replacing g.remove with g.mremove, but right,
consolidating interfaces would be also nice...
Agreed. Note also that there are is good reasoning behind the new
interface by Glynn and Huidae [1] besides the fact the old g.mremove was
used for a long time. Also I've tried to test the new interface [2].
Vaclav
[1] http://trac.osgeo.org/grass/ticket/2228#comment:6
[2] http://trac.osgeo.org/grass/attachment/ticket/2228/test_g_mremove.py
PS: Now I see that the test contains a bug, the first method is not
executed because I gave the same name to the second one. I should use
pylint next time.
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa