Warning messages v.support

[Susan Huse]

> From grass-lists-owner at max.cecer.army.mil Wed Aug 25 00:47:16 1993
> From: motte <motte at hacktic.nl>
> Subject: Warning messages v.support
> Sender: grass-lists-owner at max.cecer.army.mil
> Reply-To: grassu-list at max.cecer.army.mil
> To: grassu-list at 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: 833
> 
> Just 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