[GRASS-dev] Re: bug in Vect_cidx_find_next() ?

[Radim Blazek]

On 9/29/06, Moritz Lennert <mlennert at club.worldonline.be> wrote:
> Radim Blazek wrote:
> > Yes,
> > it seems to be bug, I think that on row 296 in cindex.c
> > the requested cat should also be checked, not only the type.
> > But I am tired now, please check it twice.
>
> Changing that line into
>
> if ( ci->cat[cat_index][0] == cat && ci->cat[cat_index][1] & type_mask )
>
> works. Thanks !
>
> But I don't really understand how this could happen, as I thought the
> following lines (286-288) should take care of this before:
>
> while ( cat_index > start_index ) {
>      if ( ci->cat[cat_index-1][0] != cat ) {
>         break;

No, this goes down to lowes index of this cat because bsearch
does not return the first item.

To simplify use of cat index in modules I would suggest 2 new functions
(not tested/compiled):

void Vect_cidx_find_lines ( struct Map_info *Map, int layer, int cat,
                                 struct ilist *lines )
{
      int type, line;
      struct Cat_index *ci;

      Vect_reset_list ( lines );
      int field_index = Vect_cidx_get_field_index ( Map, layer );
      ci = &(Map->plus.cidx[field_index]);

      int idx = Vect_cidx_find_next ( Map, field_index, cat, 0,
                                  GV_LINES|GV_POINTS, &type, &line );

      if ( idx == -1 ) return;

      do {
          if ( !(ci->cat[idx][1] & GV_LINES|GV_POINTS)
               ||  ci->cat[idx][0]  != cat )
          {
               break;
           }
           Vect_list_append ( lines, ci->cat[idx][2] );
           idx++;
       } while (   idx < ci->n_cats );
       return;
}

and similarly Vect_cidx_find_areas, then in module:

struct ilist *lines = Vect_new_list();

Vect_cidx_find_lines ( Map, layer, cat, lines );
for ( i = 0; i < lines->n_values; i++ )
{
    line = lines->value[i];
    Vect_read_line ( Map, Points, NULL, line );
}

Radim

> So it might actually be a problem in the determination of cat_index
> which is higher than it should be.
>
> But just as you, I'm too tired now to look any deeper into this...
> ;-)
>
> Moritz
>
> > Bravo Moritz!
> >
> > Radim
> >
> > On 9/28/06, Moritz Lennert <mlennert at club.worldonline.be> wrote:
> >> Hello,
> >>
> >> Trying to rework d.vect.chart I am using the Vect_cidx_find_next()
> >> function.
> >>
> >> However, using a map with areas I get behaviour which seems incorrect
> >> and which I cannot explain.
> >>
> >> I have the following category index (result of Vect_cidx_dump(Map,
> >> stdout)):
> >>
> >> .
> >> .
> >> [Field 0]
> >> .
> >> .
> >> Field      1  number of unique cats:     589  number of cats:    1185
> >> number of types: 3
> >> ------------------------------------------------------------------------------------------
> >>
> >>              type |     count
> >>                 8 |       592
> >>                 4 |         1
> >>                64 |       592
> >>   category | type | line/area
> >>      11001 |    8 |      1895
> >>      11001 |   64 |       127
> >>      11002 |    8 |      1810
> >>      11002 |   64 |        42
> >>      11004 |    8 |      1874
> >>      11004 |   64 |       106
> >>      11005 |    8 |      1923
> >>      11005 |   64 |       155
> >>      11007 |    8 |      1866
> >>
> >> etc.
> >>
> >> Now, when I launch
> >>
> >> Vect_cidx_find_next( Map, field_index=1, cat=11002, type=15,
> >> start_index=3, &stype, &sid )
> >>
> >> it returns 4 and line id=1874.
> >>
> >> This is wrong as the fourth item in the index, which does have line id
> >> 1874, has cat 11004 and not cat 11002. This is confirmed by launching
> >>
> >> Vect_cidx_get_cat_by_index ( Map, field_index, 4, &testcat, &testtype,
> >> &testid)
> >>
> >> which returns testcat = 11004.
> >>
> >> Am I right in assuming that there is a bug in Vect_cidx_find_next, or am
> >> I misunderstanding something here ?
> >>
> >> I don't have this problem with a pure point file, which only has one
> >> type:
> >>
> >> Field      1  number of unique cats:     589  number of cats:     593
> >> number of types: 1
> >> ------------------------------------------------------------------------------------------
> >>
> >>              type |     count
> >>                 1 |       593
> >>   category | type | line/area
> >>      11001 |    1 |        97
> >>      11002 |    1 |        12
> >>      11002 |    1 |       593
> >>      11004 |    1 |        76
> >>      11005 |    1 |       125
> >>      11007 |    1 |        68
> >>
> >>
> >> So this seems to be linked to the type handling.
> >>
> >> Any ideas,
> >>
> >> Moritz
> >>
> >
> > _______________________________________________
> > grass-dev mailing list
> > grass-dev at grass.itc.it
> > http://grass.itc.it/mailman/listinfo/grass-dev
>
>