[GRASS-dev] [bug #4488] (grass) v.to.rast: wrong cells
rasterised often
Maciek Sieczka
werchowyna at epf.pl
Sat May 27 05:48:45 EDT 2006
On Fri, 26 May 2006 20:57:49 +1200
Hamish <hamish_nospam at yahoo.com> wrote:
> 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?
So I did the checking. And yes, v.to.rast results in 55 and 61 are
*exactly* the same, as to which cells it picks. It seems v.to.rast
didn't change at all in this regard. Same wrong cells are output by
v.to.rast in both 55 and 61.
> 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)
I'm aware of these issues, they used to give much trouble too. I took
care not let such shifting take place in this case.
Step by step how I proceeded in 61:
$ g.region vect=streams res=10 -ap
projection: 1 (UTM)
zone: 33
datum: wgs84
ellipsoid: wgs84
north: 5684380
south: 5675370
west: 596040
east: 602820
nsres: 10
ewres: 10
rows: 901
cols: 678
$ v.to.rast input=streams output=streams_rast use=val value=1
$ d.rast streams_rast
$ d.zoom
$ d.rast.num -f streams_rast grid_color=grey
$ d.vect streams
$ g.region -p
projection: 1 (UTM)
zone: 33
datum: wgs84
ellipsoid: wgs84
north: 5678900
south: 5678690
west: 599560
east: 599780
nsres: 10
ewres: 10
rows: 21
cols: 22
Step by step how I proceeded in 55:
$ v.in.shape input=streams/streams.shp output=streams5
$ v.support streams5
$ g.region vect=streams5 res=10 -ap
projection: 1 (UTM)
zone: 33
datum: wgs84
ellipsoid: wgs84
north: 5684380
south: 5675370
west: 596040
east: 602820
nsres: 10
ewres: 10
rows: 901
cols: 678
$ v.to.rast input=streams5 output=streams_rast5
$ d.rast streams_rast5
$ d.zoom
$ d.rast.num -f streams_rast5 grid_color=grey
(note -f is ignored, a bug in 55's d.rast.num?)
$ d.vect streams5 col=red
$ g.region -p
projection: 1 (UTM)
zone: 33
datum: wgs84
ellipsoid: wgs84
north: 5678900
south: 5678700
west: 599560
east: 599820
nsres: 10
ewres: 10
rows: 20
cols: 26
See the attached PNGs for the displayed result.
Thanks for your interest.
Maciek
P.S.
In case of any doubts the testing dataset is still here:
http://www.biol.uni.wroc.pl/sieczka/udostepnione/grass/vtorast/test.tar.bz2
--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vtorast61.png
Type: image/png
Size: 7009 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20060527/701b082d/vtorast61.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vtorast55.png
Type: image/png
Size: 9553 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20060527/701b082d/vtorast55.png
More information about the grass-dev
mailing list