link to datasets from other locations?

[Timmie]

> 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 the same
projection, can also be detected automatically.
* -d: delete source dataset after successful reprojection
The same should apply for r.proj

>>> if you want to mix things you must use multiple mapsets from the
>>> same location with @othermapset.
Image the following use case:
You have project location.
Then you would like to test out some new processing workflows or
developed a new methodology.
In order not to pollute the project location with a lot of test rasters,
you start a new location to do the testing.
Maybe I am misunderstanding the concept of mapsets.
And that the develpers meat mapsets to provide this kind of functionality.
So will removing a mapset also automatically remove all datasets that
belong to it?

>> Imagine a shared location with common data such as world borders or GSHHS.
>> It would not be space efficient to import such large data into every new
>> project. Rather sharing the common location when needed.
> I find that your question/thought makes sense. I faced myself this in
> the past.
Thanks for this support ;-)

  I decided to build a location called ellas (=greece) where I
> put everything that covers/has to do with greece. From there I "pull" it
> to wherever required, do what has to be done and erase if not required
> anymore.
What command do you use to "pull"?
v.proj & r.proj?

Regards,
Timmie

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Timmie]

>> 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" location.

>> But how to /display/ data from another location?
> cp, mv, ln in the mapset if you really want and don't need to reproject.
> 'display' is no different to any other GIS function- you can either read
> map data or you can't.
moving/copying my file manager not a straightforward thing.
copying a vector for instance requires not to forget about the dbf
tables in their directory.

> make it a common Mapset not a common Location. or within your
> common location make a mapset called 'common' then symlink that around
> to other Locations of Exactly the same projection settings.
>
> (no warranty)
As everyone says: "at your own risk" and "no warranty" I would
appreciate to read the proper ways by a GRASS lead developer for the case:
1) location with common data to be reused in other locations.
2) location for testing new approaches before using the working locations

> 2c POV:
> *every* single GIS I have seen which does on-the-fly reprojection has had
on-the-fly is not the topic here. I already asked this in a thread some
time ago and was educated about the GRASS way:
http://thread.gmane.org/gmane.comp.gis.grass.user/24911

For displaying data from different locations I would like to try the
GRASS plugin of QGIS.
It's currently not working on my linux box.

Thanks for following-up,
Timmie


_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Timmie]

> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Timmie]

> 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 the same
projection, can also be detected automatically.
* -d: delete source dataset after successful reprojection
The same should apply for r.proj

>>> if you want to mix things you must use multiple mapsets from the
>>> same location with @othermapset.
Image the following use case:
You have project location.
Then you would like to test out some new processing workflows or
developed a new methodology.
In order not to pollute the project location with a lot of test rasters,
you start a new location to do the testing.
Maybe I am misunderstanding the concept of mapsets.
And that the develpers meat mapsets to provide this kind of functionality.
So will removing a mapset also automatically remove all datasets that
belong to it?

>> Imagine a shared location with common data such as world borders or GSHHS.
>> It would not be space efficient to import such large data into every new
>> project. Rather sharing the common location when needed.
> I find that your question/thought makes sense. I faced myself this in
> the past.
Thanks for this support ;-)

  I decided to build a location called ellas (=greece) where I
> put everything that covers/has to do with greece. From there I "pull" it
> to wherever required, do what has to be done and erase if not required
> anymore.
What command do you use to "pull"?
v.proj & r.proj?

Regards,
Timmie


_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Timmie]

> 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 new
/mapset/ and not a new /location/ if I intent to use the result later in
the main project (with the same projection).

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?

Then, I hope that the GRASS 7 vector format will not store the attribute
table in a direcory separate from the geographica information.

> So will removing a mapset also automatically remove all datasets that
> belong to it?
Why does the g.mapset command
(http://grass.itc.it/gdp/html_grass64/g.mapset.html) not contain a
remove option?

>>> Imagine a shared location with common data such as world borders or
>>> GSHHS.
>>> It would not be space efficient to import such large data into every
>>> new project. Rather sharing the common location when needed.
>> I find that your question/thought makes sense. I faced myself this in
>> the past.
My scenario doesn't really be that unusual:
see:
http://thread.gmane.org/gmane.comp.gis.grass.user/30422

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[hamish-2]

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 to non-
relative path names.
 
> Then, I hope that the GRASS 7 vector format will not store
> the attribute table in a direcory separate from the
> geographica information.

DBs are not a child of a particular map, they are just associated
with it.

> Why does the g.mapset command (http://grass.itc.it/gdp/html_grass64/g.mapset.html) not
> contain a remove option?

because it is dangerous, and 'rm -rf' is pretty easy and the user
should well understand the implications of that command. it is
possible from the starup GUI, but I've never been fully
convinced that's a good idea.


> Imagine a shared location with common data
> such as world borders or GSHHS.
> It would not be space efficient to import such
> large data into every new project.

The way I do it is to have a location called "ll_wgs84" which
has mapsets gshhs, etopo2, canada, modis, etc.

and other locations called "utm_58" or whatever.

but it is up to you to decide how to organize your mapsets, the
definition is left to the user so that they can organize their
data in a way which is most useful to them (eg split mapsets by
time; region; data source; job; user; etc)

see earlier posts about methods to symlink mapsets if you want
to share mapsets between locations (with warnings).



Hamish



     

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[hamish-2]

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 recommended & longstanding usage is to use mapsets within the
same location for this task.


Hamish



     

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Timmie]

>> 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, g.mapset.copy, g.mapset.remove comands.
Today' computers still have limited disk space...

A command g.mapset.proj could serve to reproject all data within a
certain mapset from one location to the other.
> but it is up to you to decide how to organize your mapsets, the
> definition is left to the user so that they can organize their
> data in a way which is most useful to them (eg split mapsets by
> time; region; data source; job; user; etc)
My qustions and posts where meant to obtain more fexibily and efficiency
in the dat organisation.
Why is there r.external or v.external?
Then why not g.external?

Thanks,
Timmie

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Nikos Alexandris]

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 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]

