Thanks for all your input as to what to do.  I'll run through the
relevant items and try to explain better my situation.

David D Gray (ddgray@armadce.demon.co.uk) writes
<<
The GRASS vector data is stored as a set of cross-indexed `topological'
structures in the dig_plus file associated with a particular vector map.
v.support (through v.build) builds this series of indices, and
associates
attributes with areas, lines and so on. If this process fails it is
usually because v.support cannot identify a topolgically correct
structure
such as an area. The reasons for this can be legion, but some common
ones are:

1) There are lines marked deleted, but not removed from the map. Run
v.clean
on the map. (Rare problem - shouldn't happen - but it does sometimes)
>>

I tried running v.clean, but whenever I tried it with anything other
than the help option, it would segfault.  I compiled it from the
grass5beta7 sources on a suse linux glibc2.1 system running kernel 2.3.x
and gcc 2.7.2.3.

<<
2) There are duplicate line segments. Run v.spag -i on the map. The -i
flag
is important. Otherwise the module attempts various other processes,
mostly
these make matters worse.
>>

v.spag seems to only mark segments for deletion, requiring v.clean
afterwards.  Read my response to (1).

<<
5) Sometimes an area edge made of just a link between two nodes is not
recognised
as a valid segment by v.build. This is a strange one. I've never been
able
to fathom why this sometimes causes problems and at other times doesn't.
I've always found that in a manually digitised map, a link like this
always causes
build failure. In v.digit delete the line and digitise it again with at
least one
intermediate vertex.
>>

Tried altering the e00 file and reimporting.

<<
> For now, when I try to see what's in the maps with v.report, I get
>         WARNING: category support for vector file [foo] in mapset
[bar]
>                 is missing
>

Just means that category text labels haven't been assigned. If you want
to assign these run v.support with option=edit
>>

At this point, I think I could use some definitions of terms as they
apply to GRASS.  Terms I would accept references to on-line material,
but at this point I'm not sure what's meant by:
    categories, labels, attributes, probably a few others, but mostly
    pertaining to rim, which I'll get to later.

<<
> I also have not been able to find any trace of having imported the
> journey to work data.  Is there something to look for that I'm
missing?
>

I htink the import just failed. There is supposedly a v.in.e00 module.
Maybe
you can get that to work.
>>

The journey to work data are not in vector format, or any other
geographic format for that matter.  The e00 file consists of one INFO
file which consists of 30 some thousand records containing origin tract,
destination tract (both actually quatrads of state, county, mcd, and
tract), and number of people who live in the origin tract and work in
the destination tract.  What I want to do is for each tract to aggregate
the number of workers working in tracts meeting criteria based on the
relative location of the tracts and the layout of the road network.  The
main part of it is a straightforward database operation, just that
checking the criteria is a geographic concern and then displaying the
result is also a geographic concern.

<<
>    V.SUPPORT:
>
> Selected information from vector header
>  Organization:
>  Map Name:      ematract
>  Source Date:
>  Orig. Scale:   100000
>  Snapping threshold   23.23
...
> PNT_TO_AREA failed: (713150.383111, 493868.203704) (Category 534)
> PNT_TO_AREA failed: (721301.768353, 461068.482060) (Category 757)
> PNT_TO_AREA failed: (713772.643071, 461330.769097) (Category 763)

These are label points where v.build couldn't identify the enclosing
polygon. Is this supposed to be an area coverage?
>>

These are tracts, which are area features, and the roads are line
features.  In subsequent retries without snapping, I've gotten it down
to 3 polygons that could not be enclosed.  Here's where the terminology
comes in, I tried checking in the e00 file for what's going on, but with
category I'm not sure whether to look for a matching -# or matching -ID
(I used the -i option.

<<
> WARNING: line 58 label: 58 matched another label: 64.
> WARNING: line 93 label: 93 matched another label: 94.
> WARNING: line 99 label: 99 matched another label: 102.
> ... About a thousand more lines like this ...

Just means that more than one area are assigned the
same category number.
>>

Tried fixing that with v.spag -i.  See note (2)

Eric G. Miller (egm2@jps.net) writes
<<
I think converting the attribute data to RIM or PostgreSQL can be used
to get around this.  Then you might use a selection query to get the
ids and then use that.
>>

I'm about convinced that that is the way to go.  The question now is
whether to go with PostgreSQL or RIM.  Looking at both the general RIM
and the v.db.rim manual, I have a few questions.  One is the nature of
databases and tables in RIM through grass.  The v.db.rim manual says
that only one set of geographic coordinates is permitted per database,
is it possible to have multiple tables per database with grass.  In
general, does RIM support compound field links between tables (as I
said, the tracts are defined by a combination of four fields) and does
it support one-to-many links.

Radim Blazek (Radim.Blazek@dhv.cz) writes
<<
To create ps map with  line width based on number of travelers you can
use
ps.map.new :
>>

While that is not useful for me yet as far as the journey to work is
concerned (read what I wrote above about how I need to aggregate it), it
should help for identify roads by their classes and once I do get the
journey to work data aggregated.

Michel Wurtz (mw@engees.u-strasbg.fr) writes
<<
Snapping lines is probably the reason why you have 6 unattached atts
for areas (or areas are too small...)
>>

I checked those tracts in the e00 file, both by TRACT# and TRACT-ID,
they both had areas and perimeters that were larger than some tracts
that were not problems.  I don't know if that means anything or if it
could have a pathological shape that would make it not narrow it beyond
recognition in some dimension.

Is it possible to just manually load things into a database for grass,
say write a perl script that will read the e00 file output each part to
a temporary file and then load it through an SQL command.  If so, what
parts would that work with and what format requirements would be required.

Thanks for your help,
Scott Smith


