[GRASS-dev] bug in Vect_cidx_find_next() ?

Moritz Lennert mlennert at club.worldonline.be
Thu Sep 28 10:26:48 EDT 2006


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




More information about the grass-dev mailing list