Hi,
I started Wiki page, which should specify future tool, which would
replace current v.digit module [1].
IMHO future v.digit should be based on v.edit module for geometry
operations and db.* modules for database management. Current version of
v.edit supports only two operations: add and delete. In the wiki, I
tryed to define desired behavior of the module, so it would be usable
for real editing of vector data.
Help with this documentation and with coding welcome! Wolf, initial
author of v.edit, did great job. v.edit has IMHO nice design. Most of
the functions can be adopted from v.in.ascii.
Please add your notes or completions to Wiki and if you can, drop some
pieces of code to vector/v.edit/*
How will this relate to current "q.digit" (v.digit in qgis)?
We find it far easier to use than the tcltk version.
It would be a pity to miss it in the future development.
pc
Jachym Cepicky ha scritto:
Hi,
I started Wiki page, which should specify future tool, which would
replace current v.digit module [1].
IMHO future v.digit should be based on v.edit module for geometry
operations and db.* modules for database management. Current version of
v.edit supports only two operations: add and delete. In the wiki, I
tryed to define desired behavior of the module, so it would be usable
for real editing of vector data.
Help with this documentation and with coding welcome! Wolf, initial
author of v.edit, did great job. v.edit has IMHO nice design. Most of
the functions can be adopted from v.in.ascii.
Please add your notes or completions to Wiki and if you can, drop some
pieces of code to vector/v.edit/*
On Mon, Dec 11, 2006 at 09:05:52AM +0100, Paolo Cavallini wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
How will this relate to current "q.digit" (v.digit in qgis)?
We find it far easier to use than the tcltk version.
It would be a pity to miss it in the future development.
pc
QGIS is using different code for vector editing. Target of new v.digit &
v.edit is to get rid of dependancy on X-driver, rather then add new
features (in first step). As side effect, GRASS will get new tool for
non-interactive vector editing (v.edit). This could enable us, use GRASS
as background tool for web-based applications.
Jachym
Jachym Cepicky ha scritto:
> Hi,
> I started Wiki page, which should specify future tool, which would
> replace current v.digit module [1].
>
> IMHO future v.digit should be based on v.edit module for geometry
> operations and db.* modules for database management. Current version of
> v.edit supports only two operations: add and delete. In the wiki, I
> tryed to define desired behavior of the module, so it would be usable
> for real editing of vector data.
>
> Help with this documentation and with coding welcome! Wolf, initial
> author of v.edit, did great job. v.edit has IMHO nice design. Most of
> the functions can be adopted from v.in.ascii.
>
> Please add your notes or completions to Wiki and if you can, drop some
> pieces of code to vector/v.edit/*
>
> Jachym
>
> [1] http://grass.gdf-hannover.de/wiki/GRASS_Digitizing_tool
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
- --
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> How will this relate to current "q.digit" (v.digit in qgis)?
> We find it far easier to use than the tcltk version.
> It would be a pity to miss it in the future development.
by all means reuse their design ideas and format if you like. but we do
ned our own digitizer unless we are deciding to make qgis our primary
GUI.
The r.in.poly format is very close the ascii vector format, so it
shouldn't be hard to build in a r.digit replacement as an export option.
Hamish ha scritto:
> by all means reuse their design ideas and format if you like. but we do
^^^^^
ned our own digitizer unless we are deciding to make qgis our primary
^^^^^^^
I do not see the two project as so separated, and I think it is
unfortunate influential grass developers do (but of course, this is not
to blame anyone, just my point of view).
pc
- --
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Hamish ha scritto:
> by all means reuse their design ideas and format if you like. but we do
^^^^^
ned our own digitizer unless we are deciding to make qgis our primary
^^^^^^^
I do not see the two project as so separated, and I think it is
unfortunate influential grass developers do (but of course, this is not
to blame anyone, just my point of view).
They are two seperate projects, with a bridge between the two built by Radim. I think we have had this discussion before and came to the conclusion that GRASS needs its own GUI independently from QGIS.
In my opinion QGIS is a great piece of software with much potential, but for my use I don't see any added value of using it instead of a much more lightweight internal GUI.
