[GRASSLIST:3743] v.reclass in GRASS 57

SWlab · June 24, 2004, 8:26pm

Hello all,
I need to dissolve boundaries between polygons sharing a same attribute in a
huge vector map. I'm trying to use v.reclass in GRASS 5.7.0 (06/17/2004),
_____
v.reclass i=WOH_all o=WOH_subbasins type=area rules=./rules.rks field=4
_____

where rules.rks is a text file as:
_____
cat 101
where SUBBASIN="Ashokan Reservoir"
cat 102
where SUBBASIN="Beaver Kill"
cat 103
where SUBBASIN="Birch Creek"
...
_____

The command above gives me :
_____
dbmi: Protocol error
ERROR: Cannot select values from database.
_____

Though, v.db.connect works nicely (seems so): it detects that WOH_all is
connected to 4 dbf tables (the map comes from a e00 transformed to coverage
by avcimport...), proper driver (dbf), proper fields (field i from table
WOH_all_i.dbf with key=cat), I can display selected areas with d.vect
correctly...
___
d.vect WOH_all col=blue where="SUBBASIN='Beaver Kill'" field=4
___

Any ideas welcomed. If there's a workaround, I'd be happy with it
Thanks a lot in advance

--
Soil & Water Laboratory
Dept. of Biological & Environmental Engineering
Cornell University
ITHACA, NY 14853
Tel: (607)255.2463

Radim_Blazek · June 25, 2004, 7:18am

I am not sure if it solves the error, but it should be
where SUBBASIN='Ashokan Reservoir'
instead of
where SUBBASIN="Ashokan Reservoir"

Radim

On Thursday 24 June 2004 22:26, SWlab wrote:

Hello all,
I need to dissolve boundaries between polygons sharing a same attribute in
a huge vector map. I'm trying to use v.reclass in GRASS 5.7.0 (06/17/2004),
_____
v.reclass i=WOH_all o=WOH_subbasins type=area rules=./rules.rks field=4
_____

where rules.rks is a text file as:
_____
cat 101
where SUBBASIN="Ashokan Reservoir"
cat 102
where SUBBASIN="Beaver Kill"
cat 103
where SUBBASIN="Birch Creek"
...
_____

The command above gives me :
_____
dbmi: Protocol error
ERROR: Cannot select values from database.
_____

Though, v.db.connect works nicely (seems so): it detects that WOH_all is
connected to 4 dbf tables (the map comes from a e00 transformed to coverage
by avcimport...), proper driver (dbf), proper fields (field i from table
WOH_all_i.dbf with key=cat), I can display selected areas with d.vect
correctly...
___
d.vect WOH_all col=blue where="SUBBASIN='Beaver Kill'" field=4
___

Any ideas welcomed. If there's a workaround, I'd be happy with it
Thanks a lot in advance

SWlab · June 25, 2004, 8:07am

[Friday 25 June 2004 03:18] From Radim Blazek

I am not sure if it solves the error, but it should be
where SUBBASIN='Ashokan Reservoir'
instead of
where SUBBASIN="Ashokan Reservoir"

Wow... I'm really impressed, it was exactly this ! Single quotes instead of
double quotes ! The reclass rules were written with a pipe to gawk, and I
thought I would avoid escaping single quotes. I'll know better next time.

That solves only part of my problem, though:
1. the boundaries are not dissolved with v.reclass, when they are with
v.extract. I expect 79 new categories (vs the initial 45657...), does this
mean I'm stuck with creating 79 vector maps with v.extract, that I'll have to
merge one way or the other ? What way, BTW ?
2. I end up with this:
_____
WARNING: For 14604 elements no new category was defined
Building topology ...
116779 primitives registered
31131 areas built
992 isles built
Topology was built.
Number of nodes : 86640
Number of primitives: 116779
Number of points : 0
Number of lines : 0
Number of boundaries: 85726
Number of centroids : 31053
Number of areas : 31131
Number of isles : 992
Number of areas without centroid : 78
31053 elments (sic) written
_____
in a nutshell, I'm missing roughly 40% of my expected output map (luckily, not
in the zone I should deal with). The pb may come from the fact that I have to
process a coverage initially e00, that flattened several layers of polygons
and non-boundary lines, plus some non-centroid point features. Top of it, the
'new' v.in.ogr seems to dislike long (more than 10-12 characters) category
names: I end up naturally with several columns sharing the same truncated
name, that I have to edit to get the right value for the right field
(something changed from my march/april version of 5.7...). The initial e00 is
about 100Mb... Any idea ??

Thanks again...

Radim_Blazek · June 25, 2004, 8:41am

On Friday 25 June 2004 10:07, SWlab wrote:

That solves only part of my problem, though:
1. the boundaries are not dissolved with v.reclass, when they are with
v.extract. I expect 79 new categories (vs the initial 45657...), does this
mean I'm stuck with creating 79 vector maps with v.extract, that I'll have
to merge one way or the other ? What way, BTW ?

No,
v.extract -d list=1-79 new=-1
should do that in one step.

