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

Doug_Newcomb@fws.gov wrote:

I'm having trouble viewing any datasets on the map canvas. When I "Enter
GRASS" I get the following message popping up :

can't read "end": no such variable
can't read "end": no such variable
    while executing
"string trim $parts(projection) $end"
    (procedure "MapCanvas::runprograms" line 47)

The code (mapcanvas.tcl:593) is:

    # Finally put this into wind file format to use with GRASS_REGION
    regexp -nocase {^.* (\(.*\))} $parts(projection) trash end
    set parts(projection) [string trim $parts(projection) $end]

It should be checking the return value from regexp before trying to
use the match variables.

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

Doug_Newcomb@fws.gov wrote:

> > I'm having trouble viewing any datasets on the map canvas. When I "Enter
> > GRASS" I get the following message popping up :
> >
> > can't read "end": no such variable
> > can't read "end": no such variable
> > while executing
> > "string trim $parts(projection) $end"
> > (procedure "MapCanvas::runprograms" line 47)
>
> The code (mapcanvas.tcl:593) is:
>
> # Finally put this into wind file format to use with GRASS_REGION
> regexp -nocase {^.* (\(.*\))} $parts(projection) trash end
> set parts(projection) [string trim $parts(projection) $end]
>
> It should be checking the return value from regexp before trying to
> use the match variables.

      The regions that I entered were created using the startup tool with
the EPSG code and Georefernced file options. Based on your feedback below,
I created a new mapset using qgis 0.9. I was then able to open the new
mapset in GRASS without the error message.

       Could there be a problem with the way that the startup menu creates
new regions/mapsets from EPSG codes and Georeferenced files?

Possibly. It would be useful to see the output from "g.region -up"
for a non-working location.

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

Doug_Newcomb@fws.gov wrote:

Output from g.region -up for problem region:

projection: 99 (Lambert Conformal Conic
)

So, there is actually a newline before the closing parenthesis?

What is in the PERMANENT/PROJ_INFO file?

My first guess is that the code which creates the broken locations is
writing the PROJ_INFO file with CRLF line terminators. The CR is
making its way into the projection name, then getting converted to a
LF later.

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

Doug_Newcomb@fws.gov 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

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.

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

Doug_Newcomb 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:

Index: lib/gis/key_value2.c

RCS file: /home/grass/grassrepository/grass6/lib/gis/key_value2.c,v
retrieving revision 2.3
diff -u -r2.3 key_value2.c
--- lib/gis/key_value2.c 14 Apr 2007 23:01:59 -0000 2.3
+++ lib/gis/key_value2.c 21 Nov 2007 01:11:54 -0000
@@ -32,7 +32,7 @@
     kv = G_create_key_value();
     if (kv == NULL)
        return NULL;
