[GRASS-dev] GRASS 7 timeline
glynn at gclements.plus.com
Fri Mar 16 09:40:06 EDT 2007
> > This is actually pretty good news from one viewpoint. All the commands
> > below now have all or most of their interactive functionality
> > replicated in TckTk except for
> > bin/d.path
> easy to write a replacement with v.net.path
> > bin/r.digit (a pretty primitive module anyway; v.digit+v.to.rast is
> > better)
> IMHO GUI canvas + r.in.poly is simple enough to be better. But yes
> v.digit + v.to.rast will provide the functionality.
v.digit doesn't have a tool to draw circles.
> AFAIK there is no functionality replacement for d.extract, d.geodesic
> (draw great circle lines), and d.nviz (which awaits a rewrite anyway).
d.geodesic doesn't require a mouse; you can use coor= instead. This
would be easy enough to integrate into gis.m.
More generally, it would be useful to be able to mark points on a map
canvas, then pass the coordiantes to arguments to commands (both those
used in display layers and those run from the menus).
> Brad: [re. i.ortho.photo]
> > Then there is the small issue of do we want 8 modules or 1 module to
> > complete a single task (ie. a front-end)? Can we put it to a vote and
> > be done with it?
> I'm confused about the question. A single GUI linking to many apps? A
> single monolithic app? UNIX style little programs which do one job well?
> Are you talking about imagery/i.ortho.photo/menu/menu.c ?
He's talking about i.orpho.photo, and whether we want one module with
a mode= option or a separate module for each task.
As a programmer, I prefer modularity, which means that I favour
several smaller modules over one large module. You don't have to worry
about whether function F reads or modifies variable V if the two are
in different programs.
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev