[GRASS-dev] d.vect -a shows only some elements

mlennert · October 12, 2006, 3:36pm

Using d.vect.thematic -u I fill a grassrgb column in the attribute table. See http://moritz.homelinux.org/grass/d_vect_a1.png.

But when I try to reuse these colors with d.vect -a, only a few of the regions get filled (with an additional dissolution of common boundaries): http://moritz.homelinux.org/grass/d_vect_a2.png

All of the objects in the map have a color code in the grassrgb column.

I cannot reproduce this problem in spearfish, so I am a bit lost.

Any ideas ?

Moritz

H_B · October 12, 2006, 10:23pm

Moritz Lennert wrote:

Using d.vect.thematic -u I fill a grassrgb column in the attribute
table. See http://moritz.homelinux.org/grass/d_vect_a1.png.

But when I try to reuse these colors with d.vect -a, only a few of the

regions get filled (with an additional dissolution of common
boundaries): http://moritz.homelinux.org/grass/d_vect_a2.png

All of the objects in the map have a color code in the grassrgb
column.

I cannot reproduce this problem in spearfish, so I am a bit lost.

Any ideas ?

"with an additional dissolution of common boundaries" is causing the
problem.

dissolution is based on common cat, but thematic colors are based on
"jk" column. areas with a common cat can have different attribute
values.

e.g. if cat refers to country number, and attr col refers to province
area.

Hamish

mlennert · October 20, 2006, 4:45pm

Hamish wrote:

Moritz Lennert wrote:

Using d.vect.thematic -u I fill a grassrgb column in the attribute table. See http://moritz.homelinux.org/grass/d_vect_a1.png.

But when I try to reuse these colors with d.vect -a, only a few of the

regions get filled (with an additional dissolution of common boundaries): http://moritz.homelinux.org/grass/d_vect_a2.png

All of the objects in the map have a color code in the grassrgb
column.

I cannot reproduce this problem in spearfish, so I am a bit lost.

Any ideas ?

"with an additional dissolution of common boundaries" is causing the
problem.

dissolution is based on common cat, but thematic colors are based on
"jk" column. areas with a common cat can have different attribute
values.

e.g. if cat refers to country number, and attr col refers to province
area.

This is not it. The dissolution came from the simple fact, that I used 'd.vect type=area' instead of d.vect type=area,boundary. Sorry, I didn't realize this before.

So I still have:

GRASS 6.3.cvs (ESPON):~ > psql -d espon -c "select * from temp where grassrgb is NULL"
cat | nuts2 | jk | dkdldm | ab | lmn | grassrgb
-----+-------+----+--------+----+-----+----------
(0 lignes)

and

GRASS 6.3.cvs (ESPON):~ > psql -d espon -c "select distinct grassrgb from temp"
  grassrgb
----------
  0:0:255
  170:0:85
  255:0:0
  85:0:170

So, the grassrgb column is filled as it should. To make sure there is not problem with the colours, I do a seperate d.vect for each range. This works perfectly: http://moritz.homelinux.org/grass/d_vect_a1.png

But trying to reproduce this with d.vect -a, I get: http://moritz.homelinux.org/grass/d_vect_a2.png.

As you can see, those regions that are colored, are colored correctly, but not all regions are colored. If I change the color scheme, I get exactly the same results: http://moritz.homelinux.org/grass/d_vect_a3.png

It is as if d.vect stopped coloring at one point.
..

If I display the map in four d.vect calls with where='grassrgb=255:0:0', etc, it displays fine.

I also get the same problem if I use d.vect.thematic on the cat column...

And I still cannot reproduce this in spearfish. Quite lost...

Moritz

mlennert · October 20, 2006, 5:23pm

Moritz Lennert wrote:

Hamish wrote:

Moritz Lennert wrote:

Using d.vect.thematic -u I fill a grassrgb column in the attribute table. See http://moritz.homelinux.org/grass/d_vect_a1.png.

But when I try to reuse these colors with d.vect -a, only a few of the

regions get filled (with an additional dissolution of common boundaries): http://moritz.homelinux.org/grass/d_vect_a2.png

All of the objects in the map have a color code in the grassrgb
column.

I cannot reproduce this problem in spearfish, so I am a bit lost.

Any ideas ?

"with an additional dissolution of common boundaries" is causing the
problem.

dissolution is based on common cat, but thematic colors are based on
"jk" column. areas with a common cat can have different attribute
values.

e.g. if cat refers to country number, and attr col refers to province
area.

