[GRASS-dev] Re: [GRASS-windows] Problems with Mapcanvas

[Glynn Clements]

Glynn Clements wrote:

> > > > Contents of PERMANENT/PROJ_INFO file:
> > > > 
> > > > name: Lambert Conformal Conic
> > > > proj: lcc
> > > > datum: nad83
> > > > ellps: grs80
> > > > lat_1: 36.16666666666666
> > > > lat_2: 34.33333333333334
> > > > lat_0: 33.75
> > > > lon_0: -79
> > > > x_0: 609601.22
> > > > y_0: 0
> > > > no_defs: defined
> > > > towgs84: 0.000,0.000,0.000
> > 
> > Glynn:
> > > That doesn't tell me the one thing I really need to know: whether
> > > there are CR characters in the file.
> > > 
> > > Try "od -t x1z PROJ_INFO"; look for any occurrences of "0d" in the
> > > output.
> > 
> > perhaps this patch helps:

[snip]

> Probably. Although we should also change the code which is putting the
> CRs there in the first place (assuming that's what's happening).

A followup confirms that it is happening:

> [dnewcomb at yoda2 grass]$ od -t x1z PROJ_INFO
> 0000000 6e 61 6d 65 3a 20 4c 61 6d 62 65 72 74 20 43 6f  >name: Lambert Co<
> 0000020 6e 66 6f 72 6d 61 6c 20 43 6f 6e 69 63 0d 0a 70  >nformal Conic..p<
> 0000040 72 6f 6a 3a 20 6c 63 63 0a 64 61 74 75 6d 3a 20  >roj: lcc.datum: <
> 0000060 6e 61 64 38 33 0a 65 6c 6c 70 73 3a 20 67 72 73  >nad83.ellps: grs<
> 0000100 38 30 0a 6c 61 74 5f 31 3a 20 33 36 2e 31 36 36  >80.lat_1: 36.166<
> 0000120 36 36 36 36 36 36 36 36 36 36 36 0a 6c 61 74 5f  >66666666666.lat_<
> 0000140 32 3a 20 33 34 2e 33 33 33 33 33 33 33 33 33 33  >2: 34.3333333333<
> 0000160 33 33 33 34 0a 6c 61 74 5f 30 3a 20 33 33 2e 37  >3334.lat_0: 33.7<
> 0000200 35 0a 6c 6f 6e 5f 30 3a 20 2d 37 39 0a 78 5f 30  >5.lon_0: -79.x_0<
> 0000220 3a 20 36 30 39 36 30 31 2e 32 32 0a 79 5f 30 3a  >: 609601.22.y_0:<
> 0000240 20 30 0a 6e 6f 5f 64 65 66 73 3a 20 64 65 66 69  > 0.no_defs: defi<
> 0000260 6e 65 64 0a 74 6f 77 67 73 38 34 3a 20 30 2e 30  >ned.towgs84: 0.0<
> 0000300 30 30 2c 30 2e 30 30 30 2c 30 2e 30 30 30 0a     >00,0.000,0.000.<
> 0000317
> [dnewcomb at yoda2 grass]$ od -t x1z PROJ_INFO|grep 0d
> 0000020 6e 66 6f 72 6d 61 6c 20 43 6f 6e 69 63 0d 0a 70  >nformal Conic..p<

For some reason, it's only the projection name which has the CR. That
suggests that the code which writes the file is okay, but the code
which gets the projection name is getting a CR.

If I understand this correctly, epsg_option.tcl uses "g.proj -c epsg=..." 
to create the location. That calls OSRImportFromProj4() and
GPJ_osr_to_grass(). The latter takes the value for proj= and looks it up
in the etc/projections file using G_lookup_key_value_from_file() (if it
isn't found, the "proj" value will also be used for "name").

AFAICT, the lookup is getting a CR on the end of the projection name.

Check the etc/projections file. If it can be viewed normally in Notepad,
then it has CRLF line endings (Notepad can't handle Unix-style LF line
endings).

-- 
Glynn Clements <glynn at gclements.plus.com>