[GRASS5] 100% cpu mouse bug

Radim Blazek radim.blazek at gmail.com
Fri Apr 28 03:50:54 EDT 2006

On 4/27/06, Glynn Clements <glynn at gclements.plus.com> wrote:
> What I want to do exactly is extract vector maps from GRASS to a
> textual format which can be read by e.g. Tcl/Tk programs, modify the
> data, write it out in a textual format and import it back into GRASS,
> all without loss of information.
> v.out.ascii doesn't include the topology information, so if you want
> to draw filled polygons, you have to build the topology yourself.
> An example might help. I've attached a Tcl/Tk script which displays a
> vector map in a Tk canvas. Sample usage (in spearfish):
>         wish vect.tcl fields
> It uses v.out.pov, because that was the only obvious way to extract a
> vector map in a textual format with topology information. However,
> v.out.pov doesn't export everything which makes up the map, only
> enough to draw it. For a more general export tool, the textual format
> needs to contain everything, so that the export/import cycle doesn't
> lose anything.
> v.out.ascii has all of the information, but not the topology (for a
> while, I thought that it was omitting data, until I realised that the
> boundary segments didn't define complete polygons).
> Whilst I could probably figure out how to modify v.out.pov to behave a
> bit more like v.out.ascii (i.e. dump out "raw" data), the main problem
> is that, in order to avoid trashing users' data (which I'd really like
> to avoid), you need to be sure to include /everything/ in the exported
> data. Which essentially requires that you understand what you are
> doing, rather than just dumping out whatever data you can find and
> hoping that you haven't missed anything.

Now I understand, but I don't believe that would be a good solution.
It is not problem to export everything you want (but v.in/out.ascii
imports/exports everything).

The problem is that you need to reimplement big part of
the vector library in TclTk. For example, if an end vertex of boundary is moved,
the topology of neighbour areas have to be rebuild in order to redraw
lboundaries with oppropriate symbology. Without topological symbology
editing of topological format is nightmare. Similarly for centroids,
nodes etc. You will also need to reimplement spatial index
otherwise redraw of a bit larger file (zoomed in) will be terribly slow
as well as selection of existing lines/vertices.

Why dont you want to use C API from TclTk?


More information about the grass-dev mailing list