[GRASS-dev] [bug #4488] (grass) v.to.rast: wrong cells rasterised often

[Hamish]

> > I get the same result, but probably it was implemented like
> > that by purpose. The incriminated cell which you find a
> > spatial outlier is needed to give a good rasterized 
> > representation of the line *form*:
> > http://www.biol.uni.wroc.pl/sieczka/udostepnione/grass/vtorast/wrong_cell.png
> > 
> > Probably we want a flag to either strictly follow the line
> > or to preserve as much as possible of the vector shape.
..
> IMHO the default behaviour should be to follow the vector input as
> extactly as possible, not to try to be wiser than the data and the
> user.
> 
> I appreciate your theory, but I still believe that it's all just an
> oridinary bug. See these attached ones, for which I can't find a
> justification.


Way back when I spent a bit of time trying to figure out how v.to.rast
worked. While I never saw anything like this at that time*, I can offer
some possible insights:


Lines and area borders are treated differently. IIRC, lines tended to
"activate" every cell they crossed, while area boundaries (without
category numbers) activated the cell if more than half the cell was
covered by the "in"-side of the area.

I'd have to dig into the mailing list archives to find the screenshots,
but figuring it out was enough trouble that I bothered update the man
page: ("Otherwise:" section)

http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/vector/v.to.rast/description.html?rev=HEAD


[*] I did take a fair amount of time zooming way in on lines and areas,
so I think I would have seen your problem if it was a common error - do
you get the same results using GRASS 5.4?


Also, check that your raster region is not like:
res=50 w=1075 e=1125

and after zoom in the region is like:
res=50 w=100 e=150

as that can have the appearance of shifting raster cells 25m while the
lines stay in the same place. (that one was another few days of head-
scratching for me)




Hamish