[GRASS5] Problems with vector import, and a suggestion
naumov at acsu.buffalo.edu
Thu Feb 7 00:21:29 EST 2002
Hi GRASS developers,
I just killed 3 days to import a rather simple (86 polygons, 6 holes) shape
file into GRASS. In the process I lost some hair :-), but hopefully also
gained some insight which I would like to share with anyone who is willing to
I am using GRASS 5.0, the HEAD branch from CVS, compiled on Feb 4 2002.
1. I first tried v.in.shape (and v.in.shape.pg). v.in.shape failed for both a
line and a polygon shape files. It generated a lot of messages like:
WARNING: line 5466 label: 217 matched another label: 455.
Failed to attach an attribute (category 471) to a line.
but, more importantly, the geometry was completely scrambled for both line
and polygon shapes.
2. Next I tried v.in.arc (and v.in.arc.pg). I had to do some work in ARC/INFO
to convert polygon shape file to correct coverage, then UNGENERATE lines and
polygon labels. Here I got correct geometry, but polygon ids (dig_att file)
were screwed up:
2.1 "v.in.arc type=polygon lines_in=st.lin points_in=st.lab vector_out=st"
worked for geometry, but dig_att was set up incorrectly
2.2 "v.in.arc.pg" did the same thing. In addition, it segfaulted when trying
to import a dbf file. But the same dbf file was imported in Postgres with
"pg.in.dbf" with no problem at all.
3. Finally, "m.in.e00" did the job for me. It created correct geometry AND
built correct dig_att file. Together with "pg.in.dbf" for the associated
attribute file (ARC's .PAT file saved in TABLES with INFODBASE, then opened
and re-exported in ArcView) I now got a complete vector file with data. I am
finally able to map the attributes as described in the GRASS/Postgres
Resume and suggestions
It's been quite a hair-pulling experience. Of course, it's possible that I
did some things wrong, but I tried these and related commands (v.support,
etc) in many different ways and quite a few times. I am trying to think what
to do to make this sort of vector import easier...
Here are some suggestions. I apologize in advance if I missed something or
am completely off on something -- let me know.
1. My experience has been that quality of modules varies greatly. Some work
fine, some are buggy and some just do not work. What makes the situation
worse for the user is that modules seem to overlap and duplicate each other,
and it's not clear which one to use (for example in my case, besides the 5
modules mentioned above there are also v.import and v.in.arc.poly --
confusing to say the least!)
In the long run modules with similar functionality will have to be merged,
some discarded. In the meantime, it seems a useful clean-up strategy would be
(a) Establish sort of a standard (e.g. for GRASS 5.1) -- a set of
requirements that modules have to comply with (coding standards, interface,
up-to-date and detailed help page, etc.)
(b) Select a few most useful modules and pull them up to this standard
(c) Identify those modules that conform to the standard in the help pages.
They will be seen as reliable, get more testing, while others may be
2. Some sort of functional listing of modules in the help pages would be
nice, maybe even based on classification used for TclTk interface.
3. No specific suggestion here, just complaining :-) about handling of vector
attributes. Associating vectors with attributes through point markers used in
dig_att files just seems too difficult and unnatural to me. May be I am
missing something here... I don't know how it's done in 5.1.
Sorry for the long mail :-)
More information about the grass-dev