[GRASS5] Angle of incidence in viewshed/line of sight

GRASS GIS GRASS GIS developer
1

Hello all,
Just so we don't re-invent the wheel, has anyone developed the code for
evaluating the angle of incidence from a single point in the landscape (i.e.
the point used for r.los) to cells within the viewshed? I am analyzing
repeated historical topographic survey photographs (more on this later) and
want to account for components of registration and classification error due
to terrain (angle of incidence). I have looked at the code for r.los and
r.sun and will be seeking help from some students in our new computer
science/geomatics programme as I am not (yet) a programmer. Look forward to
any suggestions...

Graham Watt-Gremm
School of Environmental Studies
University of Victoria

2

Hi Graham,

seems to be a little tricky because for proper results you have to estimate
the strain caused by the lens.

Maybe it would be helpful to contact people working with photogrammetric data
like http://www.ifp.uni-stuttgart.de/eurosdr/index.html.

Mit freundlichen Grüßen / With kindest regards

Stefan Paulick

http://www.urbeli.com
mailto://stefan.paulick@urbeli.com
/*----------------------*/

Am Montag, 28. Februar 2005 20:11 schrieb Graham Watt-Gremm:

Hello all,
Just so we don't re-invent the wheel, has anyone developed the code for
evaluating the angle of incidence from a single point in the landscape
(i.e. the point used for r.los) to cells within the viewshed? I am
analyzing repeated historical topographic survey photographs (more on this
later) and want to account for components of registration and
classification error due to terrain (angle of incidence). I have looked at
the code for r.los and r.sun and will be seeking help from some students in
our new computer science/geomatics programme as I am not (yet) a
programmer. Look forward to any suggestions...

Graham Watt-Gremm
School of Environmental Studies
University of Victoria

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

3

Just so we don't re-invent the wheel, has anyone developed the code
for evaluating the angle of incidence from a single point in the
landscape (i.e. the point used for r.los) to cells within the
viewshed? I am analyzing repeated historical topographic survey
photographs (more on this later) and want to account for components of
registration and classification error due to terrain (angle of
incidence). I have looked at the code for r.los and r.sun and will be
seeking help from some students in our new computer science/geomatics
programme as I am not (yet) a programmer. Look forward to any
suggestions...

Yes, I have done this some time ago.

I modified r.los to return horizontal angle to target instead of
vertical angle to target for the values in the resultant raster map. This
was for GRASS 5.0, but it should work for 6.0 just as well I think. If
you want I can supply the code.

r.los is a real mess and doesn't scale well to larger grid sizes.

Be sure to check out r.cva as well:
  http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html

r.sunmask with altitude and azimuth options might be another way.

Hamish

4

On Wed, 2 Mar 2005 13:28:14 +1300
Hamish <hamish_nospam@yahoo.com> wrote:

> Just so we don't re-invent the wheel, has anyone developed the code
> for evaluating the angle of incidence from a single point in the
> landscape (i.e. the point used for r.los) to cells within the
> viewshed? I am analyzing repeated historical topographic survey
> photographs (more on this later) and want to account for components of
> registration and classification error due to terrain (angle of
> incidence). I have looked at the code for r.los and r.sun and will be
> seeking help from some students in our new computer science/geomatics
> programme as I am not (yet) a programmer. Look forward to any
> suggestions...

Yes, I have done this some time ago.

I modified r.los to return horizontal angle to target instead of
vertical angle to target for the values in the resultant raster map. This
was for GRASS 5.0, but it should work for 6.0 just as well I think. If
you want I can supply the code.

r.los is a real mess and doesn't scale well to larger grid sizes.

Be sure to check out r.cva as well:
  http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html

The GRASS 5 version of r.cva is currently broken due to a bug
in the floating point raster code I introduced myself (ahem).
I will have finished an updated version for GRASS 6 next week
that fixes the bug, handles vector points for observer positions
and introduces attributes for observer positions just
like Argh!nfo's Spatial Analyst uses.
I'll ask Mark Lake to update the file on his webpage then.

Regards,

Benjamin.