2. I end up with this:
_____
WARNING: For 14604 elements no new category was defined
Building topology ...
116779 primitives registered
31131 areas built
992 isles built
Topology was built.
Number of nodes : 86640
Number of primitives: 116779
Number of points : 0
Number of lines : 0
Number of boundaries: 85726
Number of centroids : 31053
Number of areas : 31131
Number of isles : 992
Number of areas without centroid : 78
31053 elments (sic) written
_____
in a nutshell, I'm missing roughly 40% of my expected output map (luckily,
not in the zone I should deal with). The pb may come from the fact that I
have to process a coverage initially e00, that flattened several layers of
polygons and non-boundary lines, plus some non-centroid point features.

I am not sure where is the problem, if any. Do you think there is a bug
in GRASS or it comes from mixing of layers? Try to list available
layers (v.in.ogr -l) and import only those you need.

Top of it, the 'new' v.in.ogr seems to dislike long (more than 10-12
characters) category names: I end up naturally with several columns sharing
the same truncated name, that I have to edit to get the right value for the
right field (something changed from my march/april version of 5.7...).

Not v.in.ogr but dbf driver (Shapefile library), 10 chars limit is
DBF format limit, use real database like Postgres, for bigger datasets
it should be used anyway.

Radim

SWlab · June 28, 2004, 8:27pm

> 1. the boundaries are not dissolved with v.reclass,...

No,
v.extract -d list=1-79 new=-1
should do that in one step.

Mmh: Radim, could you please explain me the difference bewteen new=-1, new=1
and new=0 in v.extract ? I understand from the doc that new=-1 keeps the old
category, but doesn't copy the attribute table (where's the point ? I have to
reset the connection to another dbf manually ?), that new=1 set the new
category to 1, without copying the table (how can I get the new table, then
?), and that new=0 keeps the old category while copying the table

> _____
> WARNING: For 14604 elements no new category was defined
> Building topology ...> > _____
> in a nutshell, I'm missing roughly 40% of my expected output map
> (luckily, not in the zone I should deal with).

I am not sure where is the problem, if any.

Well, the command seem to process the first 40000 elements or so, but dosent'
process the followings...

Do you think there is a bug
in GRASS or it comes from mixing of layers? Try to list available
layers (v.in.ogr -l) and import only those you need.

I guess the issue comes from my data: I've been sent 1 huge 100Mb e00 files,
merging several maps (an initial polygon map, (badly)cut into smaller pieces
by the overlaying of several line maps), and I'm struggling with e00
importation.
In GRASS5.3, m.in.e00 allowed a user to import whatever coverage, and to get a
raster, or a vector. The pb was to deal with the numerous attributes (a lot
of map.attribute files in dig_cats...). With a bit of perl, you could get all
the attributes in one table, then transform this table in a dbf file. As long
as you didn't have points along your polygons... With GRASS57beta, I needed
to use avcimport to change from e00 to coverage, then run ogr2ogr to change
from coverage to shapefiles, and import with v.in.ogr. Now, it seems that I
can import my coverage directly (I still need to get it with avcimport), as
long as the initial category names satisfy the 10character limit (limitation
of the dbf driver, as Radim pointed out). OK, I can try to fiddle with
ogr2ogr to get something in another driver... Thanks for you advices

P.

--
Soil & Water Laboratory
Dept. of Biological & Environmental Engineering
Cornell University
ITHACA, NY 14853
Tel: (607)255.2463

Radim_Blazek · June 29, 2004, 7:21am

On Monday 28 June 2004 21:32, Pierre GM wrote:

> > 1. the boundaries are not dissolved with v.reclass,...
>
> No,
> v.extract -d list=1-79 new=-1
> should do that in one step.

Mmh: Radim, could you please explain me the difference bewteen new=-1,
new=1 and new=0 in v.extract ? I understand from the doc that new=-1 keeps
the old category, but doesn't copy the attribute table (where's the point ?
I have to reset the connection to another dbf manually ?),

The point is that there was a bug in v.extract, now (cvs) it should copy
the table for new=-1.

that new=1 set
the new category to 1, without copying the table (how can I get the new
table, then ?),

The new table? And what should be in that table, all features have the
same category, do you want a table with one row and one column?

and that new=0 keeps the old category while copying the table

The same bug, it does not make sense to copy the table with new=0.

Radim

Markus_Neteler1 · June 29, 2004, 7:43am

On Mon, Jun 28, 2004 at 04:27:01PM -0400, SWlab wrote:
[...]

... With GRASS57beta, I needed
to use avcimport to change from e00 to coverage, then run ogr2ogr to change
from coverage to shapefiles, and import with v.in.ogr. Now, it seems that I
can import my coverage directly (I still need to get it with avcimport), as
long as the initial category names satisfy the 10character limit (limitation
of the dbf driver, as Radim pointed out). OK, I can try to fiddle with
ogr2ogr to get something in another driver... Thanks for you advices

Some time ago I have filed a wish for OGR to also support E00
format. Maybe you want to join this report and express your
wish? Sensing some $$ might accelerate the implementation... The
pieces seem to be almost there in the driver:

ogr/ogrsf_frmts/avc/

* Name: avc_e00parse.c
* Project: Arc/Info vector coverage (AVC) E00->BIN conversion library

If someone is able to patch it - also welcome

Markus

PS: The GDAL/OGR bugzilla is still not functional, so please
recheck later.