[GRASS5] r.proj doesn't seem to be working properly

GRASS GRASS developer
,
1

  You folks have been right on so far, so I'll ask this question now. And,
yes, I have read the man pages several times without seeing the answer.

  I used r.in.gdal to import a SDTS-formatted DEM. Because the source file
is projected in UTM and my project data are projected in State Plane
Coordinates, Nevada West Zone, I let r.in.gdal create a new location for the
translated files. It did.

  The project files are in: /mnt/usr4/projects/nevada/coeur/ and the new DEM
file(s) is in: /mnt/usr4/projects/temp/PERMANENT. So far, so good. When I
'ls ...' in the .../PERMANENT/cell/ directory, there's the dem file. But,
when I try to reproject and move it with r.proj this is what I see:

GRASS:/mnt/usr4/projects/nevada/coeur > r.proj input=rochester-dem
location=/mnt/usr4/projects/temp/ output=rochester-dem mapset=PERMANENT
method=cubic
ERROR: Mapset [PERMANENT] in input location [/mnt/usr4/projects/temp/] -
       not found

  I must be rather dense and missing something head-slappingly simple here,
but PERMANENT is there. Why isn't GRASS seeing it, and what do I do about
this?

Thanks,

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
                 Making environmentally-responsible mining happen.

2

On Wed, 25 Jul 2001, Rich Shepard wrote:

GRASS:/mnt/usr4/projects/nevada/coeur > r.proj input=rochester-dem
location=/mnt/usr4/projects/temp/ output=rochester-dem mapset=PERMANENT
method=cubic
ERROR: Mapset [PERMANENT] in input location [/mnt/usr4/projects/temp/] -
       not found

  As a follow up to my message:

  When I exit GRASS, re-start it and specify temp/PERMANENT as the location
and mapset, I can list and display the map. So, d.rast recognizes the
PERMANENT mapset, but r.proj appears not to.

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
                 Making environmentally-responsible mining happen.

3

Hi Rich,

the module r.proj does indeed work, at least partially.

What is confusing is that you must start r.proj from the mapset and
location you want the data to be projected to, not the location where
you the data are from. For the location parameter you only specify the
location name, so if your DATABASE is /mnt/usr4/projects, and your
location is nevada and the mapset is coeur, you would run:
r.proj in=rochester-dem location=tmp mapset=PERMANENT out=rochester-dem.

Please note that no map datum transformation is done. You should also
check that r.in.gdal created a correct PROJ_INFO file. There may be
other issues because the raster is resampled/interpolated in some way,
please refer to the man page.

If you need to reproject from another database dir you need the add.
datab-parameter dbase=/mnt/usr4/projects

This is all not very satisfying, i think that one could build a sort of
file - manager like interface with tcl/tk.

HTH,

Andreas

Rich Shepard wrote:

  You folks have been right on so far, so I'll ask this question now. And,
yes, I have read the man pages several times without seeing the answer.

  I used r.in.gdal to import a SDTS-formatted DEM. Because the source file
is projected in UTM and my project data are projected in State Plane
Coordinates, Nevada West Zone, I let r.in.gdal create a new location for the
translated files. It did.

  The project files are in: /mnt/usr4/projects/nevada/coeur/ and the new DEM
file(s) is in: /mnt/usr4/projects/temp/PERMANENT. So far, so good. When I
'ls ...' in the .../PERMANENT/cell/ directory, there's the dem file. But,
when I try to reproject and move it with r.proj this is what I see:

GRASS:/mnt/usr4/projects/nevada/coeur > r.proj input=rochester-dem
location=/mnt/usr4/projects/temp/ output=rochester-dem mapset=PERMANENT
method=cubic
ERROR: Mapset [PERMANENT] in input location [/mnt/usr4/projects/temp/] -
       not found

  I must be rather dense and missing something head-slappingly simple here,
but PERMANENT is there. Why isn't GRASS seeing it, and what do I do about
this?

Thanks,

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
                 Making environmentally-responsible mining happen.