- while (G_getl(buf, sizeof buf, fd) != 0)
+ while (G_getl2(buf, sizeof buf, fd) != 0)
     {
        key = value = buf;
        while (*value && *value != ':')

also, should that be using "(buf, sizeof(buf)-1, fd" ?

Hamish

      ____________________________________________________________________________________
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

Hamish 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:

Index: lib/gis/key_value2.c

RCS file: /home/grass/grassrepository/grass6/lib/gis/key_value2.c,v
retrieving revision 2.3
diff -u -r2.3 key_value2.c
--- lib/gis/key_value2.c 14 Apr 2007 23:01:59 -0000 2.3
+++ lib/gis/key_value2.c 21 Nov 2007 01:11:54 -0000
@@ -32,7 +32,7 @@
     kv = G_create_key_value();
     if (kv == NULL)
        return NULL;
- while (G_getl(buf, sizeof buf, fd) != 0)
+ while (G_getl2(buf, sizeof buf, fd) != 0)
     {
        key = value = buf;
        while (*value && *value != ':')

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

For 7.x, we should probably just rename G_getl2 -> G_getl. There can't
be many cases where we actually want to read native line ends.

also, should that be using "(buf, sizeof(buf)-1, fd" ?

Yes and no. The current behaviour of G_getl2() requires it, but it's
G_getl2() which should be changed to match G_getl(), fgets() etc.

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

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

Hamish:

> perhaps this patch helps:
>
> Index: lib/gis/key_value2.c
> ===================================================================
> RCS file: /home/grass/grassrepository/grass6/lib/gis/key_value2.c,v
> retrieving revision 2.3
> diff -u -r2.3 key_value2.c
> --- lib/gis/key_value2.c 14 Apr 2007 23:01:59 -0000 2.3
> +++ lib/gis/key_value2.c 21 Nov 2007 01:11:54 -0000
> @@ -32,7 +32,7 @@
> kv = G_create_key_value();
> if (kv == NULL)
> return NULL;
> - while (G_getl(buf, sizeof buf, fd) != 0)
> + while (G_getl2(buf, sizeof buf, fd) != 0)
> {
> key = value = buf;
> while (*value && *value != ':')

Probably.

applied in 6.3 HEAD & the 6.3.0 r.b.

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

lib/gis/key_value2.c has G_fwrite_key_value(), but that does this:
  fprintf (fd, "%s: %s\n",

r.in.gdal uses that through G_make_location()
The other way to make a new location is through g.proj -c (GUI startup screen
uses this) but that uses G_write_key_value_file() too, as does g.setproj.

?

For 7.x, we should probably just rename G_getl2 -> G_getl. There can't
be many cases where we actually want to read native line ends.

fine with me.

> also, should that be using "(buf, sizeof(buf)-1, fd" ?

Yes and no. The current behaviour of G_getl2() requires it, but it's
G_getl2() which should be changed to match G_getl(), fgets() etc.

fine with me.

Towards a goal of read sloppy & write strict, these places in lib/gis still use
G_getl() and fgets(), and should be reviewed for a possible change to
G_getl2():

lib/gis$ grep 'G_getl\|fgets' *.c | grep -v 'G_getl2\|getl.c:'
cats.c: if (G_getl(buff,sizeof buff,fd) == 0)
cats.c: if (G_getl(buff,sizeof buff,fd) == 0)
cats.c: if (G_getl(fmt,sizeof fmt,fd) == 0)
cats.c: if (G_getl(buff,sizeof buff,fd) == 0)
cats.c: if (G_getl(buff, sizeof buff, fd) == 0)
cell_title.c: if (!fgets(title, sizeof title, fd)) /* skip number of cats
*/
cell_title.c: else if (!G_getl(title, sizeof title, fd)) /* read title
*/
color_read.c: if (fgets(buf,sizeof buf,fd) == NULL)
color_read.c: if (fgets(buf,sizeof buf,fd) == NULL)
color_read.c: while (fgets(buf, sizeof buf, fd))
color_read.c: if (fgets(buf,sizeof buf,fd) == NULL)
color_read.c: while (fgets (buf, sizeof buf, fd))
color_rules.c: if (!fgets(buf, sizeof(buf), fp))
dig_title.c: if (!fgets(title, sizeof title, fd)) /* skip number of cats
*/
dig_title.c: else if (!G_getl(title, sizeof title, fd)) /* read title
*/
error.c: if (fgets(cwd, sizeof(cwd), pwd))
gets.c: eof = fgets(p,100,stdin);
histogram.c: while (fgets (buf, sizeof buf, fd))
history.c: if (!G_getl(hist->mapid, sizeof(hist->mapid), fd))
history.c: if (!G_getl(hist->title, sizeof(hist->title), fd))
history.c: if (!G_getl(hist->mapset, sizeof(hist->mapset), fd))
history.c: if (!G_getl(hist->creator, sizeof(hist->creator), fd))
history.c: if (!G_getl(hist->maptype, sizeof(hist->maptype), fd))
history.c: if (!G_getl(hist->datsrc_1, sizeof(hist->datsrc_1), fd))
history.c: if (!G_getl(hist->datsrc_2, sizeof(hist->datsrc_2), fd))
history.c: if (!G_getl(hist->keywrd, sizeof(hist->keywrd), fd))
history.c: (G_getl( hist->edhist[hist->edlinecnt], sizeof
(hist->edhist[0]), fd)))
myname.c: ok = G_getl(name, sizeof name, fd);
parser.c: if(fgets(buff,1024,stdin) == 0) exit(EXIT_SUCCESS); ;
put_title.c: for (line = 0; G_getl (buf, sizeof buf, in); line++)
put_title.c: while (fgets(buf, sizeof buf, in))
quant_io.c: while (fgets (buf, sizeof (buf), fd))
range.c: if (!fgets (buf, sizeof buf, fd))
rd_cellhd.c: while ( G_getl (buf, sizeof (buf), fd) ) count++;
rd_cellhd.c: while ( G_getl (buf, sizeof (buf), fd) )
reclass.c: for (i=0; !feof(fd) && fgets(buf2, 255, fd); )
reclass.c: if (fgets(buf,sizeof(buf),fd) == NULL)
reclass.c: if (fgets(buf,sizeof buf,fd) == NULL)
reclass.c: for (i=0; !feof(fd) && fgets(buf3, 255, fd); )
reclass.c: while (fgets (buf, sizeof buf, fd))
squeeze.c: * Also squeezes out newlines -- easier to use with fgets()
timestamp.c: while (fgets(buf, sizeof(buf), fd))
view.c: if(NULL != fgets(buffer, 80, fp)){
view.c: while(NULL != fgets(buffer, 75, fp)){
view.c: if(1 == sscanf(fgets(buffer, 80, fp),"%f",&(v->from_to[1][0])) )
view.c: if(1 == sscanf(fgets(buffer, 80, fp),"%f",&(v->from_to[1][1])) )
view.c: if(1 == sscanf(fgets(buffer, 80, fp),"%f",&(v->from_to[1][2])) )
view.c: if(1 == sscanf(fgets(buffer, 80, fp),"%f",&(v->from_to[0][0])) )
view.c: if(1 == sscanf(fgets(buffer, 80, fp),"%f",&(v->from_to[0][1])) )
view.c: if(1 == sscanf(fgets(buffer, 80, fp),"%f",&(v->from_to[0][2])) )
view.c: if(1 == sscanf(fgets(buffer, 80, fp),"%f",&(v->exag)) )
view.c: sscanf(fgets(buffer, 80, fp),"%d",&(v->mesh_freq)) ;
view.c: if(1 == sscanf(fgets(buffer, 80, fp),"%f",&(v->fov)) )
view.c: if(1 == sscanf(fgets(buffer, 80, fp),"%lf",&td) ){ /* resolution */
view.c: sscanf(fgets(buffer, 80, fp),"%s",boo) ; /* linesonly */
view.c: sscanf(fgets(buffer, 80, fp),"%s",boo) ;
view.c: sscanf(fgets(buffer, 80, fp),"%s",v->grid_col) ;
view.c: sscanf(fgets(buffer, 80, fp),"%s",v->other_col) ;
view.c: sscanf(fgets(buffer, 80, fp),"%s",v->bg_col) ;
view.c: sscanf(fgets(buffer, 80, fp),"%s",boo) ;

Hamish

      ____________________________________________________________________________________
Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs

Hamish wrote:

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

lib/gis/key_value2.c has G_fwrite_key_value(), but that does this:
  fprintf (fd, "%s: %s\n",

r.in.gdal uses that through G_make_location()
The other way to make a new location is through g.proj -c (GUI startup screen
uses this) but that uses G_write_key_value_file() too, as does g.setproj.

?

G_write_key_value_file() does fopen(file, "w"). Normally, I would
expect this to open the file in text mode (with platform EOL
conversions), although I don't know if the _fmode=O_BINARY setting
affects this.

But then G_read_key_value_file() also opens the file in text mode, so
I'm not really sure what's going on.

> > also, should that be using "(buf, sizeof(buf)-1, fd" ?
>
> Yes and no. The current behaviour of G_getl2() requires it, but it's
> G_getl2() which should be changed to match G_getl(), fgets() etc.

fine with me.

I'll change this in CVS.

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

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@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@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@gclements.plus.com>

On Tue, 27 Nov 2007, Glynn Clements wrote:

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

I'd be surprised if it doesn't - it should be included in the WinGRASS distribution umodified from the CVS checkout - and as the CVS checkout will have been done on Windows, the file will have CRLF endings.

I suppose there might be more issues like this, perhaps more obscure ones. When I was testing GRASS on Windows I gave up trying to find them all and changed G_getl() to be a wrapper around G_getl2()..

Paul