This is not it. The dissolution came from the simple fact, that I used 'd.vect type=area' instead of d.vect type=area,boundary. Sorry, I didn't realize this before.

So I still have:

GRASS 6.3.cvs (ESPON):~ > psql -d espon -c "select * from temp where grassrgb is NULL"
  cat | nuts2 | jk | dkdldm | ab | lmn | grassrgb
-----+-------+----+--------+----+-----+----------
(0 lignes)

and

GRASS 6.3.cvs (ESPON):~ > psql -d espon -c "select distinct grassrgb from temp"
  grassrgb
----------
  0:0:255
  170:0:85
  255:0:0
  85:0:170

So, the grassrgb column is filled as it should. To make sure there is not problem with the colours, I do a seperate d.vect for each range. This works perfectly: http://moritz.homelinux.org/grass/d_vect_a1.png

But trying to reproduce this with d.vect -a, I get: http://moritz.homelinux.org/grass/d_vect_a2.png.

As you can see, those regions that are colored, are colored correctly, but not all regions are colored. If I change the color scheme, I get exactly the same results: http://moritz.homelinux.org/grass/d_vect_a3.png

It is as if d.vect stopped coloring at one point.
..

If I display the map in four d.vect calls with where='grassrgb=255:0:0', etc, it displays fine.

I also get the same problem if I use d.vect.thematic on the cat column...

I have done some testing, and the problem seems to be in line 224 of display/d.vect/area.c:

if (db_CatValArray_get_value (&cvarr_rgb, cat, &cv_rgb) != DB_OK)

db_CatValArray_get_value returns 'not found' for many of the cat values.

I am wondering whether this might be due to the fact that the bsearch in db_CatValArray_get_value needs a sorted array, but that the array is not sorted as db_select_CatValArray() which creates the array on line 67 of the same file only sorts lists of ints or doubles, but not of strings...

Moritz

martinl · October 20, 2006, 7:37pm

Hi Moritz,

2006/10/20, Moritz Lennert <mlennert@club.worldonline.be>:

[snip]

I have done some testing, and the problem seems to be in line 224 of
display/d.vect/area.c:

if (db_CatValArray_get_value (&cvarr_rgb, cat, &cv_rgb) != DB_OK)

db_CatValArray_get_value returns 'not found' for many of the cat values.

I am wondering whether this might be due to the fact that the bsearch in
db_CatValArray_get_value needs a sorted array, but that the array is not
sorted as db_select_CatValArray() which creates the array on line 67 of
the same file only sorts lists of ints or doubles, but not of strings...

you are right (if I understand well), adding

db_CatValArray_sort (&cvarr_rgb);

should solve the problem. I wonder why db_select_CatValArray sorts
cvarr->value by category number only for data type int or double...
(?), see

00300 if ( type == DB_C_TYPE_INT )
00301 qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);
00302 else if ( type == DB_C_TYPE_DOUBLE )
00303 qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);

Best regards, Martin

____________________________________________

grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

mlennert · October 20, 2006, 11:26pm

On Fri, October 20, 2006 21:37, Martin Landa wrote:

Hi Moritz,

2006/10/20, Moritz Lennert <mlennert@club.worldonline.be>:

[snip]

I have done some testing, and the problem seems to be in line 224 of
display/d.vect/area.c:

if (db_CatValArray_get_value (&cvarr_rgb, cat, &cv_rgb) != DB_OK)

db_CatValArray_get_value returns 'not found' for many of the cat values.

I am wondering whether this might be due to the fact that the bsearch in
db_CatValArray_get_value needs a sorted array, but that the array is not
sorted as db_select_CatValArray() which creates the array on line 67 of
the same file only sorts lists of ints or doubles, but not of strings...

you are right (if I understand well), adding

db_CatValArray_sort (&cvarr_rgb);

should solve the problem. I wonder why db_select_CatValArray sorts
cvarr->value by category number only for data type int or double...
(?), see

00300 if ( type == DB_C_TYPE_INT )
00301 qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal),
cmpcat);
00302 else if ( type == DB_C_TYPE_DOUBLE )
00303 qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal),
cmpcat);

Applying below patch directly to db_select_CatValArray solves the problem
for me, but I don't know if this might cause other problems, even though I
doubt it.

Any ideas ?

Moritz

Index: lib/db/dbmi_client/select.c

RCS file: /grassrepository/grass6/lib/db/dbmi_client/select.c,v
retrieving revision 1.8
diff -u -r1.8 select.c
--- lib/db/dbmi_client/select.c 14 Jul 2006 16:41:22 -0000 1.8
+++ lib/db/dbmi_client/select.c 20 Oct 2006 23:22:26 -0000
@@ -297,10 +297,7 @@
db_close_cursor(&cursor);
db_free_string ( &stmt );

