[GRASS5] sites problem/bug?

GRASS GRASS developer
1

Hi,

i have a problem with a sites file. I can import the file with grass4.3
(and export and display it) with s.in.ascii, s.out.ascii and d.sites,
but on grass 5.0 i get on importing or exporting a "WARNING: error
scanning floating point attribute" and the resulting sites file is
empty.

The format is e. g.:
16.00000 45.800000 "String"
-1.05000 41.667000 "String"
..

If i import with grass4.3 or write the format with the "|" separator
myself with a perl program, s.out.ascii and d.sites work within
grass5.0beta.

I am getting mad about those inconsistencies with the sites format. I
consider this as a very annoying bug, but if someone knows a workaround,
please tell me.

cu,

Andreas

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

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

On Sun, Oct 08, 2000 at 03:18:18PM +0200, Andreas Lange wrote:

Hi,

i have a problem with a sites file. I can import the file with grass4.3
(and export and display it) with s.in.ascii, s.out.ascii and d.sites,
but on grass 5.0 i get on importing or exporting a "WARNING: error
scanning floating point attribute" and the resulting sites file is
empty.

The format is e. g.:
16.00000 45.800000 "String"
-1.05000 41.667000 "String"
..

If i import with grass4.3 or write the format with the "|" separator
myself with a perl program, s.out.ascii and d.sites work within
grass5.0beta.

I am getting mad about those inconsistencies with the sites format. I
consider this as a very annoying bug, but if someone knows a workaround,
please tell me.

Yes, s.in.ascii is still buggy. I did some small patches to it, but
it's still buggy. I don't think I can really fix this without rewriting
the program. I think the parsing makes too many assumptions about the
input. Also, I did notice the grassprogman.pdf says, unprefixed
attributes should be treated as strings, but s.in.ascii tries to import
them as doubles. It still seems buggy about whether there is a cat
number or not. Best bet, for the moment, make sure all entries have a
cat number and all attributes are prefixed with either an '@' for
string, or an '%' for numeric.

Since I've gotten rather familiar with site_list processing lately, I
could change the behavior to default to string attributes rather than
doubles and generally rewrite the module. Or be even slicker, try to
convert unknown attributes to doubles, and if it fails, save them as
strings.

In the future, I hope to see sites go away completely in favor of
attribute tables associated with vector objects (area, line, node,...).

<example sites that will work>

GRASS:~ > s.in.ascii d=2 sites=site1
23.0098 34.123 #1 %99 @"My big long string"
end

GRASS:~ > s.in.ascii d=2 sites=site3
303.999 12345.09 #5 909.99
end

</example>

<example sites that fail>

GRASS:~ > s.in.ascii d=3 sites=site2
-120.098 33.987 23.45 %99.88
end

GRASS:~ > s.in.ascii d=2 sites=site4
900.234 67.34 #1 "my string"
end

</example>

--
/bin/sh ~/.signature:
Command not found

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

3

Hi Eric,

thank you for your answer, i know now that the problem is located with
the string attribute, which was not obvious at first from the error
message.

I don't think that the sites format should go completely, because it
makes small, timesaving hacks possible and is very intuitive. For many
types of data (samples in ecology etc.) a simple point format is
sufficient and convinient (IMHO). Topologically the point format would
belong to vectors, but i think that many functions in GRASS are only
available with the sites modules, so that it would be a lot of work to
reimplement those with vector modules. I don't want to miss the sites
files in GRASS.

cu,

Andreas

Eric G . Miller wrote:

On Sun, Oct 08, 2000 at 03:18:18PM +0200, Andreas Lange wrote:
> Hi,
>
> i have a problem with a sites file. I can import the file with grass4.3
> (and export and display it) with s.in.ascii, s.out.ascii and d.sites,
> but on grass 5.0 i get on importing or exporting a "WARNING: error
> scanning floating point attribute" and the resulting sites file is
> empty.
>
> The format is e. g.:
> 16.00000 45.800000 "String"
> -1.05000 41.667000 "String"
> ..
>
> If i import with grass4.3 or write the format with the "|" separator
> myself with a perl program, s.out.ascii and d.sites work within
> grass5.0beta.
>
> I am getting mad about those inconsistencies with the sites format. I
> consider this as a very annoying bug, but if someone knows a workaround,
> please tell me.

Yes, s.in.ascii is still buggy. I did some small patches to it, but
it's still buggy. I don't think I can really fix this without rewriting
the program. I think the parsing makes too many assumptions about the
input. Also, I did notice the grassprogman.pdf says, unprefixed
attributes should be treated as strings, but s.in.ascii tries to import
them as doubles. It still seems buggy about whether there is a cat
number or not. Best bet, for the moment, make sure all entries have a
cat number and all attributes are prefixed with either an '@' for
string, or an '%' for numeric.