> * -d: delete source dataset after successful reprojection

I have the feeling that is not safe (!).

> The same should apply for r.proj


?:
> >>> if you want to mix things you must use multiple mapsets from the
> >>> same location with @othermapset.

Tim:
> Image the following use case: You have project location.
> Then you would like to test out some new processing workflows or
> developed a new methodology.
> In order not to pollute the project location with a lot of test rasters,
> you start a new location to do the testing. Maybe I am
> misunderstanding the concept of mapsets.

Maybe(?). Why not create a test-mapset/test-location within the same
dbase?

> And that the develpers meat mapsets to provide this kind of functionality.
> So will removing a mapset also automatically remove all datasets that
> belong to it?

No-way! Only the datasets that the mapset contains.

Tim:
> >> Imagine a shared location with common data such as world borders or GSHHS.
> >> It would not be space efficient to import such large data into every new
> >> project. Rather sharing the common location when needed.

Nikos:
> > I find that your question/thought makes sense. I faced myself this in
> > the past. I decided to build a location called ellas (=greece) where I
> > put everything that covers/has to do with greece. From there I "pull" it
> > to wherever required, do what has to be done and erase if not required
> > anymore.

Tim:
> What command do you use to "pull"?
> v.proj & r.proj?

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.


Nikos
---

[1] http://trac.osgeo.org/grass/ticket/328

[2]
http://n2.nabble.com/r.proj's-"use-different-location"-error-while-working-in-different-dbases-td3206919.html#a3206919

[3] http://trac.osgeo.org/grass/ticket/675

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Nikos Alexandris]

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
> table in a direcory separate from the geographica information.
>
> > So will removing a mapset also automatically remove all datasets that
> > belong to it? Why does the g.mapset command
> (http://grass.itc.it/gdp/html_grass64/g.mapset.html) not contain a
> remove option?

Just erase the whole directory as you do with any other directory in
your filesystem.



> >>> Imagine a shared location with common data such as world borders or
> >>> GSHHS.
> >>> It would not be space efficient to import such large data into every
> >>> new project. Rather sharing the common location when needed.
> >> I find that your question/thought makes sense. I faced myself this in
> >> the past.
> My scenario doesn't really be that unusual:
> see: http://thread.gmane.org/gmane.comp.gis.grass.user/30422

I just want to repeat something you probably know: remember that you
always need an "untouched / original" dataset somewhere (that's why
there is a PERMANENT mapset in each location). Most likely it is that
processing tasks will change the dataset in some way.

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Timmie]

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

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Markus Neteler]

On Wed, Jul 1, 2009 at 2:03 PM, Matthew Landis<[hidden email]> wrote:
> A related issue -- I'd like to use r.external but I can't seem to get it to
> work.  I'm running wxPython for GRASS 6.4 (from the Osgeo4W installation).
> r.external seems to work properly, but when I try to display the result, I
> get an error message telling me that GDALAllRegister can't be found.  Here,
> I've reproduced this in the spearfish60 dataset:

I contacted FrankW about this, here his answer:


On Mon, Jul 6, 2009 at 3:17 AM, Frank Warmerdam<[hidden email]> wrote:
...

> I have upgraded my OSGeo4W GRASS 6.4.0svn install to the latest available
> from OSGeo4W and then tried running r.external and it appears to work fine.
> I have also run depends.exe on r.external.exe and it properly depends on
> gdal15.dll so there is no reason it wouldn't normally pick up the copy in
> C:/OSGeo4W/bin.
>
> If someone had another copy of gdal15.dll in c:/windows/system32 it might
> get used instead of the proper one and cause problems though I don't know
> why it would be missing gdalallregister.
>
> Sorry I was unable to find anything helpful.
>

Markus
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user