r.sunmask with altitude and azimuth options might be another way.

Hamish

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

5

Benjamin,

How are you coming on a way to install code like this without compiling or
recompiling GRASS?

Michael
____________________
C. Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

From: Benjamin Ducke <benducke@compuserve.de>
Organization: FU Berlin
Date: Thu, 3 Mar 2005 21:33:12 +0100
To: <grass5@grass.itc.it>
Subject: Re: [GRASS5] Angle of incidence in viewshed/line of sight

On Wed, 2 Mar 2005 13:28:14 +1300
Hamish <hamish_nospam@yahoo.com> wrote:

Just so we don't re-invent the wheel, has anyone developed the code
for evaluating the angle of incidence from a single point in the
landscape (i.e. the point used for r.los) to cells within the
viewshed? I am analyzing repeated historical topographic survey
photographs (more on this later) and want to account for components of
registration and classification error due to terrain (angle of
incidence). I have looked at the code for r.los and r.sun and will be
seeking help from some students in our new computer science/geomatics
programme as I am not (yet) a programmer. Look forward to any
suggestions...

Yes, I have done this some time ago.

I modified r.los to return horizontal angle to target instead of
vertical angle to target for the values in the resultant raster map. This
was for GRASS 5.0, but it should work for 6.0 just as well I think. If
you want I can supply the code.

r.los is a real mess and doesn't scale well to larger grid sizes.

Be sure to check out r.cva as well:
  http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html

The GRASS 5 version of r.cva is currently broken due to a bug
in the floating point raster code I introduced myself (ahem).
I will have finished an updated version for GRASS 6 next week
that fixes the bug, handles vector points for observer positions
and introduces attributes for observer positions just
like Argh!nfo's Spatial Analyst uses.
I'll ask Mark Lake to update the file on his webpage then.

Regards,

Benjamin.

r.sunmask with altitude and azimuth options might be another way.

Hamish

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

6

On Mon, 7 Mar 2005, Michael Barton wrote:

Benjamin,

How are you coming on a way to install code like this without compiling or
recompiling GRASS?

Did we not already decide that now that GRASS has shared libraries, it only needs the header files to be included in the binary distribution?
Then only the new module needs to be compiled (and a script can be written to do this automatically).
Radim may even have already done this (added the headers to the install).

Paul

7

On Tue, 8 Mar 2005, Paul Kelly wrote:

On Mon, 7 Mar 2005, Michael Barton wrote:

> Benjamin,
>
> How are you coming on a way to install code like this without compiling or
> recompiling GRASS?

Did we not already decide that now that GRASS has shared libraries, it
only needs the header files to be included in the binary distribution?
Then only the new module needs to be compiled (and a script can be
written to do this automatically).
Radim may even have already done this (added the headers to the install).

Am I completely wrong that for a module linking against say -lgis, you
still need a copy of libgis.a somewhere on the -L? How is the module to
"know" that its function calls are resolved? libproj.* is distributed as
*.a, *.la, and *.so - but you are right that beta2/lib only has
libgrass_*.so files. Are we anticipating that a user will compile an added
module locally even though the GRASS install was binary? Is the compile
train for added modules supposed to know what wizzardry GRASS does with
the LD path?

Roger

Paul

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no

8

Hello Roger

On Tue, 8 Mar 2005, Roger Bivand wrote:

On Tue, 8 Mar 2005, Paul Kelly wrote:

Did we not already decide that now that GRASS has shared libraries, it
only needs the header files to be included in the binary distribution?
Then only the new module needs to be compiled (and a script can be
written to do this automatically).
Radim may even have already done this (added the headers to the install).

Am I completely wrong that for a module linking against say -lgis, you
still need a copy of libgis.a somewhere on the -L?

Not if there is a shared library there--it can link against it instead.

How is the module to
"know" that its function calls are resolved?

You would just link against the grass libraries when compiling it. Probably two steps: something like

cc -c -I/usr/local/grass60/include testmodule.c -o testmodule.o

cc -o testmodule testmodule.o -L/usr/local/grass60/lib -lgrass_gis