- if ( type == DB_C_TYPE_INT )
- qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);
- else if ( type == DB_C_TYPE_DOUBLE )
- qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);
+ db_CatValArray_sort ( cvarr );

return (nrows);
}

martinl · October 21, 2006, 7:49am

Hi,

2006/10/21, Moritz Lennert <mlennert@club.worldonline.be>:

[snip]

> you are right (if I understand well), adding
>
> db_CatValArray_sort (&cvarr_rgb);
>
> should solve the problem. I wonder why db_select_CatValArray sorts
> cvarr->value by category number only for data type int or double...
> (?), see
>
> 00300 if ( type == DB_C_TYPE_INT )
> 00301 qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal),
> cmpcat);
> 00302 else if ( type == DB_C_TYPE_DOUBLE )
> 00303 qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal),
> cmpcat);
>

Applying below patch directly to db_select_CatValArray solves the problem
for me, but I don't know if this might cause other problems, even though I
doubt it.

Any ideas ?

Moritz

Index: lib/db/dbmi_client/select.c

RCS file: /grassrepository/grass6/lib/db/dbmi_client/select.c,v
retrieving revision 1.8
diff -u -r1.8 select.c
--- lib/db/dbmi_client/select.c 14 Jul 2006 16:41:22 -0000 1.8
+++ lib/db/dbmi_client/select.c 20 Oct 2006 23:22:26 -0000
@@ -297,10 +297,7 @@
     db_close_cursor(&cursor);
     db_free_string ( &stmt );

- if ( type == DB_C_TYPE_INT )
- qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);
- else if ( type == DB_C_TYPE_DOUBLE )
- qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);
+ db_CatValArray_sort ( cvarr );

     return (nrows);
}

in this case the array is sorted twice for datatype DB_C_TYPE_INT and
DB_C_TYPE_DOUBLE, I suggest

Index: lib/db/dbmi_client/select.c

RCS file: /home/grass/grassrepository/grass6/lib/db/dbmi_client/select.c,v
retrieving revision 1.8
diff -u -r1.8 select.c
--- lib/db/dbmi_client/select.c 14 Jul 2006 16:41:22 -0000 1.8
+++ lib/db/dbmi_client/select.c 21 Oct 2006 07:43:35 -0000
@@ -297,9 +297,8 @@
db_close_cursor(&cursor);
db_free_string ( &stmt );

- if ( type == DB_C_TYPE_INT )
- qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);
- else if ( type == DB_C_TYPE_DOUBLE )
+ if ( type == DB_C_TYPE_INT || type == DB_C_TYPE_DOUBLE ||
+ type == DB_C_TYPE_STRING )
qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);

return (nrows);

Not sure if you need to check "type" here (what about DB_C_TYPE_DATETIME)??

Best, Martin

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

mlennert · October 23, 2006, 9:12am

Martin Landa wrote:

Hi,

2006/10/21, Moritz Lennert <mlennert@club.worldonline.be>:

[snip]

> you are right (if I understand well), adding
>
> db_CatValArray_sort (&cvarr_rgb);
>
> should solve the problem. I wonder why db_select_CatValArray sorts
> cvarr->value by category number only for data type int or double...
> (?), see
>
> 00300 if ( type == DB_C_TYPE_INT )
> 00301 qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal),
> cmpcat);
> 00302 else if ( type == DB_C_TYPE_DOUBLE )
> 00303 qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal),
> cmpcat);
>

Applying below patch directly to db_select_CatValArray solves the problem
for me, but I don't know if this might cause other problems, even though I
doubt it.

Any ideas ?

Moritz

Index: lib/db/dbmi_client/select.c

RCS file: /grassrepository/grass6/lib/db/dbmi_client/select.c,v
retrieving revision 1.8
diff -u -r1.8 select.c
--- lib/db/dbmi_client/select.c 14 Jul 2006 16:41:22 -0000 1.8
+++ lib/db/dbmi_client/select.c 20 Oct 2006 23:22:26 -0000
@@ -297,10 +297,7 @@
     db_close_cursor(&cursor);
     db_free_string ( &stmt );

- if ( type == DB_C_TYPE_INT )
- qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);
- else if ( type == DB_C_TYPE_DOUBLE )
- qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);
+ db_CatValArray_sort ( cvarr );

     return (nrows);
}