_______________________________________________
grass5 mailing list
grass5@geog.uni-hannover.de
http://www.geog.uni-hannover.de/mailman/listinfo/grass5

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de - A.C.Lange@GMX.net

4

On Fri, 27 Jul 2001, Andreas Lange wrote:

What is confusing is that you must start r.proj from the mapset and
location you want the data to be projected to, not the location where you
the data are from. For the location parameter you only specify the
location name, so if your DATABASE is /mnt/usr4/projects, and your
location is nevada and the mapset is coeur, you would run: r.proj
in=rochester-dem location=tmp mapset=PERMANENT out=rochester-dem.

Andreas,

  The destination directory is from where I was running r.proj; I got that
from reading the man page. In my brief experience with GRASS I've learned
that sometimes it wants the full path rather than the current directory, so
I figure that providing an absolute path name is harmless (even though it
means more typing). But, I'll try your suggestion anyway.

  Bruce had me try some variants because I don't keep all my data in a
directory (location) called PERMANENT, and apparently GRASS is simple-minded
about this. After playing with this idea for a while today, I tarred the
entire data directory and shipped it down to Texas for him to examine.

  The problem is that regardless of my using absolute or relative paths, or
from what directory I invoke the module, r.proj can see the location but
cannot see the PERMANENT mapset beneath it. This appears to be a bug in
r.proj. I'll know better tomorrow.

Please note that no map datum transformation is done. You should also
check that r.in.gdal created a correct PROJ_INFO file. There may be
other issues because the raster is resampled/interpolated in some way,
please refer to the man page.

  I'm aware that r.proj does no datum transformation. Yet, I hope. :slight_smile: And,
r.in.gdal did create the suite of files properly.

If you need to reproject from another database dir you need the add.
datab-parameter dbase=/mnt/usr4/projects

  I'll need to look into this to make sure that I understand it. Thanks.

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
                 Making environmentally-responsible mining happen.

5

We have just installed GRASS5.00pre1 and it seems that that the nviz start-up
script was removed (or never put into release) and
nviz is called by nviz2.2 (and path must be given first). The script worked well
and was more convenient
than the old nviz2.2, I was wondering why it was removed. It was not the cause of
the crashes that I still
have (both when running nviz2.2 and nviz) and it seems that it is more LINUX7.1
problem rather than GRASS.
I believe that the script should be put back - or am I just confusing this release
with the newer CVS version?

thanks,

Helena

P.S. Just in case that somebody gets nviz crashing his machine randomly we have
found that it is happening somewhere
in the following part of the code (Bill things that it is togl, but I don't
understand these things at all). I am suspicious that it is
not a GRASS problem because nobody else seems to have that problem, but it happens
under various window managers
(KDE, GNOME Sawfish and Enlightment and so far only under LINUX7.1).

NVIZ2.2/scripts/nviz2.2_script

puts "toplevel made"

    ###########################################################################
    # make informational text widget
    ###########################################################################

    set Nv_(text) "Start"
    entry $BASE.entry -relief sunken -borderwidth 3 -state disabled \
        -textvariable Nv_(text)
    place $BASE.entry -relx 0 -relwidth .70 -rely 0
## glxwin $BASE.canvas -rgb true -db true -zbuffersize -1
    togl $BASE.canvas -rgba true -double true -depth true
    place $BASE.canvas -relx .01 -rely .03 -relwidth .98 -relheight .97

    bind $BASE.canvas <Expose> {Nv_expose %W}
    bind $BASE.canvas <Configure> {set Nv_(height) %h}
## bind $BASE.canvas <Configure> {if [%W islinked] {glx_viewport %w %h; \
                                                         set Nv_(height) %h}}
    update

# DEBUG
puts "info widget made"

6

Bob

I think that the script is there - sorry for the confusion - GRASS that did not have
the script
was from march 2001 but it was installed only yesterday by a grad student here - I
think that these older versions should not
be there at all so that people do not report bugs which have already been fixed. I had
people writing
me who have just installed beta11 which is really old.
My older version of GRASS which has the script was from May2001 so that is why I
thought that it
was removed.