would do it for a module that only links against the GIS library I think?

libproj.* is distributed as
*.a, *.la, and *.so - but you are right that beta2/lib only has
libgrass_*.so files. Are we anticipating that a user will compile an added
module locally even though the GRASS install was binary?

Yes I think that is easily possible now and is the best way to distribute add-on modules (with a script that will compile on the local system), rather than distributing lots of large and possibly incompatible binaries.

Is the compile
train for added modules supposed to know what wizzardry GRASS does with
the LD path?

LD_LIBRARY_PATH is only relevant for running GRASS modules, not for compiling. As long as the new 'testmodule' is run from within a GRASS session, LD_LIBRARY_PATH will already be set correctly and it will find the shared libraries it was linked against.

Hope this makes sense---I don't think there is a whole lot to it any more.

Paul

9

From: Roger Bivand <Roger.Bivand@nhh.no>
Reply-To: <Roger.Bivand@nhh.no>
Date: Tue, 08 Mar 2005 17:03:49 +0100 (CET)
To: Paul Kelly <paul-grass@stjohnspoint.co.uk>
Cc: Michael Barton <michael.barton@asu.edu>, Benjamin Ducke
<benducke@compuserve.de>, <grass5@grass.itc.it>
Subject: Re: [GRASS5] Angle of incidence in viewshed/line of sight

libgrass_*.so files. Are we anticipating that a user will compile an added
module locally even though the GRASS install was binary? Is the compile

This would be the ideal. Most users don't want to have to compile grass in
order to install it. This means (currently) that they cannot add any new
modules. While we could say, 'too bad'. It would be nice to develop a 'plug
in' architecture that would let more users expand GRASS to better fit their
needs. I suspect that it would also encourage more people to develop and
distribute more modules to expand GRASS--if they knew that more people could
use them.

Michael

______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

10

...

> From: Benjamin Ducke <benducke@compuserve.de>
> Organization: FU Berlin
> Date: Thu, 3 Mar 2005 21:33:12 +0100
> To: <grass5@grass.itc.it>
> Subject: Re: [GRASS5] Angle of incidence in viewshed/line of sight
>
> On Wed, 2 Mar 2005 13:28:14 +1300
> Hamish <hamish_nospam@yahoo.com> wrote:
>
>>> Just so we don't re-invent the wheel, has anyone developed the code
>>> for evaluating the angle of incidence from a single point in the
>>> landscape (i.e. the point used for r.los) to cells within the
>>> viewshed?

Currently I am not able to follow much the list. But stupid idea:

r.sun help 2>&1 |grep incidence
    incidout Output incidence angle raster map (mode 1 only)

may contain relevant code pieces (of course code must be modified).

Note that I have fixed r.sun's parameters yesterday.

Markus

11

On Tue, 8 Mar 2005, Roger Bivand wrote:

Am I completely wrong that for a module linking against say -lgis,
you still need a copy of libgis.a somewhere on the -L? How is the
module to "know" that its function calls are resolved? libproj.* is
distributed as *.a, *.la, and *.so - but you are right that
beta2/lib only has libgrass_*.so files.

If you mean how does the linker find the symbols it needs into the .so, don't
worry, they are there. Their absence will trigger an error while linking the
final executable. The way this final linking is done is what points to one of
.a, .la, .so. So no, you don't need the .a if you are compiling a module using
-shared in the linking phase (or the equivalent for non-GNU systems).

Most libraries are distributed as libs in all of .a .la and .so; .a (created
by ar+ranlib, probably) for static compiles, .la is a static library created
by libtool which will be used in conjunction with libtool for linking further
libs, .so for shared.

Are we anticipating that a
user will compile an added module locally even though the GRASS
install was binary? Is the compile train for added modules supposed
to know what wizzardry GRASS does with the LD path?

In principle, no. It only needs to be able to compile, so the proper -L and -I
configuration, which could be provided by a grass-config script, a la tcl-config.

At run-time, any LD tricks enabled by the grass script will be there, so no
need to worry, as long as the module is used as a module within a grass
session (i.e. not in a normal shell session).

12