Since I've gotten rather familiar with site_list processing lately, I
could change the behavior to default to string attributes rather than
doubles and generally rewrite the module. Or be even slicker, try to
convert unknown attributes to doubles, and if it fails, save them as
strings.

In the future, I hope to see sites go away completely in favor of
attribute tables associated with vector objects (area, line, node,...).

<example sites that will work>

GRASS:~ > s.in.ascii d=2 sites=site1
23.0098 34.123 #1 %99 @"My big long string"
end

GRASS:~ > s.in.ascii d=2 sites=site3
303.999 12345.09 #5 909.99
end

</example>

<example sites that fail>

GRASS:~ > s.in.ascii d=3 sites=site2
-120.098 33.987 23.45 %99.88
end

GRASS:~ > s.in.ascii d=2 sites=site4
900.234 67.34 #1 "my string"
end

</example>

--
/bin/sh ~/.signature:
Command not found

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

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

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

Hi all,

I just don't know how to code NULL in a sites list with
floating point data...

Example:

3570018.250000|5766419.000000|-35|%0.86
3570018.250000|5766419.000000|-45|%1.04
3570018.250000|5766419.000000|-110|%*
                                   ^^ this shall be no data.

Is that correct?

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

5

On Wed, Oct 11, 2000 at 04:18:55PM +0100, Markus Neteler wrote:

Hi all,

I just don't know how to code NULL in a sites list with
floating point data...

Example:

3570018.250000|5766419.000000|-35|%0.86
3570018.250000|5766419.000000|-45|%1.04
3570018.250000|5766419.000000|-110|%*
                                   ^^ this shall be no data.

Is that correct?

Yes, but how will code check for any NULL attribute? I don't think the
current library functions will allow NULLs for any attribute. It's
probably a good idea to allow, but library functions will have to be
modified (not to mention modules). Can we rely on using NAN to indicate
a NULL value for a double and a zero-length string for NULL string
attributes? I know there are problems using NAN on older systems.

Still, I think we should allow it, since it's completely logical that a
site may not have a value for a particular attribute while others do.
If the library functions are modified, I don't think we need to
introduce yet another special character into the site_list file format.
Simply having the metacharacter followed by a space should be enough to
flag a NULL attribute. The library functions need to be taught that
this is okay.

3567.1234|1234.567|#1 % %234.45 @"my label" @"alt name"
12345.009|1254.234|#2 %23.54 %22.123 @"the label" @

--
/bin/sh ~/.signature:
Command not found

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

6

On Wed, Oct 11, 2000 at 08:31:11AM -0700, Eric G . Miller wrote:

On Wed, Oct 11, 2000 at 04:18:55PM +0100, Markus Neteler wrote:
> Hi all,
>
> I just don't know how to code NULL in a sites list with
> floating point data...
>
> Example:
>
> 3570018.250000|5766419.000000|-35|%0.86
> 3570018.250000|5766419.000000|-45|%1.04
> 3570018.250000|5766419.000000|-110|%*
> ^^ this shall be no data.
>
> Is that correct?

Yes, but how will code check for any NULL attribute? I don't think the
current library functions will allow NULLs for any attribute. It's
probably a good idea to allow, but library functions will have to be
modified (not to mention modules). Can we rely on using NAN to indicate
a NULL value for a double and a zero-length string for NULL string
attributes? I know there are problems using NAN on older systems.

Maybe we should allow two values:

-9999 (for all data coming from ESRI world)
NAN (but this is a strings?!)

I would be glad if NULL support is there in sites format. At least
s.in.ascii, s.to.rast and s.to.vect should accept it.

Still, I think we should allow it, since it's completely logical that a
site may not have a value for a particular attribute while others do.
If the library functions are modified, I don't think we need to
introduce yet another special character into the site_list file format.
Simply having the metacharacter followed by a space should be enough to
flag a NULL attribute. The library functions need to be taught that
this is okay.

3567.1234|1234.567|#1 % %234.45 @"my label" @"alt name"
12345.009|1254.234|#2 %23.54 %22.123 @"the label" @

This sounds good to me.

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

7

Hi all,

I have removed all local HTML/MAN files as their location
is now:
html/html/

This prevents us from having concurrent man pages. Certainly
I have done comparisons (and partly updates in html/html)
before removing from CVS.

Some 60 file are affected.

In case you add a module or update a module, put/update the
docs in HTML format in html/html/ directory. The MAN format will
be generated by a script (if working o.k. the entire man/ and
cat/ sections can be removed from CVS).

