Scott
Just a few remarks:
Scott Smith wrote:
I'm trying to perform analysis on a set of coverages I received in e00
format. I imported them with m.in.e00 with no apparrent problems, but
v.support has been complaining and I don't know if any of that would
interfere with getting the non geographic attributes connected with the
vector maps, the output from my attempt to run v.support follows.
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)
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.
3) Try adjusting the scale in v.digit - then exit v.digit and run the
v.support
again. If the scale is too big, it seems some nodes snap to other nodes
before
they can be processed during the build. If you don't need snapping
capabilities,
make it something quite small, like 1:1000 or 1:2000
4) Degenerate structures, single points or rings of points all with the
same value.
These cause build failure. Export to an ascii vector map and track down
with
utilities like sed or grep. eg an area edge with two points will have a
line like
A 2
Then reimport. You'll need to back up the dig_att file.
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.
As for what I want to do: The three coverages are of tracts, roads, and
journey to work data. What I want to do is display the road network
with different colors for each class of roadway (an attribute attached
to each road segment) and show the number of workers from any tract
traveling to any of a set of tracts somewhere else in the region. Is
this posible in vector mode or does it require conversion to raster?
Would RIM be able to do the job. And if conversion to raster is
necessary, would it have everything needed to do so?
You can display vector lines in different colors by creating a separate
map for each category and using a different display color for each. Then
for redisplay you could compose a simple script like:
#!/bin/sh
# d.multidisplay.sh
d.rast map=backdrop [for backdrop map]
d.vect map=tracts color=orange
d.vect map=roads color=gray
d.vect map=journey color=yellow
Vector display capabilities are a bit limited at the moment, as you have
to have a separate map for each color you want to display, and there are
only a few colors available(16) and these are fixed. You can have any
rgb
color and different categories in the same file if you rasterise the
lines,
and the colors can be user-selected, but here the appearance might be
rough at the edges. Again a script could aid redisplay:
#!/bin/sh
d.rast map=backdrop
d.rast -o map=vectordata
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
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.
Scott Smith
BEGIN output from v.support
V.SUPPORT:
Selected information from vector header
Organization:
Map Name: ematract
Source Date:
Orig. Scale: 100000
Snapping threshold 23.23Reading Vector file.
Building areas
Building islands
Attaching labels
PNT_TO_AREA failed: (719448.051218, 502007.230708) (Category 472)
PNT_TO_AREA failed: (720457.946193, 497473.093750) (Category 517)
PNT_TO_AREA failed: (709717.288887, 494527.788002) (Category 521)
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?
Number of lines: 2756
Number of nodes: 1861
Number of areas: 1010
Number of isles: 119
Number of atts : 1004
Number of unattached atts : 6
Snapped lines : 11V.SUPPORT:
Selected information from vector header
Organization:
Map Name: emaroads
Source Date:
Orig. Scale: 100000
Snapping threshold 23.23Reading Vector file.
Building areas
Building islands
Attaching labels
WARNING: line 3 label: 3 matched another label: 4.
WARNING: line 14 label: 14 matched another label: 16.
WARNING: line 28 label: 27 matched another label: 28.
WARNING: line 35 label: 35 matched another label: 39.
WARNING: line 46 label: 46 matched another label: 47.
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.
Number of lines: 7764
Number of nodes: 6859
Number of areas: 0
Number of isles: 0
Number of atts : 7764
Number of unattached atts : 0
Snapped lines : 0If anyone is interested, I also have logs from m.in.e00 .