[GRASS5] readsites() TODO list...

[David D Gray]

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 at geog.uni-hannover.de with
subject 'unsubscribe grass5'