[GRASSLIST:2202] Re: Another problem with r.proj

[Rich Shepard]

On Sat, 28 Jul 2001, Eric G. Miller wrote:

> Hmm. I don't know why it is failing to get the projection info.  Are you
> sure your arguments for location, mapset and dbase are correct?  r.proj
> uses standard library functions to retrieve this information...

Eric,

  Yes. The pwd is the output location; that mapset it PERMANENT and contains
the description files for destination projection and units. It is this
$GISDBASE (the only one I have), location and mapset that are entered into
GRASS's opening screen. The source arguments are equally valid.

  If I understand the error message correctly, it's telling us two things:
1) this is the actual source of the error and not a red herring because the
code has no case for the real error, and 2) the problem is finding the
_output_ projection information, not the _input_ information. The output
projection information was created by r.in.gdal when it imported an
SDTS-format DEM ... which makes me wonder:

  The first file I'm trying to convert is a map of the PLSS (Public Land
Survey System. It _may_ be that the bounds of the PLSS map exceed that of
the DEM map. Would that cause r.proj to fail with an error sequence of:

cannot initialize pj
cause: projection not named
ERROR: Can't get projection key values of output map

?

  No, that does not appear to be the problem. The module cannot find its
pajamas, apparently, but the projection _is_ named in PROJ_INFO:

proj: utm
zone: 11
ellps: clrk66
datum: NAD27

  So, I wonder what "projection key values" it needs but cannot find.

  Because the current GRASS directory holds this information it does not
seem reasonable that r.proj should have difficulty finding it. Unless the
code has wandered somewhere else and is confused. Could it be age-related
senility? Modular Alzheimer's, perhaps?

> Well.  Neither option seems particularly convenient.  Rewriting the
> whole coordinate system management framework and associated projection
> routines has been discussed for 5.1.  It's sort of a hodgepodge of two
> different approaches right now, neither of which address datum
> transformations.

  I'll be happy to supply copies of my data (source and destination) for
anyone who wants to verify this behavior. By the same token, if it works for
someone else, then that suggests a problem somewhere else in GRASS.

> I dunno.  I still would ask that you double check your arguments to the
> command.  It seems it is not looking in the right place for projection
> info.

  I checked and checked long before posting to the list. What more can I
say?

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 at appl-ecosys.com
                 Making environmentally-responsible mining happen.