Hi all
I am looking for a web based tool to display, manage Grass data and operate Grass functions.
Does such a tool exists?
If not, It possible to make such a tool, through mapserver for example?
Any comments welcome
Christian
Christian,
You can use Frank Warmerdam's GDAL library (www.remotesensing.org/gdal) to access GRASS datasets with MapServer. To do so you have to:
- compile GDAL with libgrass
- compile MapServer with this GDAL library
You can only display finished GRASS raster maps this way. If you want to operate on GRASS data via a web server, it should be possible to write PHP scripts to do so. The results of these operations can then be displayed by MapServer. I don't know if anyone has tried this out already.
Both the GDAL and MapServer sites offer precompiled binaries for Windows. I don't know if these include the GRASS link.
There are some recent postings on the mapserver-users list on using GRASS datasets with MapServer. See for example the thread from http://mapserver.gis.umn.edu/data2/wilma/mapserver-users/0304/msg00055.html
Jan
Christian Blumer wrote:
Hi all
I am looking for a web based tool to display, manage Grass data and operate Grass functions.
Does such a tool exists?
If not, It possible to make such a tool, through mapserver for example?
Any comments welcome
Christian
Jan Hartmann
Department of Geography
University of Amsterdam
jhart@frw.uva.nl
Hello list,
I just compiled Grass5.0.2 as a non-root user (i.e. with all binaries and libraries installed in my $HOME directory). All suporting packages, like Mesa and TclTK are also installed in $HOME. Everything works beautiful, except nviz. When I call it from the tcltk interface, I get a popup for specifying the input maps, but after that an error message pops up: "/home/.../grass5/tcltkgrass/main/pause: nviz: command not found". Before I start delving in the source code, has anyone an idea how to correct this? It's probably a trifle.
Jan Hartmann
Department of Geography
University of Amsterdam
jhart@frw.uva.nl
Hi,
Maybe Grasslinks is a choice. You can use Grasslinks to display and
operate your Grass data via web. It require some programming skill.
But not so many.
Here is the URL that you can view some demos and download the source
code.
http://www.regis.berkeley.edu/grasslinks/
Good luck.
Xueming
On Wed, 7 May 2003, Christian Blumer wrote:
Hi all
I am looking for a web based tool to display, manage Grass data and operate Grass functions.
Does such a tool exists?
If not, It possible to make such a tool, through mapserver for example?
Any comments welcome
Christian
Christian Blumer wrote:
> I am looking for a web based tool to display, manage Grass data and operate Grass functions.
> Does such a tool exists?
> If not, It possible to make such a tool, through mapserver for example?
The generally excellent Neteler and Mitasova (2002) includes
a section on the GRASS/MapServer interface in Chapter 13:
13. Using GRASS with other Open Source tools
* Maps in WWW: MapServer
I am not familiar enough with MapServer or web-based map
applications to know if the material in the book is
sufficient, but my experience with the book has been overall
very good.
M. Neteler, H. Mitasova, 2002. Open Source GIS: A GRASS GIS
Approach. 464 pages, Kluwer Academic Publishers, Boston,
Dordrecht, ISBN 1-4020-7088-8.
Best regards,
Michael Ash, Assistant Professor
of Economics and Public Policy
Department of Economics and CPPA
University of Massachusetts
Amherst, MA 01003
Tel 413-545-6329 Fax 413-545-2921
Email mash@econs.umass.edu
http://people.umass.edu/maash
> I am looking for a web based tool to display, manage Grass data and operate Grass functions.
> Does such a tool exists?
> If not, It possible to make such a tool, through mapserver for example?
On Wed, 7 May 2003, Xueming Wu wrote:
Maybe Grasslinks is a choice. You can use Grasslinks to display and
operate your Grass data via web. It require some programming skill.
But not so many.Here is the URL that you can view some demos and download the source code.
http://www.regis.berkeley.edu/grasslinks/
I just checked out grasslinks and it's really cool. The
advanced options are extremely good.
You might also want to look at the GRASS-MapServer demo:
http://grass.itc.it/start.html
Best,
Michael Ash, Assistant Professor
of Economics and Public Policy
Department of Economics and CPPA
University of Massachusetts
Amherst, MA 01003
Tel 413-545-6329 Fax 413-545-2921
Email mash@econs.umass.edu
http://people.umass.edu/maash
Jan Hartmann wrote:
I just compiled Grass5.0.2 as a non-root user (i.e. with all binaries
and libraries installed in my $HOME directory). All suporting packages,
like Mesa and TclTK are also installed in $HOME. Everything works
beautiful, except nviz. When I call it from the tcltk interface, I get a
popup for specifying the input maps, but after that an error message
pops up: "/home/.../grass5/tcltkgrass/main/pause: nviz: command not
found". Before I start delving in the source code, has anyone an idea
how to correct this? It's probably a trifle.
It appears that NVIZ failed to compile; error.log should confirm this.
The actual error message(s) will be in the output from "make"; if you
didn't redirect it to a file, re-run make and save the output, e.g.
"make &> build.log" (re-running make doesn't take long if everything
is already built).
--
Glynn Clements <glynn.clements@virgin.net>
Thanks Glynn, that was it. NVIZ compilation aborted with:
In file included from nvizAppInit.c: 9
interface.h:257: conflicting types for `TkSetAppName'
/home/.../include/tkDecls.h: 573: previous declaration of `TkSetAppName'
I'm using tcl/tk 8.4.2
I commented out the offending line in interface.h, and now everything compiles fine. However, I still can't start nviz from GRASS; it doesn't seem to get installed. I reran gmake5 -i and gmakelink5 -i from the NVIZ subdirectory, without errors, but also without getting a running nviz. What's wrong?
Jan
Glynn Clements wrote:
Jan Hartmann wrote:
I just compiled Grass5.0.2 as a non-root user (i.e. with all binaries and libraries installed in my $HOME directory). All suporting packages, like Mesa and TclTK are also installed in $HOME. Everything works beautiful, except nviz. When I call it from the tcltk interface, I get a popup for specifying the input maps, but after that an error message pops up: "/home/.../grass5/tcltkgrass/main/pause: nviz: command not found". Before I start delving in the source code, has anyone an idea how to correct this? It's probably a trifle.
It appears that NVIZ failed to compile; error.log should confirm this.
The actual error message(s) will be in the output from "make"; if you
didn't redirect it to a file, re-run make and save the output, e.g. "make &> build.log" (re-running make doesn't take long if everything
is already built).
Jan Hartmann wrote:
Thanks Glynn, that was it. NVIZ compilation aborted with:
In file included from nvizAppInit.c: 9
interface.h:257: conflicting types for `TkSetAppName'
/home/.../include/tkDecls.h: 573: previous declaration of `TkSetAppName'I'm using tcl/tk 8.4.2
I commented out the offending line in interface.h, and now everything
compiles fine. However, I still can't start nviz from GRASS; it doesn't
seem to get installed. I reran gmake5 -i and gmakelink5 -i from the NVIZ
subdirectory, without errors, but also without getting a running nviz.
What's wrong?
I don't know; I suggest re-running "make" and "make install".
--
Glynn Clements <glynn.clements@virgin.net>
Glynn Clements wrote:
I don't know; I suggest re-running "make" and "make install".
Yes, now it runs. Thanks.
Jan
Hi,
I am running r.mapcalc on the LandScan world population database (www.ornl.gov/gist/projects/LandScan). This is a 4 byte, 43.200*20.800 raster, and I use mapcalc to recategorize it to a one byte, 256 valued raster, according to some different categorizing algorithms (essentially variations on histogram equalisation). The category boundaries have been computed separately; the only thing r.mapcalc has to do is to apply them to the input raster. The mapcalc script only consists of a few dozens of "if" rules, but these take a very long time to execute (days). My impression is that r.mapcalc evaluates every rule for every cell. Does anyone know if this is the case, and if so, is there a way to stop evaluation after a match has been found (something like an "else" statement)?
Jan
Jan Hartmann wrote:
Glynn Clements wrote:
I don't know; I suggest re-running "make" and "make install".
Yes, now it runs. Thanks.
Jan
Jan Hartmann
Department of Geography
University of Amsterdam
Jan Hartmann wrote:
I am running r.mapcalc on the LandScan world population database
(www.ornl.gov/gist/projects/LandScan). This is a 4 byte, 43.200*20.800
raster, and I use mapcalc to recategorize it to a one byte, 256 valued
raster, according to some different categorizing algorithms (essentially
variations on histogram equalisation). The category boundaries have been
computed separately; the only thing r.mapcalc has to do is to apply them
to the input raster. The mapcalc script only consists of a few dozens of
"if" rules, but these take a very long time to execute (days). My
impression is that r.mapcalc evaluates every rule for every cell. Does
anyone know if this is the case, and if so, is there a way to stop
evaluation after a match has been found (something like an "else"
statement)?
The overall evaluation strategy is that r.mapcalc processes one row at
a time. Each function (e.g. "if") takes a row of cells (i.e. a
one-dimensional array) as input, and stores the results in a result
array. For nested expressions, the array which holds the result from
an inner term is passed as an input to the enclosing term. Once the
final result has been computed for a row, the row is written out and
computation starts on the next row.
I suspect that your problem stems from the fact that the "if" function
is strict; i.e. all of the arguments are computed, passed to the
function, then one of the arguments is returned. Any time spent
computing the unused argument is effectively wasted.
This contrasts with general-purpose programming languages, where the
"if" construct is lazy; i.e. the condition is evaluated first, and
only one of the alternatives is evaluated.
r.mapcalc doesn't provide a lazy conditional mechanism. For
general-purpose programming languages, a lazy conditional is
absolutely necessary in order to be able to define recursive
functions. As r.mapcalc doesn't allow you to define your own functions
(recursive or otherwise), this isn't an issue.
For r.mapcalc, a lazy conditional would only be an optimisation; it
wouldn't extend the set of possible computations, but would just make
some of them faster.
I appreciate that this particular optimisation might be of substantial
benefit to you personally, but it would require significant changes to
r.mapcalc. Currently, *all* functions are strict; the core evaluation
code would need to be extended to allow for lazy functions generally
before you could implement any specific lazy function.
Consequently, such an extension isn't likely to be implemented any
time soon. In the absence of any other options, you could just add
your categorisation function to r.mapcalc itself. Adding new functions
is relatively straightforward; I can provide assistance if you wish to
take that route.
--
Glynn Clements <glynn.clements@virgin.net>
Ok, very clear answer, thanks. Good to know that this is indeed the bottleneck. I'll write a C function in Grass to do my recategorization. Shouldn't be much work.
Knowing this, I don't think implementing "lazy" function in Grass itself is a good idea. It would change Grass's behavior. With r.mapcalc for example, if two if-expressions overlap, I guess the result now is the last one, and with lazy evaluation the first. This would without any doubt cause endless problems with existing applications.
Jan
Glynn Clements wrote:
Jan Hartmann wrote:
I am running r.mapcalc on the LandScan world population database (www.ornl.gov/gist/projects/LandScan). This is a 4 byte, 43.200*20.800 raster, and I use mapcalc to recategorize it to a one byte, 256 valued raster, according to some different categorizing algorithms (essentially variations on histogram equalisation). The category boundaries have been computed separately; the only thing r.mapcalc has to do is to apply them to the input raster. The mapcalc script only consists of a few dozens of "if" rules, but these take a very long time to execute (days). My impression is that r.mapcalc evaluates every rule for every cell. Does anyone know if this is the case, and if so, is there a way to stop evaluation after a match has been found (something like an "else" statement)?
The overall evaluation strategy is that r.mapcalc processes one row at
a time. Each function (e.g. "if") takes a row of cells (i.e. a
one-dimensional array) as input, and stores the results in a result
array. For nested expressions, the array which holds the result from
an inner term is passed as an input to the enclosing term. Once the
final result has been computed for a row, the row is written out and
computation starts on the next row.I suspect that your problem stems from the fact that the "if" function
is strict; i.e. all of the arguments are computed, passed to the
function, then one of the arguments is returned. Any time spent
computing the unused argument is effectively wasted.This contrasts with general-purpose programming languages, where the
"if" construct is lazy; i.e. the condition is evaluated first, and
only one of the alternatives is evaluated.r.mapcalc doesn't provide a lazy conditional mechanism. For
general-purpose programming languages, a lazy conditional is
absolutely necessary in order to be able to define recursive
functions. As r.mapcalc doesn't allow you to define your own functions
(recursive or otherwise), this isn't an issue.For r.mapcalc, a lazy conditional would only be an optimisation; it
wouldn't extend the set of possible computations, but would just make
some of them faster.I appreciate that this particular optimisation might be of substantial
benefit to you personally, but it would require significant changes to
r.mapcalc. Currently, *all* functions are strict; the core evaluation
code would need to be extended to allow for lazy functions generally
before you could implement any specific lazy function.Consequently, such an extension isn't likely to be implemented any
time soon. In the absence of any other options, you could just add
your categorisation function to r.mapcalc itself. Adding new functions
is relatively straightforward; I can provide assistance if you wish to
take that route.