[GRASS5] r.to.sites: change proposal for -a

GRASS GRASS developer
1

Hi all,

a proposal for r.to.sites:
Currently when converting raster data to sites format you
get a list like this:

3571556.25|5775981.25|#106
3571731.25|5775981.25|#123.8
3572243.75|5775981.25|#109.5
3570556.25|5775968.75|#132.5

Here we have two problems:
- #cat may be INT only
- usually you want %doubles format in sites list

I didn't read all the earlier messages, but last I knew,
cat can be any RASTER_MAP_TYPE. Did you change this?

- Bill

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

2

On Tue, Oct 24, 2000 at 08:38:04AM -0500, Bill Brown - staff wrote:

>
>Hi all,
>
>a proposal for r.to.sites:
>Currently when converting raster data to sites format you
>get a list like this:
>
>3571556.25|5775981.25|#106
>3571731.25|5775981.25|#123.8
>3572243.75|5775981.25|#109.5
>3570556.25|5775968.75|#132.5
>
>Here we have two problems:
> - #cat may be INT only
> - usually you want %doubles format in sites list
>

I didn't read all the earlier messages, but last I knew,
cat can be any RASTER_MAP_TYPE. Did you change this?

Hi Bill,

I didn't change that, was just guessing (I should read the programmer's
manual). But I am expecting problems with s.surf.rst & friends if it is not
stored as %double. Or am I wrong?

The s.info only accepts INT cats:
s.info ktb12.5
[...]
Number of DIMENSIONS: 2
--------------------
                 - - MIN - - - - MAX - -
        dim 1 3558006.250000 3574281.250000 Easting
        dim 2 5756006.250000 5775993.750000 Northing

Type of CATEGORY information: CELL_TYPE
----------------------------
                 - - MIN - - - - MAX - -
                          80 370 No Label
[...]
although there are double cats. At least this is inconsistent
currently.

And if I want to reconvert the list back to raster with s.to.rast,
this module will make an INT raster map:
s.to.rast in=ktb12.5 out=test
Using size option: 0
Finding and opening site list...

ERROR: selected decimal field column no. 1 not present in sites list.

If interpolating, the s.surf.rst is also expecting doubles:
s.surf.rst help
[...]
     input Name of the site file with input x|y|%z [%sm]

So it might be easier to modify the r.to.sites than all the other site
modules.

My 0.02 Euro...

Regards
Markus

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

3

I didn't change that, was just guessing (I should read the programmer's
manual). But I am expecting problems with s.surf.rst & friends if it is not
stored as %double. Or am I wrong?

Yes, you currently need to use r.to.sites -a if you want to
generate input for s.surf.rst. I imagine though that there
are a lot of existing scripts out there that expect r.to.sites
to generate # by default, so I have no problem with specifying -a
if I know I need input for s.surf.rst. It's not too hard to
convert # to % using vi or awk, if you have an old site list
you want to use, but it would be much better if somebody
would write this program:
http://www2.gis.uiuc.edu:2280/modviz/grass5/s.format.html

The s.info only accepts INT cats:
s.info ktb12.5
[...]
Number of DIMENSIONS: 2
--------------------
                - - MIN - - - - MAX - -
       dim 1 3558006.250000 3574281.250000 Easting
       dim 2 5756006.250000 5775993.750000 Northing

Type of CATEGORY information: CELL_TYPE
----------------------------
                - - MIN - - - - MAX - -
                         80 370 No Label
[...]

mine accepts FCELL_TYPE:

      Type of CATEGORY information: FCELL_TYPE
      ----------------------------
           - - MIN - - - - MAX - -
        1.100000 5.500000

I think the way the sites library tries to decide if the # is an
int or float is to just read the first one and take a guess by
using a decimal point as a clue. If the first site CAT doesn't have
a decimal, it reads them all as ints so you have to make sure to
use a format that will print the cats as floats (1.0 rather than 1)
when you are generating a fp site list. The sites library expects
consistant site lists - the number and types of attributes must be
consistant and the first site is used to guess what it is. There is
a format field in the header but I'm not sure what it's used for and
it doesn't allow specifying the type of the CAT.

