[GRASS5] readsites() TODO list...

GRASS GRASS developer
1

A week or so ago, I looked at the TODO list and thought I'd look into
this readsite() library function. I arrived at the conclusion that the
call would have to be different to support reading z-dim, double-att, or
strtod(string-att), for generating an *xyz struct. Anyway, I already
did one iteration that added support for the z-dim, but I wanted to put
up this call interface for comments. We could make it a readsites2()
and retain the other interface for awhile. I don't know how many
modules actually use readsites() at the moment. Anyway, please let me
know if the behaviors described here look awful (I'm still new to coding
for GRASS).

/* readsites: Reads a sites file converting to a site struct of xyz values.
* The Z value can come from one of the z-dimensions, a double attribute,
* or a string attribute converted to a double with strtod().
* If 'num' is less than one, attempt to read entire site file, otherwise
* read 'num' records. The number of records read is returned. If an
* error occurs, a negative value is returned. The caller can decide to
* abort or retry. Error values are:
* Couldn't allocate memory -1
* Attribute 'type' not found -2
* Attribute 'index' out of range -3
* Format error in file (includes conversion error) -4
* Something else (probably never happen) -5
*/

typedef struct _site {
  double x, y, z;
} site;

int readsites(
  FILE * fdsite, /* The FILE stream to the sites file */
  int num, /* Number of records to read */
  int type, /* Attribute type: 0 = Z-dim, 1 = double, 2 = string */
  int index, /* The field index (1 based) for the attribute */
  int * done, /* No more records in file? 0 = false, 1 = true */
  site **xyz /* The site array, caller must free between calls */
  );
  
--
/bin/sh ~/.signature:
Command not found

2

Hi Eric,

On Wed, Sep 20, 2000 at 03:09:24AM -0700, Eric G . Miller wrote:

A week or so ago, I looked at the TODO list and thought I'd look into
this readsite() library function. I arrived at the conclusion that the
call would have to be different to support reading z-dim, double-att, or
strtod(string-att), for generating an *xyz struct. Anyway, I already
did one iteration that added support for the z-dim, but I wanted to put
up this call interface for comments. We could make it a readsites2()
and retain the other interface for awhile. I don't know how many
modules actually use readsites() at the moment. Anyway, please let me
know if the behaviors described here look awful (I'm still new to coding
for GRASS).

thanks for taking care of this. Andreas Lange might be a potential
partner to assist as he already sent some ideas about "readsites" to
me.

Here is the list of modules to be modified:

src.contrib/CERL/sites/s.surf.krig/read_sites.c
src.contrib/GMSL/g3d/src3d/sites/s.to.rast3/read_sites.c
src.contrib/GMSL/g3d/src3d/sites/s.vol.idw/read_sites.c
src.contrib/NPS/v.circle/cmd/readsites.c
src.contrib/PURDUE/s.medp/readsites.c
src.garden/grass.rim/s.db.rim/cmd/read_sites.c
src.garden/grass.rim/s.db.rim/inter/read_sites.c
src/libes/gis/readsites.c
src/raster/r.surf.idw2/cmd/read_sites.c
src/sites/s.kcv/readsite.c
src/sites/s.menu/Lib/read_sites.c
src/sites/s.normal/readz.c
src/sites/s.probplt/readz.c
src/sites/s.qcount/readsite.c
src/sites/s.sample/readsite.c
src/sites/s.surf.idw/cmd/read_sites.c
src/sites/s.sv/readsite.c
src/sites/s.univar/readsite.c
src/mapdev/v.bubble/v.bubble.c

All these files/functions should be replaced by a common
G_readsites() function with attribute selection etc.

My "try" in src/libes/gis/readsites.c needs to be heavily
improved. It is currently used in
src/mapdev/v.bubble/v.bubble.c

only. Please feel free to modify the "new" GRASS API function and
to implement it in above modules replacing the individual readsite.c
files.

Thanks in advance

Markus

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

3

Hi all,

while compiling GRASS on a CRAY I found the problem that
there are local suspend() definitions in GRASS:

./src/imagery/i.points3/inter/dig_curses.c
557:suspend ()

./src/libes/vect32/georef/curses.c
269:int suspend (void)

./src/libes/vect32/georef/map_setup.c
28: suspend() ;

./src/mapdev/v.digit/customize.c
110: suspend ();
132: suspend ();
142: suspend ();

./src/mapdev/v.digit/dig_curses.c
617:int suspend (void)

./src/mapdev/v.digit/dig_curses.h
35:int suspend(void);

./src/mapdev/v.digit/toolbox.c
toolbox.c:67: suspend ();
toolbox.c:81: suspend ();
toolbox.c:142: suspend ();

CRAY: /usr/include/unistd.h
extern int suspend __((int _Category, int _Id));

Linux: /usr/include/unistd.h
*nothing*

GRASS internal:
int suspend (void)

I vote to change the "suspend()" calls in GRASS to "mysuspend()"
or similar to avoid such conflicts.

Will problems arise from such a change?

Markus

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

4

If you just want to read a bunch of Site structs, take a look
at load_cached_sites in src.contrib/GMSL/SG3d/sites.c and
see if that's any help.

- Bill

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

5

Hi Eric

I started work on upgrading the routines in s.surf.krig to Sites5 (and
other GRASS5 features). In fact I've completed this part to an initial
draft, though I have had thoughts about a generalised routine for
reading sites (I wasn't awre of readsites() ):

"Eric G . Miller" wrote:

A week or so ago, I looked at the TODO list and thought I'd look into
this readsite() library function. I arrived at the conclusion that the
call would have to be different to support reading z-dim, double-att, or
strtod(string-att), for generating an *xyz struct. Anyway, I already
did one iteration that added support for the z-dim, but I wanted to put
up this call interface for comments. We could make it a readsites2()
and retain the other interface for awhile. I don't know how many
modules actually use readsites() at the moment. Anyway, please let me
know if the behaviors described here look awful (I'm still new to coding
for GRASS).

/* readsites: Reads a sites file converting to a site struct of xyz values.
* The Z value can come from one of the z-dimensions, a double attribute,
* or a string attribute converted to a double with strtod().
* If 'num' is less than one, attempt to read entire site file, otherwise
* read 'num' records. The number of records read is returned. If an
* error occurs, a negative value is returned. The caller can decide to
* abort or retry. Error values are:
* Couldn't allocate memory -1
* Attribute 'type' not found -2
* Attribute 'index' out of range -3
* Format error in file (includes conversion error) -4
* Something else (probably never happen) -5
*/

typedef struct _site {
        double x, y, z;
} site;

Could we not just use the struct Site, it has all these fields and more
info? Arrays would not get over large because as I read your code, it is
intended to make multiple calls anyway.

int readsites(
        FILE * fdsite, /* The FILE stream to the sites file */
        int num, /* Number of records to read */

Perhaps this could be for maximum number of records per call. Extraneous
conditions or EOF might interrupt the read sequence.

        int type, /* Attribute type: 0 = Z-dim, 1 = double, 2 = string */
        int index, /* The field index (1 based) for the attribute */
        int * done, /* No more records in file? 0 = false, 1 = true */

Perhaps this would be returned in the status value. EOF is 1 normally I
think but here it would have to be a negative value.

        site **xyz /* The site array, caller must free between calls */

This might be best as a static field with file scope, ie. struct Site
**sites. This would allow the value to be preserved between calls. It's
more convenient than a passed parameter, but also it makes restarting a
read sequence from a previous position easier - I'm thinking ahead here
- functions like readsites_continue() could be added later. Some static
control parameters would also have to be stored, to keep track of the
stream.

David

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

6

Thanks for the responses.

Here's the deal. I just picked this up, cause I saw it on the TODO list
on the website(s). Anyway, I've coded this thing up, tested it, and it
works as planned. The question of course, is this functionality worthy
of a library function? I will have to concede, I think it isn't. I
guessed that there must've been a significant demand for this limited
function, but perhaps the more general is desirable. That is,
G_readsites() just makes an array of Site structs for the caller's
consumption. I'll agree, that for speed, etc. reuse of the array is
certainly a better idea than dynamically allocating, then freeing, then
repeating, ... As far as using a static variable, I didn't see the
need. I was taking it on faith that the caller wouldn't make operations
on the file between calls (why would they?).

Anyway, shall I look at writing a generalized G_readsites() (and maybe
G_writesites() ?) using the standard Site struct? I'm ambivalent.

Here's an annotated explanation of the API for those who had questions.

int G_readsites(

  --- G_readsites() returns either (a) the number of records read, or
  --- (b) a negative error condition (think, recoverable memory
  --- handling).
  
        FILE * fdsite,

  --- The file stream opened with G_open_sites_old(), Assumed that if
  --- multiple calls are used, the caller does not manipulate the
  --- file stream (it still points where the last call left off).
  
        int num, /* Number of records to read */

  --- This is the number of records requested (whether or not that
  --- many exist, or more exist. Don't know right?). If this was
  --- a pointer, then the caller would have to have a local copy,
  --- don't know that's any better than just returning the number read.
  
        int type, /* 0 = Z-dim, 1 = double, 2 = string */
  
  --- This is the attribute type. By "Z-dim", I mean any of the n-dims
  --- in the Site file spec. Double, is double attribute, string is
  --- string attribute. Yes, an enum or #define's are in order.

        int index, /* The field index (1 based) */

  --- The one-based index of the attribute, so the second z-dim is 2,
  --- etc...
  
        int * done, /* No more records in file? 0 = false, 1 = true*/

  --- This allows the caller to use that twisted logic if (!done) {...}
  --- It's completely superfluous, since if the function returns 0,
  --- well, you're done!
  
        site **xyz /* The site array, caller must free between calls */

  --- This is the heart of the matter. I didn't come up with this, so
  --- I'll shift blame. I guessed this simplified view of the Site
  --- world was somehow desireable. Maybe only in the special case?
);

  --- The End ---

--
/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'

7

Hi Markus

Markus Neteler wrote:

I vote to change the "suspend()" calls in GRASS to "mysuspend()"
or similar to avoid such conflicts.

Will problems arise from such a change?

I don't think so. At least I can't think of any problems off the top of
my head.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

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

8

Here's the deal. I just picked this up, cause I saw it on the TODO list
on the website(s). Anyway, I've coded this thing up, tested it, and it
works as planned. The question of course, is this functionality worthy
of a library function? I will have to concede, I think it isn't. I
guessed that there must've been a significant demand for this limited
function, but perhaps the more general is desirable.

I think your G_readxyzsites would be quite useful. I'd still like to
see "cat" added as an attribute, though. G_writexyzsites might be good
too. I think these would be more useful to the programmer because it
hides all the messy Site structure stuff. For G_writexyzsites, if "cat"
is selected, you could default to writing a double cat or add another
RASTER_MAP_TYPE parameter which would be ignored if string or floating
point attribute are chosen.

int type, /* 0 = Z-dim, 1 = double, 2 = string */

--- This is the attribute type. By "Z-dim", I mean any of the n-dims
--- in the Site file spec. Double, is double attribute, string is
--- string attribute. Yes, an enum or #define's are in order.

Z-dim is still confusing to me. Maybe I'm just being dense. So is
Z-dim 1 the same as easting and Z-dim 2 the same as northing? If so,
let's just call it "dim" - if not, "n-dim" might be better. When I
wrote d.sites.qual, I considered dim 1 to be the same as easting.
( http://www2.gis.uiuc.edu:2280/modviz/gsoils/doc/dsites_qual.html )
Here's a chunk from the Sites Format Specification:
------------------------
Part 1 of a Site Record: Location

Part 1 of a site record gives information about location. The
field separator in part 1 of the site record is a "pipe" (ASCII
0x7c) character. The last (non-escaped) pipe signifies the end
of part 1 (an escaped character is defined as one prefixed by a
"backslash" (ASCII 0x5c)). Any additional fields are
considered attribute information.

Each field in part 1 indicates a coordinate in some space.
There must be at least two fields in part 1: the first describing
a geographic easting and the second describing a geographic
northing. These may be in either decimal or
degrees-minutes-second format.

Additional fields in part 1 are optional but must be stored in
decimal format. They should only be used to represent
coordinate information about some space (e.g., elevation,
time; depending upon how a space is defined).
------------------------

Anyway, shall I look at writing a generalized G_readsites() (and maybe
G_writesites() ?) using the standard Site struct? I'm ambivalent.

Me too. I'd consider these "convenience" functions.

Thanks!

- Bill

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

9

On Thu, Sep 21, 2000 at 10:07:56AM -0500, Bill Brown - staff wrote:
[snip]

I think your G_readxyzsites would be quite useful. I'd still like to
see "cat" added as an attribute, though. G_writexyzsites might be good
too. I think these would be more useful to the programmer because it
hides all the messy Site structure stuff. For G_writexyzsites, if "cat"
is selected, you could default to writing a double cat or add another
RASTER_MAP_TYPE parameter which would be ignored if string or floating
point attribute are chosen.

I see no problem adding support for the cat value. I could add the
RASTER_MAP_TYPE thingy too. I must say, I'm a little confused by the
use of floating point cat values. I always thought of a 'cat' as a
category which implies an integral value (even if it represents a range
of floats). I don't understand how a floating point cat makes sense for
a site file either. But, this is probably another matter...

>int type, /* 0 = Z-dim, 1 = double, 2 = string */
>
>--- This is the attribute type. By "Z-dim", I mean any of the n-dims
>--- in the Site file spec. Double, is double attribute, string is
>--- string attribute. Yes, an enum or #define's are in order.

Z-dim is still confusing to me. Maybe I'm just being dense. So is
Z-dim 1 the same as easting and Z-dim 2 the same as northing? If so,
let's just call it "dim" - if not, "n-dim" might be better. When I

Okay, to my mind, every dimension after the easting and northing is a
z-dim up to the cat or label or ... I don't think well in more than 3d!
Call it a limit of perceptual reality. Anyway, I can call it just 'dim'
or 'ndim' to be consistent with the Site struct. To me, a 'dim' could
be in any spatial direction, but since the easting and northing are
already accounted for ... you're left with the z-axis (discounting time,
and other n-dimensional geometries). I don't see using those 'dims' for
anything other than the Z-axis -- there are double attributes already to
represent other things not defining the geometry.

[snip]

>Anyway, shall I look at writing a generalized G_readsites() (and maybe
>G_writesites() ?) using the standard Site struct? I'm ambivalent.
>

Me too. I'd consider these "convenience" functions.

Well, we'll let that rest for awhile. I was going to look at some
parsing problems with s.in.ascii anyway. I may not have time to do
anything for a week or so, going out of town...

--
/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'

10

I see no problem adding support for the cat value. I could add the
RASTER_MAP_TYPE thingy too. I must say, I'm a little confused by the
use of floating point cat values. I always thought of a 'cat' as a
category which implies an integral value (even if it represents a range
of floats). I don't understand how a floating point cat makes sense for
a site file either. But, this is probably another matter...

Yes, it's definitely counter-intuitive. I think it was mostly for
backward compatibility with s.to.rast/r.to.sites and some other programs
that treat site cats similar to raster values.

- Bill

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