Details Ticket 2061


Comment | Reply | Take | Open


Serial Number 2061
Subject r.los needs FP update
Area bug
Queue grass
Requestors neteler@itc.it
Owner none
Status resolved
Last User Contact Fri Aug 15 01:36:55 2003 (5 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Mon Aug 25 16:42:16 2003 (5 yr ago)
Created Wed Aug 13 14:54:53 2003 (5 yr ago)

Transaction History Ticket 2061


Wed, Aug 13 2003 14:54:53    Request created by guest  
Subject: r.los needs FP update

grass binary for platform: Compiled from Sources

After inspection of the source code (due to unsatisfying results)
it seems that 'r.los' only works with CELL elevation data:

src/raster/r.los/cmd/main.c:
         /*  allocate buffer space for row-io to layer           */
         cell = G_allocate_cell_buf();
         /*      open elevation overlay file for reading         */
         old = G_open_cell_old (elev_layer, old_mapset);
etc.

The module should be fixed to also accept FCELL/DCELL DEMs.
However, I have no clear idea how much work is needed for
that as segmentation is used internally.

Markus
Wed, Aug 13 2003 15:31:04    Mail sent by paul-grass@stjohnspoint.co.uk  
Return-Path <paul-grass@stjohnspoint.co.uk>
Delivered-To grass-bugs@lists.intevation.de
Date Wed, 13 Aug 2003 14:31:02 +0100 (BST)
From Paul Kelly <paul-grass@stjohnspoint.co.uk>
X-X-Sender paulk@agrippa.ukshells.co.uk
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #2061] (grass) r.los needs FP update
In-Reply-To <20030813125454.A0EAC13B6B@lists.intevation.de>
Message-ID <Pine.LNX.4.53.0308131419490.2504@agrippa.ukshells.co.uk>
References <20030813125454.A0EAC13B6B@lists.intevation.de>
MIME-Version 1.0
Content-Type TEXT/PLAIN; charset=US-ASCII
X-Spam-Status No, hits=-2.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55
X-Spam-Level
X-Spam-Checker-Version SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)

On Wed, 13 Aug 2003, Request Tracker wrote:

> this bug's URL: http://intevation.de/rt/webrt?serial_num=2061
> -------------------------------------------------------------------------
>
> Subject: r.los needs FP update

It is my idea for a sort of long-term plan / project that I would like to
re-write r.los, based on an algorithm that was published in the July issue
this year of 'Photogrammetric Engineering & Remote Sensing':
http://www.asprs.org/asprs/publications/pe&rs/2003journal/july/abstracts.html
The title is 'A Fast Algorithm for Approximate Viewshed Computation'
The improvements in r.cva (cumulative viewshed analysis
http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html ) would also be incorporated
into this new version. (r.cva also does not work with floating point maps
although it is well written and up-to-date and is a lot better than the
current r.los; the web page doesn't seem to have any information on the
licence though so it is unclear if it can go into the current GRASS)
Anyway the functionality can just be cloned anyway; it would probably be
easier to do this than adapt seeing it is based on the old r.los.

The algorithm in PE&RS is from the US Army CERL so it would be especially
appropriate for it to go into the latest GRASS. I would hope some of the
Vectlib and dglib functions could be used for determining the crossing
points and distances between the cells but I will have to learn about
them first.

Paul


Wed, Aug 13 2003 18:16:11    Mail sent by glynn.clements@virgin.net  
Return-Path <glynn.clements@virgin.net>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn.clements@virgin.net>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <16186.22776.730944.696768@cerise.nosuchdomain.co.uk>
Date Wed, 13 Aug 2003 16:27:52 +0100
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #2061] (grass) r.los needs FP update
In-Reply-To <20030813125454.A0EAC13B6B@lists.intevation.de>
References <20030813125454.A0EAC13B6B@lists.intevation.de>
X-Mailer VM 7.07 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid
X-Spam-Status No, hits=-2.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55
X-Spam-Level
X-Spam-Checker-Version SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Request Tracker wrote:

> Subject: r.los needs FP update
> 
> grass binary for platform: Compiled from Sources
> 
> After inspection of the source code (due to unsatisfying results)
> it seems that 'r.los' only works with CELL elevation data:
> 
> src/raster/r.los/cmd/main.c:
>          /*  allocate buffer space for row-io to layer           */
>          cell = G_allocate_cell_buf();
>          /*      open elevation overlay file for reading         */
>          old = G_open_cell_old (elev_layer, old_mapset);
> etc.
> 
> The module should be fixed to also accept FCELL/DCELL DEMs.
> However, I have no clear idea how much work is needed for
> that as segmentation is used internally.

