I recently had a simple task to complete for a client. I needed to
download a county map from the US Census Bureau (TIGER 2000 county line
map) and extract from that the street pattern for an area of a few square
miles within the county. The streets needed to be associated with
category text that named the street and the whole thing needed to be
produced in NAD83. I also needed to transform a DXF map of the same area
into the same coordinates and send that along with the Census Bureau map.
What should have been a simple task ended up taking several days and may
still not be done, mostly because several of GRASS's vector modules
(5.0pre2) didn't work right.
I didn't have time to detail all of the problems as they came up, but I
can list some of the problems were. There were probably others that I
don't remember.
1. v.in.tig.basic worked, but v.in.tig.lndmk would not import data to a
latlong location and did not associates category text with lines. It did
associated category text with areas, but not with lines.
2. v.make.subj died with a segmentation fault.
3. v.merge could not be used because of 2.
4. v.cutter automatically removed all dead-end streets. I found no way
around that behavior.
5. v.out.shape exported only closed polygons. I found no way around that
behavior. Is that inherent in shape files?
6. v.proj was useful only because I was able to use the version that I
rewrote to perform the nad27->nad83 conversion.
7. v.digit ended on segmentation faults several times while saving a
finished file. At one time I found myself abruptly dropped into a shell
while v.digit was still running. I still don't know what that was about.
Removing blocks of lines with v.digit is amazingly slow.
8. After I removed most of the lines from the original vector file the map
boundaries in the vector file header were not changed. I found no way to
change them other than to edit the boundaries in v.digit.
9. v.extract did not work.
10. v.out.ascii gave me a header with a blank line imbedded in it, and
v.transform would not read that header.
11. v.transform doesn't work in the context of GRASS database management.
It required that I export an ASCII vector file in one location and then
copy that file from it's original location to the dig_ascii element in a
second location. The transformed file is produced as an ascii file and it
has to be imported before it's very useful. That whole process is *way*
more complicated than it needs to be.
12. Not a specific module problem, but a general problem: anything you do
to change a vector file requires the user to rerun v.support. Why don't
the vector modules that trigger that requirement just run v.support
themselves, as is common in the raster modules?
13. v.info produced useless results, because the boundaries of the map
were cited in integer degrees. The map was well under 1 degree across in
any direction, so the boundaries were sited with N=S and E=W.
14. Several of the modules refer to GRASS4 in their user messages.
I know that there has been an effort to upgrade the vector capabilities
for 5.1, but has a lot of work been done on the vector modules since
5.0pre2? If not, then I'd have to say that GRASS's vector capabilities are
in a very poor state.
Roger Miller
Lee Wilson and Associates.
