By file system based copying?
Yes. If you are sure the projections of the locations are the
same, move the entire mapset over.
I am still not 100% sure why data from mapsets in different locations
with the same projection cannot be re-used in other locations.
Why there are no g.mapset.move,
Tim Michelsen wrote:
So what remains as open question:
How do I get my data from the testing location into the location my main
project location? By file system based copying?
I think better by using v.proj/r.proj.
Then, I hope that the GRASS 7 vector format will not store the attribute
Tim,
please keep person's names when you reply. It's easier to follow-up :-).
Nikos:
moving from one location to another location (which usually is/should be
of another projection) is safely done with v.proj. Why use another
command for that?
Tim M:
Then v.proj should support:
* -r flag
What about a command that lets users safely move a vector
from one locagion into the other?
as above. this is on purpose to protect distinct map projections.
please see my use case where a locations serves global datasets for
other smaller locations.
Or the one with a test / development
moving from one location to another location (which usually is/should be
of another projection) is safely done with v.proj. Why use another
command for that?
Then v.proj should support:
* -r flag for importing only the current region extend
* -ship_project flag if source target locations have
moving from one location to another location (which usually is/should be
of another projection) is safely done with v.proj. Why use another
command for that?
Then v.proj should support:
* -r flag for importing only the current region extend
* -ship_project flag if source target locations have
add the mapset as a symlink to the mapset in the other location,
then use the @othermapset notation.
As GRASS is aim to support Windows, this is not an option
___
grass-user mailing list
grass-user@lists.osgeo.org
Maybe I am misunderstanding the concept of mapsets.
And that the develpers meat mapsets to provide this kind of functionality.
I read the basic explanation at:
http://grass.osgeo.org/wiki/Gis_Concepts#How_a_GRASS_project_is_organized
So for testing new data or methods, I definately should use a
add the mapset as a symlink to the mapset in the other location,
then use the @othermapset notation.
As GRASS is aim to support Windows, this is not an option
___
grass-user mailing list
grass-user@lists.osgeo.org
Tim Michelsen wrote:
How do I get my data from the testing location into the
location my main project location?
By file system based copying?
Yes. If you are sure the projections of the locations are the
same, move the entire mapset over.
you may have to reconnect databases if you set them
Hamish wrote:
add the mapset as a symlink to the mapset in the other
location, then use the @othermapset notation.
Tim:
As GRASS is aim to support Windows, this is not an option
The symlink suggestion was meant as a local hack for you, not as
official recommended usage for all users.
The
Tim wrote:
So sharing data between locations is not really supported?
Hamish:
Not at all supported. (except for v.proj, r.proj, i.rectify)
What about a command that lets users safely move a vector
from one locagion into the other?
as above. this is on purpose to protect distinct map
Nikos Alexandris wrote:
Hamish:
...
*every* single GIS I have seen which does on-the-fly reprojection has
had major problems which can present itself in a way which is not
obvious to the user (typically due to mixed datums).
Then the user happily goes along doing their work,
Micha Silver mi...@arava.co.il writes:
And in addition I entered a paragraph in the Tips for Arc Users page
http://grass.osgeo.org/grass-wiki/Tips_for_Arc_users
Thanks, that's helpful. I think the link is wrong though:
http://grass.osgeo.org/wiki/Tips_for_Arc_users
Tyler
--
Saint Mary's -
On Thu, 2009-07-02 at 06:59 -0700, Hamish wrote:
GRASS' logical database structure (one projection
definition per LOCATION) is designed to avoid problems
such as the ones introduced with the on-the-fly
reprojection ability (typically problems caused by
mixed datums) which is present in
Nikos:
GRASS' logical database structure (one projection
definition per LOCATION) is designed to avoid problems
such as the ones introduced with the on-the-fly
reprojection ability (typically problems caused by
mixed datums) which is present in most GISes.
Hamish:
I'm not sure
GRASS' logical database structure (one projection
definition per LOCATION) is designed to avoid problems
such as the ones introduced with the on-the-fly
reprojection ability (typically problems caused by
mixed datums) which is present in most GISes.
I'm not sure I'd use the word designed
On Thu, Jul 2, 2009 at 12:07 AM, Hamishhamis...@yahoo.com wrote:
2c POV:
*every* single GIS I have seen which does on-the-fly reprojection has had
major problems which can present itself in a way which is not obvious
to the user (typically due to mixed datums). Then the user happily goes
Sorry, Hamish already gave an answer to that in his first reply:
add the mapset as a symlink to the mapset in the other location,
then use the @othermapset notation.
BTW, how do you do this on a Windows computer?
___
grass-user mailing list
So sharing data between locations is not really supported?
Not at all supported. (except for v.proj, r.proj, i.rectify)
What about a command that lets users safely move a vector from one
locagion into the other?
Even if I just want to add the layer to the map view?
if you want to mix
Tim Michelsen:
So sharing data between locations is not really supported?
Hamish:
Not at all supported. (except for v.proj, r.proj, i.rectify)
Tim:
What about a command that lets users safely move a vector from one
locagion into the other?
Tim,
moving from one location to another
---%---
Tim:
But how to /display/ data from another location?
---%---
Sorry, Hamish already gave an answer to that in his first reply:
add the mapset as a symlink to the mapset in the other location,
then use the @othermapset notation.
(at your own risk)
Hamish
22 matches
Mail list logo