It should probably be changed to just use either FCELL or DCELL
internally. I don't see any reason to preserve the underlying data
type.

AFAICT, the only situations where CELL maps shouldn't be converted to
FP is where they may actually represent discrete categories rather
than a scalar quantity.

-- 
Glynn Clements <glynn.clements@virgin.net>


Thu, Aug 14 2003 12:15:32    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 14 Aug 2003 12:15:20 +0200
From Markus Neteler <neteler@itc.it>
To Glynn Clements <glynn.clements@virgin.net>
Cc Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #2061] (grass) r.los needs FP update
Message-ID <20030814121520.J31873@itc.it>
Mail-Followup-To Glynn Clements <glynn.clements@virgin.net>, Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
References <20030813125454.A0EAC13B6B@lists.intevation.de> <16186.22776.730944.696768@cerise.nosuchdomain.co.uk>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5.1i
In-Reply-To <16186.22776.730944.696768@cerise.nosuchdomain.co.uk>; from glynn.clements@virgin.net on Wed, Aug 13, 2003 at 04:27:52PM +0100
X-Spam-Status No, hits=-5.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.55
X-Spam-Level
X-Spam-Checker-Version SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
On Wed, Aug 13, 2003 at 04:27:52PM +0100, Glynn Clements wrote:
> 
> Request Tracker wrote:
> 
> > Subject: r.los needs FP update
> > 
> > grass binary for platform: Compiled from Sources
> > 
> > After inspection of the source code (due to unsatisfying results)
> > it seems that 'r.los' only works with CELL elevation data:
> > 
> > src/raster/r.los/cmd/main.c:
> >          /*  allocate buffer space for row-io to layer           */
> >          cell = G_allocate_cell_buf();
> >          /*      open elevation overlay file for reading         */
> >          old = G_open_cell_old (elev_layer, old_mapset);
> > etc.
> > 
> > The module should be fixed to also accept FCELL/DCELL DEMs.
> > However, I have no clear idea how much work is needed for
> > that as segmentation is used internally.
> 
> It should probably be changed to just use either FCELL or DCELL
> internally. I don't see any reason to preserve the underlying data
> type.

Sounds good - but the segment library (src/libes/segment/) seems
to be limited to CELL.
 
> AFAICT, the only situations where CELL maps shouldn't be converted to
> FP is where they may actually represent discrete categories rather
> than a scalar quantity.

Help is welcome to get r.los fixed.

Markus


Thu, Aug 14 2003 17:18:23    Mail sent by glynn.clements@virgin.net  
Return-Path <glynn.clements@virgin.net>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn.clements@virgin.net>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <16187.43002.394284.32630@cerise.nosuchdomain.co.uk>
Date Thu, 14 Aug 2003 16:17:14 +0100
To Markus Neteler <neteler@itc.it>
Cc Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #2061] (grass) r.los needs FP update
In-Reply-To <20030814121520.J31873@itc.it>
References <20030813125454.A0EAC13B6B@lists.intevation.de> <16186.22776.730944.696768@cerise.nosuchdomain.co.uk> <20030814121520.J31873@itc.it>
X-Mailer VM 7.07 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid
X-Spam-Status No, hits=-2.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,REPLY_WITH_QUOTES version=2.55
X-Spam-Level
X-Spam-Checker-Version SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Markus Neteler wrote:

> > > Subject: r.los needs FP update
> > > 
> > > grass binary for platform: Compiled from Sources
> > > 
> > > After inspection of the source code (due to unsatisfying results)
> > > it seems that 'r.los' only works with CELL elevation data:
> > > 
> > > src/raster/r.los/cmd/main.c:
> > >          /*  allocate buffer space for row-io to layer           */
> > >          cell = G_allocate_cell_buf();
> > >          /*      open elevation overlay file for reading         */
> > >          old = G_open_cell_old (elev_layer, old_mapset);
> > > etc.
> > > 
> > > The module should be fixed to also accept FCELL/DCELL DEMs.
> > > However, I have no clear idea how much work is needed for
> > > that as segmentation is used internally.
> > 
> > It should probably be changed to just use either FCELL or DCELL
> > internally. I don't see any reason to preserve the underlying data
> > type.
> 
> Sounds good - but the segment library (src/libes/segment/) seems
> to be limited to CELL.

