[GRASS-dev] OGSF vector feature styling

Bob Covill bcovill at tekmap.ns.ca
Sun Oct 4 16:43:06 EDT 2009

Hello Maris,

I do not know if it helps, but I use the attached routine to draw
thematic points with ogsf. This routine takes the vector attribute
column and scales the icon accordingly. 

>From the routine:
name=vector file name, 
new_id is returned from GP_new_site() when laoding, 
marker_id is the marker type (eg. ST_CUBE),
color is the site color,
thematic_col_lab is the name of the vector column to use for attribute
(eg. dbl_2), 
thematic scale is the scale factor for the attribute. 

Note that the code is from GTK+, so gchar = char, gint = int, etc.

Hope this helps.


On Tue, 2009-09-29 at 12:06 +0300, Maris Nartiss wrote:
> Hello OGSF and NVIZ experts.
> As I was trying to fix attribute dependent rendering in NVIZ for 6.x
> releases, it turned to more serious change than expected. I have
> commited to trunk (r39323) first small change for OGSF that should
> help to rebuild attribute dependent vector feature styling in NVIZ for
> GRASS 7.
> Please take a look into gstypes.h change [1], as it's most important
> thing. It affects future NVIZ memory consumption and available
> features. My idea how it should work:
> 1) every vector feature set(map) has default style and highlighted
> feature style;
> 2) every vector feature (point, line ...) has it's layer/Cat info;
> 3) every vector feature can have own style (color, size, symbol, fill,
> orientation etc.);
> 4) thematic mapping is controled by vector map switch that stores info
> about base layer used for thematic mapping.
> If no thematic mapping is used, memory consumption is increased by
> layer/cat struct ammount for every displayed feature. In such case per
> feature styling is unset and thus should not increase memory
> consumption. When thematic mapping is enabled, every feature gets
> additional style struct overhead.
> Applying thematic styling information will be slow, as all features
> will have to be processed.
> I would like to hear something back from our OGSF/C masters what
> should be changed/improved to make solid base for futhurer
> improvements.
> Yes, tcl/tk based NVIZ in trunk is broken (and I don't plan to fully
> fix it. Can be hacked to work on request).
> Maris.
> 1. http://trac.osgeo.org/grass/changeset/39323/grass/trunk/include/gstypes.h
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nv_points_thematic.txt
Type: text/x-csrc
Size: 1602 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20091004/81986f3f/nv_points_thematic.bin

More information about the grass-dev mailing list