Maciek,
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.
Markus
-------------------------------------------- Managed by Request Tracker
On Thu, 25 May 2006 21:57:24 +0200 (CEST)
Markus Neteler via RT <grass-bugs@intevation.de> wrote:
Maciek,
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.
Markus,
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.
Thanks for your reply!
Maciek
--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/
> 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
On Fri, 26 May 2006 20:57:49 +1200
Hamish <hamish_nospam@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=1125and after zoom in the region is like:
res=50 w=100 e=150as 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/
