Opened 12 years ago

Closed 9 years ago

#891 closed enhancement (wontfix)

add a command g.move

Reported by: timmie Owned by: grass-dev@…
Priority: normal Milestone: 6.5.0
Component: Default Version: unspecified
Keywords: g.move Cc:
CPU: Unspecified Platform: Unspecified

Description

Please add a command to move data from one mapset to another. This comes handy when a mapset is cluttered and one wants to move some data to a different one.

It should do:

g.copy rast=map mapset=newmapset g.remove rast=map mapset=oldmapset

Change History (4)

comment:1 Changed 12 years ago by hamish

Type: defectenhancement

(for the most part) the multi-user access rules mean that within a certain grass session you are only allowed to write to the current mapset. you can pull maps in, but you can't push them out.

so the method is:

g.copy map@othermapset,map

then change to the other mapset and remove maps as needed.

the exception is i.rectify.

Hamish

comment:2 in reply to:  1 Changed 12 years ago by timmie

Replying to hamish:

(for the most part) the multi-user access rules mean that within a certain grass session you are only allowed to write to the current mapset. you can pull maps in, but you can't push them out.

I understand. But from what I see at current use cases is that nowadays we all have our own cheap notebook / desktop and use GRASS mostely as single user. For those users, the move command would be very useful.

So, the move command you check: Are other users logged in? => if yes, then display explanation and do not move => if no, just move the layer over.

What do you think?

comment:3 Changed 12 years ago by martinl

Milestone: 6.4.06.5.0

comment:4 Changed 9 years ago by hamish

Keywords: g.move added
Resolution: wontfix
Status: newclosed

It's not really about other users on the system (you can't write to directories you don't own either, and grass enforces that for mapset access even if there is filesystem group write permissions set), it's more about safe concurrent use. If you had two GRASS sessions running in parallel, it wouldn't be very nice if the other one suddenly overwrote a map in the one you were working in. The same is true for why starting two GRASSes running in the same mapset is disallowed (also in that case a change by g.region by the twin session could be damaging).

so it's about keeping the paperwork in order and goes pull, not push.

see also the r.pack, r.unpack modules if you need to transfer maps between different systems/locations, and g.laptop.sh from Addons:

http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#g.laptop.sh

Hamish

Note: See TracTickets for help on using tickets.