From grass-lists-owner@max.cecer.army.mil Wed Aug 25 00:47:16 1993
From: motte <motte@hacktic.nl>
Subject: Warning messages v.support
Sender: grass-lists-owner@max.cecer.army.mil
Reply-To: grassu-list@max.cecer.army.mil
To: grassu-list@max.cecer.army.mil
Date: Wed, 25 Aug 1993 09:32:35 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL21]
Content-Type> : > text>
Content-Length: 833Just to get rid of some of my annoyance regarding v.support: does the
warning 'area 7 label 1 matched other label 1' sound familiar to you?
Can anybody tell me how to get rid of these 'double' labels? I really
can't see how to find these particular labels in a dig_att file that
may contain over 4000 labels, as there is no link to the area's internal
number. The same story goes for the infamous 'PNT_TO_AREA failed' message,
althought this gives the coordinates of the sources of error, so theoretically
you should be able to find them.
v.digit!!!!! Wonder program of the 90's. Choose digitizer none.
If you have double labels with the same label (as in your example),
it doesn't really affect anything that I'm aware of. If the labels
differ, you should clean them to be sure that there are no discrepancies.
GRASS really uses only one any way, you just want it to be the right one.
To get rid of them:
go in to v.digit
use the hidden debugger menu (type "-" at the main menu)
A - Find area, (7 enter, q enter)
go to the highlighted area, and unlabel it.
Repeat for each area that has double labels.
Even though it appears completely unlabeled, after you exit and run
v.support the second label will be attached to teh area. If you have more
than 2 labels for an area, you will need to clean out one at a time,
running v.support between each iteration.
For point to area failures, that generally means that the area is not
"clean". Try using the Toolbox: open area lines option. This will
highlight areas that are not closed. You may need to snap nodes, etc.
to close the area, before the attribute will attach properly in v.support.
Rarely, an attribute will be outside of an area, which would also
fail in v.support.
Secondly: can the people managing this list try to prevent messages like
'dir' and 'ping' or the returned mail from some unknown host being spread
over the net? Last week I got about 15 of these useless messages...Philip Verhagen
Stichting RAAP
Plantage Muidergracht 14
NL-1018TV Amsterdam
Sue Huse
REGIS
UC Berkeley