[GRASS5] Problems with vector import, and a suggestion

[Aleksey Naumov]

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 
read this...

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 
tutorial 
(http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/src.garden/grass.postgresql/tutorial/index.html).


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 
to:
	(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 
merged/upgraded gradually.


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 :-)

Aleksey