In GRASS 5.1devel we might change to XML or something else.

Hope this is alright with you

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

8

On Wed, Oct 11, 2000 at 06:36:01PM +0100, Markus Neteler wrote:
<snip>

Maybe we should allow two values:

-9999 (for all data coming from ESRI world)
NAN (but this is a strings?!)

I should clarify. NAN is used for floating point (double) variables
while resident in memory. Then:

  if (isnan(my_double)) { /* It's NULL */ }
  else { /* do work */ }

For strings:
  if (string[0] == '\0') { /* Empty string */ }

    or
      if (strlen(string) == 0) { /* Again */ }

Granted, in some contexts an empty string is not the same thing as a
NULL value, but I think it'll be easier to code around rather than
library functions returning a NULL pointer for a string attribute. I
don't know...

As far as the ESRI sentinel value -9999, it's an integer. I don't know
if they use such a thing for their floating point grids. I don't see
any reason to carry this around in the site file. Import or conversion
routines might want to look for it and do an appropriate translation.
I'm not sure where this fits in in relation to sites...

I think this change in behavior should be postponed to GRASS 5.1. I
suspect it will cause lots of code breakage (maybe I'm wrong?). It
depends how important people think this is. It's hovering around the
middle in my mind.

--
/bin/sh ~/.signature:
Command not found

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

9

Hi Eric, hi all,

On Wed, Oct 11, 2000 at 06:30:48PM -0700, Eric G . Miller wrote:

On Wed, Oct 11, 2000 at 06:36:01PM +0100, Markus Neteler wrote:
<snip>
> Maybe we should allow two values:
>
> -9999 (for all data coming from ESRI world)
> NAN (but this is a strings?!)

I should clarify. NAN is used for floating point (double) variables
while resident in memory. Then:

  if (isnan(my_double)) { /* It's NULL */ }
  else { /* do work */ }

For strings:
  if (string[0] == '\0') { /* Empty string */ }

    or
      if (strlen(string) == 0) { /* Again */ }

Granted, in some contexts an empty string is not the same thing as a
NULL value, but I think it'll be easier to code around rather than
library functions returning a NULL pointer for a string attribute. I
don't know...

As far as the ESRI sentinel value -9999, it's an integer. I don't know
if they use such a thing for their floating point grids. I don't see
any reason to carry this around in the site file. Import or conversion
routines might want to look for it and do an appropriate translation.
I'm not sure where this fits in in relation to sites...

If we can just have "nothing" for a int/float value, it would be o.k.
Then the user, if using ESRI world data, can just use a text editor
to replace the "-9999" by "". If the s.in.ascii could manage that?
But probably a parameter "nv" comparing to r.in.ascii would be better:

      nv String representing NULL value data cell
           default: *

Then we don't run into problems if several columns of floats with
partly missing values are there.

I think this change in behavior should be postponed to GRASS 5.1. I
suspect it will cause lots of code breakage (maybe I'm wrong?). It
depends how important people think this is. It's hovering around the
middle in my mind.

Ok. We postpone it. Bugfixing is more important at time.

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

10

On my laptop, the tcltkgrass menu does not display fully. I can only
see the 'ui' of the 'Quit' command and the sub-menus that pop-up to the
side do not display properly for those menu choices on the right side of
the menu bar.

take care
tim cera

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

11

On Thu, Oct 12, 2000 at 06:51:16AM -0500, Tim Cera wrote:

On my laptop, the tcltkgrass menu does not display fully. I can only
see the 'ui' of the 'Quit' command and the sub-menus that pop-up to the
side do not display properly for those menu choices on the right side of
the menu bar.

Try changing the fonts. The command is on the left side. But, given the
width of the menu bar, perhaps it should be split?

--
/bin/sh ~/.signature:
Command not found

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

12

Hi,

another hint: You can tear-off menues you are using frequently by
clicking on the dotted line at the top of the menue.

I personally think that a vertical menue (like the toolbar in the GIMP)
would be better (consider the monitor ratio!), perhaps with icons
instead of txt?

If someone has ideas about this please tell the list.

cu,

Andreas

Eric G . Miller wrote:

On Thu, Oct 12, 2000 at 06:51:16AM -0500, Tim Cera wrote:
>
> On my laptop, the tcltkgrass menu does not display fully. I can only
> see the 'ui' of the 'Quit' command and the sub-menus that pop-up to the
> side do not display properly for those menu choices on the right side of
> the menu bar.
>

Try changing the fonts. The command is on the left side. But, given the
width of the menu bar, perhaps it should be split?

--
/bin/sh ~/.signature:
Command not found

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

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

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'