And if I want to reconvert the list back to raster with s.to.rast,
this module will make an INT raster map:

That's because it is still using the sites library to guess the cat
type.

Hope this helps -

Bill

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

4

On Tue, Oct 24, 2000 at 11:27:50AM -0500, Bill Brown - staff wrote:

>
>I didn't change that, was just guessing (I should read the programmer's
>manual). But I am expecting problems with s.surf.rst & friends if it is not
>stored as %double. Or am I wrong?

Yes, you currently need to use r.to.sites -a if you want to
generate input for s.surf.rst. I imagine though that there
are a lot of existing scripts out there that expect r.to.sites
to generate # by default, so I have no problem with specifying -a
if I know I need input for s.surf.rst. It's not too hard to
convert # to % using vi or awk, if you have an old site list
you want to use, but it would be much better if somebody
would write this program:
http://www2.gis.uiuc.edu:2280/modviz/grass5/s.format.html

Bill,

thanks for your notes. Why I am insiting here is that I want to
get it as convenient as possible. I am thinking of all the new
users (or lazy users) who say: "Why should I always add -a
if the GRASS could do it for me?"

>
>The s.info only accepts INT cats:
>s.info ktb12.5
>[...]
>Number of DIMENSIONS: 2
>--------------------
> - - MIN - - - - MAX - -
> dim 1 3558006.250000 3574281.250000 Easting
> dim 2 5756006.250000 5775993.750000 Northing
>
>Type of CATEGORY information: CELL_TYPE
>----------------------------
> - - MIN - - - - MAX - -
> 80 370 No Label
>[...]

mine accepts FCELL_TYPE:

      Type of CATEGORY information: FCELL_TYPE
      ----------------------------
           - - MIN - - - - MAX - -
        1.100000 5.500000

Aha! It seems you have a different version. Would you share it?

I think the way the sites library tries to decide if the # is an
int or float is to just read the first one and take a guess by
using a decimal point as a clue. If the first site CAT doesn't have
a decimal, it reads them all as ints so you have to make sure to
use a format that will print the cats as floats (1.0 rather than 1)
when you are generating a fp site list. The sites library expects
consistant site lists - the number and types of attributes must be
consistant and the first site is used to guess what it is. There is
a format field in the header but I'm not sure what it's used for and
it doesn't allow specifying the type of the CAT.

But this "guessing from the first" is quite error prone (like my
random example from previous mail). Of course it would be too time
consuming to parse the entire sites list to determine the format.

>
>And if I want to reconvert the list back to raster with s.to.rast,
>this module will make an INT raster map:

That's because it is still using the sites library to guess the cat
type.

O.k., but it does not fix the problem. :slight_smile:

I understand you prefer to keep the "-a" parameter? For me it's somewhat
inconvenient as most of the sites modules don't accept site lists
generated without "-a"...

Kind regards

Markus

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

5

Aha! It seems you have a different version. Would you share it?

It's the grass5.0beta7 version I'm using - check your sites list
and see if your first site doesn't have a decimal. If not, try
adding ".0" to the first cat, then you should get FCELL_TYPE with
s.info.

But this "guessing from the first" is quite error prone (like my
random example from previous mail). Of course it would be too time
consuming to parse the entire sites list to determine the format.

Yes, it would be better if every sites file had a format in the header
and there was also a CAT type specified in the header. But then all of
the old site lists would be incompatible. The "guess by first" was done
mostly for backward compatibility, as was the need to use -a in
r.to.sites. It is not a very good solution.
I also noticed that G__site_put uses %g when printing fp attributes,
so you can get "1" instead of "1.0". I guess the only way to make sure
it writes a decimal would be to use %#g which will write several zeros.