Paul Kelly wrote:

>> Did we not already decide that now that GRASS has shared libraries, it
>> only needs the header files to be included in the binary distribution?
>> Then only the new module needs to be compiled (and a script can be
>> written to do this automatically).
>> Radim may even have already done this (added the headers to the install).
>
> Am I completely wrong that for a module linking against say -lgis, you
> still need a copy of libgis.a somewhere on the -L?

Not if there is a shared library there--it can link against it instead.

I think that the point is that binary distributions should always
include the libraries regardless of whether they are shared or static.
IIRC, we currently only include the libraries if they are shared
libraries.

From a packaging (RPM etc) perspective, static libraries would
normally go into a separate -devel package, along with the headers,
while shared libraries would go into the main package.

--
Glynn Clements <glynn@gclements.plus.com>

13

On Sun, 13 Mar 2005, Glynn Clements wrote:

Paul Kelly wrote:

> >> Did we not already decide that now that GRASS has shared libraries, it
> >> only needs the header files to be included in the binary distribution?
> >> Then only the new module needs to be compiled (and a script can be
> >> written to do this automatically).
> >> Radim may even have already done this (added the headers to the install).
> >
> > Am I completely wrong that for a module linking against say -lgis, you
> > still need a copy of libgis.a somewhere on the -L?
>
> Not if there is a shared library there--it can link against it instead.

I think that the point is that binary distributions should always
include the libraries regardless of whether they are shared or static.
IIRC, we currently only include the libraries if they are shared
libraries.

Yes, as of now 5.4.0 and 6.0.0 only install the *.so.

From a packaging (RPM etc) perspective, static libraries would
normally go into a separate -devel package, along with the headers,
while shared libraries would go into the main package.

That is an excellent idea - it would help the add-on modules a great deal.
Today a user is reporting failure to compile gstat against 5.4.0, with the
gstat configure:

if test -d $with_grass ; then
  AC_DEFINE(HAVE_LIBGIS)
  LIBS="$LIBS -L $with_grass/lib"
  INCLUDES="$INCLUDES -I$with_grass/include"
  AC_CHECK_LIB(grass_gis, G_gisinit, GISLIB="-lgrass_gis -lgrass_datetime",
   AC_CHECK_LIB(gis, G_gisinit, GISLIB="-lgis -ldatetime"))
  LIBS="$LIBS $GISLIB -lz"
fi

failing when $with_grass is set properly (I believe, and have tried it
myself) but /lib only has the *.so. This seems to be an example of the
problems of not having *.a installed when needed for development.

Roger

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no

14

I am trying to put together a build system
for building GRASS modules and libraries externally and
installing them into the binary installation tree.

As the recent discussion thread has shown, the necessary
libs and header files are being installed by recent
GRASS versions, so that this should in principle be possible.

Unfortunately, things seem to be a bit more complicated,
because the build system still has to take into account
some machine and OS dependent compile options,
different C compiler names and options etc.

Thus, I decided to strip down the original GRASS 6 configure
script, retaining only the most important checks and used
that as a starting point. In this way, I can "simulate" a
GRASS source environment with the most important parts
of the configuration system (Grass.make, Platform.make etc.)
intact. The aim is to make it possible to build modules
externally without making changes to the original
GRASS 6 style Makefiles.

It seems to me, that three path variables in the original
make system control where things take place

Source directory (SRCDIR): this is the starting point for locating include files and libs?
Build directory (DSTDIR): this is where the object files are stored?
Installation directory: this is where the final executable modules are copied to.

Am I right about the meaning of these?

In other news:

A new version of r.cva (cumulative viewsheds) for GRASS 6 is now finished and has been
tested. I have contacted the original author, Mark Lake, about the possibility of
releasing it under a GPL compatible license. I have not got an answer so far, but
I am told that Mark is really busy these days and I am sure he will look into this
and we will find a good solution for making r.cva more accessible to GRASS users.

Benjamin

15

On Wed, 16 Mar 2005, Benjamin Ducke wrote:

It seems to me, that three path variables in the original
make system control where things take place

