[GRASS-dev] OGSF vector feature styling

[Maris Nartiss]

Hello Bob,
thanks for code. Current problem isn't with "how" but "when". I almost
got kicked out of my flat last night for fixing NVIZ with something
like "You care more about random strangers on internet than Your
family and kids". Huh. Codding GRASS isn't simple task ;)
My changes to OGSF IMHO should provide enough flexibility for various
thematic mapping needs (improvements welcome as almost no code use new
OGSF style thing). Now it's required to implement GUI part of it. As
TCL/Tk NVIZ is in bye-bye mode, it means that such functionality has
to be taken to wx-whatever and I'm not yet very familiar with wxGUI
et.al. code (and Python).

Anyway - NVIZ now is back to 6.4 state - no attribute dependent
rendering, other things should be as broken as they are in 6.4.

Maris.

2009/10/4, Bob Covill <bcovill at tekmap.ns.ca>:
> 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.
>
> --
> Bob
>
>
>
>
>
>
> 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
>