Details Ticket 4488


Comment | Reply | Take | Resolve


Serial Number 4488
Subject v.to.rast: wrong cells rasterised often
Area grass6
Queue grass
Requestors tutey@o2.pl
Owner none
Status open
Last User Contact Sun Jun 11 13:54:42 2006 (2 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Wed Jul 26 18:43:43 2006 (2 yr ago)
Created Mon May 22 15:49:48 2006 (2 yr ago)

Transaction History Ticket 4488


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  
Comment | Reply | Take | Resolve

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request