I understand you prefer to keep the "-a" parameter? For me it's somewhat
inconvenient as most of the sites modules don't accept site lists
generated without "-a"...

It's just not backward compatible, so you don't know what scripts and
programs you might break by doing it. You can always do it and then see
who complains... :-).

- Bill

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

6

The site list format spec. says FP cats are okay (though, I disagree
with this notion). It also says a cat is not required. The tricky
thing here is, if the raster is an INT type, then you really want to put
the value in the cat since there is no INT attribute type in the sites
spec. Automatically putting it in a '%' (decimal) field will cause it
to alway be interpreted as FP later. On the flip side, some modules are
not up to date with the current sites format (s.surf.rst is mentioned)
and expect a certain format. These modules should be updated so the
user can specify what attribute to use (it's often relatively easy
to add this functionality).

As far as r.to.sites goes, I'm favoring either writing a cat for CELL,
or writing a '%' for FCELL. I *really* don't like non-integer values
for the cat. It screws up conversion to vector which does not support
FP cats (and really can't).

Many of these problems could be cleanly resolved by implementing a
native attribute database in GRASS. Something like xBase would even
work. This is not a small task though.

--
#! /bin/sh
# ppp-address: What's my Internet Address for ppp0 ?
/sbin/ifconfig ppp0 2> /dev/null | grep 'inet addr:' | sed \
's=.*inet addr\:\([0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\).*=\1='

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

7

On Fri, Oct 27, 2000 at 07:08:12PM -0700, Eric G . Miller wrote:

The site list format spec. says FP cats are okay (though, I disagree
with this notion). It also says a cat is not required. The tricky
thing here is, if the raster is an INT type, then you really want to put
the value in the cat since there is no INT attribute type in the sites
spec. Automatically putting it in a '%' (decimal) field will cause it
to alway be interpreted as FP later. On the flip side, some modules are
not up to date with the current sites format (s.surf.rst is mentioned)
and expect a certain format. These modules should be updated so the
user can specify what attribute to use (it's often relatively easy
to add this functionality).

As far as r.to.sites goes, I'm favoring either writing a cat for CELL,
or writing a '%' for FCELL. I *really* don't like non-integer values
for the cat. It screws up conversion to vector which does not support
FP cats (and really can't).

Hi Eric, hi all,

I agree to restrict sites "#cat" to INT only. For me it is a sort of
index (and additionally common INT values). To store FP in cat
field is somewhat inconsistent as we have the %double, too.

My proposal is to change the specifications to have it more restrict.
Then "type guessing" is not required any more as only INT would be
allowed for #cat field.

For r.to.sites we could insert a switch for CELL and FCELL to
suppprt #cat resp. %double. Then the "-a" would not be required any
more for r.to.sites.

Bill, could you live with that?
As far as I see this restriction would not break anything.

Kind regards

Markus

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

8

Markus Neteler wrote:

On Fri, Oct 27, 2000 at 07:08:12PM -0700, Eric G . Miller wrote:
> The site list format spec. says FP cats are okay (though, I disagree
> with this notion). It also says a cat is not required. The tricky
> thing here is, if the raster is an INT type, then you really want to put
> the value in the cat since there is no INT attribute type in the sites
> spec. Automatically putting it in a '%' (decimal) field will cause it
> to alway be interpreted as FP later. On the flip side, some modules are
> not up to date with the current sites format (s.surf.rst is mentioned)
> and expect a certain format. These modules should be updated so the
> user can specify what attribute to use (it's often relatively easy
> to add this functionality).
>
> As far as r.to.sites goes, I'm favoring either writing a cat for CELL,
> or writing a '%' for FCELL. I *really* don't like non-integer values
> for the cat. It screws up conversion to vector which does not support
> FP cats (and really can't).
Hi Eric, hi all,

I agree to restrict sites "#cat" to INT only. For me it is a sort of
index (and additionally common INT values). To store FP in cat
field is somewhat inconsistent as we have the %double, too.

My proposal is to change the specifications to have it more restrict.
Then "type guessing" is not required any more as only INT would be
allowed for #cat field.

For r.to.sites we could insert a switch for CELL and FCELL to
suppprt #cat resp. %double. Then the "-a" would not be required any
more for r.to.sites.

Bill, could you live with that?
As far as I see this restriction would not break anything.

Kind regards

Markus

Hi Markus, Eric, all

That's OK by me. The sites modules I have worked on only use CELL cats
anyway. Very little recoding would be needed.

Just a thought for a future idea. Something that is a bit annoying in
some contexts is that the numerical _attribute_ fields must always be
represented as fp, as Eric has pointed out. Could a new int type be
added to the struct so that it would be for example:

typedef struct
{
  double east, north;
  double *dim;
  int dim_alloc;
  CELL cat;
  int str_alloc;
  char **str_att;
  int dbl_alloc;
  double *dbl_att;
  int int_alloc;
  double *int_att;
} Site;

Maybe if that was the case, the cat field could be confined (by
convention though not by compulsion) to an index or key. I think this is
the way we want to go with vector data also. This would allow existing
modules to continue to use the cat, but modules could be changed at
leisure to use an int attribute while still allowing a cat to be
selected as a non-default option.

David

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

9

David D Gray wrote:

>

Hi Markus, Eric, all

That's OK by me. The sites modules I have worked on only use CELL cats
anyway. Very little recoding would be needed.

Just a thought for a future idea. Something that is a bit annoying in
some contexts is that the numerical _attribute_ fields must always be
represented as fp, as Eric has pointed out. Could a new int type be
added to the struct so that it would be for example:

typedef struct
{
  double east, north;
  double *dim;
  int dim_alloc;
  CELL cat;
  int str_alloc;
  char **str_att;
  int dbl_alloc;
  double *dbl_att;
  int int_alloc;
  int *int_att; <<<<<<<<<<
} Site;

Maybe if that was the case, the cat field could be confined (by
convention though not by compulsion) to an index or key. I think this is
the way we want to go with vector data also. This would allow existing
modules to continue to use the cat, but modules could be changed at
leisure to use an int attribute while still allowing a cat to be
selected as a non-default option.

David

The int attributes should be (int *) of course - please excuse the typo.

David

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

10

Markus, David,

That looks reasonable to me. I've used the cattype element
from the Site struct in a few programs so those would
need to be changed, and I have some data with FP cats
that would need to be converted.

As far as I know, the original intent was to make the cat
equivalent to RASTER_MAP_TYPE for r.to.sites and s.to.rast,
but since the consensus seems to be to add options to those
programs I think that would take care of it.

Conceptually an FP cat sort of elevates the importance of an
FP attribute and implies that other attributes depend on that
one but maybe nobody is really using them like that. It is
probably useful to keep an int cat in the structure for
potential use in a database lookup of some sort.

As for having multiple int attributes, I don't really see
much added functionality and it seems like it would require a
lot of recoding of existing programs. Programs that require
int site attributes could clearly document that the attribute
will be treated as int or else use the cat.

- Bill

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

11

On Mon, Oct 30, 2000 at 10:07:12AM -0600, Bill Brown - staff wrote:

As for having multiple int attributes, I don't really see
much added functionality and it seems like it would require a
lot of recoding of existing programs. Programs that require
int site attributes could clearly document that the attribute
will be treated as int or else use the cat.

- Bill

I concur with Bill. At this time, let's try to avoid changing
interfaces and concentrate on getting out a stable and useable 5.0.
They're plenty of modules that need updating fixing still...

--
#! /bin/sh
# ppp-address: What's my Internet Address for ppp0 ?
/sbin/ifconfig ppp0 2> /dev/null | grep 'inet addr:' | sed \
's=.*inet addr\:\([0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\).*=\1='

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