link to datasets from other locations?

[Timmie]

Hello grass users,

There exist v.external and r.external to link to data which hasn't been
imported into GRASS.

But in order to save time and disk space I would like to link to data
sets from other locations:

How do I link to a raster and vector data in another location presuming
it has the same projection?

Kind regards,
Timmie

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

[hamish-2]

Tim Michelsen wrote:
> There exist v.external and r.external to link to data which
> hasn't been imported into GRASS.
>
> But in order to save time and disk space I would like to
> link to data sets from other locations:
>
> How do I link to a raster and vector data in another
> location presuming it has the same projection?

add the mapset as a symlink to the mapset in the other location,
then use the @othermapset notation.

(at your own risk)

Hamish



     

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

[Matthew Landis]

Some javascript/style in this post has been disabled (why?)

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:

r.out.gdal input=elevation.10m output=elev_dem10.img format=HFA type=Float32
r.external input=elev_dem10.img output=elev_dem10_rext
d.rast map=elev_dem10_rext

The layer shows up in the layer manager as "raster (double-click to set properties)".  I double-click and the name changes to elev_dem10_rext@user1...

Then I try to Zoom to Layer, or click on the Display Map button and I get:

Execution fiailed: 'd.rast.exe map=elev_dem10_rext@user1 --q'
Details:
Error: Unable to locate symbol <GDALAllRegister>

(By the way, I've also encountered this error message trying to do r.mapcalc on a GRASS file imported using r.in.gdal.)

Has anyone encountered this error?  Is there a way to fix it?

Thanks,
Matt

Hamish wrote:

Tim Michelsen wrote:
  

There exist v.external and r.external to link to data which
hasn't been imported into GRASS.

But in order to save time and disk space I would like to
link to data sets from other locations:

How do I link to a raster and vector data in another
location presuming it has the same projection?
    

add the mapset as a symlink to the mapset in the other location,
then use the @othermapset notation.

(at your own risk)

Hamish



      

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

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

[Timmie]

hamish-2 wrote:

> How do I link to a raster and vector data in another
> location presuming it has the same projection?
add the mapset as a symlink to the mapset in the other location,
then use the @othermapset notation.

So sharing data between locations is not really supported?
Even if I just want to add the layer to the map view?

Regards,
Timmie

[hamish-2]

Timmie wrote:
> So sharing data between locations is not really supported?

Not at all supported. (except for v.proj, r.proj, i.rectify)

> Even if I just want to add the layer to the map view?

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


perhaps you could sneak a way with r.external using the GRASS
GDAL driver plugin?


Hamish



     

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

[Glynn Clements]

Timmie wrote:

> >> How do I link to a raster and vector data in another
> >> location presuming it has the same projection?
>
> > add the mapset as a symlink to the mapset in the other location,
> > then use the @othermapset notation.
>
> So sharing data between locations is not really supported?
> Even if I just want to add the layer to the map view?

The only operations which access data in a different location are
those where the data is necessarily in a different location because it
uses a different projection, e.g. re-projection or rectification.

In general, if it's possible for the data to be in the current
location, then it must be.

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

[Timmie]

>> 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 things you must use multiple mapsets from the
> same location with @othermapset.
But how to /display/ data from another location?

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.

> perhaps you could sneak a way with r.external using the GRASS
> GDAL driver plugin?
I will try this.

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

[Nikos Alexandris]

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 location (which usually is/should be
of another projection) is "safely" done with v.proj. Why use another
command for that?

> >> Even if I just want to add the layer to the map view?

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


> But how to /display/ data from another location?

Just do like you do always:
d.vect YourVectorMap@othermapset

I haven't tried to draw something from @anothermapset@anotherlocation
(in case the location is of the same projection).


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

Maybe there are better (space/time efficient) tricks!?


> > perhaps you could sneak a way with r.external using the GRASS
> > GDAL driver plugin?
> I will try this.

Please let us know if something useful works-out :-)
Nikos

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

[Nikos Alexandris]

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

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

[hamish-2]

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 projections.


> > if you want to mix things you must use multiple mapsets from
> > the same location with @othermapset.
>
> 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.


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

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)


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
along doing their work, publishing their reports, only sometimes
realizing that something has misaligned internally. Or ugly non-solutions
like rubber sheet dragging to visually correct the misalignment without
considering the real cause become taught as the de facto method in the
workflow. (easier than teaching about ellipsoids and datum math)

I admit it's not the same as theoretically it could be done correctly,
but I sort of class it with the common request for scalebars or 1:xx,xxx
map scale for lat/lon cartography. It sounds like a good idea, and lots
of other software give the users what they demand there, but that doesn't
mean it's valid or a good idea. For map projections it is not invalid,
just really really hard to get right (probably because "right" is often
a very subjective answer in geodetics).


Hamish



     

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

[Glynn Clements]

Hamish wrote:

> perhaps you could sneak a way with r.external using the GRASS
> GDAL driver plugin?

I don't think so. GDAL's GRASS support uses libgis functions, and
there's only one copy of libgis' variables. So when GDAL uses
G__setenv() to set the database/location/mapset of the input map, it
will affect the process as a whole, not just GDAL.

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

[Nikos Alexandris]

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, publishing their
> reports, only sometimes realizing that something has misaligned
> internally.

> Or ugly non-solutions like rubber sheet dragging to visually correct
> the misalignment without considering the real cause become taught as
> the de facto method in the workflow. (easier than teaching about
> ellipsoids and datum math)


Added in GRASS-wiki [1]:

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

Nikos
---

[1] http://grass.osgeo.org/wiki/Location_and_Mapsets

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

[Micha Silver]

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, publishing their
>> reports, only sometimes realizing that something has misaligned
>> internally.
>>    
>
>  
>> Or ugly non-solutions like rubber sheet dragging to visually correct
>> the misalignment without considering the real cause become taught as
>> the de facto method in the workflow. (easier than teaching about
>> ellipsoids and datum math)
>>    
>
>
> Added in GRASS-wiki [1]:
>
>  

And in addition I entered a paragraph in the "Tips for Arc Users" page
http://grass.osgeo.org/grass-wiki/Tips_for_Arc_users
since the original question reflected a misunderstanding that some of us
Arc converts have to deal with.
--
Micha

> "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."
>
> Nikos
> ---
>
> [1] http://grass.osgeo.org/wiki/Location_and_Mapsets
>
> _______________________________________________
> grass-user mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
> This mail was received via Mail-SeCure System.
>
>
>  

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

[Tyler Smith]

Micha Silver <[hidden email]> 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 - they do science there!

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

[hamish-2]

> "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" that way, AFAIK that
structure was designed long before datum support was even thought
about for GRASS. it's just a matter of enforcing consistency
as a way to keep a complicated job from getting all muddled up.

fwiw in GRASS 5 there is some contrib code from Lockheed Martin
to change the projection of the display window at runtime.


also I don't mean to rag on other GISs too much, obviously we
are not some perfection and have many bugs and design issues too.
just that we should try to learn from mistakes we see around us.


Hamish



     

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

[Nikos Alexandris]

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 most GISes."
>
> I'm not sure I'd use the word "designed" that way, AFAIK that
> structure was designed long before datum support was even thought
> about for GRASS. it's just a matter of enforcing consistency
> as a way to keep a complicated job from getting all muddled up.
>
> fwiw in GRASS 5 there is some contrib code from Lockheed Martin
> to change the projection of the display window at runtime.
>
>
> also I don't mean to rag on other GISs too much, obviously we
> are not some perfection and have many bugs and design issues too.
> just that we should try to learn from mistakes we see around us.
>

Good point! So, change "design" to ...  OR  Just remove the "design"
verb... !?

Nikos

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

[Nikos Alexandris]

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 I'd use the word "designed" that way, AFAIK that
> > structure was designed long before datum support was even thought
> > about for GRASS. it's just a matter of enforcing consistency
> > as a way to keep a complicated job from getting all muddled up.

> > fwiw in GRASS 5 there is some contrib code from Lockheed Martin
> > to change the projection of the display window at runtime.
 
> > also I don't mean to rag on other GISs too much, obviously we
> > are not some perfection and have many bugs and design issues too.
> > just that we should try to learn from mistakes we see around us.


Nikos:
> Good point! So, change "design" to ...  OR  Just remove the "design"
> verb... !?

Changed to:

"GRASS' logical database structure (one projection definition per
LOCATION) avoids 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."

Please correct if required. Thanks, Nikos
---

[1] http://grass.osgeo.org/wiki/Location_and_Mapsets

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

[Dylan Beaudette-2]

On Thu, Jul 2, 2009 at 12:07 AM, Hamish<[hidden email]> 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
> along doing their work, publishing their reports, only sometimes
> realizing that something has misaligned internally. Or ugly non-solutions
> like rubber sheet dragging to visually correct the misalignment without
> considering the real cause become taught as the de facto method in the
> workflow. (easier than teaching about ellipsoids and datum math)
>
> I admit it's not the same as theoretically it could be done correctly,
> but I sort of class it with the common request for scalebars or 1:xx,xxx
> map scale for lat/lon cartography. It sounds like a good idea, and lots
> of other software give the users what they demand there, but that doesn't
> mean it's valid or a good idea. For map projections it is not invalid,
> just really really hard to get right (probably because "right" is often
> a very subjective answer in geodetics).
>
>
> Hamish

Yes. I am probably preaching to the choir here, but I have seen this
time and time again in both GIS classes, along with faculty, making
these type of basic (but not obvious) mistakes. Seems like a good
idea, but usually results in confusing and mysterious errors when
processing the data.

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

[Timmie]

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