I guess that we need to wait for Markus to get back on-line to put things into order.

thank you

Helena

Covill wrote:

Helena Mitasova wrote:
>
> >
>
> We have just installed GRASS5.00pre1 and it seems that that the nviz start-up
> script was removed (or never put into release) and
> nviz is called by nviz2.2 (and path must be given first). The script worked well
> and was more convenient
> than the old nviz2.2, I was wondering why it was removed. It was not the cause of
> the crashes that I still
> have (both when running nviz2.2 and nviz) and it seems that it is more LINUX7.1
> problem rather than GRASS.
> I believe that the script should be put back - or am I just confusing this release
> with the newer CVS version?
>
> thanks,
>
> Helena
>
> P.S. Just in case that somebody gets nviz crashing his machine randomly we have
> found that it is happening somewhere
> in the following part of the code (Bill things that it is togl, but I don't
> understand these things at all). I am suspicious that it is
> not a GRASS problem because nobody else seems to have that problem, but it happens
> under various window managers
> (KDE, GNOME Sawfish and Enlightment and so far only under LINUX7.1).
>
> NVIZ2.2/scripts/nviz2.2_script
>
> puts "toplevel made"
>
> ###########################################################################
> # make informational text widget
> ###########################################################################
>
> set Nv_(text) "Start"
> entry $BASE.entry -relief sunken -borderwidth 3 -state disabled \
> -textvariable Nv_(text)
> place $BASE.entry -relx 0 -relwidth .70 -rely 0
> ## glxwin $BASE.canvas -rgb true -db true -zbuffersize -1
> togl $BASE.canvas -rgba true -double true -depth true
> place $BASE.canvas -relx .01 -rely .03 -relwidth .98 -relheight .97
>
> bind $BASE.canvas <Expose> {Nv_expose %W}
> bind $BASE.canvas <Configure> {set Nv_(height) %h}
> ## bind $BASE.canvas <Configure> {if [%W islinked] {glx_viewport %w %h; \
> set Nv_(height) %h}}
> update
>
> # DEBUG
> puts "info widget made"
>

Helena,

The nviz script should not have been removed from CVS. I think the most
recent CVS branch is:
releasebranch_11_april_2001_5_0_0

If the file has been removed I can re-apply to CVS. My CVS system is
down right now so I cannot check the status. I will take a look at the
above TCL code to see where the crashes might be coming from.

--
Bob Covill

Tekmap Consulting
P.O. Box 2016 Fall River, N.S.
B2T 1K6
Canada

E-Mail: bcovill@tekmap.ns.ca
Phone: 902-860-1496
Fax: 902-860-1498

7

On Fri, Jul 27, 2001 at 03:03:03PM -0400, Helena Mitasova wrote:

We have just installed GRASS5.00pre1 and it seems that that the nviz
start-up script was removed (or never put into release) and nviz is
called by nviz2.2 (and path must be given first). The script worked
well and was more convenient than the old nviz2.2, I was wondering why
it was removed. It was not the cause of the crashes that I still have
(both when running nviz2.2 and nviz) and it seems that it is more
LINUX7.1 problem rather than GRASS. I believe that the script should
be put back - or am I just confusing this release with the newer CVS
version?

I don't know how much it matters, but Red Hat 7.1 uses that braindamaged
gcc-2.9.6. It may make a difference to compile from source (if you
aren't already). With the current tagged "april..." CVS, nviz is
working okay here (and using the shell script for start-up). Of course,
this is a "works for me" answer...

--
Eric G. Miller <egm2@jps.net>

8

Radim,

I am trying to take advantage of d.dm to look at my maps and it appears
that when a new monitor is opened the region
is set to the default region. Would it be possible to have it start with
the current region? My current region is much
smaller than the default and I have to zoom-in to see the map. Or am I
doing something wrong? (I was not lazy
and read the manual page).

And to the list - is anybody using d.dm (it is really nice)? What are you
using to view your data - do you go through tcltk or just
d.mon/d.rast. We are writing some instructional material with Markus and I
am trying to find out which new features
to include.

thanks

Helena