On Mon, 18 Oct 2004, Michael Barton wrote:
Markus,
I am remembering this discussion about finishing or not finishing the
kieging package better now, including Helena's note. This perhaps brings up
the chance to think strategically about the direction for GRASS development.
While there are always bugs to fix and tweaks to make, IMHO GRASS 5.7 is an
outstanding piece of spatial technology that goes well beyond most GIS
packages on the market. So, in which direction should future development
head. I think that the survey that will soon be posted will be helpful in
determining this. But here are a couple thoughts.
1) Improvement in the UI. Radim is working on merging GRASS with QGIS. This
is potentially exciting, especially with new display tools for vectors. We
also need to greatly simplify the installation procedure. An easy way to add
in special purpose packages (plugins in QGIS) without having to compile
could be a huge boost to development efforts.
2) Building on the volumetric tools. The beginning in GRASS is more than is
available in most other (any other?) GIS systems. The display tools need to
be integrated with NVIZ and we need more analysis and volume development
tools.
3) Improving the already rich set of spatial analysis tools with more
spatial analysis and geospatial statistics. There was a rich thread recently
dealing with developing tools for archaeological and geolophysical research.
Benjamin Ducke has started in this direction. A krieging package would be
another. Improvements and additions to packages for ecological analysis
(e.g., r.le) would also be desireable.
While I can agree with the first two (a bit unwillingly because I really
value the "paper trail" left in the readline history file when working at
the command line), I would argue that we should be cautious on 3). The
main reason is that linking tools seems to me a better option, because as
Glynn has (rightly) said, much of the GRASS codebase has not been used
much (at least recently), which means we just don't know if analysts
should use it. For me active analysis means having access to a scripting
language in which methods can be prototyped, and provides much more
immediate debugging than looking at the C or Tck/Tk code.
As things are now, especially after Edzer Pebesma's porting of gstat to S
(both S-PLUS and R), and after the release of R 2.0.0 with lazy loading of
packages, launching an R session from a batch file is fast and can do most
of what a hard-coded module can do (at least in principle).
Demonstrating this was why in an earlier post this evening I included
verbatim the code for s.kcv in R - for analysis, scripted interpreted
languages are the way to go until they are too slow for practical use.
Putting a GUI front end on a shell script calling R with a script is a
potentially cheap way of using calculation functions that are in daily use
by many people, and thus subject to just the kind of eyeballing Glynn was
refering to.
I think that getting the R-GRASS bridge to 5.4 is feasible, but I'd like
to invite others to join in for 5.7. Edzer, Barry Rowlingson and I will be
working together in Lancaster 2-5 November on classes for spatial data in
S/R, there is an online access point through http://www.r-project.org/Rgeo,
and contributions of ideas would be most welcome. The R-GRASS bridge now
contains a local copy of libes/gis/* files from about 5.0.2 with
modifications (raster and sites files). I hope to put that as is on
sourcefourge, and migrate to a version that links against 5.4 libgis,
before beginning a third version aimed at 5.7 and with the new class
support to interface vectors. Note that R is also getting Terralib support
- anybody else interested in Terralib?
Please accept that I do understand that linking to R is not an answer to
everything, but it isn't a bad answer to getting more analytical
functionality in a flexible way, which can be coded for speed later if
need be.
Roger
There are perhaps other strategic directions that others could add. I'd love
to see all the them, but realize that it will be necessary to prioritize.
Michael
On 10/18/04 2:24 AM, "Markus Neteler" <neteler@itc.it> wrote:
> On Sun, Oct 17, 2004 at 08:25:22PM +0100, Paul Kelly wrote:
>> Hello Michael
>>
>> On Sun, 17 Oct 2004, Michael Barton wrote:
>>
>> [...]
>>> Since GRASS doesn't have a krieging interpolator,
>>
>> s.surf.krig?
>> http://freegis.org/cgi-bin/viewcvs.cgi/grass/src/sites/s.surf.krig/
>> http://www.geog.uni-hannover.de/grass/gdp/html_grass5/html/s.surf.krig.html
>>
>> Looks substantial enough but I wonder what the problem with it is. Is it
>> just another module that was disabled and forgotten like s.kcv, m.in.ntf
>> or is there a more serious problem?
>
> Some clues here:
> http://grass.itc.it/pipermail/grass5/2000-September/011898.html
> http://grass.itc.it/pipermail/grass5/2000-September/011895.html
>
> AFAIK the update/rewrite wasn't finished.
>
> Have a look also here:
> http://intevation.de/rt/webrt?serial_num=256
> "Helena wrote:
>> #256 s.surf.krig - kriging is much better served by linking with geostats
>> packages as you need lots of additional tools to make it really useful -
>> GSTATS and R-stats would be much better for that. Unless somebody wants to
>> undertake major geostatistics developments fully integrated with GRASS
>> (inclding s.sv and other tools) I suggest retiring it and rather work on
>> improvements and education for R-stats bridge and GSTATS link"
>
>
> Markus
>
>
>
____________________
C. Michael Barton, Professor of Anthropology
School of Human, Cultural, 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>
_______________________________________________
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