[GRASS5] v.digit: text labels support implemented

sounds good. as a former arcinfo user, i'd like the
unsplit command be there in v.digit. as a humble
programmer, i'd rather keep working without.
alex
--- Markus Neteler <neteler@geog.uni-hannover.de>
wrote:

Hi all,

interesting for all using v.digit will be two new
features
implemented by Huidae Cho:

-v.digit supports (optional) text labelling now:
When digitizing it is asking for the category
number (as usual)
and additionally for a optional text label (new).
-v.digit allows to zoom/pan while digitizing now. No
more
menu jumping is required to adjust the backdrop
raster map.
You can continuously "walk" through your map
digitizing
one long vector.

The next GRASS 5 release will contain this update.
Or you
access it from CVS:
cvs co grass/src/mapdev/v.digit

To access anonymous CVS, please follow the
instructions at:
http://freegis.org/grass/

Yours

Markus Neteler

----------------------------------------
If you want to unsubscribe from GRASS Development
Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Hi all,

long awaited: I have worked out a rough proposal for a
new GRASS directory structure:

in CVS:
documents/new_directory_structure.txt

The modules are sorted in a topic oriented manner. Certainly
things have to be partly reorganized. Please feel free to modify
above file and add your comments.

We have to address some topics:
  - new Makefile system requires restructuring
  - the package should be splitted into topic oriented packages
    (probably with nice click-and-download web page)
  - internet-based updating should be possible
  - some sets of modules should be reduced (there are tons of import/export
    modules, partly working only)

Hoping for comments and modifications

Markus

--
Dipl.-Geogr. Markus Neteler * University of Hannover
Institute of Physical Geography and Landscape Ecology
Schneiderberg 50 * D-30167 Hannover * Germany
Tel: ++49-(0)511-762-4494 Fax: -3984

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Markus,
I had hoped that we could make major reorganisations
after a stable GRASS5 version.

It is against my understanding of a beta quality software to make this
reorganisations now. :slight_smile:
  Bernhard

On Sun, Sep 10, 2000 at 07:13:42PM +0100, Markus Neteler wrote:

Hi all,

long awaited: I have worked out a rough proposal for a
new GRASS directory structure:

in CVS:
documents/new_directory_structure.txt

The modules are sorted in a topic oriented manner. Certainly
things have to be partly reorganized. Please feel free to modify
above file and add your comments.

We have to address some topics:
  - new Makefile system requires restructuring
  - the package should be splitted into topic oriented packages
    (probably with nice click-and-download web page)
  - internet-based updating should be possible
  - some sets of modules should be reduced (there are tons of import/export
    modules, partly working only)

Hoping for comments and modifications

Markus

--
Dipl.-Geogr. Markus Neteler * University of Hannover
Institute of Physical Geography and Landscape Ecology
Schneiderberg 50 * D-30167 Hannover * Germany
Tel: ++49-(0)511-762-4494 Fax: -3984

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

On Mon, Sep 11, 2000 at 09:18:19AM +0200, Bernhard Reiter wrote:

Markus,
I had hoped that we could make major reorganisations
after a stable GRASS5 version.

It is against my understanding of a beta quality software to make this
reorganisations now. :slight_smile:

Hi Bernhard, hi all,

this is still a proposal... Nothing to be done now. I think we
have to discuss how to reorganize the package before doing it.
This might require more days/weeks.

No need to get nervous :slight_smile:

Two reasons might there not to wait for a stable GRASS version:
- we never know when we get it (I feel it will take more time)
- and, more important, the new Makefile system requires a reorganization

The latter reason might be confirmed by Eric (or not).
All others, please send your comments. As some of you have much experience
with large projects, they can advise us. At least I need such advice!

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

First, is there is a list of what needs to be done before GRASS-5.0
is considered final? A list of remaining modules to get working?
A list of known bugs that needs to be whittled down? If there isn't
a solid target to aim for, we'll never hit it.

Bearing that list in mind, reorganizing might be feasible.

As far as my proposed Makefile reorganization goes, the only real
limitation is directories are either branch nodes that just contain
subdirectories to recurse into, or leaf nodes, in which something is
built. Since the Makefile reorganization scheme doesn't impact the
current build system, I don't think we should be precluded from
adding it, assuming I can get a few nights to clean it up.

As far as reorganizing the source, how would it make sense to split
up GRASS? What set of modules would provide a reasonable breakdown
of the whole GRASS distribution? grass-base, nviz, nonGPL, etc? I'd
recommend reorganizing with that layout in mind. My recommendation
for dealing with the reorganization in the CVS repo, is to declare
the current tree dead, and reimport the source in the reorganized
layout somewhere new in the repository. You can still get the old
information if necessary, but moving files around a cvs repository
tends to be a pain.

Thoughts? Ideas? Comments?

Markus Neteler wrote:

On Mon, Sep 11, 2000 at 09:18:19AM +0200, Bernhard Reiter wrote:
> Markus,
> I had hoped that we could make major reorganisations
> after a stable GRASS5 version.
>
> It is against my understanding of a beta quality software to make this
> reorganisations now. :slight_smile:

Hi Bernhard, hi all,

this is still a proposal... Nothing to be done now. I think we
have to discuss how to reorganize the package before doing it.
This might require more days/weeks.

No need to get nervous :slight_smile:

Two reasons might there not to wait for a stable GRASS version:
- we never know when we get it (I feel it will take more time)
- and, more important, the new Makefile system requires a reorganization

The latter reason might be confirmed by Eric (or not).
All others, please send your comments. As some of you have much experience
with large projects, they can advise us. At least I need such advice!

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

--
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Eric B. Mitchell mailto:emitchell@altaira.com |
| tel: (301) 809 - 3534 Altair Aerospace Corporation |
| tel: (800) 7 - ALTAIR 4201 Northview Dr. Suite 410 |
| fax: (301) 805 - 8122 Bowie, MD 20716 |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
              ,___
          /"\ / o=\ /"""---===/
         / \_/ \__/ ---===/
         | //\ || /""TT""/ //\ || ||""\
         | // \ || || // \ || ||__/
         | //--==\ |L--/ || //--==\ || || "=,
          \ ---===/
           \____---===/

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

On Mon, Sep 11, 2000 at 08:29:00PM +0100, Markus Neteler wrote:

On Mon, Sep 11, 2000 at 09:18:19AM +0200, Bernhard Reiter wrote:
> Markus,
> I had hoped that we could make major reorganisations
> after a stable GRASS5 version.
>
> It is against my understanding of a beta quality software to make this
> reorganisations now. :slight_smile:

this is still a proposal... Nothing to be done now. I think we
have to discuss how to reorganize the package before doing it.
This might require more days/weeks.

This is okay,
but as Eric said: We need goals to get a stable GRASS5 release
and this kind of proposed reorganisations hit the bar what I would
call a save change for a beta version.

So we shall discussion our goals first, solve then and finally get a
stable version out. Stable also means tested. We should go into feature
freece and start fixing bugs only for a while.
Development will continue on the experimental developmen tree then.

Two reasons might there not to wait for a stable GRASS version:
- we never know when we get it (I feel it will take more time)

We should release what we haven then, as stable tree and then start a new one.
As we already discussed or planned.

The latter reason might be confirmed by Eric (or not).
All others, please send your comments. As some of you have much experience
with large projects, they can advise us. At least I need such advice!

  Bernhard
--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

On Mon, Sep 11, 2000 at 04:19:31PM -0400, Eric Mitchell wrote:

First, is there is a list of what needs to be done before GRASS-5.0
is considered final? A list of remaining modules to get working?

Markus hat something similiar to this in mind I think.

A list of known bugs that needs to be whittled down? If there isn't
a solid target to aim for, we'll never hit it.

We should come up with them then.

As far as reorganizing the source, how would it make sense to split
up GRASS? What set of modules would provide a reasonable breakdown
of the whole GRASS distribution? grass-base, nviz, nonGPL, etc? I'd
recommend reorganizing with that layout in mind.

We cannot distribute nonGPL stuff with GRASS. Nobody can use it.
Yes, grass-base and then thematic packages would be nice.
nviz is 3D and even has other requirements (OpenGL/Mesa).

My recommendation
for dealing with the reorganization in the CVS repo, is to declare
the current tree dead, and reimport the source in the reorganized
layout somewhere new in the repository. You can still get the old
information if necessary, but moving files around a cvs repository
tends to be a pain.

This might work. But this is also the time to do a more radical
cleanup and we can only do that on the development tree.
Even major source code reorganisation should IMO not done in a beta
phase of a project.

  Bernhard
--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

Hi all

Bernhard Reiter wrote:

Even major source code reorganisation should IMO not done in a beta
phase of a project.

My vote is that we make grass5beta9 (sometime in the near future if not
now, ie no more features, especially major ones) and then when people
have tested beta 9 make it the stable release. The definition for
releasing a stable version for me is that we get an error free compile
on all supported platforms, and the testing program that Markus started
should pass all platforms as well. We should try to expand the testing
program by defining the core programs that need to be tested as well as
some known bugs if any due to different platforms (the -129 bug). Of
course all known bugs should be fixed if possible. Any bugs not fixed
for any reason gets listed in the BUGS file.

This way we get a stable release out (we've been in beta for too long)
and then we can concentrate on new features.

Just my 2 cents worth.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Bernhard Reiter wrote:

Yes, grass-base and then thematic packages would be nice.
nviz is 3D and even has other requirements (OpenGL/Mesa).

What other thematic packages would make sense? I'm not
really a GIS whiz, I just like making maps of places I've
hauled my consumer grade GPS receiver with me. =) The
trick is acheiving a reasonable balance between one source
tarball with everything, and one source module for each
binary. I'm not sure where to draw a reasonable lines
between those two extremes.

> My recommendation
> for dealing with the reorganization in the CVS repo, is to declare
> the current tree dead, and reimport the source in the reorganized
> layout somewhere new in the repository. You can still get the old
> information if necessary, but moving files around a cvs repository
> tends to be a pain.

This might work. But this is also the time to do a more radical
cleanup and we can only do that on the development tree.
Even major source code reorganisation should IMO not done in a beta
phase of a project.

When I speak of reimporting the source as a new tree, I don't mean
reorganizing the development branch. I mean declare all branches
in the current source base "dead", and create a new cvs module, say
"grass-reorg" (aliased to "grass", of course) that is organized
with everything in the right and proper place. Under that top
level module, could be modules corresponding to the various thematic
packages for ease of making tarball releases. That way, if you
check out "grass", you get everything, but you could still just
check out "grass-base" and "grass-nviz" if that's all you needed.

        Bernhard

-- ebm
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Eric B. Mitchell mailto:emitchell@altaira.com |
| tel: (301) 809 - 3534 Altair Aerospace Corporation |
| tel: (800) 7 - ALTAIR 4201 Northview Dr. Suite 410 |
| fax: (301) 805 - 8122 Bowie, MD 20716 |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
              ,___
          /"\ / o=\ /"""---===/
         / \_/ \__/ ---===/
         | //\ || /""TT""/ //\ || ||""\
         | // \ || || // \ || ||__/
         | //--==\ |L--/ || //--==\ || || "=,
          \ ---===/
           \____---===/

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

On Tue, Sep 12, 2000 at 10:17:49AM -0400, Eric Mitchell wrote:

Bernhard Reiter wrote:

> Yes, grass-base and then thematic packages would be nice.
> nviz is 3D and even has other requirements (OpenGL/Mesa).

What other thematic packages would make sense? I'm not
really a GIS whiz, I just like making maps of places I've
hauled my consumer grade GPS receiver with me. =) The
trick is acheiving a reasonable balance between one source
tarball with everything, and one source module for each
binary. I'm not sure where to draw a reasonable lines
between those two extremes.

We should discussion this.
We need to seperate extra packages, which are not needed by the casual
users. I guess that some of the contrib stuff certainly falls under
this.

Remote sensing image processing would make up a package.
Some people just do not orthorective or classify images.

> > My recommendation
> > for dealing with the reorganization in the CVS repo, is to declare
> > the current tree dead, and reimport the source in the reorganized
> > layout somewhere new in the repository. You can still get the old
> > information if necessary, but moving files around a cvs repository
> > tends to be a pain.
>
> This might work. But this is also the time to do a more radical
> cleanup and we can only do that on the development tree.
> Even major source code reorganisation should IMO not done in a beta
> phase of a project.

When I speak of reimporting the source as a new tree, I don't mean
reorganizing the development branch. I mean declare all branches
in the current source base "dead", and create a new cvs module, say
"grass-reorg" (aliased to "grass", of course) that is organized
with everything in the right and proper place. Under that top
level module, could be modules corresponding to the various thematic
packages for ease of making tarball releases. That way, if you
check out "grass", you get everything, but you could still just
check out "grass-base" and "grass-nviz" if that's all you needed.

Yes I think that I understood.
Though I still prefer to do this, when we have a stable and
a development tree. Right now there is only a stable tree.
I expect there will be more code reorganisation than just moving
files around.

  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)