[GRASS5] g.region, sites and other stuff [WAS: d.zoom / sites boundaries]

GRASS GRASS developer
1

(Re: bug in g.region for setting region from sites)

I can confirm the bug. I haven't looked at it. On a related note, I
think the Site_head could use some additions and some related library
functions:

Additions that could be very useful for Site_head:

  int count; /* Number of sites in list */
  double E, W, N, W; /* Min/Max extents -- Bounding box */

  - possibly implemented in site_list as:

  stats| count=<num> E=<G_format_easting(max_x, G_projection)> ...

  - Possible related library functions:

  char *G_site_make_stats(FILE *); /* Make the stats line */

  int G_site_get_count(char *site_list); /* Convenience function */

  int G_site_get_count2(FILE *site_list); /* Variant */

  int G_site_get_bbox(char *site_list, double *N, double *S,
        double *E, double *W);
      /* Other convenience function */
  
  int G_site_get_bbox2(FILE *site_list, ... ) /* variant */
  
Change that would impact alot of programs, but would improve usability:

  Actually use the 'label' line for named fields. If no labels exist,
  or labels are unspecified, then it could default to:

  label|east north n3 [n4 ...] cat d1 [d2 ...] s1 [s2 ...]

  From a user's standpoint, it is easier to remember field names than to
  give both a field type and an index when specifying a field. However,
  this would be a significant change from current practices.

  - possible library functions:

  int G_site_field_by_name(char *site_list, char *name, int *type, int *index);

  int G_site_field_by_name2(FILE *site, char *name, int *type, int *index);

  int G_site_field_by_name3(struct Site_head *head, char *name,
        int *type, int *index);

  char * G_site_field_by_type(char *site_list, int type, int index);

  char * G_site_field_by_type2(FILE *site, int type, int index);

  char * G_site_field_by_type3(struct Site_head *head, int type,
          int index);

I could see the "stats" being immediately useful while not really
impacting existing programs. The 'labels' might require a little more
care.

One other thing that might be worth doing is having a high level
function to put a site_list in sorted NW to SE order.

  G_site_sort(char *insite, char *outsite);
  /* If outsite == NULL, the sorted site_list will replace the insite
   * list. Careful not to do that if the site_file is open!
   */

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

2

Dear Eric, dear developers,

please don't get me wrong, but i think we should rather concentrate on
fixing the modules than adding new library functions.
I think that the sites API has still some problems (at least i do get
problems reading my existing files).

I see problems with the sites head and stats info in the file if you use
the data with modules that support updating of this info and other
modules that do not. You'll never know if the info is correct, so there
is not much use to store it.

I can imagine other problems with the library functions i. e. if you
have very big files (i myself wrote a sites file with 130MB!), this will
hurt performance so much that the user will think the module does not
work.

But if you have the time and resources to implement all those changes in
time and check that it all works as supposed, i have no objections.

I agree on the field names, but i think that should wait until we start
with 5.1.

cu,

Andreas

Eric G . Miller wrote:

(Re: bug in g.region for setting region from sites)

I can confirm the bug. I haven't looked at it. On a related note, I
think the Site_head could use some additions and some related library
functions:

Additions that could be very useful for Site_head:

..

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

3

I agree about bugfixing. I was mostly just posting some thoughts. I do
see a G_site_count() as being useful. Sure, it's trivial, but I've
found myself writing little functions or loops to do it on more than one
occasion (helps to know if it's even reasonably possible to keep an
entire site_list in memory for processing or whatever).

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