That contradicts the documentation, which implies that the cells may
have arbitrary size; i.e. a cell is just "len" bytes, where "len" is
given in the call to segment_format(). Cursory examination of the code
supports the documentation.

-- 
Glynn Clements <glynn.clements@virgin.net>


Thu, Aug 14 2003 17:29:22    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 14 Aug 2003 17:29:10 +0200
From Markus Neteler <neteler@itc.it>
To Glynn Clements <glynn.clements@virgin.net>
Cc Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #2061] (grass) r.los needs FP update
Message-ID <20030814172910.F6039@itc.it>
Mail-Followup-To Glynn Clements <glynn.clements@virgin.net>, Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
References <20030813125454.A0EAC13B6B@lists.intevation.de> <16186.22776.730944.696768@cerise.nosuchdomain.co.uk> <20030814121520.J31873@itc.it> <16187.43002.394284.32630@cerise.nosuchdomain.co.uk>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5.1i
In-Reply-To <16187.43002.394284.32630@cerise.nosuchdomain.co.uk>; from glynn.clements@virgin.net on Thu, Aug 14, 2003 at 04:17:14PM +0100
X-Spam-Status No, hits=-5.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.55
X-Spam-Level
X-Spam-Checker-Version SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
On Thu, Aug 14, 2003 at 04:17:14PM +0100, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > > > Subject: r.los needs FP update
> > > > 
> > > > grass binary for platform: Compiled from Sources
> > > > 
> > > > After inspection of the source code (due to unsatisfying results)
> > > > it seems that 'r.los' only works with CELL elevation data:
> > > > 
> > > > src/raster/r.los/cmd/main.c:
> > > >          /*  allocate buffer space for row-io to layer           */
> > > >          cell = G_allocate_cell_buf();
> > > >          /*      open elevation overlay file for reading         */
> > > >          old = G_open_cell_old (elev_layer, old_mapset);
> > > > etc.
> > > > 
> > > > The module should be fixed to also accept FCELL/DCELL DEMs.
> > > > However, I have no clear idea how much work is needed for
> > > > that as segmentation is used internally.
> > > 
> > > It should probably be changed to just use either FCELL or DCELL
> > > internally. I don't see any reason to preserve the underlying data
> > > type.
> > 
> > Sounds good - but the segment library (src/libes/segment/) seems
> > to be limited to CELL.
> 
> That contradicts the documentation, which implies that the cells may
> have arbitrary size; i.e. a cell is just "len" bytes, where "len" is
> given in the call to segment_format(). Cursory examination of the code
> supports the documentation.

OK - I tried to update the code and ended up with
WARNING: can't put float row into integer map

That's why I assumed (after a *quick* grep for CELL in segment)
that's related to segment. So there must be another oversight
in my updated r.los code. Mhhh.

Markus


Fri, Aug 15 2003 01:36:55    Mail sent by glynn.clements@virgin.net  
Return-Path <glynn.clements@virgin.net>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn.clements@virgin.net>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <16188.7102.507035.653377@cerise.nosuchdomain.co.uk>
Date Fri, 15 Aug 2003 00:31:10 +0100
To Markus Neteler <neteler@itc.it>
Cc Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #2061] (grass) r.los needs FP update
In-Reply-To <20030814172910.F6039@itc.it>
References <20030813125454.A0EAC13B6B@lists.intevation.de> <16186.22776.730944.696768@cerise.nosuchdomain.co.uk> <20030814121520.J31873@itc.it> <16187.43002.394284.32630@cerise.nosuchdomain.co.uk> <20030814172910.F6039@itc.it>
X-Mailer VM 7.07 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid
X-Spam-Status No, hits=-2.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55
X-Spam-Level
X-Spam-Checker-Version SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Markus Neteler wrote:

> > > Sounds good - but the segment library (src/libes/segment/) seems
> > > to be limited to CELL.
> > 
> > That contradicts the documentation, which implies that the cells may
> > have arbitrary size; i.e. a cell is just "len" bytes, where "len" is
> > given in the call to segment_format(). Cursory examination of the code
> > supports the documentation.
> 
> OK - I tried to update the code and ended up with
> WARNING: can't put float row into integer map

That's a libgis issue; you have to create the output map as FP (with
G_open_fp_cell_new(), G_open_raster_new(..., FCELL_TYPE) etc) if you
want to put FP rows.

