[GRASS5] ps.map symbol size from DB column

Hi,

I have done most of the code for getting ps.map to do dynamic symbol/eps
sizing from a DB column, following the d.vect.chart interface. The
sizing part and variable passing is all complete (currently scaling ok
from cat number), but I need two things:

(1) I would like to check that the sizing column name exists and is of a
numerical type.

We have Vect_get_column_names_types(Map, layer) in
lib/vector/Vlib/dbcolumns.c which returns a list of column names and
types. It would be great to have another fn in dbcolumns.c like

Vect_column_name_is_type(struct Map_info *Map, int field, char *col_name);

returning the type or NULL if the column doesn't exist.

This seems like a useful thing to have, and I think it would be pretty
simple to do (just parse the output of Vect_get_column_names_types() ).

Maybe if something is wrong then the vector/db library fn's already give
a good error message so there is no need to test?

Maybe this already exists?

(2) I want to do something like:

symbol_size = Vect_db_read(Map, layer, column_name, cat);

to query the value for that category-column combination. How?

(maybe with an atof() or sscanf("%lf",) step if it returns a string; or
perhaps multiple fn's like Vect_db_read_dbl() and Vect_db_read_str() ??)

Preferably the fn's asked for in (1) and (2) should both be abstracted to
the point where one shouldn't need to be opening DB drivers, etc.

???
sorry, I don't know the DB stuff very well.

thanks,
Hamish

See v.to.rast, it is necessary to select all cat/value
pairs in one query (otherwise it is slow).

db_select_CatValArray()
db_CatValArray_get_value_int() / db_CatValArray_get_value_double()

Radim

On 9/6/05, Hamish <hamish_nospam@yahoo.com> wrote:

Hi,

I have done most of the code for getting ps.map to do dynamic symbol/eps
sizing from a DB column, following the d.vect.chart interface. The
sizing part and variable passing is all complete (currently scaling ok
from cat number), but I need two things:

(1) I would like to check that the sizing column name exists and is of a
numerical type.

We have Vect_get_column_names_types(Map, layer) in
lib/vector/Vlib/dbcolumns.c which returns a list of column names and
types. It would be great to have another fn in dbcolumns.c like

Vect_column_name_is_type(struct Map_info *Map, int field, char *col_name);

returning the type or NULL if the column doesn't exist.

This seems like a useful thing to have, and I think it would be pretty
simple to do (just parse the output of Vect_get_column_names_types() ).

Maybe if something is wrong then the vector/db library fn's already give
a good error message so there is no need to test?

Maybe this already exists?

(2) I want to do something like:

symbol_size = Vect_db_read(Map, layer, column_name, cat);

to query the value for that category-column combination. How?

(maybe with an atof() or sscanf("%lf",) step if it returns a string; or
perhaps multiple fn's like Vect_db_read_dbl() and Vect_db_read_str() ??)

Preferably the fn's asked for in (1) and (2) should both be abstracted to
the point where one shouldn't need to be opening DB drivers, etc.

???
sorry, I don't know the DB stuff very well.

thanks,
Hamish

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

> Hi,
>
> I have done most of the code for getting ps.map to do dynamic
> symbol/eps sizing from a DB column, following the d.vect.chart
> interface.

..
Radim:

See v.to.rast, it is necessary to select all cat/value
pairs in one query (otherwise it is slow).

db_select_CatValArray()
db_CatValArray_get_value_int() / db_CatValArray_get_value_double()

Great. It is now done and in CVS. Screenshot of PostScript file
attached. Probably needs some testing.

The new commands for the vpoints instruction are sizecol and scale.

happy mapping,
Hamish

(attachments)

sizecol.png

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hamish wrote:

Great. It is now done and in CVS. Screenshot of PostScript file
attached. Probably needs some testing.

The new commands for the vpoints instruction are sizecol and scale.

Hamish, you're the man !

Just one small glitch: The resulting postscript file causes an error
("Error: /undefined in inf") when the sizecol contains nulls or
zeroes. In the code, you seem to have deliberately decided to allow
size=0. Does this mean that you were able to make it work with some
values = 0 ?

Also, what are the chances of having the print dialog in the GIS
Manager actually print d.vect.chart results via ps.map ? If I
understand correctly Michael is working on integrating d.vect.chart
as a button. Does that mean that it can be saved as part of a group
and then translated into a ps.map command ?

And (just to show how insatiable we are ;-): any chances of having
the full d.vect.chart implement in ps.map, i.e. allowing pie/bar
charts ? (I know I can create the charts outside as eps files and
depict them. I have been doing this with GRASS5 and R. But having it
all within GRASS would obviously make things easier.)

In any case, thanks for this great improvement !

Moritz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDHtk7rIrMbm76jD8RAgdmAJ0RPZm4s0ZLYo1fsZTSJAo5WhIeUgCeJy5O
CZ03BtKEmBKJYljV3d0Yt2I=
=xnce
-----END PGP SIGNATURE-----

Just one small glitch: The resulting postscript file causes an error
("Error: /undefined in inf") when the sizecol contains nulls or
zeroes. In the code, you seem to have deliberately decided to allow
size=0. Does this mean that you were able to make it work with some
values = 0 ?

I threw that in there but didn't actually test it. Idea was that the
user could make the icon vanish by setting the size to zero. Maybe
PostScript doesn't like that. I was thinking about rainfall amounts
which for a small enough dt could very well have a value of 0. I'll give
those two cases (0,NULL) a try; look for any fix later today in CVS. ie:
+ if (size_val == 0.0) continue;

Also, what are the chances of having the print dialog in the GIS
Manager actually print d.vect.chart results via ps.map ? If I
understand correctly Michael is working on integrating d.vect.chart
as a button. Does that mean that it can be saved as part of a group
and then translated into a ps.map command ?

I have no idea about the print dialog, I've never really used it.
As such I will leave working on it to someone who knows about it.

And (just to show how insatiable we are ;-): any chances of having
the full d.vect.chart implement in ps.map, i.e. allowing pie/bar
charts ? (I know I can create the charts outside as eps files and
depict them. I have been doing this with GRASS5 and R. But having it
all within GRASS would obviously make things easier.)

Sounds like a nice feature but I don't think I'll be working on this
myself.

In any case, thanks for this great improvement !

No worries, thanks for the testing.

Hamish

Moritz and Hamish

A major objective of the changes to the GIS Manager I've been making are to
move all major display functions to GIS Manager layers with option panels.
This makes entering options easier. It also allows for much easier creation
of complex maps that can be modified and redisplayed. Importantly, it makes
it possible to save all types of display features as a groups, including
charts, thematic maps, grids, scales, frames, etc--as well as the normal
raster and vector maps. without having to create commands and save them in a
command layer.

One problem that has come up in this is that the print function as currently
implemented is limited to just doing basic raster and vector maps. I've put
stubs to all the new layers, but it will require someone with a much more
intimate knowledge of ps.map than I have to make it possible to directly
print a complex map made in this way through the current print dialog
(actually an interface to ps.map).

While I hope this can happen, I've also created a couple of alternative
solutions that might help in the meantime. One is a new script that will
save display monitor output to a larger variety of graphic formats (the
d.out.file script that I sent out for review a few days ago). Another is a
simple print menu item that will send the display of the active display
monitor to the default printer via lpr.

I hope to get this done and posted for testing by early next week.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Moritz Lennert <mlennert@club.worldonline.be>
Date: Wed, 07 Sep 2005 14:12:43 +0200
To: Hamish <hamish_nospam@yahoo.com>
Cc: <grass5@grass.itc.it>
Subject: Re: [GRASS5] ps.map symbol size from DB column

Also, what are the chances of having the print dialog in the GIS
Manager actually print d.vect.chart results via ps.map ? If I
understand correctly Michael is working on integrating d.vect.chart
as a button. Does that mean that it can be saved as part of a group
and then translated into a ps.map command ?

And (just to show how insatiable we are ;-): any chances of having
the full d.vect.chart implement in ps.map, i.e. allowing pie/bar
charts ? (I know I can create the charts outside as eps files and
depict them. I have been doing this with GRASS5 and R. But having it
all within GRASS would obviously make things easier.)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Barton wrote:

Moritz and Hamish

A major objective of the changes to the GIS Manager I've been making are to
move all major display functions to GIS Manager layers with option panels.
This makes entering options easier. It also allows for much easier creation
of complex maps that can be modified and redisplayed. Importantly, it makes
it possible to save all types of display features as a groups, including
charts, thematic maps, grids, scales, frames, etc--as well as the normal
raster and vector maps. without having to create commands and save them in a
command layer.

One problem that has come up in this is that the print function as currently
implemented is limited to just doing basic raster and vector maps. I've put
stubs to all the new layers, but it will require someone with a much more
intimate knowledge of ps.map than I have to make it possible to directly
print a complex map made in this way through the current print dialog
(actually an interface to ps.map).

I have begun looking at the code, but haven't got very far in
understanding what needs to be done... I'll try some more when I
have time.

While I hope this can happen, I've also created a couple of alternative
solutions that might help in the meantime. One is a new script that will
save display monitor output to a larger variety of graphic formats (the
d.out.file script that I sent out for review a few days ago). Another is a
simple print menu item that will send the display of the active display
monitor to the default printer via lpr.

Sounds good. Looking forward to testing it.

Moritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDIUrMrIrMbm76jD8RAnLQAJ0YLRZezrOz8nWlBy5odLRnaVFMmwCfV/XZ
Zr88QjH1bGp3HxDv5XOA850=
=HZxq
-----END PGP SIGNATURE-----

The main code is in $GISBASE/etc/dm/print.tcl (for binaries - easier to test
and debug in binaries); some code (including stubs for panels) is in
$GISBASE/etc/dm/dm.tcl and in $GISBASE/etc/dm/*.tcl for each panel.

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Moritz Lennert <mlennert@club.worldonline.be>
Date: Fri, 09 Sep 2005 10:41:48 +0200
To: Michael Barton <michael.barton@asu.edu>
Cc: Hamish <hamish_nospam@yahoo.com>, <grass5@grass.itc.it>
Subject: Re: [GRASS5] ps.map symbol size from DB column

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Barton wrote:

Moritz and Hamish

A major objective of the changes to the GIS Manager I've been making are to
move all major display functions to GIS Manager layers with option panels.
This makes entering options easier. It also allows for much easier creation
of complex maps that can be modified and redisplayed. Importantly, it makes
it possible to save all types of display features as a groups, including
charts, thematic maps, grids, scales, frames, etc--as well as the normal
raster and vector maps. without having to create commands and save them in a
command layer.

One problem that has come up in this is that the print function as currently
implemented is limited to just doing basic raster and vector maps. I've put
stubs to all the new layers, but it will require someone with a much more
intimate knowledge of ps.map than I have to make it possible to directly
print a complex map made in this way through the current print dialog
(actually an interface to ps.map).

I have begun looking at the code, but haven't got very far in
understanding what needs to be done... I'll try some more when I
have time.

While I hope this can happen, I've also created a couple of alternative
solutions that might help in the meantime. One is a new script that will
save display monitor output to a larger variety of graphic formats (the
d.out.file script that I sent out for review a few days ago). Another is a
simple print menu item that will send the display of the active display
monitor to the default printer via lpr.

Sounds good. Looking forward to testing it.

Moritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDIUrMrIrMbm76jD8RAnLQAJ0YLRZezrOz8nWlBy5odLRnaVFMmwCfV/XZ
Zr88QjH1bGp3HxDv5XOA850=
=HZxq
-----END PGP SIGNATURE-----