[GRASS-user] Re: link to datasets from other locations?

[Tim Michelsen]

Nikos Alexandris:
> Tim M:
>> Then v.proj should support:
>> * -r flag for importing only the current region extend
> 
> Read also discussion at trac [1]
> 
> 
>> * -ship_project flag if source & target locations have the same 
>> projection, can also be detected automatically.
> 
> Read my post (and bug-ticket) about a similar case [2][3]
It seem that we are both facing the same problem.
I also had this problem:
1) created a new location from a georeferenced file.
2) Then I tried to import a raster by reprjection a ll/wgs84 srtm file.
=> the imported file was not matching completely with my data.
3) I went to spatialreference.org and took the boundaries for my UTM 
zone and changed the region settings accordingly.
4) then, the import/reproject did work well...

citing from http://trac.osgeo.org/grass/ticket/328#comment:1
 > It violates the axiom of "do one thing well".
 > The purpose of the module is to reproject maps, not to mess with
 > the region. g.region should always be used for that.
 > It is the GUI's job to tie those tasks together for the user in a 
nice wizard or menu order, not the individual number crunching modules' 
job to do all-in-one tasks.
I agree.
The thinking of the pros on this list and the experience I got with 
GRASS show that few programs beat it when it comes to accuracy in 
projection.
But these small glitches and traps make you sometimes whaste your time 
searching why the results are strage.
In 95% I found that something was not working or taking too long because 
I forgot to adjust region settings.

The GUI gets a lot of improvement. I think the developers need to change 
the PoV towards GUI users as these expect things to happen dynamically 
and not unix-like utility-by-utility.

in https://trac.osgeo.org/grass/ticket/674#comment:1
 > crop your vector with v.in.region + v.overlay before you try to 
project it.
This means:
1) in target location do: v.in.region -> regionvector
2) v.proj of regionvector to source location
3) v.overlay of regionvector with worldata vector -> worldata_region
4) in target location: v.proj worldata_region
puh!

I would support the suggestion by Hamish:
 > It is the GUI's job to tie those tasks together for the user in a 
nice wizard or menu order
So, how do we create such wizards that could give Nikos and me more 
productivity?

> Pull from a mapset to another mapset within a location is actually
> "g.copy".
> 
> Pull from a location to another location is "v.proj"/"r.proj". because
> you (usually) need to re-project.
Thanks. I will follow this advice.

Thanks again for patience of every-day users in this discussion.
Timmie