Source directory (SRCDIR): this is the starting point for locating include files and libs?
Build directory (DSTDIR): this is where the object files are stored?
Installation directory: this is where the final executable modules are copied to.

Am I right about the meaning of these?

Yes that sounds right. I suppose at one stage the thinking was that you wouldn't need to re-run configure as you would assume the platform that the binaries were installed on was similar enough to the one that they had been compiled on, and including Platform.make in the binary distribution would be enough.

But if you are running configure why a cut-down one? What sort of things are you leaving out and why? This is an interesting little project.

In other news:

A new version of r.cva (cumulative viewsheds) for GRASS 6 is now finished and has been
tested. I have contacted the original author, Mark Lake, about the possibility of
releasing it under a GPL compatible license. I have not got an answer so far, but
I am told that Mark is really busy these days and I am sure he will look into this
and we will find a good solution for making r.cva more accessible to GRASS users.

That is really good news (although there was not much wrong with the original r.cva if you could live with having to frequently do little bits of data pre- and post-processing with r.null, s.to.rast etc.)

There was a paper in Photogrammetric Engineering & Remote Sensing a year or two ago (from CERL, actually) about a new very fast way of doing viewshed analysis that sounded like it would be a very nice project to implement using a vector graph structure to show direct paths between raster cells, and to make calculations using the Directed Graph library. But an accessible r.cva would make the line of sight capabilities in GRASS very usable indeed.

Paul

16

From: Benjamin Ducke <benducke@compuserve.de>
Sent: Wed, 16 Mar 2005 21:55:45 +0100

I am trying to put together a build system
for building GRASS modules and libraries externally and
installing them into the binary installation tree.

As the recent discussion thread has shown, the necessary
libs and header files are being installed by recent
GRASS versions, so that this should in principle be possible.

Unfortunately, things seem to be a bit more complicated,
because the build system still has to take into account
some machine and OS dependent compile options,
different C compiler names and options etc.

Have you thought about writing a grass-config executable to be included in the
grass binary?

Several packages do this: they use the @vars@ markers expected by autoconf in
a very simple executable that responds to options such as '--libs',
'--include' and so on. It is intended to be used like this (totally fictitious
example to give an idea):

$ gcc module.c `grass-config --include --libs` -o module

where grass-config, upon receiving --include --libs arguments, outputs (to
stdout) the string '-I/usr/include/grass -L/usr/lib/grass -lgrass', thus
giving all compiler options.

this scheme is used in gtk, gnome, wxWidgets and so on.

HTH, Daniel.

17

Daniel Calvelo Aros wrote:

From: Benjamin Ducke <benducke@compuserve.de>
Sent: Wed, 16 Mar 2005 21:55:45 +0100
> I am trying to put together a build system
> for building GRASS modules and libraries externally and
> installing them into the binary installation tree.
>
> As the recent discussion thread has shown, the necessary
> libs and header files are being installed by recent
> GRASS versions, so that this should in principle be possible.
>
> Unfortunately, things seem to be a bit more complicated,
> because the build system still has to take into account
> some machine and OS dependent compile options,
> different C compiler names and options etc.

Have you thought about writing a grass-config executable to be included in the
grass binary?

Several packages do this: they use the @vars@ markers expected by autoconf in
a very simple executable that responds to options such as '--libs',
'--include' and so on. It is intended to be used like this (totally fictitious
example to give an idea):

$ gcc module.c `grass-config --include --libs` -o module

It isn't quite this simple. GRASS consists of over 30 libraries, many
of which have external dependencies. It wouldn't be practical to
output the switches to link against every single GRASS library and
their dependencies.

At a minimum, you would need to supply a list of the libraries which
were required, e.g.

  gcc module.c `grass-config --include --libs gis display vector`

Such a script would be somewhat more complex than e.g. the gtk-config
script.

It would be better for external modules to use the GRASS Makefile
fragments from the include/Make directory. However, "make install"
would need to install them; also, the installed versions would need to
be processed to reflect the installed locations rather than the
build-time locations.

--
Glynn Clements <glynn@gclements.plus.com>