v.to.rast failures ( and related? v.support problem)

Susan Huse sue at ced.berkeley.edu
Mon Nov 15 14:33:17 EST 1993

> From grass-lists-owner at max.cecer.army.mil Mon Nov 15 10:36:36 1993
> 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
> Cc: bjorn at geog.GEOG.UCSB.EDU
> Bjoern: Liten i Skaune, men stor ute i Vaarlden (Sverige-Nytt, 930503)
> Advice(1/2): Tomate todo el tiempo que necesites 
> Advice(2/2): en acquellas cosas que te hacen feliz.
> Subject: v.to.rast failures ( and related? v.support problem)
> Date: Mon, 15 Nov 1993 10:21:53 -0800
> From: Bjorn Svensson <bjorn at geog.GEOG.UCSB.EDU>
> Content-Length: 1720
> I have two interrelated problems.
> 1.	I have a vector layer consisting of a bunch of areas.  
> 	When I do a v.to.rast, some of the areas don't transfer.  
> 	I've checked with d.what.vect and some areas have a value 
> 	on the vector version, but on the raster they have 
> 	become (0) meaning nothing.
> 	What could the problem be?
Got me!!!  Do you have a forgotten mask running??

> 2.	On another vector layer of areas, the v.to.rast works fine.
> 	Except that after I do a "v.support option=build" a few
> 	areas dont transfer.  The output looks like this:
> WARNING: area 5 label: 3 matched another label: 3.
> WARNING: area 32 label: 4 matched another label: 4.
> WARNING: area 3 label: 2 matched another label: 2.
> PNT_TO_AREA failed: (693691.590762, 3959246.402942) (Category 2)
> PNT_TO_AREA failed: (693700.923745, 3959055.076807) (Category 3)
> PNT_TO_AREA failed: (693685.767299, 3959246.756544) (Category 2)
>  Number of lines:   113
>  Number of nodes:   90
>  Number of areas:   32
>  Number of isles:   10
>  Number of atts :   35
>  Number of unattached atts :   3
>  Snapped lines  :   0
> 	The areas that dont transfer are the "PNT_TO_AREA" failures
> 	which makes sense, but why does it work if I DON'T do
> 	v.support?
> 	Sometimes it seems to help to use v.digit to break,remove,
> 	snap, label the areas, but only some times.
> 	Why do some labelled areas become unlabelled (unattached atts)
> 	when I do a v.support?

I have had similar problems with certain areas that seemed DESTINED not to 
work.  Usually they have been very small areas.  That are below the digitizing
and snapping threshold.  Every time you reenter v.digit
it (VERY UNFORTUNATELY) resets your digitizing threshold to 0.03 (I
forget the units).  Perhaps it does this in v.support before you enter, I
don't know.  But if the area is too small, it may get dumped when building.
If you are using the snap option, this could certainly explain it if you have 
very close nodes because of very small areas.

In some cases, I have had to actually redraw the
Other times, I have had a final point exactly on the node - resulting
in a double point and topology won't build.  That would be corrected
by the method you described.  

> 	And what does the WARNING: area 5 .. mean?
That means that you have two attribute labels in area #5.  In this particular
case, I see that all of your double labels are the same, so it doesn't matter.
What does matter is if the area label matches a second label that is different.
e.g., area 5 label: 4 matched another label: 3.  In which case, GRASS would
use the label last applied.  You would need to fix it by going into v.digit
unlabeling the area.  If the label showing in v.digit is the wanted one (or
if you v.support showed more than 2 labels) you will need to exit v.digit,
run v.support, enter v.digit, unlabel and relabel.  You can only remove
one label at a time, and you need to run v.support between each removal.
To find area 5 use the "-" (hidden debugging options accessed by a hyphen).

> =======================================================
>   ///////    Bjorn Svensson
>   //    |
>   / <---@    Department of Geography
>   |      >   University of California, Santa Barbara
>   |     <    Santa Barbara, CA 93106, USA
>   |   __X 
>   \  |       e-mail : bjorn at geog.ucsb.edu
> =======================================================

-Sue Huse
UC Berkeley

More information about the grass-user mailing list