Mon, May 22 2006
15:49:48
|
|
Request created by guest
|
|
Subject: v.to.rast: wrong cells rasterised often
Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: 2006-05-18
Example:
Grab the testing location:
http://www.biol.uni.wroc.pl/sieczka/udostepnione/grass/vtorast/test.tar.bz2
Then:
enter mapset "vtorast"
g.region test
v.to.rast input=streams output=streams_rast use=val value=1
d.rast.num -f streams_rast grid_color=grey
d.vect streams
See the result:
http://www.biol.uni.wroc.pl/sieczka/udostepnione/grass/vtorast/wrong_cell.png
A *wrong* cell is there in the v.to.rast output. Errors like this are frequent
in other parts of streams_rast.
If somebody asks, it is impossible to correct them using r.thin, becasue a correct
cell is removed, and the wrong one remains; see:
http://www.biol.uni.wroc.pl/sieczka/udostepnione/grass/vtorast/rthindoesnthelp.png
Maciek
|
|
Thu, May 25 2006
21:57:24
|
|
Mail sent by mneteler
|
|
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 |
|
Fri, May 26 2006
10:58:06
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Fri, 26 May 2006 20:57:49 +1200
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Maciek Sieczka <werchowyna@epf.pl>
|
Cc |
grass-bugs@intevation.de, grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] [bug #4488] (grass) v.to.rast: wrong cells rasterised often
|
Message-Id |
<20060526205749.331ab671.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20060525230505.b5bafb94.werchowyna@epf.pl>
|
References |
<20060525195724.4CABA1005D3@lists.intevation.de> <20060525230505.b5bafb94.werchowyna@epf.pl>
|
X-Mailer |
Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
|
X-Spam-Level |
|
> > 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
|
|
Sun, Jun 11 2006
13:52:32
|
|
Mail sent by msieczka
|
|
Re-sending the message as it was not stored in the tracker, propably
due to PNG attachements.
On Thu, 25 May 2006 21:57:24 +0200 (CEST)
Markus Neteler via RT <grass-bugs@intevation.de> wrote:
> 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
|
|
Sun, Jun 11 2006
13:54:42
|
|
Mail sent by msieczka
|
|
Re-sending the message as it was not stored in the tracker, propably
due to PNG attachements. Images are available in the grass-dev archives though.
n 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=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
|
|
Wed, Jul 26 2006
18:43:43
|
|
User changed to tutey@o2.pl by msieczka
|
|