Thanks for the detailed answer, but, my problem is much more trivial.
I attached a screenshot to make myself more clear.
/* The numbers refer to the categories of each line segment */
the tributary with cat 69 is fine, but the man channel consists of
multiple lines, and, in fact, a lot of tributaries look similar.
...
The task would be, to tell GRASS, to combine all lines of the main
channel, for this example.
ok. do they overlap or join end-to-end?
if they join, try Markus M's suggestion of v.build.polylines.
if they overlap, try 'v.clean tool=rmdupl'
They join each other -so v.build polylines … worked, but, the table is exactly the same as it was before. The command output said, that the number of lines was reduced to almost 50%. Furthermore, if I check the cat number next to the lines (via d.vect) it looks fine for both methods, first and multi. But the table does not show any diffs and holds the same number of entries like the original one. I could not find anything about that in the manual.
Anyway, thanks for hints, that helped a lot.
Stefan
On Sun, 2012-02-12 at 10:56 -0800, Hamish wrote:
Stefan wrote:
> Thanks for the detailed answer, but, my problem is much more trivial.
> I attached a screenshot to make myself more clear.
> /* The numbers refer to the categories of each line segment */
> the tributary with cat 69 is fine, but the man channel consists of
> multiple lines, and, in fact, a lot of tributaries look similar.
...
> The task would be, to tell GRASS, to combine all lines of the main
> channel, for this example.
ok. do they overlap or join end-to-end?
if they join, try Markus M's suggestion of v.build.polylines.
if they overlap, try 'v.clean tool=rmdupl'
Hamish
They join each other -so v.build polylines ... worked, but, the table is
exactly the same as it was before. The command output said, that the
number of lines was reduced to almost 50%. Furthermore, if I check the
cat number next to the lines (via d.vect) it looks fine for both
methods, first and multi. But the table does not show any diffs and
holds the same number of entries like the original one. I could not find
anything about that in the manual.
With options first and multi v.build.polylines just copies the attribute tables as is, i.e. it does not delete any lines for which there are no more category values in the vector file.
To create an attribute table that corresponds to the current vector amp with the following steps (supposing that the vector map is called river_poly):
db.copy from_table=river_poly to_table=river_bak # create backup of existing table
v.db.connect -d river_poly # erase line between vector map and table river_poly
db.droptable river_poly # erase table river_poly
v.db.addtable river_poly # create new table for vector map river_poly
If you do all this using an SQL backend (e.g. SQLite or PostgreSQL), you can then use v.db.join to join any attributes from the original table river_bak to the new table river_poly.
With options first and multi v.build.polylines just copies
the attribute tables as is, i.e. it does not delete any
lines for which there are no more category values in the
vector file.
To create an attribute table that corresponds to the current
vector amp with the following steps (supposing that the
vector map is called river_poly):
db.copy from_table=river_poly to_table=river_bak # create
backup of existing table
v.db.connect -d river_poly # erase line between vector map
and table river_poly
db.droptable river_poly # erase table river_poly
v.db.addtable river_poly # create new table for vector map
river_poly
If you do all this using an SQL backend (e.g. SQLite or
PostgreSQL), you can then use v.db.join to join any
attributes from the original table river_bak to the new
table river_poly.
With options first and multi v.build.polylines just copies
the attribute tables as is, i.e. it does not delete any
lines for which there are no more category values in the
vector file.
To create an attribute table that corresponds to the current
vector amp with the following steps (supposing that the
vector map is called river_poly):
db.copy from_table=river_poly to_table=river_bak # create
backup of existing table
v.db.connect -d river_poly # erase line between vector map
and table river_poly
db.droptable river_poly # erase table river_poly
v.db.addtable river_poly # create new table for vector map
river_poly
If you do all this using an SQL backend (e.g. SQLite or
PostgreSQL), you can then use v.db.join to join any
attributes from the original table river_bak to the new
table river_poly.
would 'v.extract list=1-9999999' also work?
Yep, and it's a bit shorter than my solution while keeping all the original attributes without having to go through v.db.join ...
I tried the short one of course , worked perfectly
Thanks a lot for your efforts.
Cheers,
stefan
On Mon, 2012-02-13 at 03:06 -0800, Hamish wrote:
Moritz wrote:
> With options first and multi v.build.polylines just copies
> the attribute tables as is, i.e. it does not delete any
> lines for which there are no more category values in the
> vector file.
>
> To create an attribute table that corresponds to the current
> vector amp with the following steps (supposing that the
> vector map is called river_poly):
>
> db.copy from_table=river_poly to_table=river_bak # create
> backup of existing table
> v.db.connect -d river_poly # erase line between vector map
> and table river_poly
> db.droptable river_poly # erase table river_poly
> v.db.addtable river_poly # create new table for vector map
> river_poly
>
> If you do all this using an SQL backend (e.g. SQLite or
> PostgreSQL), you can then use v.db.join to join any
> attributes from the original table river_bak to the new
> table river_poly.
would 'v.extract list=1-9999999' also work?
Hamish