in this case the array is sorted twice for datatype DB_C_TYPE_INT and
DB_C_TYPE_DOUBLE, I suggest

Index: lib/db/dbmi_client/select.c

RCS file: /home/grass/grassrepository/grass6/lib/db/dbmi_client/select.c,v
retrieving revision 1.8
diff -u -r1.8 select.c
--- lib/db/dbmi_client/select.c 14 Jul 2006 16:41:22 -0000 1.8
+++ lib/db/dbmi_client/select.c 21 Oct 2006 07:43:35 -0000
@@ -297,9 +297,8 @@
    db_close_cursor(&cursor);
    db_free_string ( &stmt );

- if ( type == DB_C_TYPE_INT )
- qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);
- else if ( type == DB_C_TYPE_DOUBLE )
+ if ( type == DB_C_TYPE_INT || type == DB_C_TYPE_DOUBLE ||
+ type == DB_C_TYPE_STRING )
        qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);

    return (nrows);

Not sure if you need to check "type" here (what about DB_C_TYPE_DATETIME)??

Don't know, either. The whole idea is to have the array sorted by cat
when it is returned. No reason that this should be any different
whatever the datatype of the attached data column.

This is why I suggested replacing the whole thing by one simple call to

db_CatValArray_sort ( cvarr );

where db_CatValArray_sort simply contains:

qsort( (void *) arr->value, arr->n_values, sizeof(dbCatVal), cmpcat);

i.e. exactly the same sorting call.

So, why would that sort the array twice ?

Moritz

martinl · October 23, 2006, 3:13pm

Hi Moritz,

2006/10/23, Moritz Lennert <mlennert@club.worldonline.be>:

Martin Landa wrote:
> Hi,
>
> 2006/10/21, Moritz Lennert <mlennert@club.worldonline.be>:
>
> [snip]
>
>> > you are right (if I understand well), adding
>> >
>> > db_CatValArray_sort (&cvarr_rgb);
>> >
>> > should solve the problem. I wonder why db_select_CatValArray sorts
>> > cvarr->value by category number only for data type int or double...
>> > (?), see
>> >
>> > 00300 if ( type == DB_C_TYPE_INT )
>> > 00301 qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal),
>> > cmpcat);
>> > 00302 else if ( type == DB_C_TYPE_DOUBLE )
>> > 00303 qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal),
>> > cmpcat);
>> >
>>
>> Applying below patch directly to db_select_CatValArray solves the problem
>> for me, but I don't know if this might cause other problems, even
>> though I
>> doubt it.
>>
>> Any ideas ?
>>
>> Moritz
>>
>> Index: lib/db/dbmi_client/select.c
>> ===================================================================
>> RCS file: /grassrepository/grass6/lib/db/dbmi_client/select.c,v
>> retrieving revision 1.8
>> diff -u -r1.8 select.c
>> --- lib/db/dbmi_client/select.c 14 Jul 2006 16:41:22 -0000 1.8
>> +++ lib/db/dbmi_client/select.c 20 Oct 2006 23:22:26 -0000
>> @@ -297,10 +297,7 @@
>> db_close_cursor(&cursor);
>> db_free_string ( &stmt );
>>
>> - if ( type == DB_C_TYPE_INT )
>> - qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);
>> - else if ( type == DB_C_TYPE_DOUBLE )
>> - qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);
>> + db_CatValArray_sort ( cvarr );
>>
>> return (nrows);
>> }
>
> in this case the array is sorted twice for datatype DB_C_TYPE_INT and
> DB_C_TYPE_DOUBLE, I suggest
>
> Index: lib/db/dbmi_client/select.c
> ===================================================================
> RCS file: /home/grass/grassrepository/grass6/lib/db/dbmi_client/select.c,v
> retrieving revision 1.8
> diff -u -r1.8 select.c
> --- lib/db/dbmi_client/select.c 14 Jul 2006 16:41:22 -0000 1.8
> +++ lib/db/dbmi_client/select.c 21 Oct 2006 07:43:35 -0000
> @@ -297,9 +297,8 @@
> db_close_cursor(&cursor);
> db_free_string ( &stmt );
>
> - if ( type == DB_C_TYPE_INT )
> - qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);
> - else if ( type == DB_C_TYPE_DOUBLE )
> + if ( type == DB_C_TYPE_INT || type == DB_C_TYPE_DOUBLE ||
> + type == DB_C_TYPE_STRING )
> qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);
>
> return (nrows);
>
> Not sure if you need to check "type" here (what about DB_C_TYPE_DATETIME)??

Don't know, either. The whole idea is to have the array sorted by cat
when it is returned. No reason that this should be any different
whatever the datatype of the attached data column.

This is why I suggested replacing the whole thing by one simple call to

db_CatValArray_sort ( cvarr );

where db_CatValArray_sort simply contains:

qsort( (void *) arr->value, arr->n_values, sizeof(dbCatVal), cmpcat);

i.e. exactly the same sorting call.

Personally I agree with you. I don't think you have to check data type
of CatVal.value.val for sorting of CatValArray array by cat.

So, why would that sort the array twice ?

Sorry!, it was mistake. Please forget it:-)

Moritz

Best, Martin

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

mlennert · October 23, 2006, 4:04pm

Martin Landa wrote:

Hi Moritz,

2006/10/23, Moritz Lennert <mlennert@club.worldonline.be>:

Martin Landa wrote:
> Hi,
>
> 2006/10/21, Moritz Lennert <mlennert@club.worldonline.be>:
>
> [snip]
>
>> > you are right (if I understand well), adding
>> >
>> > db_CatValArray_sort (&cvarr_rgb);
>> >
>> > should solve the problem. I wonder why db_select_CatValArray sorts
>> > cvarr->value by category number only for data type int or double...
>> > (?), see
>> >
>> > 00300 if ( type == DB_C_TYPE_INT )
>> > 00301 qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal),
>> > cmpcat);
>> > 00302 else if ( type == DB_C_TYPE_DOUBLE )
>> > 00303 qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal),
>> > cmpcat);
>> >
>>
>> Applying below patch directly to db_select_CatValArray solves the problem
>> for me, but I don't know if this might cause other problems, even
>> though I
>> doubt it.
>>
>> Any ideas ?
>>
>> Moritz
>>
>> Index: lib/db/dbmi_client/select.c
>> ===================================================================
>> RCS file: /grassrepository/grass6/lib/db/dbmi_client/select.c,v
>> retrieving revision 1.8
>> diff -u -r1.8 select.c
>> --- lib/db/dbmi_client/select.c 14 Jul 2006 16:41:22 -0000 1.8
>> +++ lib/db/dbmi_client/select.c 20 Oct 2006 23:22:26 -0000
>> @@ -297,10 +297,7 @@
>> db_close_cursor(&cursor);
>> db_free_string ( &stmt );
>>
>> - if ( type == DB_C_TYPE_INT )
>> - qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);
>> - else if ( type == DB_C_TYPE_DOUBLE )
>> - qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);
>> + db_CatValArray_sort ( cvarr );
>>
>> return (nrows);
>> }
>
> in this case the array is sorted twice for datatype DB_C_TYPE_INT and
> DB_C_TYPE_DOUBLE, I suggest
>
> Index: lib/db/dbmi_client/select.c
> ===================================================================
> RCS file: /home/grass/grassrepository/grass6/lib/db/dbmi_client/select.c,v
> retrieving revision 1.8
> diff -u -r1.8 select.c
> --- lib/db/dbmi_client/select.c 14 Jul 2006 16:41:22 -0000 1.8
> +++ lib/db/dbmi_client/select.c 21 Oct 2006 07:43:35 -0000
> @@ -297,9 +297,8 @@
> db_close_cursor(&cursor);
> db_free_string ( &stmt );
>
> - if ( type == DB_C_TYPE_INT )
> - qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);
> - else if ( type == DB_C_TYPE_DOUBLE )
> + if ( type == DB_C_TYPE_INT || type == DB_C_TYPE_DOUBLE ||
> + type == DB_C_TYPE_STRING )
> qsort( (void *) cvarr->value, nrows, sizeof(dbCatVal), cmpcat);
>
> return (nrows);
>
> Not sure if you need to check "type" here (what about DB_C_TYPE_DATETIME)??

Don't know, either. The whole idea is to have the array sorted by cat
when it is returned. No reason that this should be any different
whatever the datatype of the attached data column.

This is why I suggested replacing the whole thing by one simple call to

db_CatValArray_sort ( cvarr );

where db_CatValArray_sort simply contains:

qsort( (void *) arr->value, arr->n_values, sizeof(dbCatVal), cmpcat);

i.e. exactly the same sorting call.

Personally I agree with you. I don't think you have to check data type
of CatVal.value.val for sorting of CatValArray array by cat.

So, why would that sort the array twice ?

Sorry!, it was mistake. Please forget it:-)

Ok, have just committed my above proposal.

Thanks for the help !

Moritz