If you want to write a CELL map, just open the input map as CELL and
use CELL internally. G_get_raster_row() etc will coerce FCELL and
DCELL to CELL (via quantisation rules), but G_put_raster_row() etc
refuse to coerce FCELL or DCELL to CELL (but will do the other
combinations).

It wouldn't be difficult to make libgis do those coercions, so
presumably they were omitted deliberately. Probably due to the
possibility of overflow.

> that's why I assumed (after a *quick* grep for CELL in segment)
> that's related to segment.

No; the segment library doesn't know anything about GRASS data types
(and doesn't use any GRASS functions except G_malloc and G_warning). 
The only occurrences of CELL in the segment code are in comments:

get_row.c:11:/*  int segment_get_row (SEGMENT *SEG, CELL *buf,int row) */
put_row.c:12:/*	buf is CELL *   WRAT code	*/
put_row.c:13:/*  int segment_put_row (SEGMENT *SEG, CELL *buf,int row) */

The "buf" arguments are actually "void *".

-- 
Glynn Clements <glynn.clements@virgin.net>


Mon, Aug 18 2003 17:06:02    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Mon, 18 Aug 2003 17:05:45 +0200
From Markus Neteler <neteler@itc.it>
To Glynn Clements <glynn.clements@virgin.net>
Cc Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #2061] (grass) r.los needs FP update
Message-ID <20030818170545.L15134@itc.it>
Mail-Followup-To Glynn Clements <glynn.clements@virgin.net>, Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
References <20030813125454.A0EAC13B6B@lists.intevation.de> <16186.22776.730944.696768@cerise.nosuchdomain.co.uk> <20030814121520.J31873@itc.it> <16187.43002.394284.32630@cerise.nosuchdomain.co.uk> <20030814172910.F6039@itc.it> <16188.7102.507035.653377@cerise.nosuchdomain.co.uk>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5.1i
In-Reply-To <16188.7102.507035.653377@cerise.nosuchdomain.co.uk>; from glynn.clements@virgin.net on Fri, Aug 15, 2003 at 12:31:10AM +0100
X-Spam-Status No, hits=-5.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.55
X-Spam-Level
X-Spam-Checker-Version SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
On Fri, Aug 15, 2003 at 12:31:10AM +0100, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > > > Sounds good - but the segment library (src/libes/segment/) seems
> > > > to be limited to CELL.
> > > 
> > > That contradicts the documentation, which implies that the cells may
> > > have arbitrary size; i.e. a cell is just "len" bytes, where "len" is
> > > given in the call to segment_format(). Cursory examination of the code
> > > supports the documentation.
> > 
> > OK - I tried to update the code and ended up with
> > WARNING: can't put float row into integer map
> 
> That's a libgis issue; you have to create the output map as FP (with
> G_open_fp_cell_new(), G_open_raster_new(..., FCELL_TYPE) etc) if you
> want to put FP rows.

Right, however I was already using
new = G_open_raster_new (out_layer,FCELL_TYPE);

> If you want to write a CELL map, just open the input map as CELL and
> use CELL internally. G_get_raster_row() etc will coerce FCELL and
> DCELL to CELL (via quantisation rules), but G_put_raster_row() etc
> refuse to coerce FCELL or DCELL to CELL (but will do the other
> combinations).

I would like to write FCELL as the resulting vertical angle (in degrees)
may be nice not to see as CELL.
 
> It wouldn't be difficult to make libgis do those coercions, so
> presumably they were omitted deliberately. Probably due to the
> possibility of overflow.
> 
> > that's why I assumed (after a *quick* grep for CELL in segment)
> > that's related to segment.
> 
> No; the segment library doesn't know anything about GRASS data types
> (and doesn't use any GRASS functions except G_malloc and G_warning). 
> The only occurrences of CELL in the segment code are in comments:
> 
> get_row.c:11:/*  int segment_get_row (SEGMENT *SEG, CELL *buf,int row) */
> put_row.c:12:/*	buf is CELL *   WRAT code	*/
> put_row.c:13:/*  int segment_put_row (SEGMENT *SEG, CELL *buf,int row) */
> 
> The "buf" arguments are actually "void *".

This was a stupid 'grep' done by me, sorry.

OK, found the problem (forgot to update also the cell value variables 'old'
and 'new').

Later I'll commit the change to CVS.

Thanks

 Markus


Mon, Aug 25 2003 16:42:16    Status changed to resolved by mneteler  
Comment | Reply | Take | Open

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