OGSF vector feature styling

[Maris Nartiss]

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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Martin Landa]

Hi,

2009/9/29 Maris Nartiss <[hidden email]>:
> 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).

I would suggest to focus on wxGUI NVIZ (or 3d view mode) in trunk.
TCL/TK Nviz (and the rest of TCL/TK code) is going to be removed from
trunk. Before that wxGUI 3d view mode needs to be improved to replace
TCL/TK NViz, etc.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[hamish-2]

Martin wrote:
> TCL/TK Nviz (and the rest of TCL/TK code) is going to be
> removed from trunk. Before that wxGUI 3d view mode needs
> to be improved

Sure, once wxNviz completes and surpasses the meaningful feature
set. Until that time the Tcl/Tk version is a great and useful
app and should stay.

I would agree that it is a diversion of effort to think about
putting any new features into the Tcl/Tk version, but IMHO
known bugs should be fixed wherever they lie. If we have a
choice, I say put the thing to rest in sparkling condition.


2 grumpy c,
Hamish




_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Bob Covill]

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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-dev

[nv_points_thematic.txt]

---

/***********************************************
 * Add thematic props from vector atts
***********************************************/
gboolean
vis_load_vector_point_thematic(gchar *name,
        gint pnt_id,
        gint marker_id,
        float color,
        gchar *thematic_col_lab,
        gdouble thematic_scale)
{
geopoint *gpt;
geosite *gp;
dbDriver *Driver;
dbCatValArray cvarr;
int nrec;
struct Map_info Map;
struct field_info *Fi;
double dval;
gchar err[80];
int i;

                Vect_set_open_level (1);
                Vect_open_old (&Map, name, "");

                db_CatValArray_init ( &cvarr );
                Fi = Vect_get_field( &Map, 1);

                if ( Fi == NULL ) {
                        sprintf(err, "Cannot get layer info for vector map <%s>", name);
                        show_error(err);
                        return FALSE;
                } else {
       
                Driver = db_start_driver_open_database ( Fi->driver, Fi->database );

                        if (Driver == NULL)
                        {
                                sprintf(err, "Failed to open database %s by driver %s\n", Fi->database, Fi->driver);
                                show_error(err);
                                return FALSE;
                        } else {
                        nrec = db_select_CatValArray ( Driver, Fi->table, Fi->key,
                                thematic_col_lab, NULL, &cvarr );

                        db_close_database_shutdown_driver(Driver);

                        gp = gp_get_site(pnt_id);

                        /* init */
                        for (i=0; i<GPT_MAX_ATTR; i++)
                                gp->use_attr[i]=ST_ATT_NONE;
       
                        gp->use_attr[0] |= ST_ATT_SIZE;
                        gp->use_attr[0] |= ST_ATT_COLOR;
                        gp->use_attr[0] |= ST_ATT_MARKER;
                        for (gpt = gp->points; gpt; gpt = gpt->next) {
                                db_CatValArray_get_value_double (&cvarr, gpt->cat, &dval);
                                gpt->size[0] = (float)(dval*thematic_scale);
                                gpt->color[0] = color;
                                gpt->marker[0] = marker_id;
                        }
                        Vect_close (&Map);
                }
                }
                return TRUE;


}

---

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[hamish-2]

Maris wrote:
> 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).

huh? you can't just go around leaving broken modules in your wake with
no intention of fixing them. If we allowed that before long nothing would
work.  Or was it broken before you started?

Please do the "hack to work" thing.


thanks,
Hamish




_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Glynn Clements]

Hamish wrote:

> > 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).
>
> huh? you can't just go around leaving broken modules in your wake with
> no intention of fixing them. If we allowed that before long nothing would
> work.  Or was it broken before you started?

In 7.0, NVIZ is "broken" by virtue of requiring Tcl/Tk.

My view is that, if changes to OGSF break the Tcl/Tk NVIZ, so be it.
It's not worth expending much effort fixing the Tcl/Tk NVIZ when it's
due to be eliminated anyhow.

In other news: i.ortho.photo has been broken since I removed the Vask
library.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[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 <[hidden email]>:

> 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
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[hamish-2]

Glynn wrote:
> My view is that, if changes to OGSF break the Tcl/Tk NVIZ,
> so be it.
> It's not worth expending much effort fixing the Tcl/Tk NVIZ when it's
> due to be eliminated anyhow.

It is likely that the wx replacement will not be worked on until next
summer. In the mean time the tcl/tk version is both functional and useful.
e.g. as a native testbed for the current work on 3D vector modules in
trunk. We are so close to having it in great shape for the 6.4.x stable
series, it would be a shame to abandon the last 5% of that. "Not a focus
of new development" should not mean total abandonment for one of our
flagship modules.

So I would say it is worth a little effort for now; if it gets to the
point of needing a huge diversion of resources, of course put that into
new development instead. ie I'm not arguing that the cost threshold
should be kept heroically high, just that it should be non-zero.


> In other news: i.ortho.photo has been broken since I
> removed the Vask library.

I removed those non-functional and non-upgradable modules a year ago.
Only the near-functional support libs remain, awaiting new wx GUIs.
See trunk/imagery/i.ortho.photo/README. For this I think we would need
to find a developer who is involved in modern photogrametry research
& techniques and was interested in having that functionality in GRASS.



regards,
Hamish




_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev